7.2.9.4.1. Présentation

Les clusters MongoDB déployés dans la solution Vitam sont par défaut, et obligatoirement, configurés pour supporter le sharding des bases de données metadata, logbook et offer. Aussi, les composants vitam-mongos, vitam-mongoc et vitam-mongod sont configurés pour fonctionner ensemble. Le déploiement automatique d’une mono-instance MongoDB (un seul et unique serveur mongod) n’est pas supporté.

Les topologies de déploiement des services mongos, ainsi que des ReplicaSet des services mongoc et mongod, restent à la main de l’administrateur technique Vitam. Les choix sont réalisés lors de l’installation de la solution Vitam, mais peuvent être modifiés à posteriori (avec potentiellement des temps de migration de données à prévoir).

Le nombre de composants vitam-mongos peut varier au cours de l’utilisation du système sans contrainte particulière. Le nombre de Shards déployés, lui par contre, s’il varie, impliquera des migrations de données, réalisées en tâche de fond. Les choix opérés par les concepteurs de la base de données MongoDB ne peuvent pas être modifiés mais permettent une migration sans altérer les performances du système. Un paragraphe entier détaille ce scénario ainsi que les contraintes et temps nécessaires à la réalisation complète de l’opération.

Le nombre de composants par ReplicaSet des services mongoc et mongod reste aussi un choix à la main de l’administrateur technique et peut aussi varier dans le temps. Il est aussi assujetti à une opération plus ou moins longue de synchronisation des données. Il est important de respecter la contrainte MongoDB concernant le choix du nombre de membres d’un ReplicaSet. Pour des raisons liées à l’algorithme de l’élection d’un membre primaire, parmis les membres d’un ReplicaSet (confère documentation officielle https://docs.mongodb.com/manual/core/replica-set-elections/), ce nombre doit être impair.

La tolérance aux pannes est directement liée au choix du nombre de membres déployés par ReplicaSet et particulièrement à la redondance physique des composants et équipements réseaux qui assurent la communication entre eux. Aussi, le coût de déploiement, en ressources matérielles, est extrêmement lié au niveau de tolérance selectionné. Etant donné, la consommation importante des ressources matérielles par les services mongoDB (notamment en RAM), une option est laissée à la main de l’administrateur technique, pour configurer un ReplicaSet dans un mode particulier, nommé PSSmin, sans modifier le niveau de tolérance aux pannes. Ce point est détaillé ci-après.

Dans Vitam, la gestion du risque de la perte de données est centralisée au niveau des offres. Si un incident intervient sur le cluster mongodb-data provoquant une perte totale du service, un processus de reconstruction est prévu. Toutefois, il est important de noter que ce processus nécessite un temps relativement important, fonction de la volumétrie des données dans le système. Un autre processus de reconstruction du cluster mongodb-offer est prévu mais uniquement pour les offres chaudes. Dans le cas d’une offre froide, la reconstruction du cluster est réalisée par l’opération de restoration de la dernière sauvegarde réalisée sur le cluster.