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étails 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 au maximum avantage 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

Avant de commencer, voici un résumé des différentes étapes nécessaires pour la configuration du cluster Mongo:

  • Installation de Shinken et Mongo. L'installation de Shinken installe également ses dépendances, et donc Mongo. Cette procédure d'installation est spécifique à la version de Mongo installée avec Shinken et l'utilisation d'une version différente de Mongo (y compris sans utilisation d'un cluster) n'est pas supportée et peut entraîner de nombreux bugs.
  • Avant de commencer la mise en place des démons Mongo, on crée une clé d'authentification qui sera utilisée par les démons Mongo.
  • Mise en place des démons de stockage des données
  • Déclaration du replicaset dans Mongo: Une fois les démons de stockage des données mis en place, on dit à Mongo qu'ils font partie de la même architecture.
  • Mise en place des démons de gestion de la configuration Mongo
  • Mise en place des démons de routage Mongo
  • Vérification du bon fonctionnement du cluster: Une fois l'installation terminée, on vérifie l'état du cluster Mongo et son bon fonctionnement

Etape 1: Installation de Shinken

La première étape dans l'installation d'un cluster Mongo est avant tout l'installation de Mongo. Cette documentation s'appuie sur la version de Mongo installée par Shinken (v2.6.9).

Le bon fonctionnement de Shinken n'est garanti qu'avec la version de Mongo installée automatiquement lors de l'installation de Shinken. Toute autre version n'est pas supportée par Shinken et peut entrainer de nombreux bugs.


L'installation de Shinken est décrite dans la page de documentation dédiée: Guide d'installation et de mise à jour

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

Pour sécuriser la communication entre les serveurs Mongo du cluster, on crée une clé qui sera partagée et utilisée par les différents démons de Mongo.


  • Sur le serveur primaire, on commence par créer la clé:

    openssl rand -base64 756 > /etc/mongod.keyfile


  • A l'aide de votre outil de copie favori (scp par exemple), copier cette clé sur les autres serveurs du cluster

    scp -p /etc/mongod.keyfile  root@node2:/etc/mongod.keyfile
scp -p /etc/mongod.keyfile  root@node3:/etc/mongod.keyfile


  • Sur tous les serveurs, donner les droits adéquats au fichier de clé:

    chown mongod:mongod /etc/mongod.keyfile
chmod 400 /etc/mongod.keyfile


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

Une fois la clé d'authentification crée et copiée sur tous les serveurs du cluster, on peut commencer la mise en place des démons Mongo.

Le premier démon mis en place est le démon mongod, qui est responsable du stockage des données.


  • Avant de commencer, on arrête le démon mongod sur tous les serveurs du cluster.
    Sur tous les serveurs:


    /etc/init.d/mongod stop


  • On change aussi la configuration du démon mongod pour qu'il écoute sur le bon port, écoute sur toutes les interfaces réseau, déclare son appartenance au replicateset et qu'il utilise la clé définie précédemment.
    Sur tous les serveurs:


    vi /etc/mongod.conf


    # Changer le port d'écoute pour écouter sur 27018
port=27018


# Commenter la ligne bind_ip pour écouter sur toutes les interfaces réseau et pas seulement l'interface locale (faire commencer la ligne par #)
#bind_ip=127.0.0.1


# Déclarer que le démon mongo appartient au replicaset, qu'on va appeler "rs-shinken"
replSet=rs-shinken


# Utiliser la clé créée dans l'étape 2
keyfile=/etc/mongod.keyfile


  • Mongo ne peut démarrer que si la base est vide sur les serveurs secondaires. On vide donc la base sur les serveurs secondaires seulement.

    LA COMMANDE SUIVANTE VA SUPPRIMER TOUTE LA BASE MONGO SUR LE SERVEUR. S'assurer de ne pas avoir de données importantes sur ces serveurs.


    /etc/init.d/mongod stop
rm -rf /var/lib/mongo/*


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.