Table des matières
Haute disponibilité (High Availability)
Introduction
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.
Dimensionnement et conception d'architecture HA
Les composantes les plus importantes de Pandora FMS sont
- Base de données
- Serveur
- 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
Dimensionnement
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
Conceptions architecturales des HA
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).
Pour les grands environnements, nous définirons chacun des schémas de configuration décrits ci-dessus comme des nœuds informatiques.
Exemple
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.
Pour combiner toutes les bases de données historiques (4) dans un seul appareil, vous devez redimensionner leurs caractéristiques pour assumer la charge supplémentaire :
Histoire combinée : -------------------- CPU : 8 cores RAM : 12 GO Disque : 1200GB
Haute disponibilité du serveur de données
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
Haute disponibilité dans les agents logiciels
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
ouno
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.
Seul la configuration distante de l'agent est opérationnelle, dans le cas où elle est activée, sur le serveur principal.
Haute disponibilité des serveurs de réseau, WMI, plugin, web, prédiction et autres
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.
Configuration sur les serveurs
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 ”.
Soyez prudent en désactivant les 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 seront pas exécutés.
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
Haute disponibilité de la console 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.
Ce guide vous indique comment partager ces répertoires avec NFS et GlusterFS.
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.
Mise à jour
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.
Haute disponibilité dans la base de données
Le but de cette section est d'offrir une solution complète pour l’HA dans les environnements Pandora FMS. C'est le seul modèle d'HA qui bénéficie d'un soutien officiel pour le Pandora FMS. Cette solution est fournie - pré-installée - à partir de l'OUM 724. Ce système remplace les DRBD et autres systèmes HA recommandés dans le passé.
C'est la première implémentation de la DB HA de Pandora FMS et le processus d'installation est presque entièrement manuel, utilisant la console GNU/Linux comme root. Dans les prochaines versions, nous faciliterons la configuration à partir de l'interface graphique
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.
C'est une fonctionnalité avancée qui requiert des connaissances dans les systèmes GNU/Linux.
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.
Il est recommandé de conserver un maximum de 15 jours de données et d'événements, pour un stockage plus long, une base de données historique doit être mise en place. Voir également la rubrique “Gestion et administration des serveurs PFMS”.
Installation pour RHEL 8 et Rocky Linux 8
Version 760 ou ultérieure
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.
Conditions préalables
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
L'outil de base de données Pandora FMS HA ne fonctionnera pas correctement si OpenSSH a un avertissement configuré.
Générez de nouvelles clés d'authentification SSH pour chaque host et copiez la clé publique pour chacun des hosts.
Vous pouvez générer des clés pour un utilisateur autre que root pour une installation ultérieure du cluster avec l'utilisateur “non-root”.
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/
Les étapes suivantes ne sont nécessaires que si les nœuds exécutent SSH sur un port non standard.
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
Installation de Percona
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
Si le service système n'est pas désactivé, le gestionnaire de ressources cluster ne fonctionnera pas correctement.
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
Chaque nœud doit avoir un identifiant unique.
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
Installation du FMS Pandora
Vous pouvez soit effectuer une installation entièrement nouvelle, soit migrer les données que vous avez depuis une instance existante.
Nouvelle installation du FMS de Pandora
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).
Installation existante de Pandora FMS
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"
Configuration de la réplication
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 à:
Vous devez vous assurer que Slave_IO_Running
et Slave_SQL_Running
indiquent Yes. D'autres valeurs peuvent être différentes de celles de l'exemple.
Si tout est correct, quittez l'interface de la base de données:
#node2 mysql> QUIT
Configuration d'un cluster à deux nœuds
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
Vous pouvez voir un message d'erreur lorsque vous essayez de démarrer le service corosync: c'est parce qu'il n'est pas encore configuré, ignorez-le et continuez avec les étapes suivantes.
Arrêtez le serveur Percona:
all# systemctl stop mysqld
Authentification de tous les nœuds du cluster
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 à :
Les deux noeuds doivent être en ligne
( Online: [ node1 node2 ]
).
D'autres valeurs peuvent être différentes de celles de l'exemple.
Installation de l'agent de réplication Pacemaker de Percona
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.
Si le mot de passe par défaut utilisé dans ce guide pour l'utilisateur root de la base de données a été modifié, il est conseillé de mettre à jour respectivement replication_passwd
et test_passwd
Les noms des ressources du cluster doivent être exactement ceux indiqués dans ce guide ( pandoraip et pandoradb)
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 à :
Les deux noeuds doivent être en ligne
( Online: [ node1 node2 ]
).
D'autres valeurs peuvent être différentes de celles de l'exemple.
Configuration d'un cluster à deux nœuds avec un utilisateur "non root"
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
Installation pour RedHat 7 et CentOS 7
Version 759 ou antérieure
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é.
Lorsque l'on référence all, cela 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.
Pré-requis
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
L'outil de base de données HA de Pandore FMS ne fonctionnera pas correctement si une bannière est configurée pour Open SSH.
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 :
Vous pouvez générer des clés pour un utilisateur non root pour une installation ultérieure de clusters avec un utilisateur “no root.”
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
Installation de Percona
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
Si le service système n'est pas désactivé, le gestionnaire de ressources de cluster ne fonctionnera pas correctement.
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
Important : Chaque noeud doit avoir un identificateur unique
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
Installation de Pandora FMS
Nouvelle installation de Pandora FMS
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
À partir de la version NG 754 il dispose d'options additionnelles dans le démarrage et l'arrête manuelle d'Environnements d'Haute Disponibilité (HA).
Installation de Pandora FMS existante
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"
Configuration de la réplication
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
Nous devons nous assurer que Slave_IO_Running
et Slave_SQL_Running
affichent Yes
. D'autres valeurs peuvent être différentes de l'exemple.
Il est recommandé de ne pas utiliser l'utilisateur root pour effectuer ce processus. Il est conseillé de donner les permissions à un autre utilisateur chargé de la gestion de la base de données pour éviter d'éventuels conflits.
Configuration du cluster de deux nœuds
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
Nous authentifions tous les noeuds du cluster
Créer et démarrer le cluster :
all# echo hapass | passwd hacluster --stdin
node1# pcs cluster auth -u hacluster -p hapass --force node1 node2 node1# pcs cluster setup --force --name pandoraha node1 node2 node1# pcs cluster start --all node1# pcs cluster enable --all node1# pcs property set stonith-enabled=false node1# pcs property set no-quorum-policy=ignore
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
Les deux nœuds doivent être en ligne
(Online: [ node1 node2 ]
).
D'autres valeurs peuvent être différentes de l'exemple.
Installation de l'agent de réplication Pacemaker de Percona
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 :
Si vous avez changé le mot de passe par défaut utilisé dans ce guide pour l'utilisateur root de la base de données, vous devez mettre à jour replication_passwd
et test_passwd
en conséquence.
Les noms des resspurces du cluster doivent être exactement ceux indiqués dans ce guide (pandoraip
et pandoradb
).
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
Les deux nœuds doivent être en ligne (Online : [|node1 node2 ]
). D'autres valeurs peuvent être différentes de l'exemple.
Configuration du cluster de deux nœuds avec l'utilisateur "no root"
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
Configuration du Pandora FMS
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 :
Seconds_behind_master
devrait être proche de 0
. Si elle continue à augmenter, la réplication se produit à velocité ralenti ou s'arrête tout simplement. Si vous souhaitez connaitre plus d'informations (en général) sus les repliques de bases de données, consultez notre blog.
Récupération automatique des nœuds dans Splitbrain
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 :
- Supprimez les sauvegardes précédentes.
- Sauvegarder le
datadir
du nœud secondaire. - Sauvegarde le nœud primaire.
- Envoie la sauvegarde du nœud principal au nœud secondaire ( Master → Slave).
- Démarre la ressource du nœud “secondaire” avec les paramètres de resynchronisation correspondants au moment de la sauvegarde.
- 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.
Ajout d'un nouveau nœud au cluster
Répétez les étapes pour installer le node1 et le node2, en fonction de la version que vous allez utiliser sur le nouveau nœud:
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:
Les clés peuvent être générées pour un utilisateur autre que root pour l'installation du cluster avec un utilisateur “non-root”
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
Si le service système n'est pas désactivé, le gestionnaire de ressources du cluster ne fonctionnera pas correctement.
Configurez Percona, en remplaçant <ID> par un numéro qui doit être unique pour chaque nœud de cluster:
La réplication de la base de données ne fonctionnera pas si deux nœuds ont le même SERVER_ID.
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
Assurez-vous que Slave_IO_Running
etSlave_SQL_Running
indiquent Yes. D'autres valeurs peuvent être différentes de celles de l'exemple.
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
Tous les nœuds doivent être en ligne
(Online: [ node1 node2 node3 ]
).
D'autres valeurs peuvent être différentes de l'exemple.
Enregistrez le nœud de cluster dans la console Pandora FMS à partir du menu Servers → Manage database HA.
Réparation d'un nœud cassé
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
node2 devrait être en attente
(Node node2 : standby
).
D'autres valeurs peuvent être différentes de l'exemple.
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
Les deux nœuds doivent être en ligne
(Online: [node1 node2 ]
).
D'autres valeurs peuvent être différentes de l'exemple.
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)
Il convient de vérifier que Slave_IO_Running
et Slave_SQL_Running
montrent Yes
. D'autres valeurs pourraient être différents de ceux de l'exemple.
Dépannage
Que faire si un des nœuds du cluster ne fonctionne pas ?
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é.