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 :
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 :
/var/spool/pandora/data_in
.oui
ou non
selon que vous souhaitez utiliser SSL pour transférer des données via Tentacle.Seule la configuration à distance de l'agent logiciel est opérationnelle, si elle est activée, sur le serveur principal.
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 :
MASTER
).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.
Soyez prudent lors de la désactivation des serveurs. Si un serveur avec des modules réseau tombe en panne et que le serveur réseau du serveur maître est désactivé, ces modules ne fonctionneront pas.
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.
Il est important de ne partager que les sous-répertoires à l'intérieur de data_in
et non le data_in
lui-même car cela affecterait négativement les performances du serveur.
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. 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.
L'objectif de cette section est d'offrir une solution complète pour la haute disponibilité dans les environnements Pandora FMS. Il s'agit du seul modèle HA avec prise en charge officielle de Pandora FMS, et il est fourni à partir de la version 770. Ce système remplace la configuration en cluster avec Corosync et Pacemaker des versions précédentes.
La nouvelle solution Pandora FMS HA est intégrée au produit (au sein du binaire pandora_ha). Elle 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 sorte que la conception ne met donc pas en œuvre un système de quorum et simplifie la configuration et les exigences en matière de ressources. De cette manière, le système de supervision 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.
À partir de la version 772, l'HA a été modifié pour le rendre plus simple et moins bogué. Pour cette nouvelle HA, il est recommandé d'utiliser des disques SSD pour une vitesse d'écriture/lecture (IOPS) plus élevée, au minimum 500 Mb/s (ou plus, en fonction de l'environnement). La latence entre les serveurs doit également être prise en compte, car avec des latences très élevées, il est difficile de synchroniser les deux bases de données à temps.
Avec la nouvelle proposition, nous voulons résoudre les trois problèmes actuels :
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.
Il s'agit d'une fonctionnalité avancée qui nécessite une connaissance des systèmes GNU/Linux. Il est important que tous les serveurs aient l'heure synchronisée avec un serveur NTP (service chronyd dans Rocky Linux 8).
Les nœuds du cluster de réplication binaire MySQL sont gérés avec le binaire pandora_ha
, à partir de la version 770. 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 :
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.Version 770 ou ultérieure.
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.
Vous devrez ouvrir une fenêtre de terminal avec les droits root ou en tant qu'utilisateur root. Vous êtes seul responsable de ladite clé. Dans les instructions suivantes, il est indiqué si vous devez exécuter des instructions dans tous les appareils, dans certains ou dans un en particulier, faites attention aux instructions.
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
Dans le cas où vous installez le serveur Percona avec la console Web et le serveur PFMS, vous pouvez utiliser le deploy indiquant la version de MySQL 8 via le paramètre MYVER=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
Il est recommandé que stocker les binlogs générés par la réplication sur une partition supplémentaire ou un disque externe, leur taille doit être la même que celle réservée à la base de données. Voir aussi les jetons log-bin
et log-bin-index
.
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
binlog_expire_logs_seconds
est défini sur une période de deux jours.[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é).
Il est important que le jeton server_id
soit différent dans tous les nœuds, dans cet exemple pour le nœud 1, ce numéro est utilisé.
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
binlog_expire_logs_seconds
est défini sur une période de deux jours.[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é).
Il est important que le jeton server_id
soit différent dans tous les nœuds, dans cet exemple pour le nœud 2, le numéro correspondant est utilisé.
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
Pour la commande source: Tant que la console Pandora FMS est installée sur le même serveur, sinon, envoyez ce fichier au serveur maître.
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@'%';
À ce moment, vous avez déjà le serveur maître prêt à commencer à répliquer la base de données Pandora FMS.
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.
Version 770 ou ultérieure.
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 :
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
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
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
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
PATH_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
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
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.
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
sudo passwd root
.sshd
.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.
Version 770 ou ultérieure.
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 :
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.
Cette procédure manuelle couvre uniquement la récupération des données et événements entre deux dates. Il suppose qu'il récupère uniquement les données des agents/modules qui existent déjà sur le nœud où les données vont être fusionnées.
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)
À partir de ce moment, vous pouvez vous assurer que la réplication binaire est activée et fonctionne à nouveau correctement.