Haute disponibilité (High Availability)

Retour à l'index de documentation du Pandora FMS

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

Pandora FMS a été conçu pour être très modulaire, mais il est également conçu pour fonctionner en collaboration avec d'autres composants et être capable d'assumer la charge des composants qui ont echoué.

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

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

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

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

Les composantes les plus importantes de Pandora FMS sont

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

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

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

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

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

• Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz
• Amazon t2.large instance

Selon les besoins :

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

 Serveurs : 1 (partagé)

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

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

 Serveurs : 2 (1 partagé, 1 historique)

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

 Historique :
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disque : 200GB

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

 Serveurs : 3 (1 serveur + console, 1 base de données principale, 1 historique)

 Serveur + console :
 -------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 40GB

 Base de données principale :
 ------------------------
 CPU : 4 cores
 RAM : 8 GO
 Disque : 100GB

 Historique :
 ----------
 CPU : 2 cores
 RAM : 4 GO
 Disque : 200GB

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

 Serveurs : 4 (1 serveur + console, 2 bases de données, 1 historique)

 Serveur + console :
 -------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 40GB

 Base de données du nœud 1 :
 ---------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 100GB

 Base de données du noeud 2 :
 ---------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 100GB

 Historique :
 ----------
 CPU : 2 cores
 RAM : 4 GO
 Disque : 300GB

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

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

Serveur + console :

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

Base de données noeud 1 :

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

Base de données noeud 2 :

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

Base de données noeud 3 :

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

 Historique :
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disque : 200GB

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

 Serveurs : 5 (2 serveur + console, 2 base de données, 1 historique)

 Serveur + console :
 -------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 40GB

 Serveur + console :
 -------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 40GB

 Base de données du nœud 1 :
 ---------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 100GB

 Base de données du noeud 2 :
 ---------------------
 CPU : 6 cores
 RAM : 8 GO
 Disque : 100GB

 Historique :
 ----------
 CPU : 2 cœurs
 RAM : 4 GO
 Disque : 200GB

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

 Serveurs : 3 (2 partagés, 1 historique)

 Principale : (console + serveur + nœud de base de données 1)
 ----------
 CPU : 8 cores
 RAM : 12 GO
 Disque : 100GB

 Secondaire : (console + serveur + nœud de base de données 2)
 ----------
 CPU : 8 cores
 RAM : 12 GO
 Disque : 100GB

 Historique :
 ----------
 CPU : 2 cores
 RAM : 4 GO
 Disque : 200GB

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

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

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

Pour gérer tout l'environnement, vous devrez avoir une Métaconsole installée, depuis laquelle vous pourrez configurer toute l'infrastructure de monitorage.

La Metaconsole nécessitera :

 Serveurs : 1 (partagé)

 Principale :
 ----------
 CPU : 8 cores
 RAM : 12 GO
 Disque : 100GB

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

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

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

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

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

Si vous utilisez un équilibreur externe, et que l'un des serveurs tombe en panne, le mécanisme HA permet d'activer l'un des serveurs actifs disponibles et les agents Pandora FMS continueront à se connecter avec la même adresse qu'auparavant, sans remarquer le changement, mais dans ce cas, l'équilibreur de charge n'enverra plus les données au serveur qui a échoué, mais à un autre serveur actif.

Il n'est pas nécessaire de changer quoi que ce soit dans chaque serveur de données Pandora FMS, même chaque serveur peut garder son propre nom, utile pour savoir si l'un d'entre eux est tombé dans la vue d'état du serveur. Les modules de données Pandora FMS peuvent être traités par n'importe quel serveur sans préaffectation. Il est conçu précisément de cette manière pour pouvoir mettre en œuvre l'HA de manière plus simple.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Mode maître (MASTER).
• Mode non maître.

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

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

master [1..7]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dans cet exemple, un cluster de deux nœuds sera configuré, avec les hosts : node1 et node2.

Modifiez les noms de hosts, les mots de passe, etcetera selon les besoins pour correspondre à l'environnement à déployer.

Les commandes qui doivent être exécutées sur n'importe quel nœud auront la syntaxe suivante (exemple pour node1) :

node1#
<command>
<command>
<command>

Les commandes qui doivent être exécutées sur tous les nœuds seront précédées du mot all:

all#
<command>
<command>
<command>

Il existe également un hôte supplémentaire appelé pandorafms où Pandora FMS sera installé. Lorsque all est référencé, il ne fait référence qu'aux nœuds de la base de données, le nœud supplémentaire Pandora FMS sera toujours référencé comme pandorafms et ne fait pas partie de all.

RHEL version 8 ou Rocky Linux version 8 doit être installé sur tous les hosts, et doit être capable de résoudre les hostnames des autres hosts.

Un serveur OpenSSH doit être installé et fonctionner sur chaque host. Supprimez l'avertissement qu'OpenSSH affiche:

all#
[ -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

Générez de nouvelles clés d'authentification SSH pour chaque host et copiez la clé publique pour chacun des hosts.

all#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 [email protected]
ssh-copy-id -p22 [email protected]

pandorafms#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 [email protected]
ssh-copy-id -p22 [email protected]

Sur le nœud Pandora FMS, copiez la paire de clés dans les répertoires suivants httpd et ssh. La console Pandora FMS (httpd) doit récupérer le statut du cluster:

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

Vous devez remplacer 22 par le numéro de port que vous utilisez

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

Vous devez tester l'authentification sans mot de passe de chaque nœud vers les autres:

all#
ssh node1
ssh node2

pandorafms#
ssh node1
ssh node2

Installez le package requis :

all#
dnf install dnf-utils \
 https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm \
 https://repo.percona.com/yum/percona-release-latest.noarch.rpm"

dnf module disable -y mysql

dnf install -y Percona-Server-server-57 percona-xtrabackup-24

Pour plus d'informations sur le processus d'installation de Percona, vous pouvez consulter la documentation officielle du produit :

Une fois les packages installés, assurez-vous que le service Percona est désactivé, car il sera géré par le cluster:

all#
systemctl disable mysqld

Ensuite, démarrez le serveur Percona:

all#
systemctl start mysqld

Un nouveau mot de passe temporaire sera généré connecté à /var/log/mysqld.log. Connectez-vous au serveur Percona et changez le mot de passe pour root:

all#
export MYSQL_PWD=$(grep "temporary password" /var/log/mysqld.log | rev | cut -d' ' -f1 | rev)

echo """
  SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
  UNINSTALL PLUGIN validate_password;
  SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
  """ | mysql --connect-expired-password -uroot

Une fois le server installé, vous trouverez le générateur de configuration pour la réplication de la base de données au chemin :

/usr/share/pandora_server/util/myconfig_ha_gen.sh

Example: ./myconfig_ha_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
    -i --serverid Set the server id for the database (Mandatory)
Optional parameters:
    -l --location Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
    -d --database Set the database to be replicated. [ default value: pandora ] (optional)
    -b --binlog Set binlog file. [ default value: mysql-bin ] (optional)
    -u --dbuser Set dbuser for mysql connection and backups. [ default value: root ] (optional)
    -p --dbpass Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
    -s --poolsize Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
    -h --help Print help.

Dans le cas présent où les bases de données ne sont pas sur le même serveur que l'application, il faudra copier le script sur les nœuds pour être exécuté localement.

pandorafms#
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/

Il ne sera nécessaire de passer le paramètre serverid que dans les environnements standards et quelques paramètres facultatifs pour les environnements personnalisés.

Si l'utilisateur par défaut ou défini ne se connecte pas à la base de données, le script se terminera par une erreur de connexion.

Vous avez également la possibilité de passer le nom de la base de données, l'utilisateur et le mot de passe comme arguments. Sinon, les paramètres par défaut seront utilisés.

Dans ce cas, il exécutera le script sur les deux nœuds, en ne transmettant le server_id que s'il possède les informations d'identification par défaut, sinon il doit définir les paramètres nécessaires.

node1#
/root/myconfig_ha_gen.sh -i 1

node2#
/root/myconfig_ha_gen.sh -i 2

Le fichier de configuration Percona sera écrit dans /etc/my.cnf où l'identifiant du serveur et la configuration recommandée pour la réplication de la base de données seront définis. Vous devez redémarrer le service mysqld pour vérifier que la configuration a été correctement appliquée.

all#
systemctl restart mysqld

Vous pouvez soit effectuer une installation entièrement nouvelle, soit migrer les données que vous avez depuis une instance existante.

Installez Pandora FMS sur la base de données nouvellement créée. Arrêtez le serveur FMS de Pandora :

pandorafms#
/etc/init.d/pandora_server stop

À partir de la version NG 754, vous disposez d'options supplémentaires pour le démarrage et l'arrêt manuels des environnements de haute disponibilité (HA).

Arrêtez le serveur FMS de Pandora :

pandorafms#
/etc/init.d/pandora_server stop

Sauvegardez la base de données du FMS Pandora et transférez-la sur le nœud 1 :

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

Téléchargez maintenant les informations vers la nouvelle base de données sur le nœud (si vous n'utilisez pas les informations d'identification et le nom de la base de données par défaut, modifiez-les dans la commande suivante) :

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

Accordez les privilèges nécessaires à la réplication afin qu'elle puisse fonctionner sur toutes les bases de données :

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

Arrêtez la base de données node2:

node2#
systemctl stop mysqld

Sauvegarder la base de données du premier nœud (node1) et écrire le nom et la position du fichier log maître (dans cet exemple, mysql-bin.000001 et 785):

node1#
[ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
innobackupex --no-timestamp /root/pandoradb.bak/
innobackupex --apply-log /root/pandoradb.bak/
rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/
cat /root/pandoradb.bak/xtrabackup_binlog_info

Chargez la base de données sur le deuxième nœud (node2) et configurez-la pour qu'elle soit répliquée à partir du premier nœud (vous devez définir MASTER_LOG_FILE et MASTER_LOG_POS aux valeurs de l'étape précédente):

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

systemctl start mysqld

mysql -uroot -ppandora
  CHANGE MASTER TO MASTER_HOST='node1',
  MASTER_USER='root', MASTER_PASSWORD='pandora',
  MASTER_LOG_FILE ='mysql-bin.000001', MASTER_LOG_POS =785;
  START SLAVE;
  SHOW SLAVE STATUS \G

Vous obtiendrez une sortie similaire à:

Si tout est correct, quittez l'interface de la base de données:

#node2
mysql> QUIT

Installez les paquets nécessaires : pour Rocky Linux™, il vous suffit d'exécuter la commande suivante.

all#
dnf install -y --enablerepo='ha' chrony epel-release corosync pacemaker pcs

Dans le cas de RedHat, il sera nécessaire d'activer le dépôt rhel-8-for-x86_64-highavailability-rpms à partir du subscription manager avant l'installation.

all#
subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
dnf install -y --enablerepo='rhel-8-for-x86_64-highavailability-rpms' chrony epel-release corosync pacemaker pcs

Définissez maintenant le fichier de configuration et activez les services corosync, pscd et chrony (substitut de l'ancien ntpd).

all#
cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf

systemctl enable chronyd --now

systemctl enable pcsd --now

systemctl enable corosync --now

Arrêtez le serveur Percona:

all#
systemctl stop mysqld

Définir le mot de passe de l'utilisateur hacluster :

all#
echo hapass | passwd hacluster --stdin

Créez et démarrez le cluster, , ces étapes ne seront nécessaires que pour faire ceci dans node1 :

node1#
pcs host auth node1 node2 -u hacluster -p hapass

pcs cluster setup pandorafms node1 node2 --force

pcs cluster start --all
pcs cluster enable --all

pcs property set stonith-enabled=false

pcs property set no-quorum-policy=ignore

Vérifiez l'état du cluster :

node1#
pcs status

Vous verrez une sortie similaire à :

Le pacemaker peut être téléchargé manuellement à partir de la bibliothèque PFMS.

Si vous avez accès à Internet, vous pouvez l'installer en courant :

all#
cd /usr/lib/ocf/resource.d/
mkdir percona
cd percona
curl -L -o pacemaker_mysql_replication.zip
https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysq
l_replication.zip
unzip pacemaker_mysql_replication.zip
rm -f pacemaker_mysql_replication.zip
chmod u+x mysql
cd

Configurer les ressources du cluster.

Remplacez <VIRT_IP> par l'adresse IP virtuelle préférée :

#node1
export VIP='<VIRT_IP>'

pcs resource create pandoradb ocf:percona:mysql config="/etc/my.cnf" \
pid="/var/run/mysqld/mysqld.pid" socket="/var/lib/mysql/mysql.sock" \
replication_user="root" replication_passwd="pandora" max_slave_lag="60" \
evict_outdated_slaves="false" binary="/usr/sbin/mysqld" datadir="/var/lib/mysql" \
test_user="root" test_passwd="pandora" op start interval="0" timeout="60s" \
op stop interval="0" timeout="60s" op promote timeout="120" op demote timeout="120" \
op monitor role="Master" timeout="30" interval="5" on-fail="restart" op monitor role="Slave" \
timeout="30" interval="10"

pcs resource create pandoraip ocf:heartbeat:IPaddr2 ip=$VIP cidr_netmask=24 \
op monitor interval=20s

pcs resource promotable pandoradb meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" \
globally-unique=" false" target-role="Master" is-managed="true"

pcs constraint colocation add master pandoradb-clone with pandoraip

pcs constraint order promote pandoradb-clone then start pandoraip

sleep 5 ; pcs resource cleanup

Vérification de l'état du cluster :

node1#
pcs status

Vous verrez une sortie similaire à :

Elle se déroulera de manière similaire à la précédente.

Les informations d'identification de l'utilisateur doivent avoir été copiées, comme expliqué précédemment, et les étapes suivantes doivent être exécutées :

# All nodes:
useradd <usuario>
passwd <usuario>
usermod -a -G haclient <usuario>

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

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

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

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

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

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

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

node1# <command>

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

all# <command>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

installez le package nécessaire :

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

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

Pour plus d'informations sur le processus d'installation de Percona vous pouvez consulter la documentation officielle du produit : https://www.percona.com/doc/percona-server/5.7/installation/yum_repo.html

Assurez-vous que le service Percona est désactivé, car il sera géré par le cluster :

all# systemctl disable mysqld

Lancez le serveur Percona :

all# systemctl start mysqld

Un nouveau mot de passe temporaire sera généré en se connectant à /var/log/mysqld.log. Connectez-vous au serveur Percona et changez le mot de passe root :

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

Reinstaller avec le flag ha.

pandorafms# ./pandora_server_installer --install --ha

Une fois installé le serveur avec les outils HA activés, vous trouverez le générateur de configuration pour la réplication de la base de données dans le chemin : /usr/share/pandora_server/util/myconfig_ha_gen.sh

Example: ./myconfig_ha_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
       -i --serverid   Set the server id for the database (Mandatory)
Optional parameters:
       -l --location   Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
       -d --database   Set the database to be replicated. [ default value: pandora ] (optional)
       -b --binlog     Set binlog file. [ default value: mysql-bin ] (optional)
       -u --dbuser     Set dbuser for mysql connection and backups. [ default value: root ] (optional)
       -p --dbpass     Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
       -s --poolsize   Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
       -h --help       Print help.

Dans le cas actuel, dans lequel les bases de données ne sont pas dans le même serveur que celui de l'application, il sera nécessire de copier le script aux noeud pour les exécuter localement.

pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/
pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/

Il sera nécessaire seulement d'entrer le paramètre serverid (obligatoire) dans des environnements standard et quelques paramètres optionels pour les environnements personnalisés.

Si l'utilisateur par défaut ou celui défini ne connecte pas avec la base de données. le script finira en retournant un erreur de connexion.

Vous avez aussi la possibilité d'entrer en tant qu'aguments la base de données, l'utilisateur et le mot de passe. Si vous ne le faites pas, ceux configurés par défaut seront utilisés.

Pour ce cas, il exécutera le script dans les deux noeuds en entrant seulement le server id si vous avez les identifiants par défaut, au cas contraire il faut définir les paramètres nécessaires.

 node1# /root/myconfig_ha_gen.sh -i 1
 node2# /root/myconfig_ha_gen.sh -i 2

Le fichier de configuration Percona sera écrit dans /etc/my.cnf où l'identificateur du serveur et la configuration récommandée pour la réplication de la base de données seront définis.

Redémarrez le service mysqld pour vérifier que la configuration a été appliquée correctement.

all# systemctl restart mysqld

Installez Pandora FMS dans la base de données récemment créée. Arrêtez le serveur Pandora FMS :

pandorafms# /etc/init.d/pandora_server stop

Arrêtez le serveur Pandora FMS :

pandorafms# /etc/init.d/pandora_server stop

Sauvegardez la base de données de Pandora FMS :

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

Téléchargez les informations dans la nouvelle base de données :

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

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

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

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

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

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

node2# systemctl stop mysqld

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

node2# chown -R mysql:mysql /var/lib/mysql
node2# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node2# systemctl start mysqld
node2# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node2-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB: pandora
             Replicate_Ignore_DB:
              Replicate_Do_Table:
          Replicate_Ignore_Table:
         Replicate_Wild_Do_Table:
     Replicate_Wild_Ignore_Table:
                      Last_Errno: 0
                      Last_Error:
                    Skip_Counter: 0
             Exec_Master_Log_Pos: 785
                 Relay_Log_Space: 1252
                 Until_Condition: None
                  Until_Log_File:
                   Until_Log_Pos: 0
              Master_SSL_Allowed: No
              Master_SSL_CA_File:
              Master_SSL_CA_Path:
                 Master_SSL_Cert:
               Master_SSL_Cipher:
                  Master_SSL_Key:
           Seconds_Behind_Master: 0
   Master_SSL_Verify_Server_Cert: No
                   Last_IO_Errno: 0
                   Last_IO_Error:
                  Last_SQL_Errno: 0
                  Last_SQL_Error:
     Replicate_Ignore_Server_Ids:
                Master_Server_Id: 1
                     Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Master_Retry_Count: 86400
                     Master_Bind:
         Last_IO_Error_Timestamp:
        Last_SQL_Error_Timestamp:
                  Master_SSL_Crl:
              Master_SSL_Crlpath:
              Retrieved_Gtid_Set:
               Executed_Gtid_Set:
                   Auto_Position: 0
            Replicate_Rewrite_DB:
                    Channel_Name:
              Master_TLS_Version:
   1 row in set (0.00 sec)
mysql> QUIT

Installez les packages nécessaires :

 yum install -y epel-release corosync ntp pacemaker pcs

 all# systemctl enable ntpd
 all# systemctl enable corosync
 all# systemctl enable pcsd
 all# cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf

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

Arrêtez le serveur Percona :

node1# systemctl stop mysqld

node2# systemctl stop mysqld

Créer et démarrer le cluster :

all# echo hapass | passwd hacluster --stdin

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

Vérifier l’état du cluster :

node#1 pcs status
   Cluster name: pandoraha
   Stack: corosync
   Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
   Last updated: Fri Jun  8 12:53:49 2018
   Last change: Fri Jun  8 12:53:47 2018 by root via cibadmin on node1

   2 nodes configured
   0 resources configured

   Online: [ node1 node2 ]

   No resources

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

Vous pouvez télécharger manuellement depuis notre librairie PFMS :

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

Configurez les ressources du cluster. Remplacez <VIRT_IP> par l'adresse IP virtuelle de préférence :

node1# export VIP='<VIRT_IP>'

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

Vérification de l'état du cluster :

node1# pcs status
   Cluster name: pandoraha
   Stack: corosync
   Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
   Last updated: Fri Jun  8 13:02:21 2018
   Last change: Fri Jun  8 13:02:11 2018 by root via cibadmin on node1

   2 nodes configured
   3 resources configured

   Online: [ node1 node2 ]

   Full list of resources:

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

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

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

# All nodes:

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

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

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

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

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

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

Assurez-vous que php-pecl-ssh2 est installé en fonction du système d'exploitation et de la version que vous avez installés:

RHEL 8

 pandorafms# dnf install --disablerepo=rhel-8-for-x86_64-appstream-rpms php-pecl-ssh2
 pandorafms# systemctl restart php-fpm
 pandorafms# systemctl restart httpd

Rocky Linux 8

 pandorafms# dnf install php-pecl-ssh2
 pandorafms# systemctl restart php-fpm
 pandorafms# systemctl restart httpd

CentOS 7

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

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

# Pandora FMS Database HA Tool execution interval in seconds (PANDORA FMS ENTERPRISE ONLY).
ha_interval 30

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

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

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

Connectez-vous à la console Pandora FMS et naviguez jusqu'à Servers → Manage database HA :

Cliquez sur Add new node et créez une entrée pour le premier nœud :

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

Scénario.

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

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

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

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

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

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

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

1. Supprimez les sauvegardes précédentes.
2. Sauvegarder le datadir du nœud secondaire.
3. Sauvegarde le nœud primaire.
4. Envoie la sauvegarde du nœud principal au nœud secondaire ( Master → Slave).
5. Démarre la ressource du nœud “secondaire” avec les paramètres de resynchronisation correspondants au moment de la sauvegarde.
6. Vérifie que la ressource est active et correcte. Pour cela, il utilise la configuration indiquée dans les paramètres ha_max_resync_wait_retries et ha_resync_sleep.

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

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

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

Supprimez la banner ou l'avertissement qu'OpenSSH affiche :

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

Générez de nouvelles clés d'authentification SSH pour le nouveau host et copiez la clé publique pour chacun des hosts:

 node1# ssh-copy-id -p22 [email protected]
 node1# ssh node3

 node2# ssh-copy-id -p22 [email protected]
 node2# ssh node3

 pandorafms# ssh-copy-id -p22 [email protected]
 pandorafms# ssh node3

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

Dans le nœud Pandora FMS, copiez le fichier known_hosts pour l'utilisateur apache:

pandorafms# yes | cp /root/.ssh/known_hosts /usr/share/httpd/.ssh/

Les étapes suivantes ne sont nécessaires que si les nœuds exécutent SSH sur un port non standard. Remplacez 22 par le numéro de port correct :

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

Installez les paquets nécessaires :

node3# yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
node3# yum install -y Percona-Server-server-57 percona-xtrabackup-24

Assurez-vous que le service Percona est désactivé, car il sera pris en charge par cluster:

 node3# systemctl stop mysqld
 node3# systemctl disable mysqld

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

Une fois le server installé, vous trouverez le générateur de configuration pour la réplication de la base de données dans le chemin :

/usr/share/pandora_server/util/myconfig_ha_gen.sh

Example: ./myconfig_ha_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
    -i --serverid Set the server id for the database (Mandatory)
Optional parameters:
    -l --location Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
    -d --database Set the database to be replicated. [ default value: pandora ] (optional)
    -b --binlog Set binlog file. [ default value: mysql-bin ] (optional)
    -u --dbuser Set dbuser for mysql connection and backups. [ default value: root ] (optional)
    -p --dbpass Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
    -s --poolsize Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
    -h --help Print help.

Dans le cas actuel où les bases de données ne sont pas sur le même serveur que l'application, il sera nécessaire de copier le script sur les nœuds pour qu'il soit exécuté localement.

pandorafms#
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/

Il ne sera nécessaire de passer le paramètre serverid que dans les environnements standards et quelques paramètres facultatifs pour les environnements personnalisés.

Si l'utilisateur par défaut ou défini ne se connecte pas à la base de données, le script se terminera par une erreur de connexion.

Vous avez également la possibilité de passer le nom de la base de données, l'utilisateur et le mot de passe comme arguments. Sinon, les paramètres par défaut seront utilisés.

Dans ce cas, il exécutera le script sur les deux nœuds, en ne transmettant le server id que s'il possède les informations d'identification par défaut, sinon il doit définir les paramètres nécessaires.

node3#
/root/myconfig_ha_gen.sh -i 3

Démarrez le serveur Percona :

node3# systemctl start mysqld

Un nouveau mot de passe temporaire connecté à /var/log/mysqld.log. sera généré. Connectez-vous au serveur Percona et changez le mot de passe root :

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

Sauvegardez la base de données du nœud maître (node1 en este ejemplo) dans cet exemple) et entrez le nom et l'emplacement du fichier journal maître (dans l'exemple, mysql-bin.000001 et 785):

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

Chargez la base de données dans le nouveau nœud, que nous appellerons node3, et configurez-le pour qu'il réplique à partir du node1 (définissez MASTER_LOG_FILE et MASTER_LOG_POS aux valeurs de l'étape précédente) :

node3# systemctl stop mysqld

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

node3# chown -R mysql:mysql /var/lib/mysql
node3# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node3# systemctl start mysqld
node3# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node3-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB: pandora
             Replicate_Ignore_DB:
              Replicate_Do_Table:
          Replicate_Ignore_Table:
         Replicate_Wild_Do_Table:
     Replicate_Wild_Ignore_Table:
                      Last_Errno: 0
                      Last_Error:
                    Skip_Counter: 0
             Exec_Master_Log_Pos: 785
                 Relay_Log_Space: 1252
                 Until_Condition: None
                  Until_Log_File:
                   Until_Log_Pos: 0
              Master_SSL_Allowed: No
              Master_SSL_CA_File:
              Master_SSL_CA_Path:
                 Master_SSL_Cert:
               Master_SSL_Cipher:
                  Master_SSL_Key:
           Seconds_Behind_Master: 0
   Master_SSL_Verify_Server_Cert: No
                   Last_IO_Errno: 0
                   Last_IO_Error:
                  Last_SQL_Errno: 0
                  Last_SQL_Error:
     Replicate_Ignore_Server_Ids:
                Master_Server_Id: 1
                     Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Master_Retry_Count: 86400
                     Master_Bind:
         Last_IO_Error_Timestamp:
        Last_SQL_Error_Timestamp:
                  Master_SSL_Crl:
              Master_SSL_Crlpath:
              Retrieved_Gtid_Set:
               Executed_Gtid_Set:
                   Auto_Position: 0
            Replicate_Rewrite_DB:
                    Channel_Name:
              Master_TLS_Version:
   1 row in set (0.00 sec)
mysql> QUIT

node3# systemctl stop mysqld

Installez les paquets nécessaires pour le cluster :

 node3# yum install -y epel-release corosync ntp pacemaker pcs

 node3# systemctl enable ntpd
 node3# systemctl enable corosync
 node3# systemctl enable pcsd

 node3# systemctl start ntpd

Ajouter un nouveau nœud au cluster:

node3# echo -n hapass | passwd hacluster --stdin
node3# cd /usr/lib/ocf/resource.d/
node3# mkdir percona
node3# cd percona
node3# curl -L -o pacemaker_mysql_replication.zip https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysql_replication.zip
node3# unzip pacemaker_mysql_replication.zip
node3# rm -f pacemaker_mysql_replication.zip
node3# chmod u+x mysql

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

Définissez le clone-max au nombre de nœuds dans le cluster (3 dans cet exemple) :

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

Vérifiez l'état du nœud :

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

3 nodes configured
3 resources configured

Online: [ node1 node2 node3 ]

Full list of resources:

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

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

Enregistrez le nœud de cluster dans la console Pandora FMS à partir du menu Servers → Manage database HA.

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

node2# pcs node standby node2
node2# pcs status
    Cluster name: pandoraha
    Stack: corosync
    Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
    Last updated: Tue Jun 12 08:20:49 2018
    Last change: Tue Jun 12 08:20:34 2018 by root via cibadmin on node2

    2 nodes configured
    3 resources configured

    Node node2: standby
    Online: [ node1 ]

    Full list of resources:

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

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

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

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

Faites une sauvegarde de la base de données du noeud maître (noeud1 dans cet exemple) et mettezà jour le nom du noeud maître et le nom et la position du fichier journal maître (dans cet exemple noeud 1, mysql-bin.000001 et 785) :

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

Chargez la base de données du noeud brisé :

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

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

Désactivez la mode standby du noeud node2 :

 node2# pcs node unstandby node2
 node2# pcs resource cleanup --node node2

Vérifiez l'état du cluster :

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

2 nodes configured
3 resources configured

Online: [ node1 node2 ]

Full list of resources:

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

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

Vérifiez l'état de la réplication de la base de données :

node2# mysql -uroot -ppandora
 mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000001
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node2-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000001
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB: pandora
             Replicate_Ignore_DB:
              Replicate_Do_Table:
          Replicate_Ignore_Table:
         Replicate_Wild_Do_Table:
     Replicate_Wild_Ignore_Table:
                      Last_Errno: 0
                      Last_Error:
                    Skip_Counter: 0
             Exec_Master_Log_Pos: 785
                 Relay_Log_Space: 1252
                 Until_Condition: None
                  Until_Log_File:
                   Until_Log_Pos: 0
              Master_SSL_Allowed: No
              Master_SSL_CA_File:
              Master_SSL_CA_Path:
                 Master_SSL_Cert:
               Master_SSL_Cipher:
                  Master_SSL_Key:
           Seconds_Behind_Master: 0
   Master_SSL_Verify_Server_Cert: No
                   Last_IO_Errno: 0
                   Last_IO_Error:
                  Last_SQL_Errno: 0
                  Last_SQL_Error:
     Replicate_Ignore_Server_Ids:
                Master_Server_Id: 1
                     Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Master_Retry_Count: 86400
                     Master_Bind:
         Last_IO_Error_Timestamp:
        Last_SQL_Error_Timestamp:
                  Master_SSL_Crl:
              Master_SSL_Crlpath:
              Retrieved_Gtid_Set:
               Executed_Gtid_Set:
                   Auto_Position: 0
            Replicate_Rewrite_DB:
                    Channel_Name:
              Master_TLS_Version:
   1 row in set (0.00 sec)

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

Retour à l'index de documentation du Pandora FMS