7.2.9.3.1. Présentation

Le composant vitam-mongod représente le service de données du cluster MongoDB déployé. Techniquement, il s’agit d’une instance du serveur de la base de données MongoDB (processus mongod) qui détient les bases et collections Vitam. Des bases et collections de configuration sont aussi présentes pour le fonctionnement de la solution MongoDB.

Prudence

Il est fortement recommandé de ne pas modifier ces collections, excepté lorsqu’un mode opératoire Vitam le mentionne ou à la demande explicite de l’éditeur de la base MongoDB.

Ce service est déployé, comme le service vitam-mongoc, sous forme de ReplicaSet (voir le paragraphe précédent pour plus d’explication).

Pour gérer de grosses volumétries, les services mongod sont déployés de manière à pouvoir gérer un sous ensemble de données, afin de répartir la charge d’utilisation. Ce concept est nommé Sharding et le ReplicaSet représente alors un sous-ensemble des données gérées par le cluster (pour les collections dites shardées). Ce sous-ensemble est nommé Shard et ce concept est utilisé dans la configuration du cluster. Une collection non shardée sera disponible sur un unique Shard.

Dans Vitam, les collections des bases metadata et logbook de mongodb-data (exceptée la collection Operation) sont shardées, car la dimension de leur volume est estimée importante (plusieurs millions ou milliards). Les collections des bases identity, masterdata et report ne sont pas shardées.

Dans le cadre d’une offre « froide », la collection TapeAccessRequestReferential de la base offer de mongodb-offer est également shardée. Les autres collections ne sont pas shardées.

Dans le cas de mongodb-data, les ressources machines allouées à ce service doivent être relativement importantes en fonction de :

• la volumétrie et du débit des versements d’archives dans le système :

  Plus le système est sollicité, notamment dans le cas du versement, plus les clusters MongoDB, et donc les services vitam-mongod, sont sollicités. Les composants Vitam qui éméttent les requêtes vers le cluster mongodb-data sont metadata, logbook et functional-administration. Vers le cluster mongodb-offer, seul le composant offer émet les requêtes.

  Le nombre de requêtes émises vers un cluster est dépendant du nombre de composant vitam-worker déployé dans le système ainsi que du paramètre qui spécifie le nombre de worker exécutant une tâche Vitam au sein d’un composant (Thread dans la jvm).

  En fonction de la distribution des tâches, opérée dans le composant vitam-processing, du nombre de versement en parallèle et du nombre d’unité archivistique par SIP, un certain nombre de worker vont émettre des requêtes en parallèle.

  Différentes optimisations ont été réalisées dans les tâches Vitam, pour notamment, diminuer le nombre de requêtes vers les clusters MongoDB, en privilégiant une requête en mode bulk. Aussi, avec ces optimisations, les services vitam-mongod sont bien plus sollicités. Toutefois, si le nombre d’unité archivistique positionnées dans les SIP est trop faible, le nombre de requête par bulk est réduit. Les recommendations des paramètres et de l’utilisation du système de manière efficiente sont détaillées dans un autre document.

  Le nombre de vCPU disponible pour le service vitam-mongod influe sur les performances d’exécution en parallèle des requêtes MongoDB. Dans le cas des versements, la sollicitation des clusters MongoDB est essentiellement liée à des requêtes d’écriture. Dans ce mode, l’utilisation des index MongoDB ainsi que la lecture des documents en base sont limitées. Et donc dans ce contexte, la quantité de RAM disponible pour les index et pour les caches de document (workingSet MongoDB) ne doit pas être nécessairement importante.

• des fonctionnalités Vitam utilisées :

  Le versement d’archive est une fonctionnalité importante du système pour laquelle la sollicitation des clusters MongoDB est majoritairement liée à des requêtes d’écriture. D’autres fonctionnalités Vitam, comme la consultation d’archives ou la réalisation de DIP, la sécurisation des opérations et données ingérées par le système, ou tout autre traitement en masse qui nécessite un accès aux documents, sollicitent le cluster mongodb-data avec des requêtes de lecture.

  Dans Vitam, un paradigme d’architecture est posé et est respecté par l’ensemble des composants (sauf exceptions cités ci-après) : toute requête sur les données qui nécessite un filtre sur les métadonnées, est executée dans le moteur de recherche ElasticSearch, afin de récuperer une liste d’identifiants de documents à requêter dans MongoDB. Ce pattern permet en outre de limiter le nombre d’index à créer dans MongoDB.

  Aussi, dans le cas des accès aux documents, les performances seront réduites lorsque les identifiants des documents requêtés ne seront plus indexés en RAM (cas ou la quantité de RAM nécessaire pour contenir l’ensemble des index en mémoire est insuffisante) et surtout lorsque le document ne sera plus disponible dans le cache. Si les données ne sont plus disponibles en mémoire, le moteur MongoDB doit procéder à des lectures sur disque en remplaçant les données les plus anciennes par les nouvellement lues. Ce mécasnime (evictions page) est utilisé pour les index et les documents.

  Le cas particulier des sécurisations, sollicitent les clusters MongoDB en lecture, sans passer par le moteur de recherche (pour des raisons de sécurité et d’intégrité de la donnée). Elles utilisent un index supplémentaire directement dans MongoDB. Aussi, dans ce contexte, pour assurer de bonnes performances à ces opérations, il faut veiller à dimensionner le cache des documents suffisament important pour conserver les documents, et index liés aux documents, qui ont été ingérés par le système et qui n’ont pas encore été sécurisés.

  Par défaut, les sécurisations des cycles de vie des métadonnées archivistiques et des opérations Vitam sont executées toutes les 2 ou 3 heures. Durant cette période, un versement d’un million d’AU nécessitera l’utilisation d’un million de clé (identifiant Mongo et identifiant de sharding) dans les index, soit une centaine de Mo, et nécessitera l’utilisation d’un million de documents dans le cache, soit 5,7 Go.

  La quantité de RAM disponible pour le service vitam-mongod influe sur les performances d’exécution des requêtes MongoDB. Dans le contexte des fonctionnalités citées, la quantité de RAM doit être importante. La recommendation Vitam est d’allouer la quantité de RAM nécessaire pour traiter au minimum les sécurisations des documents versées dans les dernières heures, afin de ne pas ralentir le système avec ces opérations. Par exemple, pour des versements à 450.000 AU/h, les sécurisations LFC AU et GOT, et Opérations, nécessiteront environ 12 Go de RAM (quantité répartie sur l’ensemble des Shards).

Dans le cas de mongodb-offer, les ressources machines allouées à ce service sont modérément élevés, excepté le cas des offres froides où l’utilisation des ressources peut être plus conséquente, en fonction des traitements en cours.

Note

Par défaut, 50% de la RAM disponible est allouée au processus mongod pour gérer les index et caches de document, de manière à laisser disponible en cache OS les données lues sur disque (blocs des fichiers de données MongoDB).

Avertissement

Les performances du cluster MongoDB, en écriture ou lecture, restent dépendantes de la performance des disques. Il est recommandé de privilégier une infrastructure avec des disques physiques attachés aux machines qui déploient les services mongod. A défaut d’une telle configuration, il est recommandé d’octroyer la meilleure qualité de service de l’offre disque utilisée (débit ou priorité d’accès).