Vous êtes ici:

La base de données utilisée par Centreon est un élément crucial dans le fonctionnement de notre supervision. Il existe des mécanismes de failover pour remédier à la défaillance de la connexion de la base avec Centreon-Broker. Malgré tout si la base est indisponible, vous n’aurez plus d’accès à votre interface. Un autre point que l’on néglige souvent, c’est la possibilité d’effectuer des maintenances diverses sans impacter la production. Sans partir sur des usines à gaz, je vous propose une solution simple de tolérance de panne avec une base de données MariaDB.
Vous découvrirez avec cet article les mécanismes de réplication des bases MariaDB, les macros, les eventhandler et l’API centreon-clapi sans oublier un peu de script bash.

1 Principes

Notre serveur Central de supervision n’héberge pas la base de données. Nous utiliserons deux serveurs distincts contenant un SGDB MariaDB. Les deux serveurs de base de données seront configurés en réplication bidirectionnelle (MASTER to MASTER). Centreon sera connecté sur le premier serveur et vérifiera en permanence sa propre connexion grâce à un service approprié. Lorsque celle-ci est indisponible, le service activera un gestionnaire d’événement (eventhandler). Ce gestionnaire d’événement exécutera un script basculant de la base défaillante vers la base de secours. Le service broker pourra alors renvoyer les données stockées dans son failover interne vers la base de données de secours. Lorsque la première base sera de nouveau disponible, les données stockées dans la base de secours seront répliquées automatique vers la première base. Il sera possible, alors, de basculer vers la situation normale.
J’attire votre attention sur le risque d’erreur de duplication de clé avec l’option « auto_increment » en cas d’accès concurrentiel simultanés sur les deux bases de données. La connexion doit se faire sur une base à la fois.

Architecture de principe

Dans notre exemple, nous utiliserons un serveur DNS pour la résolution de nom. Le serveur Central est installé sous Debian Jessie avec le dépôt centreon-deb sans base de données. Les deux serveurs de base de données sont installés avec Debian Jessie et MariaDB 10.0

2 Installation des serveurs MariaDB

Les serveurs MariaDB sont configurés en mode Master/Slave pour chacune des deux serveurs, ce qui correspond à un mode Master/Master. J’ai opté pour cette solution après des difficultés d’utilisation du mécanisme mysqlfailover de MySQL. Celui-ci était intéressant car ce mécanisme modifie automatiquement les rôles des bases de données malheureusement je n’ai pas réussi à trouver la solution pour revenir à une situation normale. J’ai donc choisi naturellement MariaDB préconisé par Centreon. Pour éviter des problèmes de synchronisation, nous choisirons l’accès en lecture/écriture sur une seule base de données à savoir mariadb1.
J’ai découvert ce paramétrage en butinant sur la toile, vous trouvez l’article original avec ce lien http://msutic.blogspot.fr/2015/02/mariadbmysql-master-master-replication.html

2.1 prérequis

Nos serveurs seront nommés respectivement mariadb1 et mariadb2. La résolution DNS s’appuie sur le serveur3. Installons les paquets sur nos serveurs.

apt-get install mariadb-server mariadb-client

2.2 configuration mariadb1

Modifions mariadb1 pour le préparer à la réplication.

vi /etc/mysql/my.cnf

Ajoutons les lignes suivantes et modifions le paramètre bind-address pour autoriser les connexions réseaux.

bind-address            = 172.16.209.64

report_host             = mariadb1
log_bin                 = /var/log/mysql/mariadb-bin
log_bin_index           = /var/log/mysql/mariadb-bin.index
relay_log               = /var/log/mysql/relay-bin
relay_log_index         = /var/log/mysql/relay-bin.index
server-id               = 61

Redémarrons le serveur mariadb1

systemctl restart mysql

Ajoutons l’utilisateur système replusr pour effectuer les opérations de réplication.

root@mariadb1:/home/vmdebian# mysql -u root -p
MariaDB [(none)]> create user 'replusr'@'%' identified by 'replusr';
MariaDB [(none)]> grant replication slave on *.* to 'replusr'@'%';
MariaDB [(none)]> flush privileges;

2.3 configuration mariadb2

Continuons sur la configuration de mariadb2.

vi /etc/mysql/my.cnf

Ajoutons les lignes suivantes et modifions le paramètre bind-address pour autoriser les connexions réseaux. Le paramètre server-id doit être différent sur les deux serveurs.

bind-address            = 172.16.209.65

server-id               = 62
report_host             = mariadb2
log_bin                 = /var/log/mysql/mariadb-bin
log_bin_index           = /var/log/mysql/mariadb-bin.index
relay_log               = /var/log/mysql/relay-bin
relay_log_index         = /var/log/mysql/relay-bin.index

Comme sur mariadb1, ajoutons l’utilisateur système replusr pour effectuer les opérations de réplication.

root@mariadb2:/home/vmdebian# mysql -u root -p
MariaDB [(none)]> create user 'replusr'@'%' identified by 'replusr';
MariaDB [(none)]> grant replication slave on *.* to 'replusr'@'%';
MariaDB [(none)]> flush privileges;

2.4 configuration de la réplication mariadb1 vers mariadb2

Il faut maintenant créer la réplication Master (mariadb1) Slave (mariadb2). Tout d’abord, récupérez les informations du master (mariadb1) avec la commande suivante sur le client mysql.

MariaDB [(none)]> show master status;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000001 |      733 |              |                  |
+--------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Activez le mode slave sur le serveur mariadb2 avec les informations récupérées précédemment.

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='mariadb1', MASTER_USER='replusr',MASTER_PASSWORD='replusr', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=733;
Query OK, 0 rows affected (0.05 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

Vérifiez le bon fonctionnement du mode Master/Slave sur mariadb2. Vous devriez avoir ceci :

MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: mariadb1
                  Master_User: replusr
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000001
          Read_Master_Log_Pos: 733
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 537
        Relay_Master_Log_File: mariadb-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 733
              Relay_Log_Space: 828
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 61
               Master_SSL_Crl:
           Master_SSL_Crlpath:
                   Using_Gtid: No
                  Gtid_IO_Pos:
1 row in set (0.00 sec)

2.5 configuration de la réplication mariadb2 vers mariadb3

Nous allons faire la réplication dans l’autre sens. Récupérez les informations du master (mariadb2) avec la commande suivante sur le client mysql.

MariaDB [(none)]> show master status;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000002 |      441 |              |                  |
+--------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Activez le mode slave sur le serveur mariadb1 avec les informations récupérées précédemment.

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='mariadb2', MASTER_USER='replusr',MASTER_PASSWORD='replusr', MASTER_LOG_FILE='mariadb-bin.000002', MASTER_LOG_POS=441;
Query OK, 0 rows affected (0.55 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

Vérifiez le bon fonctionnement du mode Master/Slave sur mariadb1. Vous devriez avoir ceci :

MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: mariadb2
                  Master_User: replusr
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000002
          Read_Master_Log_Pos: 441
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 537
        Relay_Master_Log_File: mariadb-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 441
              Relay_Log_Space: 828
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 62
               Master_SSL_Crl:
           Master_SSL_Crlpath:
                   Using_Gtid: No
                  Gtid_IO_Pos:
1 row in set (0.00 sec)

Votre réplication Master/Master est fonctionnelle. Passons à la configuration de Centreon.

3 Configuration de Centreon

Nous utiliserons le dépôt non-officiel de centreon pour Debian pour installer notre supervision sans base de données. Pour l’ajout du dépôt voir la page suivante. Nous en profiterons pour installer le package français.

apt-get install centreon-central-without-db centreon-clapi centreon-lang-fr

Avant de configurer Centreon avec le navigateur, assurez-vous que l’utilisateur root de la base de données soit accessible par le serveur Central.

Indiquez la base de donnée mariadb1

L’objet de cet article n’étant la configuration de Centreon, nous partons du principe de votre supervision est fonctionnelle.

3.1 paramétrage du service mysql

Pour contrôler la connexion de mariabd1, nous utiliserons le plugin check_mysql. Si celui-ci n’est pas disponible dans le dossier /usr/lib/nagios/plugin, installez le package suivant.

apt-get install nagios-plugins-standard

Ce plugin est très simple à configurer comme le montre la copie d’écran suivant. On commencera par la commande de plugin, nous n’utiliserons pas les macros personnalisées dans cet exemple.

la commande check_mysql

Le service sera configuré comme ci-dessous.

le service check-mysql_master

Pour accélérer le processus de notification, paramétrons le nombre de contrôle avant validation à 1.

3.3 Configuration du gestionnaire d’événement

Le gestionnaire d’événement (eventhandler) va nous permettre de déclencher un script pour modifier la connexion à la base de données en cas de défaillance de mariadb1. C’est le moteur de supervision qui déclenchera cet événement, gardez bien en mémoire que c’est le user système centreon-engine qui doit avoir les droits d’exécuter les scripts. Commençons par créer la commande pour notre gestionnaire d’événement. Il nous permettra de gérer finement ces événements en fonction des états du service concerné (états SOFT, HARD, CRITICAL, WARNING, UNKNOW et OK)

la commande handle-master-proc-event

Créons le dossier dans l’emplacement des plugins. Affectez les droits d’écriture à centreon-engine.

mkdir /usr/lib/nagios/plugins/eventhandler
chown centreon-engine:centreon /usr/lib/nagios/plugins/eventhandler

Créons le script handle-master-proc-event qui prendra en compte les états du service.

#!/bin/sh
#script pour les service handle-master-proc-event
# prise en compte que si état HARD
case "$2" in
 HARD)
  case "$1" in
   CRITICAL)
        # prise en compte du service en état critique
        /usr/lib/nagios/plugins/eventhandler/set_master_slave.sh
    ;;
   WARNING)
        # état warning
    ;;
   UNKNOWN)
        # état unknown
    ;;
   OK)
        # état ok
    ;;
  esac
  ;;
 esac
exit 0

Créons le script set_master_slave.sh qui nous permettra de changer de connexion de base de données.

#!/bin/sh
# script automatique BDD master to Slave
#
# modify configuration centreon
/bin/sed -i -e "s/mariadb1/mariadb2/g" /etc/centreon/centreon.conf.php
# modifiy configuration broker
/usr/bin/centreon -u admin -p password -o centbrokercfg -a setoutput -v "central-broker-master;1;db_host;mariadb2"
/usr/bin/centreon -u admin -p password -o centbrokercfg -a setoutput -v "central-broker-master;3;db_host;mariadb2"
/bin/sed -i -e "s/mariadb1/mariadb2/g" /etc/centreon-broker/central-broker.xml
# apply configuration
/usr/bin/sudo /usr/share/centreon/bin/cbd reload

La première commande avec l’instruction sed est nécessaire pour pouvoir utiliser l’interface de Centreon et utiliser l’API Centreon-Clapi. Ensuite les deux lignes suivantes modifient la connexion du broker dans la base de données centreon. Actuellement la commande clapi ApplyCFG ne fonctionne pas avec un compte autre que superutilisateur. Nous modifierons directement le fichier de Centreon-Broker. La dernière recharge le service centreon-broker, votre supervision est connectée avec la base de secours. Les données contenues dans les fichiers de rétention (failover) pourront être vidées dans la base de données mariadb2.
Point important, vérifiez que le user centreon-engine soit capable de modifier le fichier centreon.conf.php. Positionnez les droits suivants le cas échéant.

chmod 664 /etc/centreon/centreon.conf.php

Pour autoriser centreon-engine à recharger le service centreon-broker, modifiez le fichier /etc/sudoers.d/centreon et ajoutez l’utilisateur centreon-engine.

## BEGIN: CENTREON SUDO
#Add by CENTREON installation script
User_Alias      CENTREON=www-data,centreon,centreon-engine

Modifions maintenant notre service check-mysql_master pour activer le gestionnaire d’événement. Sélectionnez l’onglet Traitement des données.

Configuration du gestionnaire d’événements dans le service check-mysql_master

Sélectionnez la commande handle-master-proc-event et vérifiez l’activation du gestionnaire d’événement.

4 Test de notre configuration

Il est temps de vérifier le fonctionnement de notre configuration. Connectez-vous à l’interface web de Centreon.

la supervision en état de fonctionnement

Arrêtons la base de données mariadb1

systemctl stop mysql

L’interruption de la supervision est de courte durée, si on fait une requête lors de l’arrêt de la base, vous avez droit à cet écran ci-dessous.

La base mariadb1 n’est plus accessible

Le service check-mysql_master étant en état critical, il déclenche l’événement comme l’indique le fichier de log du moteur de supervision.

[1457544168] [46871] SERVICE ALERT: mariadb1;check-mysql_master;CRITICAL;HARD;1;Can't connect to MySQL server on '172.16.209.64' (111)
[1457544168] [46871] SERVICE EVENT HANDLER: mariadb1;check-mysql_master;CRITICAL;HARD;1;handle-master-proc-event

La supervision est de nouveau accessible et on peut constater le service à l’état critical

La supervision est de nouveau accessible

Malgré plusieurs essais d’arrêt de la base mariadb1, nous n’avons perdu aucune données de performances grâce aux mécanismes de failover de Centreon-Broker et à la tolérance de panne des bases de données.