LINUX:Pacemaker - Configuration de base
→ retour au menu de la Haute disponibilité
But
Avant d'aborder des cas spécifiques de clusters, on passe d'office par une étape de configuration de base commune à tous les cas. Par la suite, quand on abordera notre cas spécifique de Loadbalancing, deux paramètres seront changés.
Matériel et adressage IP
Pour ces exercices, nous avons besoin de deux machines, chacune avec deux interfaces réseaux. Le schéma ci-dessous reprend la connectique, le nom des machines Linux et leur adressage IP.
Configuration de Pcs sur toutes les machines du cluster
Toute la configuration va se passer à l'aide du programme en ligne de commande "pcs". En premier lieu, il faut initier ce cadre de travail sur toutes les machines du cluster afin qu'elles puissent communiquer.
Initialisation du mot de passe
Sur les deux machines du cluster, un utilisateur "hacluster" est créé. Il va servir au transfert d'informations sécurisé. Son utilisation est désactivé. Pour le rendre utilisable, il faut initialiser le mot de passe par la commande suivante:
passwd hacluster
Il demande le nouveau mot de passe et sa confirmation. Nous attribuerons le mot de passe: "Chasse4321Eau" (A adapter à votre convenance. Cette tâche est à effectuer sur chaque machine du cluster.
Service "pcsd.service"
Pour effectuer la configuration, on utilisera la commande de ligne "pcs" qui va transmettre nos ordres au service local "pcsd.service". Il va le transmettre aux services équivalent "pcsd.service" s'exécutant également sur les autres machines du cluster. Ce qui nous permettra de faire ces manipulation qu'à partir d'une seule machine.
Mais en premier lieu, nous désirons restreindre ce trafic à la couche IPV4. Dans le fichier de configuration de ce service "/etc/sysconfig/pcsd'", on ajoute la ligne:
PCSD_BIND_ADDR='0.0.0.0'
On remarque au passage, dans ce fichier, que le port d'écoute TCP de ce service est par défaut le 2224 ("PCSD_PORT=2224").
On peut maintenant lancer ce service:
systemctl start pcsd.service
Ces opérations sont à faire sur toutes les machines du cluster.
A ce stade, on peut constater qu'un nouveau port est à l'écoute. La commande suivante:
netstat -nltp | grep 2224
donne:
tcp 0 0 0.0.0.0:2224 0.0.0.0:* LISTEN 14864/python3
Configuration centralisée grâce à Pcs
Maintenant nous pouvons commencer la configuration de Pacemaker et de Corosync.
Définir les machines faisant partie du cluster
La commande suivante permet d'ajouter les machines qui vont converser ensemble:
pcs host auth fo1.home.dom fo2.home.dom -u hacluster -p Chasse4321Eau
Nous y trouvons le nom de nos deux machines. On y constate également notre utilisateur Unix "hacluster" et son mot de passe "Chasse4321Eau". Ces deux paramètres additionnels nous évitent que la commande ne nous les demande interactivement. Elle s'échange une clé sécurisée comme le protocole Ssh, pour pouvoir s'abstenir à l'avenir de devoir s'authentifier par le couple nom d'utilisateur/mot de passe.
Création du cluster
La commande suivante crée le cluster auquel nous avons donné de nom de "fo_cluster" et qui va inclure nos deux machines. Par la même occasion, Corosync va être configuré. Il utilisera le protocole crypté "knet" en utilisant le port UDP multicast 5420 sous IPV4.
pcs cluster setup fo_cluster fo1.home.dom addr=192.168.1.71 fo2.home.dom addr=192.168.1.72 transport knet ip_version=ipv4 link transport=udp mcastport=5420
Si vous avez plusieurs clusters qui cohabitent, donnez un n° de port différent. Le n° de port par défaut est 5405.
Fichier de configuration de Corosync
Notre action précédente a créé le fichier de configuration de Corosync "/etc/corosync/corosync.conf" dont voici le contenu:
totem {
version: 2
cluster_name: fo_cluster
transport: knet
ip_version: ipv4
crypto_cipher: aes256
crypto_hash: sha256
cluster_uuid: b7c29a052377490da9c146c33d671672
interface {
knet_transport: udp
linknumber: 0
mcastport: 5420
}
}
nodelist {
node {
ring0_addr: 192.168.1.71
name: fo1.home.dom
nodeid: 1
}
node {
ring0_addr: 192.168.1.72
name: fo2.home.dom
nodeid: 2
}
}
quorum {
provider: corosync_votequorum
two_node: 1
}
logging {
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
timestamp: on
}
Vous y retrouvez les paramètres introduits par la commande "pcs" précédente (en gras).
Remarquez au passage le paramètre spécial "two_node: 1". Il est propre au cas d'un cluster composé de seulement deux machines. Normalement pour qu'un cluster puisse démarrer, il faut 50% des machines + 1, c'est à dire 2 ou 100% dans ce cas pour que le cluster démarre, si cette option n'est pas définie. Cette notion est connue sous le nom de "quorum". Ce paramètre permet d'outrepasser cette règle pour la ramener à 50% pour deux machines. Par défaut, chaque machine a une voie (ou vote). C'est ce nombre de voies actives qui est à comparer au nombre total de voies possible, et qui équivaut par défaut au nombre de machines du cluster, pour en définir le pourcentage actif.
Activation et lancement du cluster
Maintenant nous sommes fin prêts pour activer et démarrer le cluster par les deux commandes qui suivent:
pcs cluster enable --all pcs cluster start --all
Ces commandes lancent en fait sur toutes les machines du cluster les services "corosync.service" et "pacemaker.service" en plus du service "pcsd.service".
Maintenant que Corosync est lancé, la commande suivante sur la machine "fo1.home.dom":
netstat -nlup | grep 5420
donne:
udp 0 0 192.168.3.71:5420 0.0.0.0:* 28367/corosync
Et sur l'autre machine:
udp 0 0 192.168.3.72:5420 0.0.0.0:* 23585/corosync
On y remarque l'apparition du port UDF 5420 comme mis dans le fichier de configuration de Corosync.
Finalisation
Nous sommes avec une configuration limitée. Nous désactivons deux fonctions: une action en cas de "quorum" non atteint et une détection de déficience par une ressource tierce.
pcs property set no-quorum-policy=ignore pcs property set stonith-enabled=false
Emplacement des fichiers
Tout un ensemble de fichiers sont générés:
- les fichiers de configuration dans les répertoires suivants:
/etc/corosync /etc/pacemaker
- les journaux dans les répertoires suivants:
/var/log/pcsd /var/log/cluster /var/log/pacemaker
- les autres fichiers de configuration dans les répertoires suivants:
/var/lib/corosync /var/lib/pcsd /var/lib/pacemaker/cib /var/lib/pacemaker/pengine
Un fichier est particulier. Le fichier "/var/lib/pacemaker/cib/cib.xml" contient la configuration de Pacemaker mais ne vous avisez pas de le modifier manuellement. Il est protégé par une signature. Son contenu est instructif.
Pour repartir de zéro, il faut arrêter les trois services cités ci-dessus et effacer tous les fichiers de ces répertoires
Statut
On peut visionner l'état du cluster avec la commande suivante:
crm_mon -1
Cette commande peut être exécutée à partir de toute machine du cluster. Elle donne:
Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-08 11:24:39 +01:00) Cluster Summary: * Stack: corosync * Current DC: fo1.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition with quorum * Last updated: Wed Feb 8 11:24:39 2023 * Last change: Wed Feb 8 11:24:34 2023 by root via cibadmin on fo1.home.dom * 2 nodes configured * 0 resource instances configured Node List: * Online: [ fo1.home.dom fo2.home.dom ] Active Resources: * No active resources
Le paramètre "-1" permet d'avoir un affichage unique. S'il n'est pas spécifié, l'affichage est perpétuel et se rafraichit régulièrement de façon similaire à la commande "top".
La commande:
pcs status
donne un résultat très proche:
Cluster name: fo_cluster Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-08 21:23:37 +01:00) Cluster Summary: * Stack: corosync * Current DC: fo1.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition WITHOUT quorum * Last updated: Wed Feb 8 21:23:37 2023 * Last change: Wed Feb 8 21:22:50 2023 by root via cibadmin on fo1.home.dom * 2 nodes configured * 0 resource instances configured * Online: [ fo1.home.dom fo2.home.dom ] Full List of Resources: * No resources Daemon Status: corosync: active/enabled pacemaker: active/disabled pcsd: active/enabled
→ retour au menu de la Haute disponibilité