LINUX:Pacemaker - ISCSI en Failover et SBD (fence)

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche

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.

LINUX:Iscsi2.pdf

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é