Haute disponibilité (HA)

Dans des environnements critiques et/ou à forte charge, il peut être nécessaire de répartir la charge sur plusieurs machines et d'avoir la certitude que si un composant de Pandora FMS tombe en panne, le système reste en ligne.

Pandora FMS a été conçu pour être modulaire mais il est également conçu pour travailler en collaboration avec d'autres composants et être capable d'assumer la charge des composants défaillants.

Évidemment, les agents ne sont pas redondants. La solution est de redonder les systèmes critiques - qu'ils aient ou non des agents Pandora FMS en cours d'exécution - et de redonder ainsi la surveillance de ces systèmes.

On peut parler d'utiliser la Haute Disponibilité ( High Availability ou HA ) dans plusieurs scénarios :

• Serveur de données.
• Serveurs Réseau, WMI, Plugin, Web, Prediction, Recon et similaires.
• Base de données (BBDD).
• Console de Pandora FMS.

• Pour le serveur de données de Pandora FMS, il est nécessaire de monter deux machines avec un Pandora FMS data server configuré (et un hostname et un nom de serveur différents).
• Un serveur Tentacle devra être configuré sur chacun d'eux.
• Chaque machine aura une adresse IP différente.
• Si un équilibreur externe (load balancer) est utilisé, celui-ci fournira une adresse IP unique à laquelle les agents se connecteront pour envoyer leurs données.
• En cas d'utilisation du mécanisme HA des agents, il y aura un léger retard dans l'envoi des données, car à chaque exécution de l'agent, celui-ci tentera de se connecter au serveur primaire et, s'il ne répond pas, il le fera contre le secondaire (si configuré ainsi).

Si vous souhaitez utiliser deux serveurs de données et que tous deux gèrent des politiques, des collections et des configurations distantes, il faudra partager les répertoires clés pour que toutes les instances du data server puissent lire et écrire dans ces répertoires. Les consoles devront également avoir accès à ces répertoires partagés.

• /var/spool/pandora/data_in/conf
• /var/spool/pandora/data_in/collections
• /var/spool/pandora/data_in/md5
• /var/spool/pandora/data_in/netflow
• /var/www/html/pandora_console/attachment
• /var/spool/pandora/data_in/discovery

Depuis les EndPoints, il est possible d'effectuer un équilibrage de charge des serveurs de données car il est possible de configurer un serveur de données master (principal) et un autre de backup (sauvegarde opérationnelle). Dans le fichier de configuration de l'EndPoint pandora_agent.conf vous devez configurer et décommenter la partie suivante du fichier de configuration de l'agent :

• secondary_server_ip: Adresse IP du serveur secondaire.
• secondary_server_path: Chemin où les XML sont copiés sur le serveur secondaire, généralement /var/spool/pandora/data_in.
• secondary_server_port: Port par lequel les XML seront copiés vers le serveur secondaire, dans Tentacle 41121, dans SSH le port 22 et dans FTP 21.
• secondary_transfer_mode: Mode de transfert qui sera utilisé pour copier les XML vers le serveur secondaire, Tentacle, SSH, FTP.
• secondary_server_pwd: Option de mot de passe pour le transfert par FTP.
• secondary_server_ssl: Mettre yes ou no selon si l'on souhaite utiliser SSL pour transférer les données par Tentacle.
• secondary_server_opts: Dans ce champ, d'autres options nécessaires pour le transfert seront placées.
• secondary_mode: Mode dans lequel doit se trouver le serveur secondaire. Il peut avoir deux valeurs :

1. on_error: Envoie des données au serveur secondaire uniquement s'il ne peut pas les envoyer au principal.
2. always: Envoie toujours des données au serveur secondaire, indépendamment du fait qu'il puisse ou non contacter le serveur principal.

Il est nécessaire d'installer de multiples serveurs : serveur réseau, serveur WMI, serveur Plugin, serveur Web ou prediction, sur plusieurs machines du réseau (toutes avec la même visibilité vers les systèmes à surveiller) et qu'elles soient toutes 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 récupéreront automatiquement les données de tous les modules assignés à un serveur marqué comme “tombé”. Les serveurs Pandora FMS eux-mêmes implémentent un mécanisme pour détecter que l'un d'eux est tombé grâce à une vérification de sa dernière date de contact (server threshold x 2). Il suffit qu'un seul serveur Pandora FMS soit actif pour qu'il puisse détecter la chute des autres.

La façon évidente d'implémenter HA et un équilibrage de charge dans un système à deux nœuds est d'assigner 50 % des modules à chaque serveur et de marquer les deux serveurs comme principaux (Master). Dans le cas où il y a plus de deux serveurs principaux et un troisième serveur tombé avec des modules en attente d'exécution, le premier des serveurs principaux qui exécute le module s'“auto-assigne” le module du serveur tombé. En cas de récupération d'un des serveurs tombés, les modules qui avaient été assignés au serveur primaire sont automatiquement réassignés.

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

• Mode maître (mode principal ou mode MASTER).
• Mode non maître.

Si un serveur “tombe” (est hors ligne), ses modules seront exécutés par le serveur maître de manière à ce qu'aucune donnée ne soit perdue.

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

master [1..7]

Si le serveur maître actuel tombe, un nouveau maître est choisi. S'il y a plus d'un candidat, celui qui a la valeur la plus élevée dans master est choisi.

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

• ha_file: Adresse du fichier binaire temporaire de HA.
• ha_pid_file: Processus actuel de HA.
• pandora_service_cmd: Contrôle d'état du service de Pandora FMS.

Si vous disposez de la Haute Disponibilité dans la Base de Données, quelques configurations supplémentaires sont nécessaires pour connecter plus de serveurs Pandora FMS au cluster MySQL. Dans le fichier pandora_server.conf (situé par défaut dans /etc/pandora) de chacun des serveurs Pandora FMS indépendants à ajouter, les paramètres suivants doivent être configurés :

• dbuser: Vous devez avoir le nom d'utilisateur d'accès au cluster MySQL. Par exemple :

/etc/pandora/pandora_server.conf

dbuser pandora

• dbpass: Doit contenir le mot de passe de l'utilisateur d'accès au cluster MySQL. Par exemple :

/etc/pandora/pandora_server.conf

dbpass pandora

• ha_hosts: Le paramètre ha_host doit être configuré suivi des adresses IP ou FQDN des serveurs MySQL qui composent l'environnement HA. Exemple :

ha_hosts 192.168.80.170,192.168.80.172

Il suffit d'installer une autre console web pointant vers la base de données. N'importe laquelle des consoles pourra être utilisée simultanément depuis différents emplacements par différents utilisateurs. Vous pouvez utiliser un équilibreur de charge web devant les consoles si vous avez besoin d'une croissance horizontale pour la répartition de la charge sur la console. Le système de sessions est géré par des cookies et ceux-ci sont stockés dans le navigateur.

En cas d'utilisation d'une configuration distante et pour la gérer depuis toutes les consoles, les serveurs de données ainsi que les consoles doivent partager le répertoire de données d'entrée (par défaut : /var/spool/pandora/data_in) pour la configuration distante des agents, les collections et d'autres répertoires (voir le sujet "Architecture de sécurité").

• /var/spool/pandora/data_in/conf
• /var/spool/pandora/data_in/collections
• /var/spool/pandora/data_in/md5
• /var/spool/pandora/data_in/netflow
• /var/www/html/pandora_console/attachment
• /var/spool/pandora/data_in/discovery

Lors de la mise à jour de la console de Pandora FMS dans un environnement à Haute Disponibilité, il est important de prendre en compte les considérations suivantes lors de la mise à jour via OUM par le biais de Management → Warp update → Update offline. Le package OUM pourra être téléchargé depuis le site web de support de Pandora FMS.

Étant dans un environnement équilibré avec une base de données partagée, la mise à jour de la première console applique les modifications correspondantes dans la base de données. Cela provoque lors de la mise à jour de la deuxième console, l'affichage par Pandora FMS d'une erreur en trouvant les informations déjà insérées dans la base de données. Cependant, la mise à jour de la console sera réalisée de la même manière.

La nouvelle solution de HA de Pandora FMS est intégrée au produit (dans le binaire pandora_ha). Elle implémente une HA qui supporte des sites géographiquement isolés, avec différentes plages d'adresses IP, chose qui ne peut pas être réalisée avec Corosync/Pacemaker.

Dans le nouveau modèle de HA, la configuration habituelle est par paires, donc la conception n'implémente pas de système de quorum et simplifie la configuration et les ressources nécessaires. De cette façon, le système de surveillance fonctionnera toujours tant qu'un nœud de BDD disponible existera et en cas de Split-Brain de la BDD, le système fonctionnera en parallèle jusqu'à la fusion à nouveau des deux nœuds.

Avec la nouvelle proposition, on souhaite résoudre les trois problèmes actuels :

1. Complexité et maintenance du système actuel (jusqu'à la version NG 770).
2. Possibilité de disposer d'un environnement HA réparti dans des emplacements géographiques différents avec une segmentation réseau non locale.
3. Procédure de récupération des données en cas de Split-Brain et fonctionnement assuré du système en cas de rupture de la communication entre les deux sites séparés géographiquement.

Le nouveau système de HA pour BDD est implémenté sur Percona 8, bien que dans les versions successives, il sera détaillé comment le faire également sur MySQL/MariaDB 8.

Pandora FMS se base sur une base de données MySQL pour configurer et stocker des données, une défaillance de la base de données peut donc paralyser temporairement l'outil de surveillance. Le cluster de base de données à haute disponibilité de Pandora FMS permet de déployer facilement une architecture robuste et tolérante aux pannes.

Les nœuds du cluster MySQL de réplication binaire sont gérés avec le binaire pandora_ha, à partir de la version 770. Percona a été choisi comme RDBMS par défaut pour sa scalabilité, sa disponibilité, sa sécurité et ses fonctionnalités de sauvegarde (backup).

La réplication actif/passif est développée depuis un nœud maître unique (avec autorisation d'écriture) vers un nombre quelconque de secondaires (lecture seule). Si le nœud maître tombe en panne, l'un des secondaires est promu maître et pandora_ha se charge de mettre à jour l'adresse IP du nœud maître.

L'environnement sera formé des éléments suivants :

• Serveurs MySQL8 avec réplication binaire activée (Actif - Passif).
• Serveur avec pandora_ha avec la configuration de tous les serveurs MySQL pour effectuer une surveillance continue et effectuer les promotions esclave-maître et maître-esclave nécessaires au bon fonctionnement du cluster.

Avant toute chose, il est nécessaire d'avoir installé le dépôt Percona sur tous les nœuds de l'environnement afin de pouvoir réaliser ultérieurement l'installation des paquets du serveur Percona.

Exécuter sur tous les périphériques impliqués :

yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm

Activez la version 8 du dépôt Percona sur tous les périphériques :

percona-release setup ps80

Installez le serveur Percona avec l'outil de backup avec lequel les sauvegardes seront effectuées pour la synchronisation manuelle des deux environnements. Exécuter sur tous les périphériques impliqués :

yum install percona-server-server percona-xtrabackup-80

curl -Ls https://pfms.me/deploy-pandora-el8 | env MYVER=80 bash

Installez le dépôt Percona sur tous les périphériques :

curl -O https://repo.percona.com/apt/percona-release_latest.generic_all.deb
apt install -y gnupg2 lsb-release ./percona-release_latest.generic_all.deb

Activez la version 8 du dépôt Percona sur tous les périphériques :

percona-release setup ps80

Installez le serveur Percona avec l'outil de backup avec lequel les sauvegardes seront effectuées pour la synchronisation manuelle des deux environnements. Sur tous les périphériques, exécutez :

apt install -y percona-server-server percona-xtrabackup-80

L'utilisateur qui doit réaliser les étapes de ce guide sur les deux nœuds du HA est l'utilisateur root du système, il faut donc toujours vérifier que l'escalade de privilèges correspondante a été effectuée.

Entre les nœuds qui vont former le HA, il est nécessaire qu'il y ait une connectivité via SSH (numéro de port 22) et également entre leurs serveurs MySQL (3306).

De même, il est recommandé d'utiliser des hostnames descriptifs et la résolution DNS entre les machines.

Si vous souhaitez utiliser deux serveurs de données et que les deux gèrent les politiques, les collections et les configurations distantes, il faudra partager les répertoires clés pour que toutes les instances du Data Server puissent lire et écrire dans ces répertoires. Les Consoles devront également avoir accès à ces répertoires partagés. Par exemple en les partageant via NFS :

/var/spool/pandora/data_in/conf
/var/spool/pandora/data_in/collections
/var/spool/pandora/data_in/md5
/var/spool/pandora/data_in/netflow
/var/www/html/pandora_console/attachment
/var/spool/pandora/data_in/discovery

Nettoyage des MOTD et Banners.

Sur Rocky Linux 9 :

[ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
cp -a /etc/ssh/sshd_config{,.bak-$(date +%F)}
sed -i -e 's/^Banner.*/#Banner none/g' /etc/ssh/sshd_config
sed -i 's/^\s*session\s\+optional\s\+pam_motd\.so/#&/' /etc/pam.d/sshd
systemctl restart sshd

Sur Ubuntu 22.04 :

cp -a /etc/pam.d/sshd{,.bak-$(date +%F)}
sed -i 's/^session\s\+optional\s\+pam_motd.so/# &/' /etc/pam.d/sshd
chmod -x /etc/update-motd.d/*
systemctl restart sshd

a) Génération de clé RSA sans passphrase :

printf "\n\n\n" | ssh-keygen -t rsa -P ''

b) Copie d'identité (Bidirectionnelle et Réflexive) :

ssh-copy-id -p22 root@pandoraha1
ssh-copy-id -p22 root@pandoraha2

c) Vérifier qu'il ne demande pas de pass lors de la connexion SSH (Bidirectionnelle et Réflexive) :

ssh pandoraha1
ssh pandoraha2

Accéder à la console MySQL :

mysql -u root -p pandora
# Password by default: Pandor4!

Exécuter les requêtes SQL suivantes :

UNINSTALL COMPONENT 'file://component_validate_password';
CREATE USER replicationuser@'%' IDENTIFIED WITH mysql_native_password BY 'pandora';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO replicationuser@'%';
CREATE USER root@'%' IDENTIFIED WITH mysql_native_password BY 'Pandor4!';
GRANT ALL PRIVILEGES ON *.* TO root@'%';
CREATE USER pandora@'%' IDENTIFIED WITH mysql_native_password BY 'pandora';
GRANT ALL PRIVILEGES ON pandora.* TO pandora@'%';
FLUSH PRIVILEGES;
EXIT;

Configuration de la réplication binaire

Une fois le serveur MySQL installé sur tous les nœuds du cluster, on procède à la configuration dans les deux environnements pour les avoir répliqués.

Tout d'abord, le fichier de configuration my.cnf doit être configuré en le préparant pour que la réplication binaire fonctionne correctement.

Nœud 1

Nœud 1 /etc/my.cnf (/etc/mysql/my.cnf sur le serveur Ubuntu) :

[mysqld]
server_id=1 # It is important that it is different in all nodes.
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# OPTIMIZATION FOR PANDORA FMS
innodb_buffer_pool_size = 4096M
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
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
sql_mode=""
# SPECIFIC PARAMETERS FOR BINARY REPLICATION
binlog-do-db=pandora
replicate-do-db=pandora
max_binlog_size = 100M
binlog-format=ROW
binlog_expire_logs_seconds=172800 # 2 DAYS
#log-bin=/path                     # Uncomment for adding an additional storage path for binlogs and setting a new path
#log-bin-index=/path/archive.index # Uncomment for adding an additional storage path for binlogs and setting a new path
sync_source_info=1
sync_binlog=1
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 = 0
replica_compressed_protocol = 1
replica_parallel_workers = 1
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 1800

[client]
user=root
password=pandora

• Les token à la suite du commentaire OPTIMIZATION FOR PANDORA FMS effectuent la configuration optimisée pour Pandora FMS.
• Après le commentaire SPECIFIC PARAMETERS FOR BINARY REPLICATION, les paramètres spécifiques pour la réplication binaire sont configurés.
• Le token appelé binlog_expire_logs_seconds est configuré pour une période de deux jours.
• Dans la sous-section [client], placez l'utilisateur et le mot de passe utilisés pour la base de données, par défaut lors de l'installation de PFMS ce sont root et pandora respectivement. Ces valeurs sont nécessaires pour la réalisation des sauvegardes sans indiquer d'utilisateur (automatisé).

Nœud 2

Nœud 2 /etc/my.cnf (/etc/mysql/my.cnf sur le serveur Ubuntu) :

[mysqld]
server_id=2 # It is important that it is different in all nodes.
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# OPTIMIZATION FOR PANDORA FMS
innodb_buffer_pool_size = 4096M
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
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
sql_mode=""
# SPECIFIC PARAMETERS FOR BINARY REPLICATION
binlog-do-db=pandora
replicate-do-db=pandora
max_binlog_size = 100M
binlog-format=ROW
binlog_expire_logs_seconds=172800 # 2 DAYS
#log-bin=/path                     # Uncomment for adding an additional storage path for binlogs and setting a new path
#log-bin-index=/path/archive.index # Uncomment for adding an additional storage path for binlogs and setting a new path
sync_source_info=1
sync_binlog=1
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 = 0
replica_compressed_protocol = 1
replica_parallel_workers = 1
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 1800

[client]
user=root
password=pandora

• Les token à la suite du commentaire OPTIMIZATION FOR PANDORA FMS effectuent la configuration optimisée pour Pandora FMS.
• Après le commentaire SPECIFIC PARAMETERS FOR BINARY REPLICATION, les paramètres spécifiques pour la réplication binaire sont configurés.
• Le token appelé binlog_expire_logs_seconds est configuré pour une période de deux jours.
• Dans la sous-section [client], placez l'utilisateur et le mot de passe utilisés pour la base de données, par défaut lors de l'installation de PFMS ce sont root et pandora respectivement. Ces valeurs sont nécessaires pour la réalisation des sauvegardes sans indiquer d'utilisateur (automatisé).

Il est nécessaire de redémarrer MySQL pour que les modifications soient prises en compte :

Exécuter sur les deux nœuds

Sur Rocky Linux 9 :

systemctl restart mysqld

Sur Ubuntu 22.04 :

systemctl restart mysql

Clonage de la base de données : L'étape suivante consiste à faire un clone de la base de données maître (MASTER) sur le nœud esclave (SLAVE). Pour ce faire, suivez les étapes suivantes :

1.- Faire un téléchargement (dump) complet de la base de données MASTER :

MASTER #

xtrabackup --backup --target-dir=/root/pandoradb.bak/

MASTER #

xtrabackup --prepare --target-dir=/root/pandoradb.bak/

2.- Obtenez la position du log binaire à partir du backup :

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

Cela renverra quelque chose de similaire à ce qui suit :

binlog.000003 157

Prenez note de ces deux valeurs car elles sont nécessaires pour le point numéro 6.

Arrêter le service MySQL sur le Serveur Slave :

Sur Rocky Linux 9 :

systemctl stop mysqld

Sur Ubuntu 22.04 :

systemctl stop mysql

Effacer TOUT le contenu (Supprimer la BDD par défaut) :

rm -rf /var/lib/mysql/*

Afin d'éviter des problèmes, nous arrêterons également le service pandora_ha sur les deux nœuds.

systemctl stop pandora_ha

3.- Faites une copie en utilisant rsync avec le serveur SLAVE pour envoyer le backup réalisé :

MASTER # rsync -avpP -e ssh /root/pandoradb.bak/ pandoraha2:/var/lib/mysql/

4.- Sur le serveur SLAVE, configurez les permissions pour que le serveur MySQL puisse accéder sans problème aux fichiers envoyés :

SLAVE # chown -R mysql:mysql /var/lib/mysql

SLAVE # chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql

5.- Démarrez le service mysqld sur le serveur SLAVE :

systemctl start mysqld

6.- Démarrez le mode SLAVE sur ce serveur (utilisez les données notées au point numéro 2) :

SLAVE # mysql -u root -ppandora

SLAVE # mysql > reset slave all;

SLAVE # mysql >

CHANGE MASTER TO MASTER_HOST='pandoraha1',
 MASTER_USER='replicationuser',
 MASTER_PASSWORD='pandora',
 MASTER_LOG_FILE='binlog.000003',
 MASTER_LOG_POS=157;

SLAVE # mysql > start slave;

SLAVE # mysql > SET GLOBAL read_only=1;

Une fois que vous avez terminé toutes ces étapes, si vous exécutez la commande show slave status dans le shell de MySQL, vous observerez que le nœud est en mode slave. S'il a été configuré correctement, vous devriez observer une sortie comme celle-ci :

*************************** 1. row ***************************
Slave_IO_State: Waiting for source to send event
Master_Host: pandoraha1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000018
Read_Master_Log_Pos: 1135140
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 1135306
Relay_Master_Log_File: binlog.000018
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: 1135140
Relay_Log_Space: 1135519
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: fa99f1d6-b76a-11ed-9bc1-000c29cbc108
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Replica 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:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set, 1 warning (0,00 sec)

Si vous utilisez MySQL 8.4, les commandes changent légèrement :

sudo mysql -u root

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='pandoraha1', -- Enter the IP or dns address of your MASTER MySQL server
SOURCE_USER='replicationuser', -- Enter the replication username
SOURCE_PASSWORD='pandora', -- Enter the replication password
SOURCE_LOG_FILE='binlog.000003', -- Update to the values retrieved on previous step
SOURCE_LOG_POS=157 -- Update to the values retrieved on previous step
;

Nous démarrons la réplique et vérifions que tout est correct :

STOP REPLICA;
 
START REPLICA;
SHOW REPLICA STATUS\G

Nous vérifions que la réplique est correcte, en exécutant la commande show slave status et en confirmant la sortie :

      Replica_IO_Running: Yes
      Replica_SQL_Running: Yes

Les deux doivent être sur Yes.

À partir de ce moment, on pourrait assurer que la réplication binaire est activée et fonctionne correctement.

Il est nécessaire de configurer dans le fichier pandora_server.conf une série de paramètres nécessaires au bon fonctionnement de pandora_ha.

Les paramètres à ajouter sont les suivants :

• ha_hosts <IP_ADDRESS1>,<IP_ADDRESS2>:

Le paramètre ha_host doit être configuré suivi des adresses IP ou FQDN des serveurs MySQL qui composent l'environnement HA. L'adresse IP que vous placez en premier aura la préférence pour être le serveur MASTER ou a au moins le rôle de maître lors du premier démarrage de l'environnement HA. Exemple :

ha_hosts 192.168.80.170,192.168.80.172

• ha_dbuser y ha_dbpass:

Ce sont les paramètres où vous devez indiquer l'utilisateur et le mot de passe de l'utilisateur root ou, à défaut, d'un utilisateur MySQL avec les privilèges maximums qui sera chargé d'effectuer toutes les opérations de promotion master - slave sur les nœuds. Exemple :

ha_dbuser root
ha_dbpass pandora

• repl_dbuser y repl_dbpass:

Paramètres pour définir l'utilisateur de réplication que le SLAVE utilisera pour se connecter au MASTER. Exemple :

repl_dbuser replicationuser
repl_dbpass pandora

• ha_sshuser y ha_sshport:

Paramètres pour définir l'utilisateur/port avec lequel se connecter par ssh aux serveurs Percona/MySQL pour effectuer les opérations de récupération. Pour le bon fonctionnement de cette option, il est nécessaire d'avoir partagé les clés ssh entre l'utilisateur avec lequel le service pandora_ha est exécuté et l'utilisateur indiqué dans le paramètre ha_sshuser. Exemple :

ha_sshuser root
ha_sshport 22

• ha_resyncPATH_SCRIPT_RESYNC:

Par défaut, le script pour réaliser la resynchronisation des nœuds se trouve dans :

/usr/share/pandora_server/util/pandora_ha_resync_slave.sh

Dans le cas où vous avez une installation personnalisée du script, indiquez dans ce paramètre son emplacement pour que la synchronisation automatique ou manuelle du nœud SLAVE soit effectuée lorsque cela est nécessaire.

ha_resync /usr/share/pandora_server/util/pandora_ha_resync_slave.sh

• ha_resync_log:

Chemin du log où sera sauvegardée toute l'information relative aux exécutions réalisées par le script de synchronisation configuré dans le token précédent. Exemple :

ha_resync_log /var/log/pandoraha_resync.log

• ha_connect_retries:

Nombre de tentatives qu'il réalisera à chaque vérification avec chacun des serveurs de l'environnement HA avant d'effectuer toute modification dans l'environnement. Exemple :

ha_connect_retries 2

Une fois tous ces paramètres configurés, vous pourrez démarrer le serveur de Pandora FMS avec le service pandora_ha. Le serveur obtiendra une image de l'environnement et saura à ce moment-là qui est le serveur MASTER.

Lorsqu'il le saura, il créera le fichier pandora_ha_hosts.conf dans le dossier /var/spool/pandora/data_in/conf/, où sera indiqué à tout moment le serveur Percona/MySQL qui a le rôle de MASTER.

Dans le cas où le paramètre incomingdir du fichier pandora_server.conf contient un chemin (PATH) différent, ce fichier sera situé dans ce PATH.

Ce fichier sera utilisé comme échange avec la Console Pandora FMS afin qu'elle connaisse à tout moment l'adresse IP du serveur Percona/MySQL avec le rôle de MASTER.

• restart:

Il sera indiqué avec une valeur de 0, car le daemon de pandora_ha est chargé de redémarrer le service en cas de panne et de cette façon, d'éventuels conflits sont évités. Exemple :

# Pandora FMS will restart after restart_delay seconds on critical errors.
restart 0

• ha_backup_source_dir:

Répertoire qui contiendra les données de sauvegarde de HA. Valeur par défaut : /var/tmp.

• ha_mysql_source_dir:

Répertoire contenant les données MySQL. Valeur par défaut : /var/lib.

Une fois les modifications effectuées dans le fichier de configuration, nous démarrons pandora_ha sur les deux nœuds :

systemctl start pandora_ha

Le fichier config.php de la Console situé dans

/var/www/html/pandora_console/include/

doit être configuré et la valeur suivante ajoutée :

$config["remote_config"] = "/var/spool/pandora/data_in";

Ressemblant à ceci :

Avec cela, Pandora FMS lira le fichier

/var/spool/pandora/data_in/conf/pandora_ha_hosts.conf

d'où il obtiendra l'adresse IP pour faire la connexion.

Un nouveau paramètre a été ajouté à la configuration de config.php indiquant le chemin du répertoire d'échange que Pandora FMS utilise par défaut /var/spool/pandora/data_in.

S'il est configuré, il cherchera le fichier /var/spool/pandora/data_in/conf/pandora_ha_hosts.conf d'où il obtiendra l'adresse IP pour établir la connexion.

$config["remote_config"] = "/var/spool/pandora/data_in";

Dans la console de Pandora FMS, vous pourrez visualiser l'état du cluster en accédant à la vue de Manage HA.

https://PANDORA_IP/pandora_console/index.php?sec=gservers&sec2=enterprise/godmode/servers/HA_cluster

Les données de cette vue sont constamment mises à jour grâce à pandora_ha, il n'y a aucune procédure de configuration préalable à réaliser pour pouvoir visualiser cette section tant que le pandora_server.conf est correctement configuré avec les paramètres mentionnés dans la section précédente.

Parmi les actions disponibles, il est possible de configurer une étiquette pour chacun des nœuds et on peut effectuer l'option de synchroniser le nœud SLAVE via l'icône.

Cette icône peut avoir les états suivants :

• Vert : Normal, aucune opération à effectuer.
• Bleu : En attente de resynchronisation.
• Jaune : La resynchronisation est en cours.
• Rouge : Erreur, la resynchronisation a échoué.

Une fois que les étapes décrites précédemment ont été suivies, nous pouvons vérifier l'état du cluster en accédant à la vue de gestion de HA :

https://PANDORA_IP/pandora_console/index.php?sec=gservers&sec2=enterprise/godmode/servers/new_HA_cluster

Dans celle-ci, nous verrons des informations sur l'état de la connexion et de la réplication :

• IP: Adresses IP des nœuds qui forment le cluster.
• Node label: Étiquettes d'identification qui peuvent être configurées pour les nœuds.
• SQL Node status: État du service MySQL.
• SSH: État de la connexion SSH.
• Replication Status: État de la réplication.
• DB Role: Les rôles dans les nœuds qui forment le cluster pour identifier le Master.
• Delay: Temps de delay ou ce que prend le nœud non Master pour recevoir les modifications de la BDD.
• Last Update: Heure de la dernière mise à jour.
• SQL version: Version installée de MySQL.
• DB version: Version installée du schéma dans la BDD de PandoraFMS.

Dans la dernière colonne de la vue de HA, nous avons différentes actions que nous pouvons exécuter :

• Est utilisé pour modifier le champ Node label.
• Est utilisé pour désactiver/activer le nœud slave.
• Est utilisé pour lancer la resynchronisation depuis la console et peut avoir les états suivants :

1. Vert : Normal, aucune opération à effectuer.
2. Bleu : En attente de resynchronisation.
3. Jaune : La resynchronisation est en cours.
4. Rouge : Erreur, la resynchronisation a échoué.

Utilisation du script de synchronisation : Avec le serveur de Pandora FMS, un script est implémenté qui vous permet de synchroniser la base de données SLAVE au cas où elle serait désynchronisée.

L'exécution manuelle de ce script est la suivante :

./pandora_ha_resync_slave.sh "pandora_server.conf file" MASTER SLAVE

Par exemple, pour effectuer une synchronisation manuelle du nœud 1 vers le nœud 2, l'exécution serait la suivante :

/usr/share/pandora_server/util/pandora_ha_resync_slave.sh \ 
 /etc/pandora/pandora_server.conf \ 
 pandoraha1 \ 
 pandoraha2

Pour configurer la récupération automatique de l'environnement HA en cas de problème de synchronisation entre MASTER et SLAVE, il est nécessaire d'avoir le token de configuration splitbrain_autofix configuré à 1, dans le fichier de configuration du serveur (/etc/pandora/pandora_server.conf).

Ainsi, chaque fois qu'un Split-Brain se produit (les deux serveurs ont le rôle de maître) ou qu'il y a un problème de synchronisation entre le nœud MASTER et SLAVE, pandora_ha tentera de lancer le script pandora_ha_resync_slave.sh pour synchroniser à partir de ce moment l'état du serveur MASTER sur le serveur SLAVE.

Ce processus générera des événements dans le système indiquant le début, la fin et si une erreur s'y est produite.

La principale différence qui existe entre un environnement HA utilisé dans la version 5 de MySQL/Percona Server avec le mode HA actuel est que maintenant pandora_ha est utilisé pour gérer les nœuds du cluster au détriment de Corosync-Pacemaker, qui cesseront désormais d'être utilisés.

La migration de l'environnement consistera en :

1.- Mettre à jour Percona de la version 5.7 vers la version 8.0 : “Installation et mise à jour vers MySQL 8”.

2.- Installer xtrabackup-80 sur tous les périphériques :

yum install percona-xtrabackup-80

Si un serveur Ubuntu est utilisé, voir la section “Installation de Percona 8 pour Ubuntu Server”.

3.- Créer tous les utilisateurs de nouveau avec le token mysql_native_password sur le nœud MASTER.

mysql > CREATE USER replicationuser@% IDENTIFIED WITH mysql_native_password BY 'pandora';

mysql > GRANT REPLICATION CLIENT, REPLICATION SLAVE on *.* to replicationuser@%;

mysql > CREATE USER pandora@% IDENTIFIED WITH mysql_native_password BY 'pandora';

mysql > grant all privileges on pandora.* to pandora@%;

4.- Faire le vidage (dump) de la base de données depuis le nœud MASTER vers le SLAVE :

4.1.- Faire un dump complet de la base de données du MASTER :

MASTER #

xtrabackup --backup --target-dir=/root/pandoradb.bak/

MASTER #

xtrabackup --prepare --target-dir=/root/pandoradb.bak/

4.2.- Obtenez la position du log binaire à partir du backup :

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

binlog.000003 157

Prenez note de ces deux valeurs car elles sont nécessaires au point 4.6.

4.3.- Effectuez une synchronisation avec rsync avec le serveur SLAVE pour envoyer le backup réalisé.

SLAVE # rm -rf /var/lib/mysql/*

MASTER # rsync -avpP -e ssh /root/pandoradb.bak/ pandoraha2:/var/lib/mysql/

4.4- Sur le serveur SLAVE, configurez les permissions pour que le serveur MySQL puisse accéder sans problème aux fichiers envoyés.

SLAVE # chown -R mysql:mysql /var/lib/mysql

SLAVE # chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql

4.5.- Démarrez le service mysqld sur le serveur SLAVE.

systemctl start mysqld

4.6.- Démarrez le mode SLAVE sur ce serveur (utilisez les données du point 4.2) :

SLAVE # mysql -u root -ppandora

SLAVE # mysql > reset slave all;

SLAVE # mysql >

CHANGE MASTER TO MASTER_HOST='pandoraha1',
MASTER_USER='replicationuser', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='binlog.000003', MASTER_LOG_POS=157;

SLAVE # mysql > start slave;

SLAVE # mysql > SET GLOBAL read_only=1;

Dans le cas où vous souhaitez installer l'environnement à partir de zéro sur un nouveau serveur, dans la procédure de migration, il suffit de l'installer à partir de zéro tel qu'indiqué par la procédure actuelle dans le nouvel environnement, et à l'étape de création de la base de données Pandora FMS, les données doivent être importées avec un backup de la base de données de l'ancien environnement.

À son tour, il sera nécessaire d'enregistrer dans le nouvel environnement la configuration de la Console et du Serveur Pandora FMS indiquées dans les sections précédentes.

En raison de divers facteurs, de latences élevées, de coupures de réseau, etc., on peut constater que les deux serveurs MySQL ont acquis le rôle de maître et nous n'avons pas l'option autoresync activée dans pandora_ha pour que le serveur lui-même choisisse le serveur qui agira comme maître et effectue la synchronisation du nœud maître vers l'esclave, perdant ainsi toutes les informations qui auraient pu être collectées sur ce serveur.

Pour résoudre ce problème, les données peuvent être fusionnées (merge) en suivant cette procédure.

Si de nouveaux agents sont créés pendant la période de Split-Brain, ou de nouvelles informations de configuration (alertes, politiques, etc.) celles-ci ne seront pas prises en compte. Seules les données et les événements seront récupérés. C'est-à-dire les données relatives aux tables tagente_datos, tagente_datos_string et tevento.

Les commandes suivantes seront exécutées sur le nœud qui a été déconnecté (celui qui sera promu en SLAVE), où yyyy-mm-dd hh:mm:ss est la date et l'heure de début du Split-Brain et yyyy2-mm2-dd2 hh2:mm2:ss2 sa date et heure de fin.

Exécutez la commande mysqldump avec les droits d'utilisateur appropriés pour obtenir un téléchargement de données (data dump ou simplement dump) :

mysqldump -u root -p -n -t --skip-create-options --databases pandora --tables tagente_datos --where='FROM_UNIXTIME(utimestamp)> "yyyy-mm-dd hh:mm:ss" AND FROM_UNIXTIME(utimestamp) <"yyyy2-mm2-dd2 hh2:mm2:ss2"'> tagente_datos.dump.sql

mysqldump -u root -p -n -t --skip-create-options --databases pandora --tables tagente_datos_string --where='FROM_UNIXTIME(utimestamp)> "yyyy-mm-dd hh:mm:ss" AND FROM_UNIXTIME(utimestamp) <"yyyy2-mm2-dd2 hh2:mm2:ss2"'> tagente_datos_string.dump.sql

mysqldump -u root -p -n -t --skip-create-options --databases pandora --tables tevento --where='FROM_UNIXTIME(utimestamp)> "yyyy-mm-dd hh:mm:ss" AND FROM_UNIXTIME(utimestamp) <"yyyy2-mm2-dd2 hh2:mm2:ss2"' | sed -e "s/([0-9]*,/(NULL,/gi"> tevento.dump.sql

Une fois les dumps de ces tables obtenus, ces données seront chargées sur le nœud MASTER :

MASTER # cat tagente_datos.dump.sql | mysql -u root -p pandora

MASTER # cat tagente_datos_string.dump.sql | mysql -u root -p pandora

MASTER # cat tagente_evento.dump.sql | mysql -u root -p pandora

Après avoir chargé les données récupérées du nœud à promouvoir en SLAVE, on procédera à sa synchronisation en utilisant la procédure suivante :

0.- Supprimer le répertoire /root/pandoradb.bak/ sur le MASTER.

1.- Faire un dump complet de la BDD du Maître :

MASTER #

xtrabackup --backup --target-dir=/root/pandoradb.bak/

MASTER #

xtrabackup --prepare --target-dir=/root/pandoradb.bak/

2.- Obtenez la position du log binaire des données sauvegardées (backup) :

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

Vous obtiendrez quelque chose de similaire à ce qui suit (prenez dûment note de ces valeurs) :

binlog.000003   157

À ce stade sur le SLAVE, le contenu de /var/lib/mysql/ doit être nettoyé comme indiqué là-bas au point 4.3 :

SLAVE # rm -rf /var/lib/mysql/*

3.- Faites une tâche avec la commande rsync avec le serveur slave pour envoyer ainsi le backup réalisé.

MASTER # rsync -avpP -e ssh /root/pandoradb.bak/ pandoraha2:/var/lib/mysql/

4.- Sur le serveur esclave, configurez les permissions pour que le serveur MySQL puisse accéder sans problème aux fichiers envoyés.

SLAVE # chown -R mysql:mysql /var/lib/mysql

SLAVE # chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql

5.- Nous démarrons le service mysqld sur le serveur esclave.

systemctl start mysqld

6.- Démarrez le mode esclave sur ce serveur.

SLAVE # mysql -u root -ppandora

SLAVE # mysql > reset slave all;

SLAVE # mysql > CHANGE MASTER TO MASTER_HOST='pandoraha1', MASTER_USER='replicationuser', MASTER_PASSWORD='pandora', MASTER_LOG_FILE='binlog.000003', MASTER_LOG_POS=157;

SLAVE # mysql > start slave;

SLAVE # mysql > SET GLOBAL read_only=1;

Une fois toutes ces étapes terminées, si nous exécutons la commande show slave status dans le shell de MySQL, vous observerez que le nœud est en mode slave. S'il a été configuré correctement, vous devriez observer une sortie comme dans l'exemple suivant :

*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: pandoraha1
                  Master_User: root
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000018
          Read_Master_Log_Pos: 1135140
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 1135306
        Relay_Master_Log_File: binlog.000018
             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: 1135140
              Relay_Log_Space: 1135519
              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: fa99f1d6-b76a-11ed-9bc1-000c29cbc108
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Replica 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:
       Master_public_key_path:
        Get_master_public_key: 0
            Network_Namespace:
1 row in set, 1 warning (0,00 sec)

← Retour à l'index de la documentation de Pandora FMS