# 7.2.9.4.3. Déploiement d’un cluster de production

En environnement de production, la tolérance aux pannes doit être prévue. Avec trois membres par `ReplicaSet`, le niveau de tolérance aux pannes est satisfaisant : si le noeud primaire n’est plus disponible, le système provoque une élection au sein du `ReplicaSet`, permettant alors à un noeud secondaire de devenir noeud primaire. Dans cette situation, si le nouveau noeud primaire devient indisponible, il ne restera plus qu’un seul noeud disponible pour disposer d’un noeud primaire et la situation devient alors critique (par rapport à la disponibilité de la donnée). Pour autant, dans le cas ou un noeud primaire et un seul noeud secondaire sont disponibles, la consistance de la donnée n’est potentiellement plus assurée, puisque les mécanismes configurés avec la valeur `Majority` ne permettent plus une vérification de la réplication : la majorité correspond à un membre, et donc uniquement le membre `Primary` acquitera l’écriture. Aussi, dans ce cas, si le membre primaire devient indisponible après une écriture et avant la réplication, lorsque le dernier membre disponible devient primaire, l’écriture n’a pas été répliquée. Dans le cas nominal ou les deux membres secondaires étaient disponibles, c’est le membre qui a réalisé l’acquitement de la replication qui devient primaire (dans les faits, le membre secondaire le plus à jour vis à vis de la réplication) et alors l’écriture a bien été prise en compte.

Une tolérance aux pannes plus importante peut être mise en place en déployant un quatrième membre. Et afin de respecter un nombre impair de membres déployés, il est possible de déployer un cinquième membre qui ne consomme pas autant de ressources matérielles qu’un membre actif et dont la responsabilité n’est d’intervenir que dans l’élection d’un noeud primaire. Ce type de membre est nommé membre `Arbiter`. La topologie de déploiement du `ReplicaSet` est alors nommée `PSSSA`, pour illustrer le déploiement d’un membre `Primary`, de 3 membres `Secondary` et d’un membre `Arbiter`.

L’indisponibilité d’un noeud peut être liée à différentes causes : un problème matériel provoquant un `crash` du processus, mais pour lequel le service sera redémarré automatiquement suite à l’incident (faute de mémoire, faute d’accès disque durant l’écriture, …); ou un problème matériel important provoquant la perte de la machine physique et pour lequel le service ne pourra pas redémarrer (provisionning virtuel, coupure éléctrique, …). Aussi, il est important de déployer les membres d’un `replicaSet` dans des zones matérielles différentes. Dans le cas, d’un environnement virtuel opéré physiquement par différentes machines, il est opportun de spécifier un provisionning physique afin d’assurer une répartition physique des machines.

Pour augmenter véritablement la tolérance aux pannes, en plus d’augmenter le nombre de membre d’un `ReplicaSet` correctement réparti physiquement, il est recommandé de déployer un environnement de production constitué de deux salles physiquement indépendantes (alimentation éléctrique, droits d’accès, …) et pour lesquelles les communications réseaux sont autorisées et resteront performantes. Il s’agit bien la, de discerner le cas du site secondaire prévu dans le système Vitam, notamment pour gérer la criticité de la perte d’une offre de stockage. Dans ce scénario, il est recommandé que ce second site soit géographiquement distant du premier, de plusieurs dizaines de kilomètres. Aussi, les performances réseaux entre les deux sites pourraient être insuffisante au regard des performances attendues dans le cluster MongoDB.

Pour réaliser le déploiement du cluster `mongodb-data`, en mode `PSS`, composé de 3 machines hebergeant les services `vitam-mongos` et `vitam-mongoc` et de 6 machines hebergeant le service `vitam-mongod` (pour disposer de 2 `Shards`), l’inventaire ansible doit référencer les 3 premières machines pour les groupes `hosts-mongos-data` et `hosts-mongoc-data` et les 6 autres machines pour le groupe `hosts-mongod-data`. Le paramètre `mongo_shard_id` spécifie le regroupement des machines dans le même `ReplicaSet` et identifie un numéro de `Shard`. Le paramètre `mongo_rs_bootstrap` spécifie la machine sur laquelle l’initialisation du `ReplicaSet` sera réalisée (voir command rs.initiate()). Les autres machines du `ReplicaSet` y seront alors ajoutées (voir commande rs.add()).

Exemple

    [hosts-mongodb-data:children]
    hosts-mongos-data
    hosts-mongoc-data
    hosts-mongod-data

    [hosts-mongos-data]
    host1.vm    mongo_cluster_name=mongodb-data
    host2.vm    mongo_cluster_name=mongodb-data
    host3.vm    mongo_cluster_name=mongodb-data                    mongo_rs_bootstrap=true

    [hosts-mongoc-data]
    host1.vm    mongo_cluster_name=mongodb-data
    host2.vm    mongo_cluster_name=mongodb-data
    host3.vm    mongo_cluster_name=mongodb-data                    mongo_rs_bootstrap=true

    [hosts-mongod-data]
    host4.vm    mongo_cluster_name=mongodb-data  mongo_shard_id=0
    host5.vm    mongo_cluster_name=mongodb-data  mongo_shard_id=0
    host6.vm    mongo_cluster_name=mongodb-data  mongo_shard_id=0  mongo_rs_bootstrap=true
    host7.vm    mongo_cluster_name=mongodb-data  mongo_shard_id=1
    host8.vm    mongo_cluster_name=mongodb-data  mongo_shard_id=1
    host9.vm    mongo_cluster_name=mongodb-data  mongo_shard_id=1  mongo_rs_bootstrap=true

Le déploiement d’un cluster `mongodb-offer` en mode `PSS` suit les mêmes règles que l’exemple illustré ci-dessus (les groupes ansible ne sont pas les mêmes).