7.2.9.2.1. Présentation

Le composant vitam-mongoc représente le service de configuration 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 des bases et collections de configuration.

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 composant est déployé sous forme de ReplicaSet, c’est à dire un groupe de serveurs qui détiennent les mêmes données, afin de permettre une haute disponibilité du service ainsi qu’une réplication des données gérées.

A un instant donné, un serveur est identifié comme Master tandis que les autres serveurs sont identifiés comme Slave. Un serveur est appellé membre (d’un ReplicaSet). La réplication des données est réalisée, au travers d’une communication Master/Slave, sur les serveurs Slave, en reprenant les opérations (OpLog) réalisées sur le serveur Master. Le serveur Master est nommé membre Primary et les serveurs Slave sont nommés membres Secondary. Un mécanisme de vérification du statut d’un membre permet de gérer la haute disponibilité : si le membre Primary devient indisponible, un membre Secondary sera élu pour devenir Primary. Ces concepts sont utilisés dans la configuration du cluster.

Toutes les requêtes d’écriture sont réalisées uniquement sur le membre Primary, alors que les requêtes de lecture peuvent aussi être réalisées sur les membres Secondary. Pour gérer la consistance de la donnée entre les membres (concept eventual consistency), un mécanisme permet d’acquitter une écriture lorsque le membre Primary a pris en compte l’écriture (écris dans les logs d’opérations), et éventuellement lorsque l’écriture a été répliquée sur un, des ou l’ensemble des membres Secondary. Les requêtes Vitam sont executées avec ce mécanisme, configuré pour qu’une majorité de membre retourne un acquittement (voir Write Concern valué à Majority). Le même mécanisme existe pour les lectures, à savoir, qu’une lecture peut éventuellement être vérifiée sur plusieurs membres afin d’assurer la consistance de la lecture. La encore, les requêtes Vitam sont executées avec ce mécasnime, configuré pour qu’une majorité de membres confirme disposer de la même donnée (voir Read Concern valué à Majority). Les paramètres Write Concern et Read Concern positionnés à Majority permettent de configurer le niveau de consistance d’un ReplicaSet en jouant uniquement sur le nombre de membres déployés dans un ReplicaSet. Ces paramètres ne sont donc pas modifiables vis à vis des fichiers de paramétrage Vitam.

Le déploiement standard d’un ReplicaSet en production, est composé de 3 membres. Cet exemple de déploiement est nommé PSS, pour illustrer la composition du ReplicaSet avec des membres Primary Secondary Secondary. Avec cette topologie, les mécanismes pour garantir la consistance de la donnée (configurés avec la valeur Majority) permettent de s’assurer que la donnée est pris en compte par 2 membres (sur les 3).

Note

cette configuration permet une tolérance aux pannes satisfaisante. Toutefois, il est possible d’améliorer cette tolérance en ajoutant des membres. Consulter la documentation officielle pour plus de détail : https://docs.mongodb.com/manual/core/replica-set-architectures/.

La charge estimée du service mongoc est faible, aussi les ressources machines allouées peuvent être réduites (par exemple, 2 vCPU / 4 Go RAM).

Note

les tests de performance du système ont montrés que la colocalisation des services vitam-mongos et vitam-mongoc sur la même machine n’a pas d’impact.