Page History

Introduction

Remarques préliminaires

Lexique

Dans cette documentation est décrite de manière détaillée comment mettre en place des mécanismes de haute disponibilité pour la base Mongo.

Avant d'aborder les étapes de configuration et les détails techniques, cette section présente quelques points importants à savoir avant de continuer.

Voici un lexique décrivant certains termes utilisés dans la suite de cette documentation:

• Primaire: nom de Mongo pour désigner un serveur maître
• Secondaire: nom de Mongo pour désigner un Spare
• Replicat Set: nom de Mongo pour désigner la haute disponibilité
• Sharding: nom de Mongo pour désigner le load balacing
• Quorum: Dans une assemblée, le quorum est un chiffre représentant un nombre minimal de personnes en dessous duquel une délibération ne peut pas être considérée comme valide. Dans le cas de Mongo, avoir un quorom suffisant signifie avoir suffisamment de nœuds qui arrivent à communiquer pour être sûr d'être la partie principale du cluster en cas de problème réseau. En général, on définit ce quorum à N/2 + 1 nœuds dans un cluster de N nœuds.

Commandes à lancer

Dans la procédure d'installation, des commandes doivent être lancées. On distingue ces commandes en 2 types:

• Le commandes shell Unix, qui sauf mention contraire, doivent être lancées en tant que root. Elles seront présentées comme suivant:

  Code Block
  language bash theme Emacs title (commande shell)
  echo "commande shell"

  
  

• Les commandes Mongo doivent elles être lancées dans un shell Mongo (les instructions pour ouvrir le bon shell Mongo seront présentes avant ces commandes). Elles seront présentées comme suivant:

  Code Block
  theme Eclipse title (commande mongo)
  commande mongo

  
  

Nuance importante

Ce qui est mis en place dans cette documentation est la haute disponibilité (réplication) de la base Mongo, et non une répartition de charge entre plusieurs nœuds Mongo (sharding).

Un load balancing entre plusieurs nœuds Mongo permet d'améliorer la disponibilité de la base lorsqu'elle est soumise à des contraintes importantes (de nombreux utilisateurs en parallèle) en répartissant la charge mise sur chaque nœud Mongo.

On se concentre ici plutôt sur la haute disponibilité, qui essaye de garantir l'intégrité des données et leur accès. Les données sont donc répliquées entre plusieurs nœuds Mongo, au lieu d'être reparties sur plusieurs nœuds.

Cette nuance a la conséquence suivante sur l'architecture mise en place:

• Puisque chaque nœud Mongo contient l'ensemble des données, il faut que chacun des nœuds puisse supporter la charge complète puisque la base est répliquée sur chaque nœud. Il est donc conseillé d'avoir des machines identiques pour chaque nœud du cluster Mongo

Architecture mise en place

Quels sont Détail sur les différents démons utilisés dans l'archi et résumé rapide de ce qu'on a à la fin de la procédure de configurationExplication avec démons Mongo

Dans une installation Mongo classique, on possède sur un machine un démon qui se charge du stockage des données (mongod). Ce démon représente dans ce cas là la base Mongo en elle même.

Pour obtenir une architecture distribuée permettant de mettre en place de la haute disponibilité, il faut répartir l'installation de Mongo sur plusieurs machines, qu'on appelle "nœud" dans la suite de cette documentation.

Chaque nœud Mongo possède plusieurs démons Mongo qui permettent de gérer la base de données. Dans cette installation, on a 3 nœuds:

• Un nœud primaire, qui ordonnance la réplication et gère la configuration du cluster Mongo
• 2 noeuds secondaires, qui obéisse aux ordres du nœud primaire et s'occupe d'enregistrer les données qu'on leur envoie
  
  

Dans une architecture distribuée hautement disponible, il faut des démons supplémentaires pour que Mongo puisse gérer la réplication. Sur chaque noeud, les démons utilisés sont les suivants:

• mongod
  • Comme dans une installation Mongo classique, le démon mongod se charge du stockage des données
  • Il s'assure que les données sont bien répliquées sur les autres nœuds du cluster.
• mongo-configsrv
  • Ce démon gère la configuration du cluster Mongo sur chaque nœud. Les autres démons Mongo s'appuient sur ce démon pour avoir des informations sur le cluster et sa configuration pour fonctionner. 
• mongos
  • Ce démon s'occupe du routage des requêtes vers le démon mongod adéquat. En s'appuyant sur la configuration donnée par le démon mongo-configsrv, il sait sur quel démon mongod du cluster effectuer la requête.
    • En écriture: Effectue l'écriture sur le démon mongod du nœud primaire
    • En lecture: Effectue la lecture sur un serveur secondaire (si autorisé), sur le serveur primaire sinon
  • Ce démon écoute seulement les requêtes locales

Prérequis pour l'installation

ATTENTION: Pour optimiser, Si plusieurs VM, éviter de les mettre sur le meme hyperviseur, parce que si crash de l'hyperviseur, le montage haute dispo sert a rien les schémas de Jean

Procédure de configuration

Etape 1: Installation de Shinken

On installe pas Mongo tout seul, on utilise celui fournit par Shinken !!!

Etape 2: Création d'une clé partagée pour l'authentification

Etape 3: Mise en place des démons de stockage des données

Etape 4: Déclaration du replicaset dans Mongo

Etape 5: Mise en place des démons de gestion de la configuration

Etape 6: Mise en place des démons de routage des requêtes Mongo

Etape 7: Vérification du bon fonctionnement du cluster

Comportement de Shinken avec un cluster Mongo

Synchronizer crash à chaque changement de primary (quand le primary tombe et quand il revient, puisqu'a chaque fois il y a une élection d'un nouveau primary et pendant ce temps on a personne)

SLA redémarre tant qu'il ne trouve pas de master et au final c'est bon

La retention mongo fait des retry, donc si l'election du nouveau primary se fait suffisamment rapidement, pas de pb. Aussi, si le changement de primary n'arrive pas pendant une sauvegarde de la rétention, le module va meme pas le remarquer.

Supervision du cluster Mongo

Checks mongo, pas top mais c'est ce qu'on a de base de livré dans Shinken et ca fait le boulot.