Partager via

Configurer Pacemaker sur SUSE Linux Enterprise Server dans Azure

  • Article

Cet article explique comment configurer Pacemaker sur SUSE Linux Enterprise Server (SLES) dans Azure.

Vue d’ensemble

Dans Azure, vous disposez de deux options pour configurer l’isolation au sein du cluster Pacemaker pour SLES. Vous pouvez utiliser un agent d’isolation Azure, qui redémarre un nœud défaillant via les API Azure, ou vous pouvez utiliser un appareil SBD.

Utilisation d’un appareil SBD

Vous pouvez configurer l’appareil SBD de deux manières :

  • Appareil SBD avec un serveur cible iSCSI :

    L’appareil SBD exige au moins une machine virtuelle supplémentaire qui agit en tant que serveur cible iSCSI (Internet Small Computer System Interface) et fournit un appareil SBD. Ces serveurs cibles iSCSI peuvent toutefois être partagés avec d’autres clusters Pacemaker. Le recours à un appareil SBD présente l’avantage que, si vous utilisez déjà des appareils SBD en local, ils ne vous obligent pas à revoir la façon dont vous exploitez le cluster Pacemaker.

    Vous pouvez utiliser jusqu’à trois appareils SBD pour un cluster Pacemaker de façon à autoriser l’indisponibilité d’un appareil SBD (par exemple lors de la mise à jour corrective du système d’exploitation du serveur cible iSCSI). Si vous souhaitez avoir recours à plusieurs appareils SBD par Pacemaker, veillez à déployer plusieurs serveurs cibles iSCSI et à connecter un appareil SBD à partir de chaque serveur cible iSCSI. Nous vous recommandons d’utiliser soit un appareil SBD, soit trois appareils SBD. Pacemaker ne peut pas isoler automatiquement un nœud de cluster si seulement deux appareils SBD sont configurés et que l’un d’eux n’est pas disponible. Si vous souhaitez pouvoir procéder à une isolation lorsqu’un serveur cible iSCSI est inactif, vous devez utiliser trois appareils SBD, et donc trois serveurs cibles iSCSI. Il s’agit de la configuration la plus résiliente avec des appareils SBD.

    Diagramme de vue d’ensemble de Pacemaker sur SLES.

    Important

    Quand vous planifiez et déployez des nœuds en cluster et des appareils SBD Linux de type Pacemaker, n’autorisez pas le routage entre vos machines virtuelles et celles qui hébergent les appareils SBD à traverser d’autres appareils, par exemple une appliance virtuelle réseau.

    Les événements de maintenance et d’autres problèmes liés à l’appliance virtuelle réseau peuvent avoir un impact négatif sur la stabilité et la fiabilité de la configuration générale du cluster. Pour plus d’informations, consultez Règles d’acheminement définies par l’utilisateur.

  • Appareil SBD avec un disque partagé Azure :

    Pour configurer l’appareil SBD, vous devez joindre au moins un disque partagé Azure à toutes les machines virtuelles qui font partie du cluster Pacemaker. L’avantage d’un appareil SBD utilisant un disque partagé Azure est que vous n’avez pas besoin de déployer de machines virtuelles supplémentaires.

    Diagramme de l’appareil SBD à disque partagé Azure pour le cluster Pacemaker sur SLES.

    Voici quelques considérations importantes concernant les appareils SBD utilisés avec un disque partagé Azure :

    • Un disque partagé Azure avec SSD Premium est pris en charge en tant qu’appareil SBD.
    • Les appareils SBD qui utilisent un disque partagé Azure sont pris en charge sur SLES High Availability 15 SP01 et les versions plus récentes.
    • Les appareils SBD qui utilisent un disque partagé Azure Premium sont pris en charge sur le stockage localement redondant (LRS, Locally Redundant Storage) et le stockage redondant interzone (ZRS, Zone-Redundant Storage).
    • Selon le type de votre déploiement, choisissez le stockage redondant approprié pour un disque partagé Azure comme appareil SBD.
    • Un appareil SBD utilisant le stockage LRS pour un disque partagé Azure Premium (skuName - Premium_LRS) n’est pris en charge qu’avec un déploiement dans un groupe à haute disponibilité.
    • Un appareil SBD utilisant le stockage ZRS pour un disque partagé Azure Premium (skuName - Premium_ZRS) est recommandé avec un déploiement dans des zones de disponibilité.
    • Le stockage ZRS pour le disque managé n’est actuellement pas disponible dans toutes les régions offrant des zones de disponibilité. Pour plus d’informations, consultez la section « Limitations » du stockage ZRS dans Options de redondance des disques managés.
    • Le disque partagé Azure utilisé pour les appareils SBD n’a pas besoin d’être de grande taille. La valeur maxShares détermine combien de nœuds de cluster peuvent utiliser le disque partagé. Par exemple, vous pouvez choisir les tailles de disque P1 et P2 pour votre appareil SBD sur un cluster à deux nœuds, par exemple un scale-up SAP ASCS/ERS ou SAP HANA.
    • Pour un scale-out HANA avec la réplication système HANA (HSR) et Pacemaker, vous pouvez utiliser un disque partagé Azure pour les appareils SBD dans des clusters contenant jusqu’à quatre nœuds par site de réplication en raison de la limite actuelle de maxShares.
    • Nous vous déconseillons d’attacher un appareil SBD de disque partagé Azure sur plusieurs clusters Pacemaker.
    • Si vous utilisez plusieurs appareils SBD de disque partagé Azure, vérifiez le nombre maximal de disques de données pouvant être attachés à la machine virtuelle.
    • Pour plus d’informations sur les limitations des disques partagés Azure, lisez attentivement la section « Limitations » de la documentation Disque partagé Azure.

Utilisation d’un agent d’isolation Azure

Vous pouvez configurer l’isolation à l’aide d’un agent d’isolation Azure. L’agent de clôture Azure nécessite des identités managées pour les machines virtuelles de cluster ou un principal de service qui gère le redémarrage des nœuds ayant échoué via des API Azure. L’agent de clôture Azure n’imposent pas le déploiement de machines virtuelles supplémentaires.

Appareil SBD avec un serveur cible iSCSI

Pour utiliser un appareil SBD qui a recours à un serveur cible iSCSI pour l’isolation, suivez les instructions des sections suivantes.

Configuration du serveur cible iSCSI

Vous devez tout d’abord créer les machines virtuelles cibles iSCSI. Vous pouvez partager les serveurs cibles iSCSI avec plusieurs clusters Pacemaker.

  1. Déployez de nouvelles machines virtuelles SLES 12 SP3 (ou une version plus récente) et connectez-vous-y via le protocole SSH. Les machines n’ont pas besoin d’être volumineuses. Les tailles de machines virtuelles Standard_E2s_v3 et Standard_D2s_v3 sont suffisantes. Veillez à utiliser le Stockage Premium pour le disque de système d’exploitation.

  2. Sur les machines virtuelles cibles iSCSI, exécutez les commandes suivantes :

    a. Mettez à jour SLES.

    sudo zypper update

    Notes

    Vous pouvez être amené à redémarrer le système d’exploitation après la mise à niveau ou la mise à jour de celui-ci.

    b. Supprimez des packages.

    Pour éviter un problème connu avec targetcli et SLES 12 SP3, désinstallez les packages suivants. Vous pouvez ignorer les erreurs concernant des packages introuvables.

    sudo zypper remove lio-utils python-rtslib python-configshell targetcli

    c. Installez les packages cibles iSCSI.

    sudo zypper install targetcli-fb dbus-1-python

    d. Activez le service cible iSCSI.

    sudo systemctl enable targetcli
sudo systemctl start targetcli

Création d’un appareil iSCSI sur le serveur cible iSCSI

Pour créer les disques iSCSI des clusters qui doivent être utilisés par vos systèmes SAP, exécutez les commandes suivantes sur toutes les machines virtuelles cibles iSCSI. Dans l’exemple, des appareils SBD sont créés pour plusieurs clusters. Il vous montre comment utiliser un serveur cible iSCSI pour plusieurs clusters. Les appareils SBD sont placés sur le disque de système d’exploitation. Assurez-vous d’avoir suffisamment d’espace.

  • nfs : identifie le cluster NFS.
  • ascsnw1 : identifie le cluster ASCS de NW1.
  • dbnw1 : identifie le cluster de base de données de NW1.
  • nfs-0 et nfs-1 : noms d’hôte des nœuds de cluster NFS.
  • nw1-xscs-0 et nw1-xscs-1 : noms d’hôte des nœuds de cluster ASCS NW1.
  • nw1-db-0 et nw1-db-1 : noms d’hôte des nœuds de cluster de base de données.

Dans les instructions suivantes, remplacez l’ajustement des noms d’hôte de vos nœuds de cluster et du SID de votre système SAP.

  1. Créez le dossier racine de tous les appareils SBD.

    sudo mkdir /sbd

  2. Créez l’appareil SBD du serveur NFS.

    sudo targetcli backstores/fileio create sbdnfs /sbd/sbdnfs 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.nfs.local:nfs
sudo targetcli iscsi/iqn.2006-04.nfs.local:nfs/tpg1/luns/ create /backstores/fileio/sbdnfs
sudo targetcli iscsi/iqn.2006-04.nfs.local:nfs/tpg1/acls/ create iqn.2006-04.nfs-0.local:nfs-0
sudo targetcli iscsi/iqn.2006-04.nfs.local:nfs/tpg1/acls/ create iqn.2006-04.nfs-1.local:nfs-1

  3. Créez l’appareil SBD du serveur ASCS de NW1 du système SAP.

    sudo targetcli backstores/fileio create sbdascsnw1 /sbd/sbdascsnw1 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.ascsnw1.local:ascsnw1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/luns/ create /backstores/fileio/sbdascsnw1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.nw1-xscs-0.local:nw1-xscs-0
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.nw1-xscs-1.local:nw1-xscs-1

  4. Créez l’appareil SBD du cluster de base de données de NW1 du système SAP.

    sudo targetcli backstores/fileio create sbddbnw1 /sbd/sbddbnw1 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.dbnw1.local:dbnw1
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/luns/ create /backstores/fileio/sbddbnw1
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/acls/ create iqn.2006-04.nw1-db-0.local:nw1-db-0
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/acls/ create iqn.2006-04.nw1-db-1.local:nw1-db-1

  5. Enregistrez les modifications apportées à targetcli.

    sudo targetcli saveconfig

  6. Vérifiez que tout a été correctement configuré.

    sudo targetcli ls

o- / .......................................................................................................... [...]
o- backstores ............................................................................................... [...]
| o- block ................................................................................... [Storage Objects: 0]
| o- fileio .................................................................................. [Storage Objects: 3]
| | o- sbdascsnw1 ................................................ [/sbd/sbdascsnw1 (50.0MiB) write-thru activated]
| | | o- alua .................................................................................... [ALUA Groups: 1]
| | |   o- default_tg_pt_gp ........................................................ [ALUA state: Active/optimized]
| | o- sbddbnw1 .................................................... [/sbd/sbddbnw1 (50.0MiB) write-thru activated]
| | | o- alua .................................................................................... [ALUA Groups: 1]
| | |   o- default_tg_pt_gp ........................................................ [ALUA state: Active/optimized]
| | o- sbdnfs ........................................................ [/sbd/sbdnfs (50.0MiB) write-thru activated]
| |   o- alua .................................................................................... [ALUA Groups: 1]
| |     o- default_tg_pt_gp ........................................................ [ALUA state: Active/optimized]
| o- pscsi ................................................................................... [Storage Objects: 0]
| o- ramdisk ................................................................................. [Storage Objects: 0]
o- iscsi ............................................................................................. [Targets: 3]
| o- iqn.2006-04.ascsnw1.local:ascsnw1 .................................................................. [TPGs: 1]
| | o- tpg1 ................................................................................ [no-gen-acls, no-auth]
| |   o- acls ........................................................................................... [ACLs: 2]
| |   | o- iqn.2006-04.nw1-xscs-0.local:nw1-xscs-0 ............................................... [Mapped LUNs: 1]
| |   | | o- mapped_lun0 ............................................................ [lun0 fileio/sbdascsnw1 (rw)]
| |   | o- iqn.2006-04.nw1-xscs-1.local:nw1-xscs-1 ............................................... [Mapped LUNs: 1]
| |   |   o- mapped_lun0 ............................................................ [lun0 fileio/sbdascsnw1 (rw)]
| |   o- luns ........................................................................................... [LUNs: 1]
| |   | o- lun0 .......................................... [fileio/sbdascsnw1 (/sbd/sbdascsnw1) (default_tg_pt_gp)]
| |   o- portals ..................................................................................... [Portals: 1]
| |     o- 0.0.0.0:3260 ...................................................................................... [OK]
| o- iqn.2006-04.dbnw1.local:dbnw1 ...................................................................... [TPGs: 1]
| | o- tpg1 ................................................................................ [no-gen-acls, no-auth]
| |   o- acls ........................................................................................... [ACLs: 2]
| |   | o- iqn.2006-04.nw1-db-0.local:nw1-db-0 ................................................... [Mapped LUNs: 1]
| |   | | o- mapped_lun0 .............................................................. [lun0 fileio/sbddbnw1 (rw)]
| |   | o- iqn.2006-04.nw1-db-1.local:nw1-db-1 ................................................... [Mapped LUNs: 1]
| |   |   o- mapped_lun0 .............................................................. [lun0 fileio/sbddbnw1 (rw)]
| |   o- luns ........................................................................................... [LUNs: 1]
| |   | o- lun0 .............................................. [fileio/sbddbnw1 (/sbd/sbddbnw1) (default_tg_pt_gp)]
| |   o- portals ..................................................................................... [Portals: 1]
| |     o- 0.0.0.0:3260 ...................................................................................... [OK]
| o- iqn.2006-04.nfs.local:nfs .......................................................................... [TPGs: 1]
|   o- tpg1 ................................................................................ [no-gen-acls, no-auth]
|     o- acls ........................................................................................... [ACLs: 2]
|     | o- iqn.2006-04.nfs-0.local:nfs-0 ......................................................... [Mapped LUNs: 1]
|     | | o- mapped_lun0 ................................................................ [lun0 fileio/sbdnfs (rw)]
|     | o- iqn.2006-04.nfs-1.local:nfs-1 ......................................................... [Mapped LUNs: 1]
|     |   o- mapped_lun0 ................................................................ [lun0 fileio/sbdnfs (rw)]
|     o- luns ........................................................................................... [LUNs: 1]
|     | o- lun0 .................................................. [fileio/sbdnfs (/sbd/sbdnfs) (default_tg_pt_gp)]
|     o- portals ..................................................................................... [Portals: 1]
|       o- 0.0.0.0:3260 ...................................................................................... [OK]
o- loopback .......................................................................................... [Targets: 0]
o- vhost ............................................................................................. [Targets: 0]
o- xen-pvscsi ........................................................................................ [Targets: 0]

Configuration de l’appareil SBD du serveur cible iSCSI

Connectez-vous à l’appareil iSCSI créé à l’étape précédente à partir du cluster. Exécutez les commandes suivantes sur les nœuds du nouveau cluster que vous souhaitez créer.

Notes

  • [A] : s’applique à tous les nœuds.
  • [1] : s’applique uniquement au nœud 1.
  • [2] : s’applique uniquement au nœud 2.

  1. [A] Installez le package iSCSI.

    sudo zypper install open-iscsi

  2. [A] Connectez-vous aux appareils iSCSI. Tout d’abord, activez les services iSCSI et SBD.

    sudo systemctl enable iscsid
sudo systemctl enable iscsi
sudo systemctl enable sbd

  3. [1] Modifiez le nom de l’initiateur sur le premier nœud.

    sudo vi /etc/iscsi/initiatorname.iscsi

  4. [1] Modifiez le contenu du fichier pour qu’il corresponde aux listes de contrôle d’accès (ACL, Access Control List) utilisées lors de la création de l’appareil iSCSI sur le serveur cible iSCSI (par exemple pour le serveur NFS).

    InitiatorName=iqn.2006-04.nfs-0.local:nfs-0

  5. [2] Modifiez le nom de l’initiateur sur le deuxième nœud.

    sudo vi /etc/iscsi/initiatorname.iscsi

  6. [2] Modifiez le contenu du fichier pour qu’il corresponde aux listes ACL utilisées lors de la création de l’appareil iSCSI sur le serveur cible iSCSI.

    InitiatorName=iqn.2006-04.nfs-1.local:nfs-1

  7. [A] Redémarrez le service iSCSI pour appliquer la modification.

    sudo systemctl restart iscsid
sudo systemctl restart iscsi

  8. [A] Connectez les appareils iSCSI. Dans l’exemple suivant, 10.0.0.17 est l’adresse IP du serveur cible iSCSI, et 3260 le port par défaut. iqn.2006-04.nfs.local:nfs est un des noms cibles indiqués lorsque vous exécutez la première commande, iscsiadm -m discovery.

    sudo iscsiadm -m discovery --type=st --portal=10.0.0.17:3260   
sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.17:3260
sudo iscsiadm -m node -p 10.0.0.17:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

  9. [A] Si vous souhaitez utiliser plusieurs appareils SBD, connectez-vous également au deuxième serveur cible iSCSI.

    sudo iscsiadm -m discovery --type=st --portal=10.0.0.18:3260   
sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.18:3260
sudo iscsiadm -m node -p 10.0.0.18:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

  10. [A] Si vous souhaitez utiliser plusieurs appareils SBD, connectez-vous également au troisième serveur cible iSCSI.

    sudo iscsiadm -m discovery --type=st --portal=10.0.0.19:3260   
sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.19:3260
sudo iscsiadm -m node -p 10.0.0.19:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

  11. [A] Vérifiez que les appareils iSCSI sont disponibles et notez leur nom (/dev/sde dans l’exemple suivant).

    lsscsi

# [2:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
# [3:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
# [5:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc
# [5:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdd
# [6:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdd
# [7:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sde
# [8:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdf

  12. [A] Récupérez l’ID des appareils iSCSI.

    ls -l /dev/disk/by-id/scsi-* | grep sdd

# lrwxrwxrwx 1 root root  9 Aug  9 13:20 /dev/disk/by-id/scsi-1LIO-ORG_sbdnfs:afb0ba8d-3a3c-413b-8cc2-cca03e63ef42 -> ../../sdd
# lrwxrwxrwx 1 root root  9 Aug  9 13:20 /dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03 -> ../../sdd
# lrwxrwxrwx 1 root root  9 Aug  9 13:20 /dev/disk/by-id/scsi-SLIO-ORG_sbdnfs_afb0ba8d-3a3c-413b-8cc2-cca03e63ef42 -> ../../sdd

ls -l /dev/disk/by-id/scsi-* | grep sde

# lrwxrwxrwx 1 root root  9 Feb  7 12:39 /dev/disk/by-id/scsi-1LIO-ORG_cl1:3fe4da37-1a5a-4bb6-9a41-9a4df57770e4 -> ../../sde
# lrwxrwxrwx 1 root root  9 Feb  7 12:39 /dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df -> ../../sde
# lrwxrwxrwx 1 root root  9 Feb  7 12:39 /dev/disk/by-id/scsi-SLIO-ORG_cl1_3fe4da37-1a5a-4bb6-9a41-9a4df57770e4 -> ../../sde

ls -l /dev/disk/by-id/scsi-* | grep sdf

# lrwxrwxrwx 1 root root  9 Aug  9 13:32 /dev/disk/by-id/scsi-1LIO-ORG_sbdnfs:f88f30e7-c968-4678-bc87-fe7bfcbdb625 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Aug  9 13:32 /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf -> ../../sdf
# lrwxrwxrwx 1 root root  9 Aug  9 13:32 /dev/disk/by-id/scsi-SLIO-ORG_sbdnfs_f88f30e7-c968-4678-bc87-fe7bfcbdb625 -> ../../sdf

    La commande fait apparaître trois ID par appareil SBD. Nous vous recommandons d’utiliser celui qui commence par scsi-3. Dans l’exemple précédent, les ID sont les suivants :

    • /dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03
    • /dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df
    • /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf

  13. [1] Créez l’appareil SBD.

    a. Utilisez l’ID d’appareil des appareils iSCSI pour créer de nouveaux appareils SBD sur le premier nœud de cluster.

    sudo sbd -d /dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03 -1 60 -4 120 create

    b. Créez également le deuxième et le troisième appareil SBD si vous souhaitez en utiliser plusieurs.

    sudo sbd -d /dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df -1 60 -4 120 create
sudo sbd -d /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf -1 60 -4 120 create

  14. [A] Adaptez la configuration SBD.

    a. Ouvrez le fichier de configuration SBD.

    sudo vi /etc/sysconfig/sbd

    b. Modifiez la propriété de l’appareil SBD, activez l’intégration de Pacemaker et modifiez le mode de démarrage de l’appareil SBD.

    [...]
SBD_DEVICE="/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]

    Remarque

    Si la valeur de propriété SBD_DELAY_START est définie sur « non », remplacez la valeur par « oui. » Vous devez également vérifier le fichier de service SBD pour vous assurer que la valeur de TimeoutStartSec est supérieure à la valeur de SBD_DELAY_START. Pour plus d’informations, consultez configuration du fichier SBD

  15. [A] Créez le fichier de configuration softdog.

    echo softdog | sudo tee /etc/modules-load.d/softdog.conf

  16. [A] Chargez le module.

    sudo modprobe -v softdog

Appareil SBD avec un disque partagé Azure

Cette section s’applique uniquement si vous souhaitez utiliser un appareil SBD avec un disque partagé Azure.

Création et attachement d’un disque partagé Azure avec PowerShell

  1. Ajustez les valeurs de votre groupe de ressources, de votre région Azure, de vos machines virtuelles, de vos numéros d’unité logique, etc.

    $ResourceGroup = "MyResourceGroup"
$Location = "MyAzureRegion"

  2. Définissez la taille du disque en fonction de la taille de disque disponible pour les disques SSD Premium. Dans cet exemple est indiquée la taille de disque P1 de 4 Go.

    $DiskSizeInGB = 4
$DiskName = "SBD-disk1"

  3. Avec le paramètre -MaxSharesCount, définissez le nombre maximal de nœuds de cluster pour attacher le disque partagé concernant l’appareil SBD.

    $ShareNodes = 2

  4. Dans le cas d’un appareil SBD qui utilise le stockage LRS pour un disque partagé Azure Premium, utilisez le SkuName de stockage suivant :

    $SkuName = "Premium_LRS"

  5. Dans le cas d’un appareil SBD qui utilise le stockage ZRS pour un disque partagé Azure Premium, utilisez le SkuName de stockage suivant :

    $SkuName = "Premium_ZRS"

  6. Configurez un disque partagé Azure.

    $diskConfig = New-AzDiskConfig -Location $Location -SkuName $SkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$dataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $diskConfig

  7. Attachez le disque aux machines virtuelles du cluster.

    $VM1 = "prod-cl1-0"
$VM2 = "prod-cl1-1"

    a. Ajoutez le disque partagé Azure au nœud de cluster 1.

    $vm = Get-AzVM -ResourceGroupName $ResourceGroup -Name $VM1
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroup -Verbose

    b. Ajoutez le disque partagé Azure au nœud de cluster 2.

    $vm = Get-AzVM -ResourceGroupName $ResourceGroup -Name $VM2
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroup -Verbose

Si vous souhaitez déployer des ressources avec Azure CLI ou le Portail Azure, vous pouvez également consulter Déploiement d’un disque ZRS.

Configuration de l’appareil SBD du disque partagé Azure

  1. [A] Activez les services SBD.

    sudo systemctl enable sbd

  2. [A] Vérifiez que le disque attaché est disponible.

    # lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0      2:0    1    4K  0 disk
sda      8:0    0   30G  0 disk
├─sda1   8:1    0    2M  0 part
├─sda2   8:2    0  512M  0 part /boot/efi
├─sda3   8:3    0    1G  0 part /boot
├─sda4   8:4    0 28.5G  0 part /
sdb      8:16   0  256G  0 disk
├─sdb1   8:17   0  256G  0 part /mnt
sdc      8:32   0    4G  0 disk
sr0     11:0    1 1024M  0 rom

# lsscsi
[1:0:0:0]    cd/dvd  Msft     Virtual CD/ROM   1.0   /dev/sr0
[2:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[3:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[5:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc

  3. [A] Récupérez les ID des disques attachés.

    # ls -l /dev/disk/by-id/scsi-* | grep sdc
lrwxrwxrwx 1 root root  9 Nov  8 16:55 /dev/disk/by-id/scsi-14d534654202020204208a67da80744439b513b2a9728af19 -> ../../sdc
lrwxrwxrwx 1 root root  9 Nov  8 16:55 /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19 -> ../../sdc

    Les commandes indiquent les ID de l’appareil SBD. Nous vous recommandons d’utiliser celui qui commence par scsi-3. Dans l’exemple précédent, l’ID est /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19.

  4. [1] Créez l’appareil SBD.

    Utilisez l’ID d’appareil de l’étape 2 pour créer les nouveaux appareils SBD sur le premier nœud de cluster.

    # sudo sbd -d /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19 -1 60 -4 120 create

  5. [A] Adaptez la configuration SBD.

    a. Ouvrez le fichier de configuration SBD.

    sudo vi /etc/sysconfig/sbd

    b. Modifiez la propriété de l’appareil SBD, activez l’intégration de Pacemaker et modifiez le mode de démarrage de l’appareil SBD.

    [...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]

    Remarque

    Si la valeur de propriété SBD_DELAY_START est définie sur « non », remplacez la valeur par « oui. » Vous devez également vérifier le fichier de service SBD pour vous assurer que la valeur de TimeoutStartSec est supérieure à la valeur de SBD_DELAY_START. Pour plus d’informations, consultez configuration du fichier SBD

  6. Créez le fichier de configuration softdog.

    echo softdog | sudo tee /etc/modules-load.d/softdog.conf

  7. Chargez le module.

    sudo modprobe -v softdog

Utilisation d’un agent d’isolation Azure

Cette section s’applique uniquement si vous souhaitez utiliser un appareil d’isolation avec un agent d’isolation Azure.

Créer un appareil d’agent d’isolation Azure

Cette section s’applique uniquement si vous utilisez un appareil d’isolation basé sur un agent d’isolation Azure. L’appareil d’isolation utilise une identité managée ou un principal de service à autoriser sur Microsoft Azure.

Pour créer une identité managée (MSI), créez une identité managée affectée par le système pour chaque machine virtuelle du cluster. Si une identité managée affectée par le système existe déjà, elle sera utilisée. Les identités managées attribuées par l’utilisateur ne doivent pas être utilisées avec Pacemaker pour l’instant. L’agent de clôture Azure, basé sur l’identité managée, est pris en charge pour SLES 12 SP5 et SLES 15 SP1 et versions ultérieures.

[1] Créer un rôle personnalisé pour l’agent d’isolation

Par défaut, ni l’identité managée ni le principal de service ne disposent des autorisations nécessaires pour accéder à vos ressources Azure. Vous devez accorder à l’identité managée ou au principal de service les autorisations pour démarrer et arrêter (libérer) toutes les machines virtuelles du cluster. Si vous n’avez pas encore créé le rôle personnalisé, utilisez pour cela PowerShell ou Azure CLI.

Utilisez le contenu suivant pour le fichier d’entrée. Vous devez adapter le contenu à vos abonnements, Autrement dit, remplacez xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx et yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy par vos propres ID d’abonnement. Si vous ne possédez qu’un seul abonnement, supprimez la deuxième entrée sous AssignableScopes.

{
      "Name": "Linux fence agent Role",
      "description": "Allows to power-off and start virtual machines",
      "assignableScopes": [
              "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
              "/subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
      ],
      "actions": [
              "Microsoft.Compute/*/read",
              "Microsoft.Compute/virtualMachines/powerOff/action",
              "Microsoft.Compute/virtualMachines/start/action"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
}

[A] Attribuer le rôle personnalisé

Utilisez une identité managée ou un principal de service.

Attribuez le rôle personnalisé « Rôle d’agent de clôture Linux » créé dans le dernier chapitre à chaque identité managée des machines virtuelles du cluster. Chaque identité managée affectée par le système de machine virtuelle a besoin du rôle attribué pour la ressource de chaque machine virtuelle du cluster. Pour connaître les étapes en détail, consultez Attribuer à une identité managée un accès à une ressource à l’aide du Portail Azure. Vérifiez que l’attribution de rôle d’identité managée de chaque machine virtuelle contient toutes les machines virtuelles du cluster.

Important

L’attribution et la suppression de l’autorisation avec des identités managées peuvent être retardées jusqu’à leur entrée en vigueur.

Installation du cluster

Notes

  • [A] : s’applique à tous les nœuds.
  • [1] : s’applique uniquement au nœud 1.
  • [2] : s’applique uniquement au nœud 2.

  1. [A] Mettez à jour SLES.

    sudo zypper update

    Remarque

    Sur SLES 15 SP4, vérifiez la version du package crmsh et pacemaker et assurez-vous que les exigences minimales de version sont remplies :

    • crmsh-4.4.0+20221028.3e41444-150400.3.9.1 ou version ultérieure
    • pacemaker-2.1.2+20211124.ada5c3b36-150400.4.6.1 ou version ultérieure

  2. [A] Installez le composant dont vous avez besoin pour les ressources du cluster.

    sudo zypper in socat

  3. [A] Installez le composant azure-lb dont vous avez besoin pour les ressources de cluster.

    sudo zypper in resource-agents

    Remarque

    Vérifiez que la version du package resource-agents respecte la version minimale requise :

    • SLES 12 SP4/SP5 : la version doit être resource-agents-4.3.018.a7fb5035-3.30.1 ou une version plus récente.
    • SLES 15/15 SP1 : la version doit être resource-agents-4.3.0184.6ee15eb2-4.13.1 ou une version plus récente.

  4. [A] Configurez le système d’exploitation.

    a. Pacemaker crée parfois de nombreux processus, ce qui risque d’épuiser le nombre autorisé. Dans ce cas de figure, une pulsation entre les nœuds de cluster peut échouer et entraîner un basculement de vos ressources. Nous vous recommandons d’augmenter le nombre maximal autorisé de processus en définissant le paramètre suivant :

    # Edit the configuration file
sudo vi /etc/systemd/system.conf

# Change the DefaultTasksMax
#DefaultTasksMax=512
DefaultTasksMax=4096

# Activate this setting
sudo systemctl daemon-reload

# Test to ensure that the change was successful
sudo systemctl --no-pager show | grep DefaultTasksMax

    b. Réduisez la taille du cache d’intégrité. Pour plus d’informations, consultez Faibles performances en écriture sur les serveurs SLES 11/12 avec une grande quantité de RAM.

    sudo vi /etc/sysctl.conf
# Change/set the following settings
vm.dirty_bytes = 629145600
vm.dirty_background_bytes = 314572800

    c. Assurez-vous que vm.swappiness a la valeur 10 pour réduire l’utilisation de l’échange et favoriser la mémoire.

    sudo vi /etc/sysctl.conf
# Change/set the following setting
vm.swappiness = 10

  5. [A] Vérifiez la version du package cloud-netconfig-azure.

    Vérifiez la version installée du package cloud-netconfig-azure en exécutant zypper info cloud-netconfig-azure. Si la version est plus ancienne, nous vous recommandons de mettre à jour le package cloud-netconfig-azure avec la dernière version disponible.

    Conseil

    Si la version dans votre environnement est 1.3 ou une version plus récente, il n’est plus nécessaire de bloquer la gestion des interfaces réseau par le plug-in réseau cloud.

    Si la version de cloud-netconfig-azure est inférieure à la version 1.3, modifiez le fichier de configuration de l’interface réseau comme indiqué dans le code suivant pour empêcher le plug-in réseau cloud de supprimer l’adresse IP virtuelle (Pacemaker doit contrôler l’affectation). Pour plus d’informations, consultez SUSE KB 7023633.

    # Edit the configuration file
sudo vi /etc/sysconfig/network/ifcfg-eth0 

# Change CLOUD_NETCONFIG_MANAGE
# CLOUD_NETCONFIG_MANAGE="yes"
CLOUD_NETCONFIG_MANAGE="no"

  6. [1] Activez l’accès SSH.

    sudo ssh-keygen

# Enter file in which to save the key (/root/.ssh/id_rsa), and then select Enter
# Enter passphrase (empty for no passphrase), and then select Enter
# Enter same passphrase again, and then select Enter

# copy the public key
sudo cat /root/.ssh/id_rsa.pub

  7. [2] Activez l’accès SSH.

    sudo ssh-keygen

# Enter file in which to save the key (/root/.ssh/id_rsa), and then select Enter
# Enter passphrase (empty for no passphrase), and then select Enter
# Enter same passphrase again, and then select Enter

# Insert the public key you copied in the last step into the authorized keys file on the second server
sudo vi /root/.ssh/authorized_keys   

# copy the public key
sudo cat /root/.ssh/id_rsa.pub

  8. [1] Activez l’accès SSH.

    # insert the public key you copied in the last step into the authorized keys file on the first server
sudo vi /root/.ssh/authorized_keys

  9. [A] Installez le package fence-agents si vous utilisez un appareil d’isolation basé sur l’agent d’isolation Azure.

    sudo zypper install fence-agents

    Important

    Vous devez installer la version 4.4.0 ou une version plus récente du package fence-agents pour pouvoir tirer parti des délais de basculement plus rapides avec l’agent d’isolation Azure lorsqu’un nœud de cluster est isolé. Si vous utilisez une version plus ancienne, nous vous recommandons de mettre à jour le package.

    Important

    Si vous utilisez une identité managée, la version installée du package agents de clôture doit être :

    • SLES 12 SP5: fence-agents 4.9.0+git.1624456340.8d746be9-3.35.2 ou version ultérieure
    • SLES 15 SP1 et versions ultérieures : fence-agents 4.5.2+git.1592573838.1eee0863 ou version ultérieure.

    Les versions antérieures ne fonctionnent pas correctement avec une configuration d’identités managées.

  10. [A] Installez le SDK Azure Python et le module Python Azure Identity.

    Installez le kit de développement logiciel (SDK) Azure Python sur SLES 12 SP4 ou SLES 12 SP5 :

    # You might need to activate the public cloud extension first
SUSEConnect -p sle-module-public-cloud/12/x86_64
sudo zypper install python-azure-mgmt-compute
sudo zypper install python-azure-identity

    Installez le kit SDK Azure Python sur la version 15 ou une version plus récente de SLES :

    # You might need to activate the public cloud extension first. In this example, the SUSEConnect command is for SLES 15 SP1
SUSEConnect -p sle-module-public-cloud/15.1/x86_64
sudo zypper install python3-azure-mgmt-compute
sudo zypper install python3-azure-identity

    Important

    Selon la version et le type d’image, vous devrez peut-être activer l’extension cloud public correspondant à la version de votre système d’exploitation pour pouvoir installer le kit SDK Azure Python. Pour vérifier l’extension, exécutez SUSEConnect ---list-extensions. Pour obtenir des délais de basculement plus rapides avec l’agent d’isolation Azure, procédez comme suit :

    • Sur SLES 12 SP4 ou SLES 12 SP5, installez la version 4.6.2 ou une version plus récente du package python-azure-mgmt-compute.
    • Si la version de votre package python-azure-mgmt-compute ou python3-azure-mgmt-compute est 17.0.0-6.7.1, suivez les instructions indiquées dans l’article de base de connaissances SUSE pour mettre à jour la version de fence-agents et installer la bibliothèque de client d’identité Azure pour le module Python si elle est absente.

  11. [A] Configurez la résolution du nom d’hôte.

    Vous pouvez utiliser un serveur DNS ou modifier le fichier /etc/hosts sur tous les nœuds. Cet exemple montre comment utiliser le fichier /etc/hosts.

    Remplacez l’adresse IP et le nom d’hôte dans les commandes suivantes.

    Important

    Si vous utilisez des noms d’hôte dans la configuration du cluster, il est essentiel que vous disposiez d’une résolution fiable du nom d’hôte. Les communications de cluster échouent si les noms ne sont pas disponibles, ce qui risque d’entraîner des retards de basculement de cluster.

    Le recours au fichier /etc/hosts présente l’avantage que votre cluster devient indépendant du serveur DNS, qui peut aussi constituer un point de défaillance unique.

    sudo vi /etc/hosts

    Insérez les lignes suivantes dans le fichier /etc/hosts. Changez l’adresse IP et le nom d’hôte en fonction de votre environnement.

    # IP address of the first cluster node
10.0.0.6 prod-cl1-0
# IP address of the second cluster node
10.0.0.7 prod-cl1-1

  12. [1] Installez le cluster.

    • Si vous utilisez des appareils SBD pour l’isolation (pour le serveur cible iSCSI ou le disque partagé Azure) :

      sudo crm cluster init
# ! NTP is not configured to start at system boot.
# Do you want to continue anyway (y/n)? y
# /root/.ssh/id_rsa already exists - overwrite (y/n)? n
# Address for ring0 [10.0.0.6] Select Enter
# Port for ring0 [5405] Select Enter
# SBD is already configured to use /dev/disk/by-id/scsi-36001405639245768818458b930abdf69;/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf - overwrite (y/n)? n
# Do you wish to configure an administration IP (y/n)? n

    • Si vous n’utilisez pas d’appareils SBD pour l’isolation :

      sudo crm cluster init
# ! NTP is not configured to start at system boot.
# Do you want to continue anyway (y/n)? y
# /root/.ssh/id_rsa already exists - overwrite (y/n)? n
# Address for ring0 [10.0.0.6] Select Enter
# Port for ring0 [5405] Select Enter
# Do you wish to use SBD (y/n)? n
# WARNING: Not configuring SBD - STONITH will be disabled.
# Do you wish to configure an administration IP (y/n)? n

  13. [2] Joignez le nœud au cluster.

    sudo crm cluster join
# ! NTP is not configured to start at system boot.
# Do you want to continue anyway (y/n)? y
# IP address or hostname of existing node (for example, 192.168.1.1) []10.0.0.6
# /root/.ssh/id_rsa already exists - overwrite (y/n)? n

  14. [A] Changez le mot de passe hacluster pour utiliser le même mot de passe.

    sudo passwd hacluster

  15. [A] Ajustez les paramètres corosync.

    sudo vi /etc/corosync/corosync.conf

    a. Vérifiez la section suivante dans le fichier et faites des ajustements si les valeurs ne sont pas là ou sont différentes. Veillez à remplacer la valeur du jeton par 30000 pour autoriser la maintenance avec préservation de la mémoire. Pour plus d’informations, consultez l’article Maintenance des machines virtuelles dans Azure pour Linux ou Windows.

    [...]
  token:          30000
  token_retransmits_before_loss_const: 10
  join:           60
  consensus:      36000
  max_messages:   20

  interface { 
     [...] 
  }
  transport:      udpu
} 
nodelist {
  node {
   ring0_addr:10.0.0.6
  }
  node {
   ring0_addr:10.0.0.7
  } 
}
logging {
  [...]
}
quorum {
     # Enable and configure quorum subsystem (default: off)
     # See also corosync.conf.5 and votequorum.5
     provider: corosync_votequorum
     expected_votes: 2
     two_node: 1
}

    b. Redémarrez le service corosync.

    sudo service corosync restart

Créer un appareil d’isolation sur le cluster Pacemaker

Conseil

  • Pour éviter les courses de clôture au sein d’un cluster pacemaker à deux nœuds, vous pouvez configurer une propriété de cluster « priority-fencing-delay » supplémentaire. Cette propriété introduit un délai supplémentaire dans un délimiteur de nœud qui a une priorité de ressource totale supérieure lorsqu’un scénario split-brain se produit. Pour plus d’informations, consultez le guide d’administration de l’extension haute disponibilité SUSE Linux Enterprise Server.
  • L’instruction sur la définition de la propriété de cluster « priority-fencing-delay » est disponible dans le document SAP ASCS/ERS/ERS (applicable uniquement sur ENSA2) et le document de haute disponibilité SAP HANA.

  1. [1] Si vous utilisez un appareil SBD (serveur cible iSCSI ou disque partagé Azure) en tant qu’appareil d’isolation, exécutez les commandes suivantes. Activez l’utilisation d’un appareil d’isolation, et définissez le délai d’isolation.

    sudo crm configure property stonith-timeout=144
sudo crm configure property stonith-enabled=true

# List the resources to find the name of the SBD device
sudo crm resource list
sudo crm resource stop stonith-sbd
sudo crm configure delete stonith-sbd
sudo crm configure primitive stonith-sbd stonith:external/sbd \
   params pcmk_delay_max="15" \
   op monitor interval="600" timeout="15"

  2. [1] Si vous utilisez un agent d’isolation Azure pour l’isolation, exécutez les commandes suivantes. Une fois que vous avez attribué des rôles aux deux nœuds de cluster, vous pouvez configurer les appareils d’isolation dans le cluster.

    sudo crm configure property stonith-enabled=true
sudo crm configure property concurrent-fencing=true

    Notes

    L’option « pcmk_host_map » n’est requise dans la commande que si les noms d’hôte et les noms de machines virtuelles Azure ne sont pas identiques. Spécifiez le mappage au format nom-d-hôte:nom-machine-virtuelle.

# Adjust the command with your subscription ID and resource group of the VM

sudo crm configure primitive rsc_st_azure stonith:fence_azure_arm \
params msi=true subscriptionId="subscription ID" resourceGroup="resource group" \
pcmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_delay_max=15 pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
op monitor interval=3600 timeout=120

sudo crm configure property stonith-timeout=900

Si vous utilisez l’appareil de clôture, en fonction de la configuration du principal de service, lisez Passer de SPN à MSI pour les clusters Pacemaker à l’aide de la clôture Azure et découvrez comment effectuer la conversion en configuration d’identité managée.

Important

Les opérations de monitoring et d’isolation sont désérialisées. Par conséquent, si un événement d’isolation se produit en même temps qu’une opération de monitoring longue, il n’y a aucun délai pour le basculement du cluster. En effet, l’opération de monitoring est déjà en cours d’exécution.

Conseil

L’agent d’isolation Azure exige une connectivité sortante vers les points de terminaison publics. Cet aspect est documenté, avec des solutions possibles, dans Connectivité des points de terminaison publics pour les machines virtuelles avec un équilibreur de charge interne standard.

Configuration de Pacemaker pour les événements planifiés Azure

Azure propose des événements planifiés. Les événements planifiés sont fournis via le service de métadonnées et permettent à l’application de se préparer à ces événements. L’agent de ressources azure-events-az surveille les événements Azure planifiés. Si des événements sont détectés et que l’agent de ressources détermine qu’un autre nœud de cluster est disponible, il définit un attribut d’intégrité de cluster. Lorsque l’attribut d’intégrité du cluster est défini pour un nœud, les déclencheurs de contrainte d’emplacement et toutes les ressources, dont le nom ne commence pas par « health- » sont déplacées loin du nœud avec un événement planifié. Une fois que le nœud de cluster affecté est libre d’exécuter des ressources de cluster, l’événement planifié est reconnu et peut exécuter son action, notamment le redémarrage.

Important

Auparavant, ce document décrivait l'utilisation de l'agent de ressource azure-events. Un nouvel agent de ressources azure-events-az prend entièrement en charge les environnements Azure déployés dans différentes zones de disponibilité. Nous recommandons d’utiliser l’agent azure-events-az plus récent pour tous les systèmes SAP hautement disponibles avec Pacemaker.

  1. [A] Vérifiez que le package de l’agent azure-events est déjà installé et à jour.

    sudo zypper info resource-agents

    Exigences minimales pour la version :

    • SLES 12 SP5 : resource-agents-4.3.018.a7fb5035-3.98.1
    • SLES 15 SP1 : resource-agents-4.3.0184.6ee15eb2-150100.4.72.1
    • SLES 15 SP2 : resource-agents-4.4.0+git57.70549516-150200.3.56.1
    • SLES 15 SP3 : resource-agents-4.8.0+git30.d0077df0-150300.8.31.1
    • SLES 15 SP4 et versions ultérieures : resource-agents-4.10.0+git40.0f4de473-150400.3.19.1

  2. [1] Configurez les ressources dans Pacemaker.

    #Place the cluster in maintenance mode
sudo crm configure property maintenance-mode=true

  3. [1] Définir la stratégie et la contrainte du nœud d’intégrité du cluster Pacemaker

    sudo crm configure property node-health-strategy=custom
sudo crm configure location loc_azure_health \
/'!health-.*'/ rule '#health-azure': defined '#uname'

    Important

    Ne définissez aucune autre ressource dans le cluster en commençant par « health- », en plus des ressources décrites dans les étapes suivantes de la documentation.

  4. [1] Définissez la valeur initiale des attributs de cluster. Exécutez chaque nœud de cluster. Pour les environnements de scale-out, y compris la machine virtuelle de Pacemaker majoritaire.

    sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0
sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0

  5. [1] Configurez les ressources dans Pacemaker. Important : les ressources doivent commencer par « health-azure. »

    sudo crm configure primitive health-azure-events ocf:heartbeat:azure-events-az \ 
meta allow-unhealthy-nodes=true failure-timeout=120s \ 
op start start-delay=60s \ 
op monitor interval=10s

sudo crm configure clone health-azure-events-cln health-azure-events

    Remarque

    Lors de la configuration de la ressource « health-azure-events », le message d’avertissement suivant peut être ignoré.

    AVERTISSEMENT : health-azure-events: unknown attribute 'allow-unhealthy-nodes'.

  6. Retirer le mode maintenance du cluster Pacemaker

    sudo crm configure property maintenance-mode=false

  7. Effacez les erreurs lors de l’activation et vérifiez que les ressources health-azure-events ont démarré correctement sur tous les nœuds de cluster.

    sudo crm resource cleanup

    La première exécution d'une requête pour des événements programmés peut prendre jusqu'à 2 minutes. Les tests Pacemaker avec des événements planifiés peuvent utiliser des actions de redémarrage ou de redéploiement pour les machines virtuelles du cluster. Pour plus d’informations, consultez la documentation sur les événements planifiés.

    Remarque

    Si, après avoir configuré les ressources Pacemaker pour l’agent azure-events, vous placez le cluster en mode maintenance ou quittez ce mode, les messages d’avertissement suivants peuvent s’afficher :

    AVERTISSEMENT : cib-bootstrap-options: unknown attribute 'hostName_hostname'
    WARNING: cib-bootstrap-options: unknown attribute 'azure-events_globalPullState'
    WARNING: cib-bootstrap-options: unknown attribute 'hostName_ hostname'
    Ces messages d’avertissement peuvent être ignorés.

Étapes suivantes