Introduction

De nombreux composants de Shinken Entreprise peuvent être installés et configurés de manière à former une architecture hautement disponible. Dans le page Haute disponibilité des démons de Shinken Entreprise sont décrites les procédures permettant de mettre en place des démons Shinken de remplacement pour améliorer la disponibilité.

Cependant, un certain de nombre de ces démons et leurs modules associés s'appuient sur une base Mongo pour fonctionner. Pour améliorer la résistance aux pannes de la plateforme Shinken dans son ensemble, on peut également s'assurer que la base Mongo soit plus robuste.



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:

    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:

    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

Détail sur les 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

Un nœud du cluster Mongo a alors l'architecture décrite dans le schéma ci-contre.

Dans ce schéma, on a donc les 3 démons présents:

  • Démon mongod (data): Ecoute sur le port 27018 et s'occupe de stocker les données (dans /var/lib/mongo par défaut)
  • Démon mongo-configsrv: Ecoute sur le port 27019 et s'occupe de stocker la configuration (/var/lib/mongo/configdb par défaut)
  • Démon mongos (routeur): Ecoute sur le port 27017 qui est utilisé dans une architecture classique par le démon mongod. Cette configuration permet à Shinken d'effectuer ses requêtes Mongo de manière locale sur le port 27017 comme d'habitude. Le démon mongos va ensuite s'occuper du routage de la requête pour que cette donnée soit stockée correctement dans le cluster.



Chaque noeud du cluster interagit comme décrit sur le schéma ci-contre.

Dans ce schéma, chaque noeud constituant du cluster possède les démons décrits précédemment. Shinken effectue ses requêtes de manière locale sur le démon mongos, qui ensuite s'occupe de l'aspect cluster de Mongo et du bon traitement et acheminement des données.


Du point de vue de Shinken, la transformation de Mongo en un cluster Mongo est transparente.

Les requêtes sont toujours faites sur le même port et Shinken n'a pas conscience de la haute dispoinibilité de Mongo. Cela permet d'avoir 2 systèmes plus indépendants et leur association plus facilement configurable.



Prérequis pour l'installation

Pour la mise en place du cluster Mongo, il faut que les conditions suivantes soient réunies:

  • Il faut 3 serveurs distincts
    • Il peut s'agir de VM ou de serveurs physiques
  • Il faut que chaque serveur du cluster puisse joindre tous les autres serveurs du cluster
  • Pour des raisons de sécurité et de fiabilité des communications, on préfère que les serveurs du cluster soient dans le même réseau privé.
  • Les 2 serveurs secondaires du cluster Mongo doivent être vidés de toutes données Mongo
  • Pour une configuration et une maintenance plus facile, on se réfère aux machines via leur nom DNS (via un serveurs DNS ou /etc/hosts) au lieu de leur IP qui peut potentiellement changer


Comme indiqué précédemment, il faut que chaque serveur puisse supporter la charge de requêtes à eux seuls, et ce en permanence


Pour tirer un maximum d'avantages de l'architecture haute disponibilité, il est plus judicieux dans le cas ou les serveurs du cluster sont des VM de ne pas les mettre sur le même hyperviseur (si possible). En effet, un problème sur l'hyperviseur pourrait alors affecter toutes les VM en même temps et rendre l'architecture haute disponibilité inutile.


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.