Haute disponibilité (HA)

Dans des environnements critiques et/ou avec beaucoup de charge, il peut être nécessaire de répartir la charge sur plusieurs machines et de s'assurer qu'en cas de défaillance d'un composant de Pandora FMS, le système reste en ligne.

Pandora FMS a été conçu pour être modulaire mais il est également conçu pour fonctionner en collaboration avec d'autres composants et pour pouvoir assumer la charge de ces composants qui sont tombés.

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

Vous pouvez parler de l'utilisation de la haute disponibilité ( High Availability ou HA ) dans plusieurs scénarios :

• Serveur de données.
• Serveurs réseau, WMI, Plugin, Web, Prédiction, Recon, etc.
• Base de données (BBDD).
• Console Pandora FMS.

• Pour le serveur de données Pandora FMS, il est nécessaire de monter deux machines avec un serveur de données Pandora FMS configuré (et un nom d'hôte et un nom de serveur différents).
• Un serveur Tentacle devra être configuré dans chacun d'eux.
• Chaque machine aura une adresse IP différente.
• Si vous allez utiliser un équilibreur externe, il fournira une adresse IP unique à laquelle les agents se connecteront pour envoyer leurs données.
• Dans le cas de l'utilisation du mécanisme HA des agents, il y aura un petit retard dans l'envoi des données, car à chaque exécution de l'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é de cette façon).

Si vous souhaitez utiliser deux serveurs de données et que les deux gèrent les stratégies, les collections et les configurations à distance, vous devrez partager les répertoires de clés afin que toutes les instances de serveur de données puissent lire et écrire dans ces répertoires. Les consoles doivent é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

A partir des Agents Logiciels, il est possible d'effectuer un équilibrage des serveurs de données puisqu'il est possible de configurer un serveur de données maître (principal) et un de sauvegarde (sauvegarde opérationnelle). Dans le fichier de configuration de l'agent logiciel pandora_agent.conf vous devez configurer et décommenter la partie suivante du fichier de configuration de l'agent :

• secondary_mode: Mode dans lequel le serveur secondaire doit être. Il peut avoir deux valeurs :
  • on_error: envoie des données au serveur secondaire uniquement s'il ne peut pas les envoyer au serveur principal.
  • always: envoie toujours des données au serveur secondaire, qu'il puisse ou non contacter le serveur principal.
• secondary_server_ip: adresse IP du serveur secondaire.
• secondary_server_path: chemin où le XML est copié sur le serveur secondaire, généralement /var/spool/pandora/data_in.
• secondary_server_port: Port par lequel le XML sera copié sur le serveur secondaire, dans Tentacle 41121, dans le port SSH 22 et dans FTP 21.
• secondaire_transfer_mode : Mode de transfert qui sera utilisé pour copier le XML vers le serveur secondaire, Tentacle, SSH, FTP.
• secondary_server_pwd: option de mot de passe pour le transfert FTP.
• secondary_server_ssl: définissez oui ou non selon que vous souhaitez utiliser SSL pour transférer des données via Tentacle.
• secondary_server_opts: Les autres options nécessaires au transfert seront mises dans ce champ.

Vous devez installer plusieurs servers : serveur de réseau, serveur WMI, serveur de plug-in, serveur Web ou prédiction, sur différentes machines du réseau (toutes avec la même visibilité sur les systèmes que vous souhaitez surveiller) et qu'elles soient toutes dans le même segment (afin que les données de latence du réseau soient cohérentes).

Les serveurs peuvent être marqués comme principal. Ces serveurs collecteront automatiquement les données de tous les modules affectés à un serveur marqué “down”. Les serveurs Pandora FMS implémentent eux-mêmes un mécanisme pour détecter que l'un d'entre eux est tombé grâce à une vérification de sa date de dernier contact (seuil serveur x 2). Il suffit qu'il n'y ait qu'un seul serveur Pandora FMS actif pour qu'il puisse détecter la panne du reste.

La manière évidente d'implémenter la haute disponibilité et l'équilibrage de charge dans un système à deux nœuds consiste à attribuer 50 % des modules à chaque serveur et à marquer les deux serveurs comme maîtres. Dans le cas de plus de deux serveurs principaux et d'un troisième serveur en panne avec des modules en attente d'exécution, le premier des serveurs principaux qui exécute le module « s'auto-attribue » 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.

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 en panne » (est hors ligne), ses modules seront exécutés par le serveur maître afin qu'aucune donnée ne soit perdue.

À tout moment, il ne peut y avoir qu'un seul serveur maître, 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 tombe en panne, un nouveau maître est élu. S'il y a plus d'un candidat, celui avec la valeur maître la plus élevée est choisi.

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

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

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

• dbuser : Vous devez avoir le nom d'utilisateur pour accéder au cluster MySQL. Par exemple:

dbuser pandora

• dbpass : Il doit contenir le mot de passe de l'utilisateur pour accéder au cluster MySQL. Par exemple:

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

Juste installer une autre console pointant vers la base de données. Chacune des consoles peut être utilisée simultanément à partir de différents emplacements par différents utilisateurs. Un équilibreur de charge Web peut être utilisé devant les consoles si vous devez vous développer horizontalement pour le partage de charge sur 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 la gérer à partir de toutes les consoles, les serveurs de données et les consoles doivent partager le répertoire des données d'entrée (par défaut : /var/spool/pandora/data_in) pour la configuration à distance des agents, collections et autres répertoires.

Lors de la mise à jour de la console 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 via Management → Warp update → Update offline .

Les utilisateurs de la version Enterprise peuvent télécharger le package OUM à partir du site Web d'assistance de Pandora FMS.

Étant dans un environnement équilibré avec une base de données partagée, la première mise à niveau de la console applique les modifications correspondantes à la base de données. Cela fait que lors de la mise à jour de la deuxième console, Pandora FMS affiche une erreur lors de la recherche des informations déjà insérées dans la base de données. Cependant, la mise à jour de la console s'effectuera de la même manière.

La nouvelle solution Pandora FMS HA est intégrée au produit (au sein du binaire pandora_ha). Il implémente une HA qui prend en charge des sites géographiquement isolés, avec différentes plages d'IP, ce qui ne peut pas être fait avec Corosync/Pacemaker.

Dans le nouveau modèle HA, la configuration habituelle est par paires de deux, de sorte que la conception n'implémente passystème de quorum et simplifie la configuration et les ressources nécessaires. De cette manière, le système de surveillance fonctionnera chaque fois qu'un nœud de base de données sera disponible et s'il existe un Split-Brain de la base de données, le système fonctionnera en parallèle jusqu'à ce que les deux nœuds soient à nouveau fusionnés.

Avec la nouvelle proposition, nous voulons résoudre les trois problèmes actuels :

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

Le nouveau système HA pour les bases de données est implémenté sur Percona 8, bien que les versions successives détailleront également comment le faire sur MySQL/MariaDB 8.

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

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

Actif/passif replication actif/passif se développe à partir d'un seul nœud maître (avec autorisation d'écriture) vers un nombre quelconque de nœuds secondaires (en lecture seule). Si le nœud maître tombe en panne, l'un des nœuds secondaires devient maître et pandora_ha se charge de mettre à jour l'adresse IP du nœud maître.

L'environnement sera composé 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.

Tout d'abord, il est nécessaire d'avoir le référentiel Percona installé sur tous les nœuds de l'environnement afin d'installer ultérieurement les packages du serveur Percona.

Exécutez sur tous les appareils concernés :

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

Activez la version 8 du référentiel Percona sur tous les appareils :

percona-release setup ps80

Installez le serveur Percona avec l'outil de sauvegarde avec lequel les sauvegardes seront effectuées pour la synchronisation manuelle des deux environnements. Exécutez sur tous les appareils concernés :

yum installer 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 appareils :

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 référentiel Percona sur tous les appareils :

percona-release setup ps80

Installez le serveur Percona avec l'outil de sauvegarde avec lequel les sauvegardes seront effectuées pour la synchronisation manuelle des deux environnements. Sur tous les appareilsexécutez-les :

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

Une fois que vous avez installé le serveur MySQL sur tous les nœuds du cluster, procédez à la configuration des deux environnements pour les répliquer.

Tout d'abord, vous devez configurer le fichier de configuration my.cnf en vue du bon fonctionnement de la réplication binaire.

Noeud 1 /etc/my.cnf ( /etc/mysql/my.cnf sur le serveur Ubuntu) :

[mysqld]
server_id=1 # Il est important qu'il soit différent dans tous les nœuds.
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# OPTIMISATION POUR 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_connexions = 200
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
sql_mode=""
# PARAMÈTRES SPÉCIFIQUES À LA RÉPLICATION BINAIRE
binlog-do-db=pandore
replica-do-db=pandore
max_binlog_size = 100M
binlog-format=MIXTE
binlog_expire_logs_seconds=172800 # 2 JOURS
sync_source_info=1
sync_binlog=1
port=3306
rapport-port=3306
rapport-hôte=maître
gtid-mode=off
appliquer-gtid-consistance=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]
utilisateur=racine
mot de passe=pandore

• Les jetons après le commentaire OPTIMISATION POUR PANDORA FMS effectuent la configuration optimisée pour Pandora FMS.
• Après le commentaire PARAMETRES SPECIFIQUES A LA REPLICATION BINAIRE les paramètres spécifiques à la réplication binaire sont configurés.
• Le jeton nommé binlog_expire_logs_seconds est défini sur une période de deux jours.
• Dans la sous-section [client], placez le nom d'utilisateur et le mot de passe utilisés pour la base de données, par défaut lors de l'installation de PFMS, ils sont respectivement root et pandora. Ces valeurs sont nécessaires pour effectuer des sauvegardes sans indiquer l'utilisateur (automatisé).

Noeud 2 /etc/my.cnf ( /etc/mysql/my.cnf sur le serveur Ubuntu)

[mysqld]
server_id=2 # Il est important qu'il soit différent dans tous les nœuds.
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# OPTIMISATION POUR 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_connexions = 200
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
sql_mode=""
# PARAMÈTRES SPÉCIFIQUES À LA RÉPLICATION BINAIRE
binlog-do-db=pandore
replica-do-db=pandore
max_binlog_size = 100M
binlog-format=MIXTE
binlog_expire_logs_seconds=172800 # 2 JOURS
sync_source_info=1
sync_binlog=1
port=3306
rapport-port=3306
rapport-hôte=maître
gtid-mode=off
appliquer-gtid-consistance=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]
utilisateur=racine
mot de passe=pandore

• Les jetons après le 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 à la réplication binaire sont configurés.
• Le jeton nommé binlog_expire_logs_seconds est défini sur une période de deux jours.
• Dans la sous-section [client], placez le nom d'utilisateur et le mot de passe utilisés pour la base de données, par défaut lors de l'installation de PFMS, ils sont respectivement root et pandora. Ces valeurs sont nécessaires pour effectuer des sauvegardes sans indiquer l'utilisateur (automatisé).

Une fois que vous avez la bonne configuration sur les deux nœuds, lancez la configuration du nœud qui jouera le rôle de serveur maître.

1.- Démarrez le service mysqld :

systemctl start mysqld

2.- Accédez avec le mot de passe temporaire de root qui aura été généré dans le log, au fichier /var/log/mysqld.log :

grep "temporary password" /var/log/mysqld.log

Avec le mot de passe qui apparaît, accédez au serveur MySQL :

mysql -u root -p

Password: → Saisir le mot de passe observé avec la commande grep.

3.- Changez le mot de passe temporaire en pandora pour l'utilisateur root. Rappelez-vous que le mysql > (prompt) correspond à l'interpréteur de commandes MySQL (MYSQL CLI) :

mysql > ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'Pandor4!';

mysql > UNINSTALL COMPONENT 'file://component_validate_password';

mysql > ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'pandora';

4.- Créez l'utilisateur de réplication binaire et l'utilisateur root pour les connexions à distance et la gestion du cluster :

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

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

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

mysql > GRANT ALL PRIVILEGES ON *.* to root@'%';

5.- Créez la base de données Pandora FMS :

mysql > create database pandora;

mysql > use pandora;

mysql > source /var/www/html/pandora_console/pandoradb.sql

mysql > source /var/www/html/pandora_console/pandoradb_data.sql

6.- Créez l'utilisateur pandora et accordez les privilèges d'accès audit utilisateur :

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

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

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

1.- Effectuez un téléchargement complet (dump) 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 journal binaire de sauvegarde :

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

Il 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.

3.- Faites une copie en utilisant rsync avec le serveur SLAVE pour envoyer la sauvegarde effectuée :

MASTER # rsync -avpP -e ssh /root/pandoradb.bak/ node2:/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 >

CHANGER LE MAITRE EN MASTER_HOST='noeud1',
  MASTER_USER='esclave',
  MASTER_PASSWORD='pandore',
  MASTER_LOG_FILE='binlog.000003',
  MASTER_LOG_POS=157 ;

SLAVE # mysql > démarrer l'esclave;

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 MySQL, vous verrez que le nœud est trouvé comme esclave. S'il a été configuré correctement, une sortie comme celle-ci doit être observée :

**************************** 1ère ligne ****************************
Slave_IO_State : attente de la source pour envoyer l'événement
Master_Host : nœud1
Utilisateur_maître : racine
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 : Oui
Slave_SQL_Running : Oui
Replicate_Do_DB : pandora
Replicate_Ignore_DB :
Répliquer_Do_Table :
Répliquer_Ignorer_Table :
Répliquer_Wild_Do_Table :
Replicate_Wild_Ignore_Table :
Last_Errno : 0
Dernière_erreur :
Skip_Counter : 0
Exec_Master_Log_Pos : 1135140
Relay_Log_Space : 1135519
Jusqu'à_Condition : Aucune
Jusqu'au_fichier_journal :
Jusqu'à_Log_Pos : 0
Master_SSL_Allowed : Non
Master_SSL_CA_File :
Master_SSL_CA_Path :
Master_SSL_Cert :
Chiffrement_SSL_maître :
Master_SSL_Key :
Seconds_Behind_Master : 0
Master_SSL_Verify_Server_Cert : Non
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
Délai_SQL : 0
SQL_Remaining_Delay : NULL
Slave_SQL_Running_State : le réplica a lu tous les journaux de relais ; en attendant plus
mises à jour
Master_Retry_Count : 86400
Master_Bind :
Last_IO_Error_Timestamp :
Last_SQL_Error_Timestamp :
Maître_SSL_Crl :
Master_SSL_Crlpath :
Retrieved_Gtid_Set :
Executed_Gtid_Set :
Auto_Position : 0
Replicate_Rewrite_DB :
Nom du canal:
Master_TLS_Version :
Master_public_key_path :
get_master_public_key : 0
Network_Namespace :
1 rangée dans le jeu, 1 avertissement (0,00 sec)

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

Il est nécessaire de configurer au sein du 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_mode [pandora|pacemaker] :

Le jeton avec la valeur pandora sera indiqué pour la configuration actuelle de pandora_ha, dans le cas où le mode précédent est utilisé (version 769 et antérieure), la valeur pacemaker sera utilisée. Exemple:

ha_mode pandora

• ha_hosts <IP_ADDRESS1>,<IP_ADDRESS2> :

Vous devez configurer le paramètre ha_host suivi des adresses IP ou FQDN des serveurs MySQL qui composent l'environnement HA. L'adresse IP que vous mettez en premier aura la priorité pour être le serveur MASTER ou au moins avoir 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 et ha_dbpass :

Ce sont les paramètres où doivent être indiqués le nom d'utilisateur et le mot de passe de l'utilisateur root ou, à défaut, un utilisateur MySQL avec les privilèges les plus élevés qui sera chargé d'effectuer toutes les opérations de promotion maître-esclave dans les nœuds. Exemple:

ha_dbuser root
ha_dbpass pandora

• repl_dbuser et repl_dbpass :

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

repl_dbuser slaveuser
repl_dbpass pandora

• ha_sshuser et ha_sshport :

Paramètres pour définir l'utilisateur/port avec lequel se connecter par ssh aux serveurs Percona/MySQL pour effectuer des opérations de restauration. Pour que cette option fonctionne correctement, il est nécessaire que les clés ssh soient partagées 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 effectuer la resynchronisation des nœuds se trouve à :

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

Dans le cas d'une installation personnalisée du script, indiquez son emplacement dans ce paramètre afin 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 journal où seront enregistrées toutes les informations relatives aux exécutions effectuées par le script de synchronisation configuré dans le jeton précédent. Exemple:

ha_resync_log /var/log/pandoraha_resync.log

• ha_connect_retries:

Le nombre de tentatives pour effectuer chaque vérification sur chacun des serveurs de l'environnement HA avant d'apporter des modifications à l'environnement. Exemple:

ha_connect_retries 2

Une fois tous ces paramètres configurés, vous pourrez démarrer le serveur Pandora FMS avec le service pandora_ha. Le serveur obtiendra une image de l'environnement et saura alors 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ù le serveur Percona/MySQL qui a le rôle de MASTER sera indiqué à tout moment.

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

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

• redémarrage :

Il sera indiqué avec une valeur de 0, car le démon pandora_ha est chargé de redémarrer le service en cas d'échec 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

Un serveur OpenSSH doit être installé et en cours d'exécution sur chaque hôte. Supprimer le message ou la bannière de bienvenue affichés par OpenSSH, exécutez sur tous les appareils :

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

Partagez les clés SSH entre pandora_ha et tous les serveurs Percona/MySQL existants dans l'environnement, exécutez sur le serveur Pandora FMS :

printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 root@node1
ssh-copy-id -p22 root@node2

Avec le serveur Pandora FMS, un script est implémenté qui permet de synchroniser la base de données SLAVE en cas de désynchronisation.

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 node1 node2

Pour configurer la récupération automatique de l'environnement HA lorsqu'il y a un problème de synchronisation entre MASTER et SLAVE, il est nécessaire d'avoir le jeton de configuration splitbrain_autofix défini sur 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 les nœuds MASTER et SLAVE, pandora_ha essaiera de lancer le script pandora_ha_resync_slave.sh pour synchroniser à partir de ce moment l'état du serveur MASTER dans 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'est produite.

Un nouveau paramètre a été ajouté à la configuration 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 où il obtiendra l'adresse IP pour établir la connexion.

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

Dans la console Pandora FMS, vous pouvez afficher l'état du cluster en accédant à la vue 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, aucune procédure de configuration préalable n'est nécessaire pour pouvoir visualiser cette section tant que pandora_server.conf est correctement configuré avec les paramètres mentionnés dans la section précédente.

Parmi les actions disponibles, une étiquette peut être configurée pour chacun des nœuds et l'option de synchronisation du nœud SLAVE peut être effectuée via l'icône .

Cette icône peut avoir les états suivants :

• Vert: Normal, aucune opération à effectuer.
• Bleu: En attente en raison d'une resynchronisation.
• Jaune: la resynchronisation est en cours.
• Rouge: erreur, la resynchronisation a échoué.

Il faut vérifier dans la section Setup → Setup → Enterprise, que le token Legacy HA database management est désactivé pour que la vue HA s'affiche avec la configuration de ce nouveau mode.

La principale différence entre un environnement HA utilisé dans la version 5 de MySQL/Percona Server avec le mode HA actuel est que pandora_ha est désormais utilisé pour gérer les nœuds du cluster au lieu de Corosync-Pacemaker, qui ne sera plus utilisé à partir de maintenant.

La migration de l'environnement consistera en :

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

2.- Installez xtrabackup-80 sur tous les appareils :

yum install percona-xtrabackup-80

Si vous utilisez le serveur Ubuntu, consultez la section “Installation Percona 8 pour Ubuntu Server”.

3.- Créez à nouveau tous les utilisateurs avec le token mysql_native_password dans le nœud MASTER :

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

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

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

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

4.- Vider la base de données du nœud MASTER vers le SLAVE :

4.1.- Faites un 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/

4.2.- Obtenir la position du journal binaire de sauvegarde :

MASTER # cat /root/pandoradb.bak/xtrabackup_binlog_info

binlog.000003 157

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

4.3.- Effectuez une synchronisation avec rsync avec le serveur SLAVE pour envoyer la sauvegarde effectuée.

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

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

4.4- Sur le serveur SLAVE, définissez les autorisations afin que le serveur MySQL puisse accéder librement aux fichiers soumis.

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émarrer le mode SLAVE sur ce serveur (utiliser les données du point 4.2) :

SLAVE # mysql -u root -ppandora

SLAVE # mysql > reset slave all;

SLAVE # mysql >

CHANGE MASTER TO MASTER_HOST='nodo1',
MASTER_USER='slaveuser', 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, vous devez uniquement l'installer à partir de zéro comme indiqué par la procédure actuelle dans le nouvel environnement, et à l'étape de création de la base de données Pandora FMS, vous devez importer les données avec une backup de l'ancienne base de données de l'environnement.

À son tour, il sera nécessaire de sauvegarder la configuration de la console et du serveur Pandora FMS indiquée dans les sections précédentes dans le nouvel environnement.

En raison de divers facteurs, latences élevées, pannes de réseau, etc., il peut être constaté 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 de sorte que c'est le serveur lui-même qui choisit le serveur qui va agir en tant que maître et effectue la synchronisation du nœud maître vers l'esclave, perdant ainsi toutes les informations qui pourraient être collectées sur ce serveur.

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

Si de nouveaux agents sont créés pendant le temps 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 tablas tagente_datos, tagente_datos_string et tevento.

Les commandes suivantes seront exécutées sur le nœud qui s'est déconnecté (celui qui sera promu SLAVE), où aaaa-mm-jj hh:mm:ss est la date et l'heure de début de Split-Brain et aaaa2-mm2-jj2 hh2:mm2:ss2 sa date et heure de fin.

Exécutez la commande mysqldump avec les droits d'utilisateur appropriés pour obtenir un vidage de données (vidage de données ou simplement vidage).

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_da tousser.dump.sq je

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"'> tagent _data_string.d ump.sql

mysqldump -u root -p -n -t --skip-create-options --databases pandora --tables tevento --where='FROM_UNIXTIME(utimestamp)> "aaaa-mm-jj 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, lesdites données seront chargées dans 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 qui ont été récupérées du nœud à promouvoir en SLAVE, procédez à sa synchronisation en suivant la procédure suivante :

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

1.- Faire un vidage 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.- Obtenir 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 bonne note de ces valeurs) :

binlog.000003 157

À ce stade, dans SLAVE, vous devez effacer le contenu de /var/lib/mysql/ comme indiqué au point 4.3 ci-dessus :

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

3.- Faites une tâche avec la commande rsync avec le serveur esclave pour envoyer la sauvegarde effectuée.

MASTER # rsync -avpP -e ssh /root/pandoradb.bak/ node2:/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.- Démarrez le service mysqld sur le serveur slave.

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='nodo1', MASTER_USER='slaveuser', 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 effectuées, si vous exécutez la commande show slave status dans le shell MySQL, vous verrez que le nœud est en mode slave. S'il a été configuré correctement, une sortie comme l'exemple suivant doit être observée :

**************************** 1ère ligne ****************************
                Slave_IO_State : attente de la source pour envoyer l'événement
                   Master_Host : nœud1
                   Utilisateur_maître : racine
                   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 : Oui
             Slave_SQL_Running : Oui
               Replicate_Do_DB : pandora
           Replicate_Ignore_DB :
            Répliquer_Do_Table :
        Répliquer_Ignorer_Table :
       Répliquer_Wild_Do_Table :
   Replicate_Wild_Ignore_Table :
                    Last_Errno : 0
                    Dernière_erreur :
                  Skip_Counter : 0
           Exec_Master_Log_Pos : 1135140
               Relay_Log_Space : 1135519
               Jusqu'à_Condition : Aucune
                Jusqu'au_fichier_journal :
                 Jusqu'à_Log_Pos : 0
            Master_SSL_Allowed : Non
            Master_SSL_CA_File :
            Master_SSL_CA_Path :
               Master_SSL_Cert :
             Chiffrement_SSL_maître :
                Master_SSL_Key :
         Seconds_Behind_Master : 0
Master_SSL_Verify_Server_Cert : Non
                 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
                     Délai_SQL : 0
           SQL_Remaining_Delay : NULL
       Slave_SQL_Running_State : le réplica a lu tous les journaux de relais ; en attente de plus de mises à jour
            Master_Retry_Count : 86400
                   Master_Bind :
       Last_IO_Error_Timestamp :
      Last_SQL_Error_Timestamp :
                Maître_SSL_Crl :
            Master_SSL_Crlpath :
            Retrieved_Gtid_Set :
             Executed_Gtid_Set :
                 Auto_Position : 0
          Replicate_Rewrite_DB :
                  Nom du canal:
            Master_TLS_Version :
        Master_public_key_path :
         get_master_public_key : 0
             Network_Namespace :
1 rangée dans le jeu, 1 avertissement (0,00 sec)

Retour à l'index de la documentation de Pandora FMS