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.

.. caution:: 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.