Haute disponibilité (High Availability)

Retour à l'index de documentation du Pandora FMS

Pandora FMS est une application très stable (grâce aux tests et aux améliorations introduits dans chaque version et à la correction de centaines de pannes découvertes par les utilisateurs), cependant, dans des environnements critiques et/ou avec beaucoup de charge, il est possible qu'il soit nécessaire de répartir la charge sur plusieurs machines et d'être sûr que si un composant de Pandora FMS tombe en panne, le système ne s'effondrera pas.

Pandora FMS a été conçu pour être très modulaire, et que chacun de ses modules puisse fonctionner de manière indépendante. Mais il est également conçu pour fonctionner en collaboration avec d'autres composants et être capable d'assumer la charge des composants qui sont tombés.

Une conception standard de Pandora FMS pourrait être celle que l'on voit dans l'illustration suivante.

Il est clair que les agents ne sont pas redondants. Si un agent tombe, il n'est pas logique d'en exécuter un autre, car la seule cause de la chute d'un agent est que les données n'ont pas pu être obtenues parce qu'un module a échoué dans son exécution -ce qui n'a pas pu être corrigé avec un autre agent fonctionnant en parallèle- ou parce que le système est isolé ou qu'il a été suspendu. La solution évidente est de redondance des systèmes critiques - qu'ils aient ou non des agents Pandora FMS en fonctionnement - et ainsi de redondance de la surveillance de ces systèmes.

On pourrait parler de l'utilisation de l'HA (High Availability) dans plusieurs scénarios :

• Equilibrage et HA du serveur de données.
• Balancement et HA des serveurs du réseau, WMI, plugin, web, prédiction, reconnaissance et autres
• Equilibrage et HA dans la Base de Données.
• Balancement et HA dans la console Pandora FMS.

Les composantes les plus importantes de Pandora FMS sont

1. Base de données
2. Serveur
3. Console

Chacun des composants peut être reproduit pour protéger le système de surveillance contre tout désastre.

Pour désigner le nombre de nœuds nécessaires pour équilibrer la charge, nous étudierons le nombre de cibles à surveiller et la quantité, le type et la fréquence de saisie des mesures à recueillir.

En fonction des besoins de surveillance, nous définirons les différentes architectures.

Note : Les tests effectués pour définir les architectures ont été réalisés avec différents équipements :

Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz

Amazon t2.large instance ¹⁾

Selon les besoins :

1. Standalone (sans haute disponibilité) jusqu'à 2500 agents / 50000 modules toutes les 5 minutes, données uniformes, pas de données historiques

 Serveurs : 1 (partagé)
 
 Principale:
 ----------
 CPU: 6 cores
 RAM: 8 GB
 Disque: 100GB

2. Standalone (sans haute disponibilité) jusqu'à 2500 agents / 50000 modules toutes les 5 minutes, données uniformes, avec données historiques (1 an)

 Serveurs : 2 (1 partagé, 1 historique)
 
 Principale :
 ----------
 CPU: 6 cores
 RAM: 8 GB
 Disque : 100GB
 
 Historique :
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disque : 200GB

3. Standalone (sans haute disponibilité) jusqu'à 5000 agents / 100000 modules toutes les 5 minutes, données uniformes, avec données historiques (1 an)

 Serveurs : 3 (1 serveur + console, 1 base de données principale, 1 historique)
 
 Serveur + console :
 -------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 40GB
 
 Base de données principale :
 ------------------------
 CPU : 4 cores
 RAM : 8 GO
 Disque : 100GB
 
 Historique :
 ----------
 CPU : 2 cores
 RAM : 4 GO
 Disque : 200GB

1. Base de données HA unique, jusqu'à 7500 agents / 125000 modules toutes les 5 minutes, données uniformes, avec données historiques (1 an)

 Serveurs : 4 (1 serveur + console, 2 bases de données, 1 historique)
 
 Serveur + console :
 -------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 40GB
 
 Base de données du nœud 1 :
 ---------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 100GB
 
 Base de données du noeud 2 :
 ---------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 100GB
 
 Historique :
 ----------
 CPU : 2 cores
 RAM : 4 GO
 Disque : 300GB

2. Base de données HA complète (avec quorum), jusqu'à 7500 agents / 125000 modules toutes les 5 minutes, données uniformes, avec données historiques (1 an)

Serveurs : 5 (1 serveur + console, 3 bases de données, 1 historique)

Serveur + console :

 -------------------
 CPU: 6 cores
 RAM: 8 GB
 Disque : 40GB

Base de données noeud 1 :

 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100GB

Base de données noeud 2 :

 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disque: 100GB

Base de données noeud 3 :

 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100GB
 
 Historique :
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disque : 200GB

3. Base de données en HA simple et Pandora FMS en HA équilibré, jusqu'à 7500 agents / 125000 modules toutes les 5 minutes, données uniformes, avec données historiques (1 an)

 Serveurs : 5 (2 serveur + console, 2 base de données, 1 historique)
 
 Serveur + console :
 -------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 40GB
 
 Serveur + console :
 -------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 40GB
 
 Base de données du nœud 1 :
 ---------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 100GB
 
 Base de données du noeud 2 :
 ---------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 100GB
 
 Historique :
 ----------
 CPU : 2 cœurs
 RAM : 4 GO
 Disque : 200GB

4. HA de base équilibrée en serveur, base de données principale et réplique, jusqu'à 4000 agents / 90000 modules toutes les 5 minutes, données uniformes, avec données historiques (1 an)

 Serveurs : 3 (2 partagés, 1 historique)
 
 Principale : (console + serveur + nœud de base de données 1)
 ----------
 CPU : 8 cores
 RAM : 12 GO
 Disque : 100GB
 
 Secondaire : (console + serveur + nœud de base de données 2)
 ----------
 CPU : 8 cores
 RAM : 12 GO
 Disque : 100GB
 
 Historique :
 ----------
 CPU : 2 cores
 RAM : 4 GO
 Disque : 200GB

Dans ce schéma, les nœuds de la base de données Pandora FMS sont configurés dans chacun des deux serveurs disponibles (principal et secondaire).

Note : Pour les grands environnements, nous définirons chacun des schémas de configuration décrits ci-dessus comme des nœuds informatiques.

Si vous devez surveiller 30.000 agents avec 500.000 modules, vous devez configurer autant de nœuds que nécessaire pour couvrir ces besoins. Suivant l'exemple :

Si nous choisissons la conception HA#1 (1 serveur+console, 2 nœuds de base de données dans HA, et une base de données historique), nous devrions configurer 30.000 / 7500 = 4 nœuds.

Pour gérer tout l'environnement, nous devrons avoir une Meta Console installée, depuis laquelle nous pourrons configurer toute l'infrastructure de monitorage.

La Metaconsole nécessitera :

 Serveurs : 1 (partagé)
 
 Principale :
 ----------
 CPU : 8 cores
 RAM : 12 GO
 Disque : 100GB

Nombre total de serveurs avec bases de données historiques indépendantes : 17

Nombre total de serveurs avec bases de données historiques combinées : 13

Note : Pour combiner toutes les bases de données historiques (4) dans un seul appareil, vous devez redimensionner leurs caractéristiques pour assumer la charge supplémentaire :

 Histoire combinée :
 --------------------
 CPU : 8 cores
 RAM : 12 GO
 Disque : 1200GB

Le plus simple est d'utiliser la propre HA implémentée dans les agents (qui permet de contacter un serveur alternatif si le principal ne répond pas). Cependant, puisque le serveur de données est accessible par le port 41121 et qu'il s'agit d'un port TCP standard, il est possible d'utiliser n'importe quelle solution commerciale qui permet d'équilibrer ou de mettre en grappe un service TCP ordinaire.

Pour le serveur de données Pandora FMS, vous devrez configurer deux machines avec un serveur de données Pandora FMS configuré (et un nom d'hôte et un nom de serveur différents). Vous devrez configurer un serveur Tentacle dans chacun d'eux. Chaque machine aura une adresse IP différente. Si nous devons utiliser un équilibreur externe, il fournira une adresse IP unique à laquelle les agents se connecteront pour envoyer leurs données.

Si nous utilisons un équilibreur externe, et que l'un des serveurs tombe en panne, le mécanisme HA permet d'activer l'un des serveurs actifs disponibles et les agents Pandora FMS continueront à se connecter avec la même adresse qu'auparavant, sans remarquer le changement, mais dans ce cas, l'équilibreur de charge n'enverra plus les données au serveur qui a échoué, mais à un autre serveur actif. Il n'est pas nécessaire de changer quoi que ce soit dans chaque serveur de données Pandora FMS, même chaque serveur peut garder son propre nom, utile pour savoir si l'un d'entre eux est tombé dans la vue d'état du serveur. Les modules de données Pandora FMS peuvent être traités par n'importe quel serveur sans préaffectation. Il est conçu précisément de cette manière pour pouvoir mettre en œuvre l'HA de manière plus simple.

Dans le cas de l'utilisation du mécanisme HA des agents, il y aura un petit retard dans l'envoi des données, donc à chaque exécution d'un agent, il essaiera de se connecter avec le serveur primaire, et s'il ne répond pas, il le fera contre le secondaire (s'il a été configuré comme ça). Ceci est décrit ci-dessous comme “ Équilibrage dans les agents logiciels ”.

Si vous souhaitez utiliser deux serveurs de données et que tous deux gèrent des politiques, des collections et des configurations distantes, vous devrez partager par NFS les répertoires suivants afin que toutes les instances du serveur de données puissent lire et écrire dans ces répertoires. Les consoles doivent également avoir accès à ces répertoires partagés via NFS.

• /var/spool/pandora/data_in/conf
• /var/spool/pandora/data_in/collections
• /var/spool/pandora/data_in/md5

A partir des agents logiciels il est possible de faire un équilibrage du serveur de données puisqu'il est possible de configurer un serveur de données de base et un serveur de sauvegarde. Dans le fichier de configuration de l'agent pandora_agent.conf, vous devez configurer et décommenter la partie suivante du fichier de configuration de l'agent :

1. Secondary server configuration

 # ==============================
 # If secondary_mode is set to on_error, data files are copied to the secondary
 # server only if the primary server fails. If set to always, data files are
 # always copied to the secondary server
 secondary_mode on_error
 secondary_server_ip localhost
 secondary_server_path /var/spool/pandora/data_in
 secondary_server_port 41121
 secondary_transfer_mode tentacle
 secondary_server_pwd mypassword
 secondary_server_ssl no
 secondary_server_opts

Il existe les options suivantes (pour plus d'informations, voir le chapitre de configuration des agents).

• secondary_mode : Mode dans lequel le serveur secondaire doit être. Il peut avoir deux valeurs :
  • on_error : envoie des données au serveur secondaire seulement s'il ne peut pas les envoyer au serveur primaire.
  • always : Il envoie toujours des données au serveur secondaire, indépendamment du fait qu'il puisse ou non contacter le serveur principal.
• secondary_server_ip : IP du serveur secondaire.
• secondary_server_path : Chemin où les XML sont copiés sur le serveur secondaire, habituellement /var/spool/pandora/data_in
• secondary_server_port : Port par lequel le XML sera copié sur le serveur secondaire, en tentacule 41121, en ssh 22 et en ftp 21.
• secondary_transfer_mode : Mode de transfert qui sera utilisé pour copier le XML vers le serveur secondaire, en tentacule, ssh, ftp, …
• secondary_server_pwd : option de mot de passe pour le transfert FTP
• secondary_server_ssl : Il sera mis à oui ou à non selon que vous voulez utiliser ssl pour transférer des données à travers Tentacle.
• secondary_server_opts : Dans ce champ seront placées les autres options nécessaires au transfert.

Vous devez installer plusieurs serveurs, en réseau. WMI, Plugin, Web ou prédiction, dans plusieurs machines du réseau (toutes avec la même visibilité vers les systèmes que vous voulez surveiller) et que toutes se trouvent dans le même segment (pour que les données de latence du réseau soient cohérentes).

Les serveurs peuvent être marqués comme primaires. Ces serveurs collecteront automatiquement les données de tous les modules assignés à un serveur marqué comme “ down ”. Les propres serveurs de Pandora FMS mettent en œuvre un mécanisme permettant de détecter que l'un d'entre eux est passé à travers une vérification de sa dernière date de contact (seuil du serveur x 2). Il suffit qu'il n'y ait qu'un seul serveur FMS Pandora actif pour qu'il puisse détecter la chute des autres. Si tous les serveurs FMS de Pandora sont en panne, il n'y a aucun moyen de détecter ou de mettre en œuvre l'HA.

La façon la plus évidente de mettre en œuvre l'HA et l'équilibrage de charge, dans un système à deux nœuds, est d'affecter 50 % des modules à chaque serveur et de marquer les deux serveurs comme maîtres. Dans le cas où il y a plus de deux serveurs maîtres et un troisième serveur en panne avec des modules en attente d'exécution, le premier des serveurs maîtres qui exécute le module est “ auto-assigné ” le module du serveur en panne. En cas de récupération d'un des serveurs en panne, les modules qui avaient été affectés au serveur primaire sont automatiquement réaffectés.

La répartition de charge entre les différents serveurs se fait dans la partie administration de l'agent dans le menu “setup”.

Dans le champ “server”, il y a un combo où vous choisissez le serveur qui effectuera les vérifications.

Un serveur Pandora FMS peut fonctionner selon deux modes différents :

• Mode maître.
• Mode non maître.

Si un serveur tombe en panne, ses modules seront exécutés par le serveur maître de sorte qu'aucune donnée ne sera perdue.

A tout moment, il ne peut y avoir qu'un seul serveur maître, qui est choisi parmi les serveurs qui ont l'option de configuration maître dans /etc/pandora/pandora_server.conf avec une valeur supérieure à 0 :

master [1..7]

Si le serveur maître actuel est hors service, un nouveau maître est choisi. S'il y a plus d'un candidat, on choisit celui qui a une valeur plus élevée dans “master”.

Par exemple, si vous avez trois serveurs Pandora FMS avec master à 1, un serveur master sera choisi au hasard et les deux autres fonctionneront en mode non master. Si le serveur maître tombe en panne, un nouveau maître sera choisi au hasard.

Dans le fichier pandora_server.conf, les paramètres suivants ont été introduits :

• ha_file : Adresse du fichier binaire temporaire de l'HA.
• ha_pid_file : Processus actuel de l'HA.
• pandora_service_cmd : contrôle du statut du service Pandora FMS

Tout ce que vous avez à faire est d'installer une autre console. Chacun d'entre eux peut être utilisé simultanément à partir de différents endroits par différents utilisateurs. Vous pouvez utiliser un équilibreur Web devant les consoles si vous avez besoin de croissance horizontale pour équilibrer la charge de la console. Le système de session est géré par des cookies et ceux-ci sont stockés dans le navigateur.

Dans le cas de l'utilisation de la configuration à distance et pour le gérer dans toutes les consoles, les serveurs de données et les consoles doivent partager (NFS) le répertoire des données d'entrée (/var/spool/pandora/data_in) pour la configuration à distance des agents, des collections et des autres répertoires.

Il est important de partager les sous-répertoires dans data-in mais pas data_in, puisqu'il pourrait affecter négativement la performance du serveur.

Lors de la mise à jour de la console Pandora FMS dans un environnement de haute disponibilité, il est important de prendre en compte les considérations suivantes lors de la mise à jour par OUM via Update Manager → Update Manager offline.

Les utilisateurs de la version Enterprise peuvent télécharger le package OUM sur le site de support de Pandora FMS.

Etant dans un environnement équilibré avec une base de données partagée, la mise à jour de la première console applique les changements correspondants dans la base de données. Cela fait que lors de la mise à jour de la deuxième console, Pandora FMS affiche une erreur lorsqu'il trouve les informations déjà insérées dans la base de données. Cependant, la mise à jour de la console se fera de la même manière.

Pandora FMS est basé sur une base de données MySQL pour configurer et stocker les données. Une défaillance de la base de données pourrait paralyser momentanément l'outil de surveillance. Le cluster de base de données haute disponibilité de Pandora FMS nous permet de déployer facilement une architecture robuste et tolérante aux pannes.

Les ressources des clusters sont gérées par Pacemaker, un gestionnaire de ressources de cluster haute disponibilité avancé et évolutif. Corosync fournit un modèle de communication de groupe de processus fermé pour la création de machines à états répliqués. Percona a été choisi comme SGBDR par défaut pour son évolutivité, sa disponibilité, sa sécurité et ses fonctions de sauvegarde.

La réplication active/passive replication est développée à partir d'un seul nœud maître (permission d'écriture) vers un nombre quelconque d'esclaves (lecture seule). Une adresse IP virtuelle mène toujours au maître actuel. En cas de défaillance du nœud maître, l'un des esclaves est mis à niveau vers le maître et l'adresse IP virtuelle est mise à jour en conséquence.

L'outil de base de données HA de Pandora FMS, pandora_ha, surveille le cluster et s'assure que le serveur de Pandora FMS fonctionne en permanence, en le redémarrant si nécessaire. pandora_ha est surveillé en même temps avec systemd.

Nous allons configurer un cluster de deux nœuds, avec les hôtes node1 et node2. Nous changeons les noms d'hôtes, les mots de passe, etc. en fonction de ce dont nous avons besoin pour correspondre à notre environnement.

Les commandes qui doivent être exécutées dans un nœud seront précédées du nom d'hôte de ce nœud. Par exemple :

node1# <command>

Les commandes à exécuter dans tous les nœuds seront précédées du mot “ all ”. Par exemple :

all# <command>

Il existe un hôte supplémentaire, appelé pandorafms, où Pandora FMS est ou sera installé.

CentOS version 7 doit être installé sur tous les hôtes, et doit être capable de résoudre les noms d'hôtes des autres hôtes.

 node1# ping node2
 PING node2 (192.168.0.2) 56(84) bytes of data.
 
 node2# ping node1
 PING node1 (192.168.0.1) 56(84) bytes of data.
 
 pandorafms# ping node1
 PING node1 (192.168.0.1) 56(84) bytes of data.
 
 pandorafms# ping node2
 PING node2 (192.168.0.2) 56(84) bytes of data.

Un serveur Open SSH doit être installé et exécuté sur chaque hôte. Nous avons retiré la bannière qui montre Open SSH :

all# [ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
all# sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config
all# systemctl restart sshd

Nous générons de nouvelles clés d'authentification SSH pour chaque hôte et nous copions la clé publique pour chaque hôte :

 node1# echo -e "\n\n\n" | ssh-keygen -t rsa
 node1# ssh-copy-id -p22 [email protected]
 node2# ssh node2
 
 node2# echo -e "\n\n\n" | ssh-keygen -t rsa
 node2# ssh-copy-id -p22 [email protected]
 node2# ssh node1
 
 pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa
 pandorafms# ssh-copy-id -p22 [email protected]
 pandorafms# ssh-copy-id -p22 [email protected]
 pandorafms# ssh node1
 pandorafms# ssh node2

Dans le nœud FMS de Pandora, nous copions la paire de clés dans /usr/share/httpd/.ssh/. La console Pandora FMS a besoin de récupérer l'état du cluster :

 pandorafms# cp -r /root/.ssh/ /usr/share/httpd/
 pandorafms# chown -R apache:apache /usr/share/httpd/.ssh/

Les étapes suivantes ne sont nécessaires que si les nœuds exécutent SSH sur un port non standard. Nous remplaçons “ 22” par le bon numéro de port :

 all# echo -e "Host node1\n    Port 22" >> /root/.ssh/config
 all# echo -e "Host node2\n    Port 22" >> /root/.ssh/config

Nous installons le paquet nécessaire :

all# yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm

all# yum install -y Percona-Server-server-57 percona-xtrabackup-24

Nous nous assurons que le service Percona est désactivé, car il sera géré par le cluster :

all# systemctl disable mysqld

Nous configurons Percona en remplaçant <ID> par un numéro qui doit être unique pour chaque nœud de cluster :

all# export SERVER_ID=<ID>
all# export POOL_SIZE=$(grep -i total /proc/meminfo | head -1 | \
awk '{print $(NF-1)*0.4/1024}' | sed s/\\..*$/M/g)
all# cat <<EOF> /etc/my.cnf
[mysqld]
server_id=$SERVER_ID

datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
log-error=/var/log/mysqld.log
show_compatibility_56=on

max_allowed_packet = 64M
# Recommendation: not to assign a value greater than 35% of available RAM memory
innodb_buffer_pool_size = $POOL_SIZE
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
thread_cache_size = 8
max_connections = 200
wait_timeout = 900
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
log-bin=mysql-bin
query_cache_type = 1
query_cache_size = 32M
query_cache_limit = 8M
sql_mode=""
expire_logs_days=3

binlog-format=ROW
log-slave-updates=true
sync-master-info=1
sync_binlog=1
max_binlog_size = 100M
replicate-do-db=pandora
port=3306
report-port=3306
report-host=master
gtid-mode=off
enforce-gtid-consistency=off
master-info-repository=TABLE
relay-log-info-repository=TABLE

sync_relay_log = 10
sync_relay_log_info = 10
slave_compressed_protocol = 1
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 10
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 1800

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[client]
user=root
password=pandora
EOF

Nous lançons le serveur Percona :

all# systemctl start mysqld

Un nouveau mot de passe temporaire sera généré en se connectant à /var/log/mysqld.log. Nous nous connectons au serveur Percona et changeons le mot de passe root :

all# mysql -uroot -p$(grep "temporary password" /var/log/mysqld.log | \
rev | cut -d' ' -f1 | rev)
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
mysql> UNINSTALL PLUGIN validate_password;
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
mysql> quit

Nouvelle installation de Pandora FMS

Nous avons installé Pandora FMS dans la base de données récemment créée. Pour plus d'informations, veuillez consulter 01_installing

On arrête le serveur FMS de Pandora :

pandorafms# /etc/init.d/pandora_server stop

Installation de FMS Pandora existants

On arrête le serveur FMS de Pandora :

pandorafms# /etc/init.d/pandora_server stop

Nous faisons une sauvegarde de la base de données de Pandora FMS :

 pandorafms# mysqldump -uroot -ppandora --databases pandora > /tmp/pandoradb.sql
 pandorafms# scp /tmp/pandoradb.sql node1:/tmp/

Nous l'avons téléchargé dans la nouvelle base de données :

node1# mysql -uroot -ppandora pandora -e source "/tmp/pandoradb.sql"

Nous accordons les privilèges nécessaires pour la réplication afin de travailler sur toutes les bases de données :

all# mysql -uroot -ppandora
mysql> GRANT ALL ON pandora.* TO 'root'@'%' IDENTIFIED BY 'pandora';
mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.*
TO 'root'@'%' IDENTIFIED BY 'pandora';
mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE, SUPER, PROCESS, RELOAD ON *.*
TO 'root'@'localhost' IDENTIFIED BY 'pandora';
mysql> GRANT select ON mysql.user TO 'root'@'%' IDENTIFIED BY 'pandora';
mysql> FLUSH PRIVILEGES;
mysql> quit

Nous faisons une sauvegarde de la base de données du premier noeud et nous écrivons le nom et la position du fichier journal maître (dans l'exemple, mysql-bin.000001 et 785) :

node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# cat /root/pandoradb.bak/xtrabackup_binlog_info 
mysql-bin.000001        785

Nous chargeons la base de données dans le second noeud et la configurons pour qu'elle se réplique à partir du premier noeud (nous configurons MASTER_LOG_FILE et MASTER_LOG_POS aux valeurs de l'étape précédente) :

node2# systemctl stop mysqld

node1# rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/

node2# chown -R mysql:mysql /var/lib/mysql
node2# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node2# systemctl start mysqld
node2# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node2-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB: pandora
             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: 785
                 Relay_Log_Space: 1252
                 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: 1
                     Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Master_Retry_Count: 86400
                     Master_Bind: 
         Last_IO_Error_Timestamp: 
        Last_SQL_Error_Timestamp: 
                  Master_SSL_Crl: 
              Master_SSL_Crlpath: 
              Retrieved_Gtid_Set: 
               Executed_Gtid_Set: 
                   Auto_Position: 0
            Replicate_Rewrite_DB: 
                    Channel_Name: 
              Master_TLS_Version: 
   1 row in set (0.00 sec)
mysql> QUIT

Nous installons les paquets nécessaires :

 yum install -y epel-release corosync ntp pacemaker pcs
 
 all# systemctl enable ntpd
 all# systemctl enable corosync
 all# systemctl enable pcsd
 all# cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf

 all# systemctl start ntpd
 all# systemctl start corosync
 all# systemctl start pcsd

On arrête le serveur Percona :

node1# systemctl stop mysqld

node2# systemctl stop mysqld

Nous authentifions tous les noeuds du cluster :

Créer et démarrer le cluster :

all# echo hapass | passwd hacluster --stdin

node1# pcs cluster auth -u hacluster -p hapass --force node1 node2
node1# pcs cluster setup --force --name pandoraha node1 node2
node1# pcs cluster start --all
node1# pcs cluster enable --all
node1# pcs property set stonith-enabled=false
node1# pcs property set no-quorum-policy=ignore

Nous vérifions l’état du cluster :

node#1 pcs status
   Cluster name: pandoraha
   Stack: corosync
   Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
   Last updated: Fri Jun  8 12:53:49 2018
   Last change: Fri Jun  8 12:53:47 2018 by root via cibadmin on node1
   
   2 nodes configured
   0 resources configured
   
   Online: [ node1 node2 ]
   
   No resources
   
   
   Daemon Status:
     corosync: active/disabled
     pacemaker: active/disabled
     pcsd: active/enabled

Nous avons installé l'agent de réplication Percona Pacemaker :

all# cd /usr/lib/ocf/resource.d/
all# mkdir percona
all# cd percona
all# curl -L -o mysql https://github.com/Percona-Lab/\
pacemaker-replication-agents/raw/1.0.0-stable/agents/mysql_prm
all# chmod u+x mysql

Nous configurons les ressources du cluster. Nous remplaçons <VIRT_IP> par l'adresse IP virtuelle de préférence :

node1# export VIP=<VIRT_IP>
node1# pcs resource create pandoradb ocf:percona:mysql config="/etc/my.cnf" \
pid="/var/run/mysqld/mysqld.pid" socket="/var/lib/mysql/mysql.sock" \
replication_user="root" replication_passwd="pandora" max_slave_lag="60" \
evict_outdated_slaves="false" binary="/usr/sbin/mysqld" datadir="/var/lib/mysql" \
test_user="root" test_passwd="pandora" op start interval="0" timeout="60s" \
op stop interval="0" timeout="60s" op promote timeout="120" op demote timeout="120" \
op monitor role="Master" timeout="30" interval="5" on-fail="restart" op monitor role="Slave" \
timeout="30" interval="10"
node1# pcs resource create pandoraip ocf:heartbeat:IPaddr2 ip=$VIP cidr_netmask=24 \
op monitor interval=20s
node1# pcs resource master master_pandoradb pandoradb meta master-max="1" \
master-node-max="1" clone-max="2" clone-node-max="1" notify="true" \
globally-unique="false" target-role="Master" is-managed="true"
node1# pcs constraint colocation add master master_pandoradb with pandoraip
node1# pcs constraint order promote master_pandoradb then start pandoraip

Nous avons vérifié l'état du cluster :

node1# pcs status
   Cluster name: pandoraha
   Stack: corosync
   Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
   Last updated: Fri Jun  8 13:02:21 2018
   Last change: Fri Jun  8 13:02:11 2018 by root via cibadmin on node1
   
   2 nodes configured
   3 resources configured
   
   Online: [ node1 node2 ]
   
   Full list of resources:
   
    Master/Slave Set: master_pandoradb [pandoradb]
        Masters: [ node1 ]
        Slaves: [ node2 ]
    pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
   
   Daemon Status:
     corosync: active/disabled
     pacemaker: active/disabled
     pcsd: active/enabled

Cela se fera de la même manière que pour la précédente. Les informations d'identification de l'utilisateur doivent avoir été copiées, expliquées précédemment, et les étapes suivantes doivent être suivies :

# All nodes:

 useradd <usuario>
 passwd <usuario>
 usermod -a -G haclient <usuario>

 # Enable PCS ACL system
 pcs property set enable-acl=true --force

 # Create role
 pcs acl role create <rol> description="RW role"  write xpath /cib

 # Create PCS user - Local user
 pcs acl user create <usuario> <rol>

 # Login into PCS from ALL nodes
 su - <usuario>
 pcs status
 Username: <usuario>
 Password: ***** 

# Wait for 'Authorized' message, ignore output. Wait a second and retry 'pcs status' command

Nous nous assurons que php-pecl-ssh2 est installé :

 pandorafms# yum install php-pecl-ssh2
 pandorafms# systemctl restart httpd

Il y a deux paramètres dans /etc/pandora/pandora_server.conf qui contrôlent le comportement de l'outil HA de la base de données Pandora FMS. Ils peuvent être modifiés pour les adapter à nos besoins :

# Pandora FMS Database HA Tool execution interval in seconds (PANDORA FMS ENTERPRISE ONLY).                                                                                                                                               
ha_interval 30                                                                                                                                                                                                                            
                                                                                                                                                                                                                                         
# Pandora FMS Database HA Tool monitoring interval in seconds. Must be a multiple of ha_interval (PANDORA FMS ENTERPRISE ONLY).                                                                                                           
ha_monitoring_interval 60

Nous dirigeons Pandora FMS vers l'adresse IP virtuelle du maître (en remplaçant <IP> par l'adresse IP virtuelle) :

pandorafms# export VIRT_IP=<IP>
pandorafms# sed -i -e "s/^dbhost .*/dbhost $VIRT_IP/" \
/etc/pandora/pandora_server.conf
pandorafms# sed -i -e "s/\$config\[\"dbhost\"\]=\".*\";/\$config[\"dbhost\"]=\"$VIRT_IP\";/" \
/var/www/html/pandora_console/include/config.php

Nous avons installé et démarré le service pandora_ha :

pandorafms# cat > /etc/systemd/system/pandora_ha.service <<-EOF
[Unit]
Description=Pandora FMS Database HA Tool

[Service]
Type=forking

PIDFile=/var/run/pandora_ha.pid
Restart=always
ExecStart=/usr/bin/pandora_ha -d -p /var/run/pandora_ha.pid /etc/pandora/pandora_server.conf

[Install]
WantedBy=multi-user.target
EOF

pandorafms# systemctl enable pandora_ha
pandorafms# systemctl start pandora_ha

Connectez-vous à la console Pandora FMS et naviguez jusqu'à Serveurs → Gérer la base de données HA :

Cliquez sur Ajouter un nouveau nœud et créez une entrée pour le premier nœud :

Ensuite, on clique sur Create slave et on ajoute une nouvelle entrée dans le deuxième nœud. Ça devrait ressembler à quelque chose comme ça :

Nous avons installé Percona (voir Installation de Percona Installation_de_Percona). Nous faisons une sauvegarde de la base de données du noeud maître (noeud1 dans cet exemple) et nous écrivons le nom et la position du fichier journal maître (dans l'exemple, mysql-bin.000001 et 785) :

node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# cat /root/pandoradb.bak/xtrabackup_binlog_info 
mysql-bin.000001        785

Nous chargeons la base de données dans le nouveau noeud, que nous appellerons noeud3, et nous le configurons pour qu'il se réplique à partir du noeud1 (nous configurons MASTER_LOG_FILE et MASTER_LOG_POS aux valeurs de l'étape précédente) :

node3# systemctl stop mysqld

node1# rsync -avpP -e ssh /root/pandoradb.bak/ node3:/var/lib/mysql/

node3# chown -R mysql:mysql /var/lib/mysql
node3# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node3# systemctl start mysqld
node3# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node3-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB: pandora
             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: 785
                 Relay_Log_Space: 1252
                 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: 1
                     Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Master_Retry_Count: 86400
                     Master_Bind: 
         Last_IO_Error_Timestamp: 
        Last_SQL_Error_Timestamp: 
                  Master_SSL_Crl: 
              Master_SSL_Crlpath: 
              Retrieved_Gtid_Set: 
               Executed_Gtid_Set: 
                   Auto_Position: 0
            Replicate_Rewrite_DB: 
                    Channel_Name: 
              Master_TLS_Version: 
   1 row in set (0.00 sec)
mysql> QUIT

node3# systemctl stop mysqld

Nous ajoutons un nouveau nœud au cluster :

node3# echo -n hapass | passwd hacluster --stdin
node3# cd /usr/lib/ocf/resource.d/
node3# mkdir percona
node3# cd percona
node3# curl -L -o mysql https://github.com/Percona-Lab/\
pacemaker-replication-agents/raw/master/agents/mysql_prm
node3# chmod u+x mysql

 node1# pcs cluster auth -u hacluster -p hapass --force node3
 node1# pcs cluster node add --enable --start node3

Nous configurons clone-max au nombre de nœuds de notre cluster (3 dans cet exemple) :

node3# pcs resource update master_pandoradb meta master-max="1" \
master-node-max="1" clone-max="3" clone-node-max="1" notify="true" \
globally-unique="false" target-role="Master" is-managed="true"

Nous avons vérifié l'état du nœud :

node3# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun  1 10:55:47 2018
Last change: Fri Jun  1 10:55:09 2018 by root via crm_attribute on node3

3 nodes configured
3 resources configured

Online: [ node1 node2 node3 ]

Full list of resources:

pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
Master/Slave Set: master_pandoradb [pandoradb]
    Masters: [ node1 ]
    Slaves: [ node2 node3 ]

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Nous utiliserons le nœud 2 comme exemple. Nous avons mis le nœud 2 en mode veille :

node2# pcs node standby node2
node2# pcs status
    Cluster name: pandoraha
    Stack: corosync
    Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
    Last updated: Tue Jun 12 08:20:49 2018
    Last change: Tue Jun 12 08:20:34 2018 by root via cibadmin on node2
    
    2 nodes configured
    3 resources configured
    
    Node node2: standby
    Online: [ node1 ]
    
    Full list of resources:
    
     Master/Slave Set: master_pandoradb [pandoradb]
         Masters: [ node1 ]
         Stopped: [ node2 ]
     pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

Nous faisons une sauvegarde du répertoire de données de Percona :

node2# systemctl stop mysqld
node2# [ -e /var/lib/mysql.bak ] && rm -rf /var/lib/mysql.bak
node2# mv /var/lib/mysql /var/lib/mysql.bak

Nous faisons une sauvegarde de la base de données du noeud maître (noeud1 dans cet exemple) et nous écrivons le nom et la position du fichier journal maître (dans cet exemple, mysql-bin.000001 et 785) :

node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# cat /root/pandoradb.bak/xtrabackup_binlog_info 
mysql-bin.000001        785

Nous chargeons la base de données du noeud brisé et la configurons pour qu'elle se réplique à partir du noeud 1 (nous configurons MASTER_LOG_FILE et MASTER_LOG_POS aux valeurs de l'étape précédente) :

node1# rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/

node2# chown -R mysql:mysql /var/lib/mysql
node2# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node2# systemctl start mysqld
node2# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node2-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB: pandora
             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: 785
                 Relay_Log_Space: 1252
                 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: 1
                     Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Master_Retry_Count: 86400
                     Master_Bind: 
         Last_IO_Error_Timestamp: 
        Last_SQL_Error_Timestamp: 
                  Master_SSL_Crl: 
              Master_SSL_Crlpath: 
              Retrieved_Gtid_Set: 
               Executed_Gtid_Set: 
                   Auto_Position: 0
            Replicate_Rewrite_DB: 
                    Channel_Name: 
              Master_TLS_Version: 
   1 row in set (0.00 sec)
mysql> QUIT

node2# systemctl stop mysqld

Nous désactivons le mode de veille du nœud 2 :

node3# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun  1 10:55:47 2018
Last change: Fri Jun  1 10:55:09 2018 by root via crm_attribute on node3

2 nodes configured
3 resources configured

Online: [ node1 node2 ]

Full list of resources:

pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
Master/Slave Set: master_pandoradb [pandoradb]
    Masters: [ node1 ]
    Slaves: [ node2 ]

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Scénario.

Les deux serveurs sont considérés comme principaux ou Master, dans la vue de la console, les deux apparaissent comme principaux mais l'IP virtuelle n'est que sur un seul nœud (celui qui agit réellement comme principal ou Master).

À ce stade, si le token splitbrain_autofix est défini sur 1, le processus de récupération du nœud commencera dans splitbrain.

Pour que cette fonctionnalité fonctionne correctement, les composants suivants doivent être correctement configurés:

• Clés utilisateur root SSH partagées entre le serveur pandora_ha master et tous les serveurs de base de données.
• Utilisateur du réplicateur configuré dans le setup avec les droits (grants) du serveur Pandora HA où le serveur pandora_ha master est hébergé.

• Espace disponible pour la sauvegarde (backup) des bases de données sur les deux serveurs où sont hébergées les 2 bases de données (primaire et secondaire, Master/Slave).

Dans le cas où le datadir et le path où la partition doit être faite sont dans la même partition, il est nécessaire que l'espace libre soit d'au moins 50%.

Si tous les points ci-dessus sont correctement configurés, le processus de récupération est le suivant:

1. Supprimez les sauvegardes précédentes.
2. Sauvegarder le datadir du nœud secondaire.
3. Sauvegarde le nœud primaire.
4. Envoie la sauvegarde du nœud principal au nœud secondaire ( Master → Slave).
5. Inicia el recurso del nodo “slave” con los parámetros de resincronización correspondientes en el momento del backup.
6. Démarre la ressource du nœud “secondaire” avec les paramètres de resynchronisation correspondants au moment de la sauvegarde.
7. Vérifie que la ressource est active et correcte. Pour cela, il utilise la configuration indiquée dans les paramètres ha_max_resync_wait_retries et ha_resync_sleep.

En cas d'échec à un moment quelconque du processus, il répète le processus le nombre de fois indiqué par le paramètre ha_max_splitbrain_retries.

Une fois le processus terminé, un événement apparaîtra dans la vue des événements, indiquant que le processus s'est achevé avec succès.

Si l'environnement n'est toujours pas récupéré automatiquement, il laisse le nœud secondaire en veille et un événement apparaît indiquant que la récupération doit être effectuée manuellement dans la vue des événements.

Le service ne sera pas affecté tant que le nœud maître est en service. En cas de défaillance du nœud maître, un nœud esclave sera automatiquement mis à niveau vers le maître. Voir Réparation d'un noeud cassé.

Retour à l'index de documentation du Pandora FMS