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).