Pandora: Documentation fr: Haute disponibilite

From Pandora FMS Wiki
Jump to: navigation, search

Retour à l'index de documentation du Pandora FMS

1 Haute disponibilité (High Availability)

1.1 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, et que chacun de ses modules puisse fonctionner de manière indépendante. Mais il est également conçu pour fonctionner en collaboration avec d'autres composants et être capable d'assumer la charge des composants qui sont tombés.

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

Ha1.png

Il est clair que les agents ne sont pas redondants. Si un agent tombe, il n'est pas logique d'en exécuter un autre, car la seule cause de la chute 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.

1.2 Dimensionnement et conception d'architecture HA

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 [1]


1.2.1 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

Dim std1.png

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

Dim std2.png


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

Dim std3.png

1.2.2 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

Dim ha1.png

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


Dim ha2.png

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


Dim ha3.png


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


Dim ha4.png


Note : Pour les grands environnements, nous définirons chacun des schémas de configuration décrits ci-dessus comme des nœuds informatiques.

1.2.3 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, nous devrons avoir une Meta Console installée, depuis laquelle nous pourrons 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


Note : 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

1.3 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 nous utilisons 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 par NFS les répertoires suivants 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

Ha2.png

1.4 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 :

  1. 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 tentacule 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 tentacule, ssh, ftp, ...
  • secondary_server_pwd : option de mot de passe pour le transfert FTP
  • secondary_server_ssl : Il sera mis à oui ou à non 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.

Template warning.png

Seul la configuration distante de l'agent est opérationnelle, dans le cas où elle est activée, sur le serveur principal.

 


1.5 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 (seuil du serveur 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.

Ha3.png

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

Ha4.png

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

1.5.1 Configuration sur les serveurs

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

  • Mode maître.
  • Mode non maître.

Si un serveur tombe en panne, 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".

Template warning.png

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

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

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.

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

OUM1.JPG

OUM2.JPG

1.7 Haute disponibilité dans la base de données

Info.png

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

 


Template warning.png

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 Linux comme racine. 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.

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.

Ha cluster diagram.png

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.

Template warning.png

C'est une fonctionnalité avancée qui requiert des connaissances dans les systèmes Linux.

 


1.7.1 Installation

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

1.7.1.1 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. Nous avons retiré 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

Template warning.png

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 :

Template warning.png

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. Nous remplaçons " 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

1.7.1.2 Installation de Percona

Nous installons le paquet 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

Nous nous assurons que le service Percona est désactivé, car il sera géré par le cluster :

all# systemctl disable mysqld

Template warning.png

Si le service système n'est pas désactivé, le gestionnaire de ressources de cluster ne fonctionnera pas correctement.

 


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

Template warning.png

La réplication de la base de données ne fonctionnera pas si deux nœuds ont le même SERVER_ID.

 


all# export SERVER_ID=<ID>
all# export POOL_SIZE=$(grep -i total /proc/meminfo | head -1 | \
awk '{print $(NF-1)*0.4/1024}' | sed s/\\..*$/M/g)
all# cat <<EOF > /etc/my.cnf
[mysqld]
server_id=$SERVER_ID

datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
log-error=/var/log/mysqld.log
show_compatibility_56=on

max_allowed_packet = 64M
# Recommendation: not to assign a value greater than 35% of available RAM memory
innodb_buffer_pool_size = $POOL_SIZE
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
thread_cache_size = 8
max_connections = 200
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
log-bin=mysql-bin
query_cache_type = 1
query_cache_size = 32M
query_cache_limit = 8M
sql_mode=""
expire_logs_days=3
   
binlog-format=ROW
log-slave-updates=true
sync-master-info=1
sync_binlog=1
max_binlog_size = 100M
replicate-do-db=pandora
port=3306 
report-port=3306
report-host=master
gtid-mode=off
enforce-gtid-consistency=off
master-info-repository=TABLE
relay-log-info-repository=TABLE

sync_relay_log = 10
sync_relay_log_info = 10
slave_compressed_protocol = 1
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 10
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 1800 


[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[client]
user=root
password=pandora
EOF

Nous lançons le serveur Percona :

all# systemctl start mysqld

Un nouveau mot de passe temporaire sera généré en se connectant à /var/log/mysqld.log. Nous nous connectons au serveur Percona et changeons 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

1.7.1.3 Installation du FMS Pandora

1.7.1.3.1 Nouvelle installation de Pandora FMS

Nous avons installé Pandora FMS dans la base de données récemment créée. Pour plus d'informations, veuillez consulter :

https://pandorafms.com/docs/index.php?title=Pandora:Documentation_fr:Instalation

On arrête le serveur FMS de Pandora :

pandorafms# /etc/init.d/pandora_server stop
1.7.1.3.2 Installation de FMS Pandora existants

On arrête le serveur FMS de Pandora :

pandorafms# /etc/init.d/pandora_server stop

Nous faisons une sauvegarde de la base de données de Pandora FMS :

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

Nous l'avons téléchargé dans la nouvelle base de données :

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

1.7.1.4 Configuration de la réplication

Nous accordons 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

Nous faisons une sauvegarde de la base de données du premier noeud et nous écrivons 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

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

Template warning.png

Si l'installation de Pandora FMS a été faite à partir d'une ISO il faudra supprimer la base de données originale du noeud 2. Seule la base de données du noeud 1 sera nécessaire, c'est celle qui stockera les informations des deux machines. De cette façon, l'équilibrage sera fait correctement.

 


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

Template warning.png

Nous devons nous assurer que Slave_IO_Running et Slave_SQL_Running affichent Oui. D'autres valeurs peuvent être différentes de l'exemple.

 


Template warning.png

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.

 


1.7.1.5 Configuration du cluster de deux nœuds

Nous installons les paquets 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

On arrête 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

Nous vérifions 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

Template warning.png

Les deux nœuds doivent être en ligne ('En ligne : [ node1 node2 ]). D'autres valeurs peuvent être différentes de l'exemple.

 


Nous avons installé l'agent de réplication Percona Pacemaker :

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

Nous configurons les ressources du cluster. Nous remplaçons <VIRT_IP> par l'adresse IP virtuelle de préférence :

Template warning.png

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.

 


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

Nous avons vérifié 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

Template warning.png

Les deux nœuds doivent être en ligne ('En ligne : [ node1 node2 ]). D'autres valeurs peuvent être différentes de l'exemple.

 


1.7.1.6 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

1.7.1.7 Configuration du Pandora FMS

Nous nous assurons que php-pecl-ssh2 est installé :

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

Nous avons installé et démarré le service pandora_ha :

pandorafms# cat > /etc/systemd/system/pandora_ha.service <<-EOF
[Unit]
Description=Pandora FMS Database HA Tool

[Service]
Type=forking

PIDFile=/var/run/pandora_ha.pid
Restart=always
ExecStart=/usr/bin/pandora_ha -d -p /var/run/pandora_ha.pid /etc/pandora/pandora_server.conf

[Install]
WantedBy=multi-user.target
EOF

pandorafms# systemctl enable pandora_ha
pandorafms# systemctl start pandora_ha

Connectez-vous à la console Pandora FMS et naviguez jusqu'à Serveurs -> Gérer la base de données HA :

HAnuevo1.JPG

Cliquez sur Ajouter un nouveau nœud et créez une entrée pour le premier nœud :

Manage ha add node.png

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

Manage ha view.png

Template warning.png

Vous devrez vérifier que le fichier 'functions_HA_cluster.php a les bons chemins $ssh_user pour qu'il s'affiche correctement et vous permette d'interagir correctement avec les icônes.

 


Template warning.png

Seconds behind master devrait être proche de 0. Si elle continue à augmenter, la réplication n'augmente pas.

 


1.7.2 Ajout d'un nouveau nœud au cluster

Template wip.png

Nous sommes en train de travailler sur la traduction de la documentation de Pandora FMS. Veuillez nous excuser de cet inconvénient.

 


Nous avons installé Percona (voir Installation de Percona [2]). Nous faisons une sauvegarde de la base de données du noeud maître (noeud1 dans cet exemple) et nous écrivons 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

Nous chargeons la base de données dans le nouveau noeud, que nous appellerons noeud3, et nous le configurons pour qu'il se réplique à partir du noeud1 (nous configurons 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

{{Warning|Vous devez vous assurer que Slave_IO_Running et Slave_SQL_Running affichent Yes. D'autres valeurs pourraient être différentes de l'exemple.}

Nous ajoutons 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 mysql https://github.com/Percona-Lab/\
pacemaker-replication-agents/raw/master/agents/mysql_prm
node3# chmod u+x mysql
node1# pcs cluster auth -u hacluster -p hapass --force node3
node1# pcs cluster node add --enable --start node3

Nous configurons clone-max au nombre de nœuds de notre 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"

Nous avons vérifié 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

Template warning.png

Tous les nœuds doivent être en ligne ('En ligne : [ node1 node2 node3 ]). D'autres valeurs peuvent être différentes de l'exemple.

 


1.7.3 Réparation d'un noeud 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

Template warning.png

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

Nous faisons une sauvegarde de la base de données du noeud maître (noeud1 dans cet exemple) et nous écrivons le nom et la position du fichier journal maître (dans cet 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

Nous chargeons la base de données du noeud brisé et la configurons pour qu'elle se réplique à partir du noeud 1 (nous configurons MASTER_LOG_FILE et MASTER_LOG_POS aux valeurs de l'étape précédente) :

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

node2# systemctl stop mysqld

Template warning.png

Vous devez vous assurer que Slave_IO_Running et Slave_SQL_Running affichent Yes. D'autres valeurs pourraient être différentes de l'exemple.

 


Nous désactivons le mode de veille du nœud 2 :

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

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

{{Warning|Les deux nœuds doivent être en ligne (Online: [ node1 node2 ]). D'autres valeurs peuvent être différentes de l'exemple.}

1.7.4 Dépannage

1.7.4.1 Que faire si un des nœuds du cluster ne fonctionne pas ?

Manage ha failed.png

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