5.11.16. Mongodb

Base de données dédiée aux données métier, ainsi qu’aux données de suivi d’écriture dans les offres (archivelog).

Type :
COTS
Données stockées :
  • Données d’archives
  • Journaux métier
  • Référentiels métier
  • (mongo-offer) Offset d’écriture dans les offres
Typologie de consommation de ressources :
  • CPU : moyenne
  • Mémoire : forte
  • Réseau : forte
  • Disque : forte

5.11.16.1. Architecture de déploiement

5.11.16.1.1. Architecture 1 noeud

L’architecture à 1 noeud est uniquement constituée d’un noeud mongod ; elle n’est pas supportée par VITAM.

5.11.16.1.2. Architecture distribuée

Une architecture MongoDB distribuée utilise les notions suivantes :

  • Sharding
    • Mongodb utilise le sharding pour scaler la base de données (scalabilité horizontale)
    • Le sharding distribue les données à travers les n partitions physiques (shards) dont le cluster est composé
    • Bien choisir la clé de sharding est primordial pour une répartition égale des documents insérés dans les différents shards
    • Chaque shard est composé d’un Replica Set
  • Replica Set (RS)
    • Les Replica Sets assurent la haute disponibilité de Mongodb
    • Un Replica Set est (règles Mongodb de production) composé de 2 x n + 1 noeuds, avec n >= 1 (1 noeud primaire, les autres étant des noeuds secondaires) ; le noeud primaire est choisi de manière arbitraire par MongoDB dans la liste des noeuds du Replica Set
    • L’écriture se fait obligatoirement sur le noeud primaire
  • Replica Set de config
    • Un Replica Set est dédié pour le stockage de la configuration du cluster
    • Comme tous les autres Replica Sets, il est recommandé de le peupler de 2 x n + 1 noeuds, avec n >= 1
  • Routeur de requêtes
    • Le routeur mongos permet de rediriger une requête sur le ou les shards requis, en fonction de la clé de sharding ; il agit comme coordinateur de requête

Une architecture MongoDB distribuée comprend 3 types de noeuds différents :

  • mongod : stockent les données des Replica Sets métier ;
  • mongos : routent les requêtes ;
  • mongoc : stockent les données d’état et de configuration du cluster (ces noeuds utilisent en fait un moteur mongod, mais pour un Replica Set particulier : le Replica Set de configuration).
../../_images/mongo-cluster.svg

Déploiement d’un cluster Mongo DB avec sharding.

L’architecture proposée dans le cadre de VITAM consiste à séparer les noeuds liés au routage des requêtes et de gestion du cluster d’une part (donc de colocaliser mongos et mongoc), avec les noeuds de stockage des données (mongod) d’autre part.

Ainsi, avec n shards et r noeuds par Replica Set (cluster), on obtient le déploiement suivant :

  • au moins 3 serveurs config / service, chacun hébergeant:

    • 1 noeud mongos (service)
    • 1 noeud mongoc (Replica Set de configuration)

  • n x r serveurs, chacun hébergeant:

    • 1 noeud mongod

Note

Une typologie de cluster complète (mongos, mongoc, mongod) est systématiquement déployée dans le cadre de la solution logicielle VITAM, cela afin de permettre une extension ultérieure du cluster par le rajout d’un nouveau shard et le rééquilibrage du cluster, et ce même si un seul shard est instancié au démarrage.

Prudence

Une colocalisation des composants (mongos, mongoc & mongod) reste possible dans un déploiement avec un seul shard; cette colocalisation n’est plus possible dans le cas d’un déploiement multi-shardé et il sera nécessaire d’avoir des noeuds dédiées (mongos & mongoc) et des noeuds dédiés pour chacun des shards (mongod) selon les recommandations précédentes.

5.11.16.1.3. Ports utilisés

Les ports utilisés par mongodb sont les suivants:

  • tcp:27017 : Port de communication pour les noeuds mongos
  • tcp:27018 : Port d’écoute des noeuds du Replica Set de config (mongoc)
  • tcp:27019 : Port d’écoute des noeuds du/des Replica Set(s) de données (mongod)