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:

  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:

  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 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 configuration

Explication avec 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.