LINUX:Pacemaker - Serveurs en Failover
→ retour au menu de la Haute disponibilité
But
Autre application, nous allons mettre deux serveurs en Failover. Nous utiliserons l'approche utilisée par les routers mis en Failover couplée à l'utilisation de Drbd.
Principe
On dispose de deux ordinateurs Linux configurés en mode serveur. On va utiliser le logiciel Pacemaker qui les regroupent en cluster. Il sera utilisé en Failover. L'un des serveurs concentrera les ressources configurées dans Pacemaker tandis que l'autre sera en attente. Quand le premier serveur sera indisponible, par exemple suite à un problème matériel ou plus simplement lors d'une mise à jour de version, le second reprendra la tâche de serveur en récupérant les ressources de Pacemaker.
La première ressource consiste à créer une adresse IP virtuelle sur l'interface réseau "eth1" accessible par les clients; les autres "eth2" seront réservés à la synchronisation des données effectuée par la seconde ressource Drbd. L'adresse IP virtuelle sera le point d'accès pour les clients voulant utiliser les ressources du serveur. Les adresses IP réelles ne seront utilisées que pour une administration locale, par exemple, pour mettre à jour l'OS.
Le schéma suivant visualise la situation stable complètement opérationnelle. Dans ce cas, au contraire du cas des deux routeurs, aucun serveur n'a la préférence; quand le serveur qui a la main, s'arrête, le second reprend cette charge et la garde quand la situation redevient normale. Le tracé en vert visualise de trafic et l'adresse IP en rouge est virtuelle; elle n'est pas liée à un serveur mais va devoir passer de gauche à droite et inversement en fonction des besoins.
Dans le cas où le serveur de gauche tombe en panne (grisé), celui de droite prend la relève. L' adresse IP virtuelle migre sur l'autre serveur "fo2.home.dom" et la ressource Drbd de ce second serveur passe en mode Actif ("Primary").
Et en situation redevenue normale.
Pour plus grande facilité de présentation, nous allons séparer la partie de d'adresse IP virtuelle, de mise en oeuvre de Drbd et de montage du disque partagé, de la partie reprenant les ressources de services propres à un serveur. Pour cette seconde partie, nous prendrons l'exemple de services Web (Apache et Php), de service de base de données (Mariadb) utilisé par nombre d'applications Web tel WordPress et enfin de services de messagerie (Postfix et Dovecot). Le tout sera en mode sécurisé incontournable actuellement grâce à l'utilisation de certificats.
Grâce à Drbd, nous disposerons d'un espace disque partagé nommé ici "/data". C'est sur cet espace que les données utilisées par ces services seront placées.
Prérequis
Configurations de base
En premier, la Configuration de base de Pacemaker doit être effectuée. Elle complétée par la mise en place de Drbd vue dans l'article précédent. Quelques uns de ces prérequis seront adaptés en cours de route.
Fichier "hosts"
Sur chaque machine du cluster, on ajoute un nom aux différentes adresses réseaux. On le fait en local dans le fichier "/etc/hosts" suivant le schéma ci-dessus. Son contenu devient:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.1.71 fo1.home.dom 192.168.1.72 fo2.home.dom 192.168.1.73 cluster.home.dom 192.168.2.71 fd1.data.dom 192.168.2.72 fd2.data.dom # serveur mail 192.168.1.110 servermail.home.dom home.dom
L'adresse IP virtuelle "192.168.1.73" et le nom de machine associé "cluster.home.dom" sont cruciales pour la suite. En effet c'est par ce nom que les clients accèderont aux services du serveur actif.
Bug
Au cours de notre mise en place, nous avons été confrontés à un message d'erreur lors de la création de la ressource Drbd sous Pacemaker que ce soit par la commande "pcs" ou par l'interface Web. Ce problème était bloquant.
Voici le message d'erreur:
Error: Validation result from agent (use --force to override): ocf-exit-reason:meta parameter misconfigured, expected clone-max -le 2, but found unset. Error: Errors have occurred, therefore pcs is unable to continue
Nous utilisons la version "9.23.0-1" de Drbd sous Fedora 37.
En traçant le problème, il est apparu qu'une constante n'était pas initialisée pour effectuer correctement le test.
Dans le fichier "drbd" situé dans le répertoire "/usr/lib/ocf/resource.d/linbit" a cette tâche de création et d'utilisation de cette ressource sous Pacemaker.
Aux environs de la ligne 185 de ce fichier, nous avons ces lignes:
: ${OCF_RESKEY_CRM_meta_clone_node_max=1}
: ${OCF_RESKEY_CRM_meta_master_max=1}
: ${OCF_RESKEY_CRM_meta_master_node_max=1}
Il faut ajouter à ce bloc, la ligne:
: ${OCF_RESKEY_CRM_meta_clone_max=2}
Dès la ligne ajoutée, la création de la ressource Drbd ne pose plus de problème. Cette ligne n'a pas d'impact par la suite si elle n'est pas présente; elle n'intervient que lors de la phase de vérification des paramètres de Drbd avant son implémentation.
Configuration de la première partie
Dans cette partie, on se concentre sur l'activation de Drbd, de son espace disque partage et de l'adresse IP virtuelle.
Script
On effectue la suite des commandes suivantes à partir d'une des machines du cluster. On peut les mettre dans un script.
#!/bin/bash pcs resource create ClusterDrbd ocf:linbit:drbd drbd_resource=drbddata \ op start interval=0s timeout=240s \ op stop interval=0s timeout=100s \ op monitor interval=29s role=Promoted \ op monitor interval=31s role=Unpromoted \ clone promotable=true promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1 notify=true pcs resource create ClusterFs ocf:heartbeat:Filesystem device="/dev/drbd1" directory="/data" fstype="xfs" pcs constraint colocation add ClusterFs with Promoted ClusterDrbd-clone score=INFINITY pcs constraint order promote ClusterDrbd-clone then start ClusterFs pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.1.73 nic=eth1 cidr_netmask=24 iflabel=ethcl1 lvs_support=true op monitor interval=30s pcs constraint colocation add ClusterIP with ClusterFs score=INFINITY pcs constraint order ClusterFs then start ClusterIP
Ajout de la ressource de Drbd
Les lignes suivantes:
pcs resource create ClusterDrbd ocf:linbit:drbd drbd_resource=drbddata \ op start interval=0s timeout=240s \ op stop interval=0s timeout=100s \ op monitor interval=29s role=Promoted \ op monitor interval=31s role=Unpromoted \ clone promotable=true promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1 notify=true
va créer une ressource, nommée "ClusterDrbd" qui va activer Drbd en mode "Actif/Passif" ("Primary/Secondery") grâce à la fonction "ocf:linbit:drbd" sur base de la ressource Drbd "drbddata". Cette ressource sera présente sur les deux machines ("clone" et "clone-max=2"). Une seule machine est "Active" ("promoted-node-max=1"). Notons que la syntaxe a évolué par rapport au passé; avant on parlait de "Master/Slave", maintenant "Promoted/Unpromoted". Ces changements de syntaxe selon les versions se rencontre un peu partout d'où la nécessité de revalider celle-ci minutieusement avant tout changement de version spécialement lors de changement de version de l'OS qui intervient tous les 6 mois dans le cas de Fedora.
Ajout de la ressource qui monte l'espace disque partagé
La ligne suivante:
pcs resource create ClusterFs ocf:heartbeat:Filesystem device="/dev/drbd1" directory="/data" fstype="xfs"
va créer la ressource disque, nommée "ClusterFs" qui va monter le device "/dev/drbd1", initiée par la ressource "drbddata", sur le répertoire "/data" en utilisant le format "xfs".
Ajout de la ressource de l'adresse IP virtuelle
La ligne suivante:
pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.1.73 nic=eth1 cidr_netmask=24 iflabel=ethcl1 lvs_support=true op monitor interval=30s
va créer une ressource, nommées "ClusterIP" qui va activer l'adresse virtuelle "192.168.1.73/24" grâce à la fonction "ocf:heartbeat:IPaddr2". Elle sera placée sur l'interface réseau "eth1". Le nom virtuel sera aussi donné: "ethcl1".
Contraintes
Les contraintes d'ordre de démarrage sont connues; elles ont déjà été rencontrées dans les articles précédents. Il tombe sous le sens que la ressource "drbddata" active doit être effective avant de pouvoir la monter cet espace partagé.
Les deux ressources "ClusterFs" et "ClusterIP" doivent se situer sur la même machine ("INFINITY") que la ressource Drbd (ClusterDrbd") qui est active ("Promoted"), parmi les deux ("clone"), d'où la syntaxe "Promoted ClusterDrbd-clone".
→ retour au menu de la Haute disponibilité