LINUX:Pacemaker - ISCSI en Failover et SBD (fence)
→ retour au menu de la Haute disponibilité
But
A la configuration précédente, nous ajoutons la notion de "Fence" avec la couche SBD. Le logiciel SBD utilise un device de type Watchdog (chien de garde) qui permet d'arrêter la machine client ISCSI Initiator quand elle ne plus atteindre sa cible ISCSI de référence. Cette situation se présente, par exemple, dans le cas d'une défaillance réseau. Cette arrêt permet d'éviter des problèmes de corruptions de données sur les ressources distantes. Nous n'utiliserons qu'un serveur ISCSI Target mais nous garderons l'approche Failover.
Matériel et adressage IP
Dans notre exemple, nous utilisons un serveur ISCSI ("target") et deux clients ISCSI ("initiator"). Le schéma ci-dessous nous montre l'adressage IP et le nom de ces trois machines. En outre pour mettre la fonction Failover, une adresse IP virtuelle est ajoutée. Elle passera d'un client ISCSI à l'autre.
Le cluster Pacemaker ne comportera que les deux clients ISCSI (Initiator): "cl1.home.dom" et "cl2.home.dom".
Prérequis
Configurations de base
En premier, les Prérequis doivent être effectués.
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 sv1.home.dom 192.168.1.73 cl1.home.dom 192.168.1.74 cl2.home.dom 192.168.1.75 cluster.home.dom # serveur mail 192.168.1.110 servermail.home.dom home.dom
ISCSI
Nous nous baserons sur la configuration de l'article sur ISCSI à part qu'on double le client Initiator. Mais le service "iscsi.service" ainsi que le montage du disque ISCSI "/datab" (fichier "/etc/fstab") sur les clients Initiator n'est pas lancé. C'est Pacemaker qui s'en chargera.
Nous expliciterons les quelques changements et leurs buts sera explicités par la suite.
Liste des parties à configurer
Cette configuration est plus compliquée et doit suivre une série d'étapes dans le bon ordre.
- Configuration du serveur ISCSI Target
- Configuration du côté des clients ISCSI Initiator
- Configuration de Watchdog sur les clients
- Configuration de SBD sur les clients
- Configuration de la base de Pacemaker sur les clients
- Configuration de SBD-fence sous Pacemaker sur les clients
- Configuration de ressources finales de Pacemaker sur les clients
ISCSI - Target
Sur le serveur ISCSI Target "sv1.home.dom", nous avons besoin de deux espaces disques. Nous les mettrons sur le même disque.
- la première partition va être utilisées par le processus SBD que nous verrons par la suite. Cette partition n'a pas besoin de beaucoup d'espace; nous utilisons 1MB. Il servira a l'échange de courts messages. Attention, cet espace ne doit pas avoir d'interaction avec d'autres espaces disques distants tels DRBD ou un RAID distant.
- la seconde partition sera utilisée comme espace disque distant par les clients. Le reste du disque lui sera attribué.
Partitionnement
Sur un disque vierge que nous nommerons "/dev/sdb", on le partitionne avec "fdisk":
fdisk /dev/sdb
Voici la suite des commandes (en gras) et de l'affichage lié:
Bienvenue dans fdisk (util-linux 2.38.1).
Les modifications resteront en mémoire jusqu'à écriture.
Soyez prudent avant d'utiliser la commande d'écriture.
Commande (m pour l'aide) : p
Disque /dev/sdb : 149,05 GiB, 160041885696 octets, 312581808 secteurs
Modèle de disque : ST3160815AS
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 043ACF55-DA46-944F-82A0-DB8258F243DC
Commande (m pour l'aide) : n
Numéro de partition (1-128, 1 par défaut) :
Premier secteur (2048-312581774, 2048 par défaut) :
Dernier secteur, +/-secteurs ou +/-taille{K,M,G,T,P} (2048-312581774, 312580095 par défaut) : +1M
Une nouvelle partition 1 de type « Linux filesystem » et de taille 1 MiB a été créée.
Commande (m pour l'aide) : n
Numéro de partition (2-128, 2 par défaut) :
Premier secteur (4096-312581774, 4096 par défaut) :
Dernier secteur, +/-secteurs ou +/-taille{K,M,G,T,P} (4096-312581774, 312580095 par défaut) :
Une nouvelle partition 2 de type « Linux filesystem » et de taille 149 GiB a été créée.
Commande (m pour l'aide) : p
Disque /dev/sdb : 149,05 GiB, 160041885696 octets, 312581808 secteurs
Modèle de disque : ST3160815AS
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 043ACF55-DA46-944F-82A0-DB8258F243DC
Périphérique Début Fin Secteurs Taille Type
/dev/sdb1 2048 4095 2048 1M Système de fichiers Linux
/dev/sdb2 4096 312580095 312576000 149G Système de fichiers Linux
Commande (m pour l'aide) : w
La table de partitions a été altérée.
Appel d'ioctl() pour relire la table de partitions.
Synchronisation des disques.
Configuration de Tgt
La configuration générale de Tgt se trouve dans le répertoire "/etc/tgt" et la configuration spécifique qui nous concerne sera mise dans le fichier "/etc/tgt/conf.d/diskb.conf. Nous allons y inclure les deux partitions créées.
Voici son contenu:
<target iqn.2023-02.dom.home.sv1:sv1.target1> backing-store /dev/sdb1 initiator-name iqn.2023-02.dom.home.sv:sv.initiator01 initiator-name iqn.2023-02.dom.home.sv:sv.initiator02 incominguser diskuser Eupen2Marron initiator-address 192.168.1.73 initiator-address 192.168.1.74 </target> <target iqn.2023-02.dom.home.sv1:sv1.target2> backing-store /dev/sdb2 initiator-name iqn.2023-02.dom.home.sv:sv.initiator01 initiator-name iqn.2023-02.dom.home.sv:sv.initiator02 incominguser diskuser Eupen2Marron initiator-address 192.168.1.73 initiator-address 192.168.1.74 </target>
Le premier "Target" sera utilisé par le processus SBD et le second pour le stockage de données.
En outre, comme nous avons ici deux clients ISCSI Initiator, chacun a son propre "initiator-name". Si nous ne faisons pas cette distinction, les connexions se feront et se déferont perpétuellement et rapidement sans stabilité.
Nous devons permettre aux clients à se connecter avec la clause "initiator-address".
Nous ajoutons une authentification avec l'option "incominguser".
Il nous reste à activer et lancer le service "tgtd.service":
systemctl enable tgtd.service systemctl start tgtd.service
On peut vérifier la configuration avec la commande:
tgtadm --mode target --op show
qui donne:
Target 1: iqn.2023-02.dom.home.sv1:sv1.target1
System information:
Driver: iscsi
State: ready
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: IET 00010000
SCSI SN: beaf10
Size: 0 MB, Block size: 1
Online: Yes
Removable media: No
Prevent removal: No
Readonly: No
SWP: No
Thin-provisioning: No
Backing store type: null
Backing store path: None
Backing store flags:
LUN: 1
Type: disk
SCSI ID: IET 00010001
SCSI SN: beaf11
Size: 1 MB, Block size: 512
Online: Yes
Removable media: No
Prevent removal: No
Readonly: No
SWP: No
Thin-provisioning: No
Backing store type: rdwr
Backing store path: /dev/sdb1
Backing store flags:
Account information:
diskuser
ACL information:
192.168.1.73
192.168.1.74
iqn.2023-02.dom.home.sv:sv.initiator01
iqn.2023-02.dom.home.sv:sv.initiator02
Target 2: iqn.2023-02.dom.home.sv1:sv1.target2
System information:
Driver: iscsi
State: ready
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: IET 00020000
SCSI SN: beaf20
Size: 0 MB, Block size: 1
Online: Yes
Removable media: No
Prevent removal: No
Readonly: No
SWP: No
Thin-provisioning: No
Backing store type: null
Backing store path: None
Backing store flags:
LUN: 1
Type: disk
SCSI ID: IET 00020001
SCSI SN: beaf21
Size: 160039 MB, Block size: 512
Online: Yes
Removable media: No
Prevent removal: No
Readonly: No
SWP: No
Thin-provisioning: No
Backing store type: rdwr
Backing store path: /dev/sdb2
Backing store flags:
Account information:
diskuser
ACL information:
192.168.1.73
192.168.1.74
iqn.2023-02.dom.home.sv:sv.initiator01
iqn.2023-02.dom.home.sv:sv.initiator02
ISCSI Initiator
Le Target étant actif, on passe à la partie Initiator sur les deux machines clients Initiator: "cl1.home.dom" et "cl2.home.dom".
Configuration de Iscsi
Les fichiers de configuration se retrouvent dans le répertoire "/etc/iscsi". Il contient deux fichiers: initiatorname.iscsi et iscsid.conf
- Dans le fichier "iscsid.conf", nous allons y apporter quelques modifications. Ces modifications sont a effectuer sur les deux machines clients Initiator.
Ces modifications permettent que la machine s'authentifie auprès des serveurs targets ISCSI. Il s'agit des deux paramètres de l'option "incominguser" activés sur les machines Targets: nom d'utilisateur et son mot de passe. On ajoute ou active ces lignes:
node.session.auth.authmethod = CHAP node.session.auth.username = diskuser node.session.auth.password = Eupen2marron
- Dans le fichier "initiatorname.iscsi", on remplace la ligne existante par le nom d'initiator défini sur le serveur target ISCSI.
Sur la première machine "cl1.home.dom", ce fichier contient le premier InitiatorName:
InitiatorName=iqn.2023-02.dom.home.sv:sv.initiator01
Sur la seconde machine "cl2.home.dom", ce fichier contient le second InitiatorName:
InitiatorName=iqn.2023-02.dom.home.sv:sv.initiator02
Découverte des Targets
Maintenant on va pouvoir ajouter les targets qui sont attribués aux clients ISCSI Initiator. Sur ces deux machines, on exécute la commande suivante:
iscsiadm -m discovery -t st -p 192.168.1.71
qui donne:
192.168.1.71:3260,1 iqn.2023-02.dom.home.sv1:sv1.target1 192.168.1.71:3260,1 iqn.2023-02.dom.home.sv1:sv1.target2
On peut vérifier la bonne exécution en constatant que des sous-répertoires et des fichiers de paramètres ont été créés dans les répertoires "/var/lib/iscsi/nodes" et "/var/lib/iscsi/send_targets".
Connexions
On active et relance le processus "iscsid" sur les deux machines clients ISCSI Initiator:
systemctl enable remote-fs.target systemctl enable iscsi.service systemctl restart iscsi.service
La commande:
lsblk
permet de constater que deux nouveaux devices disques sont apparus:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 149,1G 0 disk ├─sda1 8:1 0 600M 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 63,8G 0 part ├─fedora_cl1-root 253:0 0 15G 0 lvm / ├─fedora_cl1-swap 253:1 0 39,1G 0 lvm [SWAP] └─fedora_cl1-var 253:2 0 9,8G 0 lvm /var sdb 8:16 0 1M 0 disk sdc 8:32 0 149G 0 disk zram0 252:0 0 3,7G 0 disk [SWAP]
Partitionnement et formatage
A partir d'une des machines clients ISCSI Initiator, on crée une partition au device disque le plus gros de 149GB, "/dev/sdc" dans notre cas.
La partition "/dev/sdc1" est ajoutée:
lsblk
qui affiche:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 149,1G 0 disk ├─sda1 8:1 0 600M 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 63,8G 0 part ├─fedora_cl1-root 253:0 0 15G 0 lvm / ├─fedora_cl1-swap 253:1 0 39,1G 0 lvm [SWAP] └─fedora_cl1-var 253:2 0 9,8G 0 lvm /var sdb 8:16 0 1M 0 disk sdc 8:32 0 149G 0 disk └─sdc1 8:33 0 149G 0 part zram0 252:0 0 3,7G 0 disk [SWAP]
On peut la formater:
mkfs.xfs /dev/sdc1
qui donne:
meta-data=/dev/sdc1 isize=512 agcount=4, agsize=9767936 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=1 inobtcount=1 nrext64=0
data = bsize=4096 blocks=39071744, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=19078, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Sur l'autre machine client ISCSI Initiator, on relance le service concerné pour tenir compte de ces changements:
systemctl restart iscsi.service
Noms des devices
Dans les étapes suivantes, nous aurons besoin du nom de fichier de ces nouveaux devices:
- Pour le processus SBD nous avons besoin de celui ayant un espace de 1MB:
ls -al /dev/disk/by-path | grep sdb
qui donne:
lrwxrwxrwx 1 root root 9 18 mar 11:53 ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1 -> ../../sdb
- Pour le montage de l'espace de 149GB:
ls -al /dev/disk/by-uuid | grep sdc
qui donne:
lrwxrwxrwx 1 root root 10 18 mar 12:02 3d887218-4f2c-4f02-ba75-bea5f90e8031 -> ../../sdc1
Création du répertoire de montage
Pour pouvoir monter par la suite le disque ISCSI de 149GB, il faut un répertoire spécifique sur les deux machines clients ISCSI Initiator:
mkdir /datab
Watchdog
Le logiciel SBD a besoin de Watchdog. Watchdog est chargé d'arrêter ou de redémarrer la machine en cas de problème. C'est le logiciel SBD qui est chargé de le déclencher. Cette fonctionnalité doit être située sur les deux machines clients ISCSI Initiator: "cl1.home.dom" et "cl2.home.dom".
Module matériel
La majorité des machines sont équipées maintenant de ce genre de fonction. Pour les repérer, on va détecter le pilote associé chargé:
lsmod | grep wdt lsmod | grep softdog
qui donne sur une de mes deux machines: ---
iTCO_wdt 16384 0 intel_pmc_bxt 16384 1 iTCO_wdt iTCO_vendor_support 16384 1 iTCO_wdt mei_wdt 16384 0 mei 172032 3 mei_wdt,mei_me
On y remarque deux pilotes principaux.
S'il n'est pas seul, il faut en désactiver un, sinon aléatoirement un des deux sera chargé en premier lieu. Nous allons désactiver le module: "mei_wdt" car le module "iTCO_wdt" est plus connu et est présent sur l'autre machine. Pour y parvenir, on ajoute le fichier "/etc/modprobe.d/watchdog-blacklist.conf" qui contient:
blacklist mei_wdt install mei_wdt /bin/false
La première ligne l'empêche de se charger au démarrage et la seconde ne permet plus son chargement direct.
Pour le décharger soit on redémarre la machine, soit on exécute la commande suivante:
modprobe -r mei_wdt
Module logiciel
Si aucun module Watchdoc matériel n'est présent, on peut se retourner vers le Watchdog logiciel "watchdog". Mais dans ce cas, pour pouvoir exécuter sa tâche, le CPU doit être opérationnel. Il n'est pas à préférer.
Pour le charger, on crée le fichier "/etc/modules-load.d/watchdog.conf" qui contient la ligne:
softdog
Pour le charger soit on redémarre la machine, soit on exécute la commande suivante:
modprobe softdog
Devices
Maintenant qu'il en reste un seul, il nous faut détecter le device et vérifier son pilote.
On liste les devices:
ls -l /dev/watchdog*
qui donne:
crw------- 1 root root 10, 130 1 mar 12:18 /dev/watchdog crw------- 1 root root 246, 0 1 mar 12:18 /dev/watchdog0
Si on avait deux pilotes, on aurait:
crw------- 1 root root 10, 130 19 mar 16:23 /dev/watchdog crw------- 1 root root 246, 0 19 mar 16:23 /dev/watchdog0 crw------- 1 root root 246, 1 19 mar 16:23 /dev/watchdog1
Il y a deux moyens de savoir quel est le pilote qui se cache derrière.
- La commande suivante pour le device "/dev/watchdog0":
wdctl
qui donne:
Périphérique :/dev/watchdog0 Identité : iTCO_wdt [version 0] Expiration : 30 secondes Temps restant : 30 secondes Préexpiration : 0 seconde FLAG DESCRIPTION STATUS BOOT-STATUS KEEPALIVEPING Keep alive ping reply 1 0 MAGICCLOSE Supports magic close char 1 0 SETTIMEOUT Set timeout (in seconds) 0 0
ou on peut spécifier le device s'il est présent:
wdctl /dev/watchdog1
qui donne:
Périphérique :/dev/watchdog1 Identité : iamt_wdt [version 1] Expiration : 120 secondes Préexpiration : 0 seconde FLAG DESCRIPTION STATUS BOOT-STATUS KEEPALIVEPING Keep alive ping reply 1 0 SETTIMEOUT Set timeout (in seconds) 0 0 ALARMONLY Not trigger reboot 0 0
- Si le logiciel SBD est déjà installé:
dnf install sbd
on peut exécuter la commande:
sbd query-watchdog
qui donne:
Discovered 2 watchdog devices: [1] /dev/watchdog Identity: iTCO_wdt Driver: iTCO_wdt [2] /dev/watchdog0 Identity: iTCO_wdt Driver: iTCO_wdt
En pratique, nous choisirrons le device "/dev/watchdog0".
SBD
Le logiciel SBD est la couche qui sera utilisée sous Pacemaker pour gérer Watchdog.
Installation
On installe ce paquet sur les deux machines clients ISCSI Initiator:
dnf install sbd
Configuration
Le paramétrage de SBD se trouve dans le fichier "/dev/sysconfig/sbd".
Voici son contenu:
SBD_DEVICE=/dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1 SBD_PACEMAKER=yes SBD_STARTMODE=always SBD_DELAY_START=no SBD_WATCHDOG_DEV=/dev/watchdog0 SBD_WATCHDOG_TIMEOUT=5 SBD_TIMEOUT_ACTION=flush,off SBD_MOVE_TO_ROOT_CGROUP=auto SBD_SYNC_RESOURCE_STARTUP=yes SBD_OPTS=""
Explication de quelques paramètres:
- SBD_DEVICE : on y retrouve le nom de fichier du device ISCSI de 1MB défini un peu plus haut lors du paragraphe "ISCSI - Initiator". Attention: ce nom ne doit pas être mis entre doubles cotes (") comme rencontré sur divers sites. (Bug momentané???)
- SBD_WATCHDOG_DEV : on y retrouve le nom de fichier du device Watchdog choisi plus haut
- SBD_TIMEOUT_ACTION : le seconde paramètre "off" spécifie que la machine ayant des problèmes sera arrêtée. Si on y met à la place "reboot", elle sera redémarée.
- SBD_OPTS : est vide car les paramètres souvent rencontrés sont par défaut. Sur la machine "cl1.home.dom", on aurait pu mettre "-W -n cl1.home.dom". Si on avait deux interfaces réseau, il pouurait être utile de le spécifier.
Formatage
Le device ISCSI de 1MB doit être préparé, formaté. On le fait à partir d'une seule machine client ISCSI Initiator:
sbd -d "/dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1" create
qui affiche:
Initializing device /dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1 Creating version 2.1 header on device 3 (uuid: 5160e607-1842-4aa6-925b-e02879de27f8) Initializing 255 slots on device 3 Device /dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1 is initialized. Did you check sbd service down on all nodes before? If not do so now and restart afterwards.
On peut vérifier ensuite ce device:
sbd -d "/dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1" dump
qui affiche:
==Dumping header on disk /dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1 Header version : 2.1 UUID : 5160e607-1842-4aa6-925b-e02879de27f8 Number of slots : 255 Sector size : 512 Timeout (watchdog) : 5 Timeout (allocate) : 2 Timeout (loop) : 1 Timeout (msgwait) : 10 ==Header on disk /dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1 is dumped
Configuration de base de Pacemaker
La Configuration de base de Pacemaker doit être effectuée avec quelques modifications. Notre cluster comporte deux machines: "cl1.home.dom" et "cl2.home.dom"
Opérations locales
Sur chaque machine:
- le mot de passe de l'utilisateur "hacluster" est à implémenter. "Chasse4321Eau" pour mémoire.
- le service "pcsd.service" est à configurer et est lancé.
Initialisation du cluster
Pour initialiser le cluster, on effectue ces opérations sur une seule machine du cluster:
pcs host auth cl1.home.dom cl2.home.dom -u hacluster -p Chasse4321Eau pcs cluster setup fo_cluster \ cl1.home.dom addr=192.168.1.73 cl2.home.dom addr=192.168.1.74 \ transport knet ip_version=ipv4 link transport=udp mcastport=5420
Lancement du cluster
Pour lancer l'ensemble, on exécute les commandes suivantes à partir d'une seule machine:
pcs cluster enable --all pcs cluster start --all
Activation et lancement des services
Dès que la phase de configuration de base est effectuée et non avant, on active quatre services sur les deux machines du cluster:
systemctl enable pcsd.service systemctl enable corosync.service systemctl enable pacemaker.service
Le suivant est spécial; il concerne SBD:
systemctl enable sbd.service
qui crée trois liens spéciaux:
Created symlink /etc/systemd/system/corosync.service.requires/sbd.service → /usr/lib/systemd/system/sbd.service. Created symlink /etc/systemd/system/pacemaker.service.requires/sbd.service → /usr/lib/systemd/system/sbd.service. Created symlink /etc/systemd/system/dlm.service.requires/sbd.service → /usr/lib/systemd/system/sbd.service.
Ce dernier service ne peut se lancer directement; il se lance au travers des services "corosync.service" ou "pacemaker.service". Donc soit on relance les deux machines du cluster, soit on relance les services sur les deux machines du cluster:
systemctl restart corosync.service pacemaker.service
Vérification du fonctionnement de SBD
Dans la liste des processus, quatre lignes apparaissent liées à Sbd avec cette commande:
ps axf | grep sbd
qui donne:
1160 ? SL 0:00 sbd: inquisitor 1169 ? SL 0:00 \_ sbd: watcher: /dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1 1170 ? SL 0:00 \_ sbd: watcher: Pacemaker 1171 ? SL 0:00 \_ sbd: watcher: Cluster
On peut interroger SBD pour connaître la liste des machines concernées par le processus "sbd":
sbd -d "/dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1" list
qui donne:
0 cl1.home.dom clear 1 cl2.home.dom clear
On peut vérifier le bon fonctionnement de SBD en transmettant un message de test à une des deux machines où s'exécute le processus "sbd".
Ce message va se retrouver dans le fichier "/var/log/messages" de la machine cible.
Avec cette commande envoyée à partir de la machine "cl1.home.dom", on envoie un message de test à la machine "cl2.home.dom":
sbd -d /dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1 message cl2.home.dom test
qui donne:
Mar 20 11:34:28 cl2 sbd[1009]: /dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1: notice: servant_md: Received command test from cl1.home.dom on disk /dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1
Configuration de SBD fence sous Pacemaker
La seconde phase est d'ajouter une ressource liée à SBD et quelques options générales liées.
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 property set no-quorum-policy=ignore pcs property set stonith-enabled=true pcs property set stonith-timeout=60s #pcs property set stonith-action="reboot" pcs property set stonith-action="off" pcs property set stonith-watchdog-timeout=0 pcs stonith create ClusterSbd fence_sbd \ devices="/dev/disk/by-path/ip-192.168.1.71:3260-iscsi-iqn.2023-02.dom.home.sv1:sv1.target1-lun-1" pcmk_host_list="cl1.home.dom cl2.home.dom" \ op monitor interval=30s
Options
En début l'option "no-quorum-policy" ne tient pas compte du quorum car il est de "1" et en dessous, pour qu'il aie un impact, il n'y a plus de machine active dans le cluster.
Le premier bloc concerne principalement le processus Sbd ("stonith..."). Pour l'action, nous avons choisit l'arrêt de la machine du cluster qui a des problèmes.
Ressource Stonith
Le second bloc ajoute une ressource de type "Stonith" qui va interagir avec le processus Sbd.
Vérification
On peut vérifier l'arrêt de ou des machines du cluster en provoquant un problème réseau.
- Si on enlève le cable réseau d'une des machines du cluster, la machine concernée s'arrête.
- Si on enlève le cable réseau du serveur ISCSI Target ("sv1.home.dom"), les deux machines du cluster s'arrêtent.
Ces arrêts semblent tardifs; il faut attendre environ une minute comme spécifié dans un paramètre global.
Attention: Dès ce moment, si vous relancez, par exemple, le service "pacemaker.service", votre machine risque de s'arrêter car le processus Sbd est lancé et lié à Pacemaker.
Configuration finale de quelques ressources de Pacemaker
Pour faire bonne mesure, nous ajoutons quelques ressources qui peuvent être étendues à d'autres tels à des services Web et Mail.
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 ClusterIP ocf:heartbeat:IPaddr2 \ ip=192.168.1.75 nic=eth1 cidr_netmask=24 iflabel=ethcl1 lvs_support=true \ op monitor interval=30s pcs constraint colocation add ClusterSbd with ClusterIP score=INFINITY pcs constraint order ClusterSbd then start ClusterIP pcs resource create ClusterMailTo ocf:heartbeat:MailTo email=root subject="FailOver_Home" \ op monitor interval=30s pcs constraint colocation add ClusterMailTo with ClusterIP score=INFINITY pcs constraint order ClusterIP then start ClusterMailTo pcs resource create ClusterIscsi ocf:heartbeat:iscsi \ portal=192.168.1.71:3260 \ target=iqn.2023-02.dom.home.sv1:sv1.target2 \ op monitor interval=30s pcs constraint colocation add ClusterIscsi with ClusterMailTo score=INFINITY pcs constraint order ClusterMailTo then start ClusterIscsi pcs resource create ClusterFsDatab ocf:heartbeat:Filesystem \ device="/dev/disk/by-uuid/3d887218-4f2c-4f02-ba75-bea5f90e8031" \ directory="/datab" fstype="xfs" \ "options=defaults,_netdev" \ op monitor interval=20s on-fail=stop pcs constraint colocation add ClusterFsDatab with ClusterIscsi score=INFINITY pcs constraint order ClusterIscsi then start ClusterFsDatab
Ajout de la ressource de l'adresse IP virtuelle
En début vient la création de notre ressource "ClusterIP" en suivant la fonction déjà rencontrée "ocf:heartbeat:IPaddr2" que nous attribuons à la machine active "cl1.home.dom" ou "cl2.home.dom".
Ajout de la ressource de notification par mail
Vient ensuite la création de notre ressource "ClusterMailTo" traditionnelle que nous attribuons à la machine active "cl1.home.dom" ou "cl2.home.dom".
Ajout de la ressource Iscsi Initiator
Ici on utilise une fonction différente par rapport à des articles précédents. On ajoute la ressource "ClusterIscsid" qui utilise la fonction "ocf:heartbeat:iscsi". Elle demande deux paramètres:
- le nom du serveur ISCSI Target et le port associé à ce service
- le nom du target ciblé; il correspond à l'espace disque de 149GB.
Nous l'attribuons à la machine active "cl1.home.dom" ou "cl2.home.dom".
Ajout de la ressource disque ISCSI
Enfin viennent le bloc de création de la ressource "ClusterDatab" qui va monter l'espace disque ISCSI sur le répertoire "/datab". Elles utilisent la fonction "ocf:heartbeat:Filesystem" déjà rencontrée par le passé. On y retrouve les paramètres qui avaient été mis dans le fichier "/etc/fstab". Cette ressource ne sera localisée que sur la machine active "cl1.home.dom" ou "cl2.home.dom". Evidemment ces ressources ne peuvent être lancées qu'après la ressource "ClusterIscsid".
Colocation
Ces 5 dernières ressources se retrouvent ensemble.
Ordre
Les différentes ressources sont ordonnées pour leur lancement. Le principal est de démmarer la ressource "ClusterIscsid" avant la ressource "ClusterDatab".
Statut
Après cette opération, l'état du cluster peut être visualisé par la commande:
crm_mon -1
qui donne dans le cas des trois machines actives:
Status of pacemakerd: 'Pacemaker is running' (last updated 2023-03-18 12:35:52 +01:00) Cluster Summary: * Stack: corosync * Current DC: cl1.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition with quorum * Last updated: Sat Mar 18 12:35:53 2023 * Last change: Sat Mar 18 12:33:19 2023 by hacluster via crmd on cl1.home.dom * 2 nodes configured * 5 resource instances configured Node List: * Online: [ cl1.home.dom cl2.home.dom ] Active Resources: * ClusterSbd (stonith:fence_sbd): Started cl2.home.dom * ClusterIP (ocf::heartbeat:IPaddr2): Started cl2.home.dom * ClusterMailTo (ocf::heartbeat:MailTo): Started cl2.home.dom * ClusterIscsi (ocf::heartbeat:iscsi): Started cl2.home.dom * ClusterFsDatab (ocf::heartbeat:Filesystem): Started cl2.home.dom
Et au niveau de l'adresse IP virtuelle, la commande:
ifconfig
donne (partie):
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.74 netmask 255.255.255.0 broadcast 192.168.1.255
ether 00:1c:c0:30:2a:38 txqueuelen 1000 (Ethernet)
RX packets 16386 bytes 5410058 (5.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 15114 bytes 4212322 (4.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0x93100000-93120000
eth1:ethcl1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.75 netmask 255.255.255.0 broadcast 192.168.1.255
ether 00:1c:c0:30:2a:38 txqueuelen 1000 (Ethernet)
device interrupt 20 memory 0x93100000-93120000
On pourra vérifier également avec la commande:
lsblk
que sur la machine non active, ici "cl1.home.dom", les devices disques, liés à l'espace de 149 GB, ont été éliminés: "/dev/sdc" et "/dev/sdc1" mais l'autre ("/dev/sdb") utilisé par SBD subsiste.
→ retour au menu de la Haute disponibilité