Configurer Pacemaker sur Red Hat Enterprise Linux dans Azure

Cet article explique comment configurer et configurer un cluster Pacemaker à deux nœuds basique sur Red Hat Enterprise Linux (RHEL). Les instructions couvrent RHEL 8.6+, RHEL 9.x, et RHEL 10.x.

Prerequisites

Vue d’ensemble

Ce guide suppose que vous avez déjà déployé le groupe de ressources requis, le réseau virtuel Azure, le sous-réseau et les machines virtuelles (VM).

Les clusters fonctionnant sous Linux nécessitent un agent de fencing pour isoler les nœuds défaillants. Pour accomplir cette tâche sur Azure, utilisez l’une des méthodes suivantes :

  • Mort basée sur le stockage (SBD) avec Azure Shared Disk
  • Mort basée sur le stockage (SBD) avec cibles iSCSI
  • Agent de clôture Azure

Remarque

Les préfixes suivants sont utilisés dans ce document :

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

Important

En Azure, les clusters de haute disponibilité RHEL avec clôture basée sur le stockage (fence_sbd) utilisent un watchdog émulé par logiciel. Consultez la documentation suivante lorsque vous utilisez SBD.

Utilisation de SBD avec Azure Shared Disk

En utilisant Azure Shared Disks, vous pouvez monter le même disque sur toutes les machines virtuelles faisant partie du cluster. Vous pouvez héberger votre appareil SBD sur ce disque partagé sans nécessiter d’infrastructure supplémentaire.

Schéma d’un disque partagé Azure en tant qu’appareil SBD dans un cluster Pacemaker.

Avantages

  • Offre une option native d’appareil à blocs partagés Azure pour SBD sans nécessiter de ressources supplémentaires.
  • Les machines virtuelles connectent directement le disque géré, réduisant ainsi la dépendance à des considérations réseau supplémentaires.

Considérations importantes

  • Vous pouvez utiliser un disque partagé Azure avec le Premium SSD SKU comme un périphérique SBD.
  • Consultez la liste des systèmes d’exploitation pris en charge.
  • Les appareils SBD utilisant un disque partagé premium Azure prennent en charge le stockage localement redondant (LRS) et le stockage redondant en zone (ZRS).
  • Selon le type de votre déploiement, choisissez le stockage redondant approprié pour un disque partagé Azure comme appareil SBD.
    • Un périphérique SBD qui utilise LRS pour un disque partagé Premium Azure (skuName - Premium_LRS) prend uniquement en charge les déploiements dans un ensemble de disponibilité.
    • Un dispositif SBD utilisant ZRS pour un disque partagé premium Azure (skuName - Premium_ZRS) est recommandé pour les déploiements dans les zones de disponibilité.
  • Le Azure disque partagé que vous utilisez pour les appareils SBD n'a pas besoin d'être volumineux. La valeur maxShares détermine combien de nœuds de cluster peuvent utiliser le disque partagé. Par exemple, vous pouvez utiliser des tailles de disque P1 ou P2 pour votre appareil SBD sur un cluster à deux nœuds comme SAP ASCS/ERS ou SAP HANA Scale-up.
    • Pour les clusters de plus de deux nœuds, consultez la valeur maxShares documentée pour le disque sélectionné.
  • Ne connectez pas un dispositif Azure shared disk SBD entre différents clusters Pacemaker.
  • Si vous utilisez plusieurs appareils SBD de disque partagé Azure, vérifiez la limite d’un nombre maximal de disques de données pouvant être attachés à une machine virtuelle.
  • Pour plus d’informations sur les limitations relatives aux disques partagés Azure, consultez attentivement la section « Limitations » de Azure documentation sur les disques partagés.

Utilisation de SBD avec des cibles iSCSI

Cette solution nécessite d’héberger des cibles Internet Small Computer System Interface (iSCSI) sur au moins une machine virtuelle (VM) supplémentaire.

Schéma des serveurs iSCSI hébergeant des cibles iSCSI pour des appareils SBD dans un cluster Pacemaker.

Avantages

  • Ces serveurs hôtes iSCSI peuvent également héberger des cibles iSCSI pour d’autres clusters Pacemaker dans la même région.
  • Si vous les utilisez déjà sur site, ils ne nécessitent aucun changement dans la façon dont vous utilisez le cluster Pacemaker.

Considérations importantes

  • Vous devez utiliser trois serveurs hôtes iSCSI pour avoir le plus haut niveau de résilience pour votre cluster.
    • Utiliser un seul serveur crée un point de défaillance unique qui empêche votre cluster d’effectuer le fencing s’il tombe en panne.
    • Pacemaker n’autorise pas le fencing si vous n’avez que deux cibles et que l’une d’elles est hors service.
  • Les serveurs hôtes cibles iSCSI doivent résider dans la même région que vos clusters.
  • Le routage réseau entre vos clusters et les serveurs hôtes iSCSI ne doit pas traverser de dispositifs réseau non redondants (comme un Network Virtual Appliance).
    • Les événements de maintenance et autres problèmes liés aux dispositifs réseau peuvent nuire à la stabilité et à la fiabilité de la configuration globale du cluster.

Utilisation de l’agent de clôture Azure

En utilisant l’agent Azure Fence, votre cluster peut isoler les nœuds en appelant directement les API Azure afin de redémarrer les nœuds défaillants.

Schéma de l’agent d’isolation Azure dans un cluster Pacemaker.

Avantages

  • Aucune ressource supplémentaire n’est nécessaire.
  • Les identités gérées suppriment toute maintenance des identifiants.

Considérations importantes

  • Utilisez des identités gérées pour l’authentification. Si vous utilisez actuellement un principal de service, mettez à jour l'Agent Azure Fence de SPN à MSI.
  • L’agent de clôture Azure nécessite une connectivité sortante vers les points de terminaison Azure publics. Pour plus d’informations et pour découvrir les solutions potentielles, consultez Connectivité de point de terminaison public pour les machines virtuelles avec ILB Standard.
  • 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.

Déploiement d’un disque partagé Azure pour SBD

Pour créer et attacher un disque partagé Azure en utilisant PowerShell, exécutez les commandes suivantes. Si vous souhaitez déployer des ressources en utilisant la interface Azure CLI ou le portail Azure, consultez Déploiement d’un disque ZRS.

$ResourceGroup = "<ResourceGroupName>"
$DiskSizeInGB = 4
$DiskName = "<SBDDiskName>"
# Must be Equal to or greater than the Number of Nodes in the Cluster
$ShareNodes = 2 
# Options are "Premium_LRS" or "Premium_ZRS"
$SKUName = "<DiskSKU>"
# VMs to attach the disk to
$vmNames = @("sap-cl1", "sap-cl2")
# Lun to attach the disk to. You should use the same lun on all servers in the cluster.
$lunNumber = <lunNumber>

$diskConfig = New-AzDiskConfig -Location $Location -SkuName $SkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes

$dataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $diskConfig

# Attach SBD disk to cluster VMs
foreach ($vmName in $vmNames) 
{
  $vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
  Add-AzVMDataDisk -VM $vm -Name $diskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun $lunNumber
  Update-AzVM -VM $vm -ResourceGroupName $resourceGroup -Verbose
}

Utiliser des cibles iSCSI

Construire des serveurs hôtes cibles iSCSI

  1. Déployez trois machines virtuelles qui fonctionnent sur une version RHEL prise en charge. Les machines virtuelles n’ont pas besoin d’être très grandes. Les tailles de VM telles que Standard_E2s ou Standard_D2s sont suffisantes.

    Remarque

    Vous n’avez pas besoin d’utiliser RHEL pour SAP avec HA et Update Services, ni RHEL pour l’image SAP Apps OS du serveur cible iSCSI. Vous pouvez utiliser une image RHEL OS standard à la place. Toutefois, le cycle de vie de prise en charge varie selon les différentes versions du produit du système d’exploitation.

  2. Installez les dernières mises à jour, et redémarrez si nécessaire.

    sudo dnf -y update
    
  3. Installez le package cible iSCSI.

    sudo dnf install -y targetcli
    
  4. Activez et lancez le service iSCSI.

    sudo systemctl start target
    sudo systemctl enable target
    
  5. Ouvre le port dans le pare-feu.

    sudo firewall-cmd --add-port=3260/tcp --permanent
    sudo firewall-cmd --reload
    

Créer des cibles iSCSI

Pour chaque cluster, vous devez provisionner un disque iSCSI sur chaque serveur hôte iSCSI, puis accorder l’accès à chaque nœud du cluster à ce disque. Dans cet exemple, vous créez des disques pour deux clusters différents :

  • ascsnw1 : Le cluster ASCS/ERS pour NW1
  • hdbnw1 : Le cluster de bases de données HANA pour NW1
  • sap-cl1 et sap-cl2 : noms d’hôte pour les nœuds du cluster ASCS/ERS NW1
  • sap-db1 et sap-db2 : noms d’hôte pour les nœuds du cluster HANA NW1
  1. Créez le dossier racine de tous les appareils SBD.
    sudo mkdir /sbd
    
  2. Créez le dispositif SBD pour le premier cluster (ascsnw1).
    # Create Storage Object
    sudo targetcli backstores/fileio create sbdascsnw1 /sbd/sbdascsnw1 50M write_back=false
    # Create iSCSI Target
    sudo targetcli iscsi/ create iqn.2006-04.ascsnw1.local:ascsnw1
    # Creates the LUN and attaches it to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/luns/ create /backstores/fileio/sbdascsnw1
    # Grant Cluster Node 1 (sap-cl1) access to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.sap-cl1.local:sap-cl1
    # Grant Cluster Node 2 (sap-cl2) access to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.sap-cl2.local:sap-cl2
    
  3. Créer le périphérique SBD pour le second cluster (hdbnw1).
    # Create Storage Object
    sudo targetcli backstores/fileio create sbdhdbnw1 /sbd/sbdhdbnw1 50M write_back=false
    # Create iSCSI Target
    sudo targetcli iscsi/ create iqn.2006-04.hdbnw1.local:hdbnw1
    # Creates the LUN and attaches it to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.hdbnw1.local:hdbnw1/tpg1/luns/ create /backstores/fileio/sbdhdbnw1
    # Grant Cluster Node 1 (sap-db1) access to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.hdbnw1.local:hdbnw1/tpg1/acls/ create iqn.2006-04.sap-db1.local:sap-db1
    # Grant Cluster Node 2 (sap-db2) access to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.hdbnw1.local:hdbnw1/tpg1/acls/ create iqn.2006-04.sap-db2.local:sap-db2
    
  4. Enregistrez la configuration.
    sudo targetcli saveconfig
    
  5. Vérifiez la configuration.
    sudo targetcli ls
    
    o- / ............................................................................................... [...]
      o- backstores .................................................................................... [...]
      | o- block ........................................................................ [Storage Objects: 0]
      | o- fileio ....................................................................... [Storage Objects: 2]
      | | o- sbdascsnw1 ..................................... [/sbd/sbdascsnw1 (50.0MiB) write-thru activated]
      | | | o- alua ......................................................................... [ALUA Groups: 1]
      | | |   o- default_tg_pt_gp ............................................. [ALUA state: Active/optimized]
      | | o- sbdhdbnw1 ....................................... [/sbd/sbdhdbnw1 (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: 2]
      | o- iqn.2006-04.hdbnw1.local:hdbnw1 ......................................................... [TPGs: 1]
      | | o- tpg1 ..................................................................... [no-gen-acls, no-auth]
      | |   o- acls ................................................................................ [ACLs: 2]
      | |   | o- iqn.2006-04.sap-db1.local:sap-db1 .......................................... [Mapped LUNs: 1]
      | |   | | o- mapped_lun0 ..................................................... [lun0 fileio/sbdhdb (rw)]
      | |   | o- iqn.2006-04.sap-db2.local:sap-db2 .......................................... [Mapped LUNs: 1]
      | |   |   o- mapped_lun0 ..................................................... [lun0 fileio/sbdhdb (rw)]
      | |   o- luns ................................................................................ [LUNs: 1]
      | |   | o- lun0 ................................. [fileio/sbdhdbnw1 (/sbd/sbdhdbnw1) (default_tg_pt_gp)]
      | |   o- portals .......................................................................... [Portals: 1]
      | |     o- 0.0.0.0:3260 ........................................................................... [OK]
      | o- iqn.2006-04.ascsnw1.local:ascsnw1 ....................................................... [TPGs: 1]
      |   o- tpg1 ..................................................................... [no-gen-acls, no-auth]
      |     o- acls ................................................................................ [ACLs: 2]
      |     | o- iqn.2006-04.sap-cl1.local:sap-cl1 .......................................... [Mapped LUNs: 1]
      |     | | o- mapped_lun0 ................................................. [lun0 fileio/sbdascsnw1 (rw)]
      |     | o- iqn.2006-04.sap-cl2.local:sap-cl2 .......................................... [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- loopback ............................................................................... [Targets: 0]
    

Configurer Azure Fence Agent

  1. Créer une identité

    Pour créer une identité managée (MSI), créez une identité managée assignée par le système pour chaque VM du cluster. Les identités gérées attribuées par les utilisateurs ne sont pas prises en charge pour le moment.

  2. créer un rôle personnalisé ;

    Votre identité nécessite des autorisations via RBAC Azure pour effectuer des actions d’isolation sur vos machines virtuelles. Pour se conformer au modèle de sécurité à accès minimal privilégié (LPA), créez un rôle RBAC personnalisé.

    Utilisez la définition suivante pour votre rôle, en remplaçant vos identifiants d’abonnement là où c’est nécessaire :

    {
          "Name": "Linux Fence Agent",
          "description": "Allowed to power-off and start virtual machines",
          "assignableScopes": [
                  "/subscriptions/<Subscription 1 ID (GUID)>",
                  "/subscriptions/<Subscription N ID (GUID)>"
          ],
          "actions": [
                  "Microsoft.Compute/*/read",
                  "Microsoft.Compute/virtualMachines/powerOff/action",
                  "Microsoft.Compute/virtualMachines/start/action"
          ],
          "notActions": [],
          "dataActions": [],
          "notDataActions": []
    }
    
  3. Attribuez le rôle personnalisé à vos identités.

    Pour chaque VM de votre cluster, attribuez son identité gérée au rôle personnalisé « Linux Fence Agent » pour chaque VM du cluster, y compris elle-même. Pour connaître les étapes en détail, consultez Attribuer à une identité managée un accès à une ressource à l’aide du Portail Azure.

    Important

    Sachez que l’attribution et la suppression des autorisations avec des identités gérées peuvent être retardées jusqu’à leur entrée en vigueur.

Créer et configurer un cluster

  1. [A] Mettez à jour le système d’exploitation et redémarrez si nécessaire.

    sudo dnf -y update
    
  2. [A] Installez les packages de cluster nécessaires.

    sudo dnf install -y nmap-ncat pcs pacemaker resource-agents resource-agents-cloud
    
  3. [A] Installer les paquets de clôture requis.

    sudo dnf install -y sbd fence-agents-sbd
    
    sudo dnf install -y sbd fence-agents-sbd iscsi-initiator-utils
    
    sudo dnf install -y fence-agents-azure-arm
    
  4. [A] Configurez le DNS.

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

    Mettez à jour les entrées pour qu’elles correspondent à vos adresses IP et noms d’hôte.

    sudo vi /etc/hosts
    [...]
    # IP address of cluster node 1
    10.27.0.6    sap-cl1
    # IP address of cluster node 2
    10.27.0.7    sap-cl2
    
    sudo vi /etc/hosts
    [...]
    # IP address of cluster node 1
    10.0.0.6    sap-cl1
    # IP address of cluster node 2
    10.0.0.7    sap-cl2
    # IP address of iSCSI Target Host Server 1
    10.0.0.17   sbd-iscsi1
    # IP address of iSCSI Target Host Server 1
    10.0.0.18   sbd-iscsi2
    # IP address of iSCSI Target Host Server 1
    10.0.0.19   sbd-iscsi3
    
  5. [A] Mettez à jour le hacluster mot de passe pour qu’il soit identique sur tous les nœuds.

    sudo passwd hacluster
    
  6. [A] Mettez à jour le pare-feu.

    sudo firewall-cmd --add-service=high-availability --permanent
    sudo firewall-cmd --reload
    
  7. [A] Activez les services Pacemaker.

    sudo systemctl start pcsd.service
    sudo systemctl enable pcsd.service
    
  8. [1] Créez le cluster.

    sudo pcs host auth sap-cl1 sap-cl2 -u hacluster
    sudo pcs cluster setup ascsnw1 sap-cl1 sap-cl2 totem token=30000
    sudo pcs cluster start --all
    
  9. Configurez un délai de démarrage pour Pacemaker.

    Le démarrage de Pacemaker immédiatement après le démarrage du système peut potentiellement permettre à un nœud de réintégrer le cluster avant la fin du basculement, ce qui empêche le basculement ou retarde la reprise. Pour résoudre ce problème, utilisez un service de minuterie pour retarder le démarrage du pacemaker au redémarrage.

    1. [A] Configurez le service de minuterie.
      sudo vi /etc/systemd/system/pacemaker.timer   
      
      [Unit]
      Description=Delay start of pacemaker.service after boot
      [Timer]
      OnBootSec=186
      Unit=pacemaker.service
      [Install]
      WantedBy=timers.target
      
    2. [A] Activez le service de minuterie.
      sudo systemctl daemon-reload
      sudo systemctl enable pacemaker.timer
      
    3. [1] Désactivez les services Pacemaker.
      sudo pcs cluster disable --all
      
  10. Validez le cluster.

    1. [1] Valider le cluster Pacemaker.
      sudo pcs status
      
      Cluster name: ascsnw1
      Cluster Summary:
        * Stack: corosync (Pacemaker is running)
        * Current DC: sap-cl1 (version 3.0.0-5.1.el10_0-8818a21) - partition with quorum
        * Last updated: Tue May 19 22:15:08 2026 on sap-cl1
        * Last change:  Tue Apr 21 23:11:34 2026 by root via root on sap-cl1
        * 2 nodes configured
        * 0 resource instances configured
      
      Node List:
        * Online: [ sap-cl1 sap-cl2 ]
      
      Full List of Resources:
      
      Daemon Status:
        corosync: active/disabled
        pacemaker: active/disabled
        pcsd: active/enabled
      
    2. [A] Validez les services.
      systemctl list-unit-files pacemaker.timer pacemaker.service corosync.service pcsd.service
      
      UNIT FILE         STATE    PRESET
      corosync.service  disabled disabled
      pacemaker.service disabled disabled
      pacemaker.timer   enabled  disabled
      pcsd.service      enabled  disabled
      

Configurez la clôture

  1. [A] Activez le service SBD.
    sudo systemctl enable sbd
    
  2. [A] Activez le watchdog logiciel.
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [A] Découvrez l’ID de l’appareil iSCSI.
    1. Déterminer le point de montage en fonction du numéro LUN
      ls -l /dev/disk/azure/scsi1/lun1
      lrwxrwxrwx. 1 root root 12 Apr 16 20:22 /dev/disk/azure/scsi1/lun1 -> ../../../sdb
      
    2. Récupérez l’identifiant du périphérique iSCSI à partir du point de montage.
      ls -l /dev/disk/by-id/scsi-3* | grep -i sdb
      lrwxrwxrwx. 1 root root  9 Apr 16 20:22 /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 -> ../../sdb
      
  4. [1] Créez l’appareil SBD.
    sudo sbd -d /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 -1 60 -4 120 create
    
  1. [1] Ajouter l’appareil SBD au cluster.
    sudo pcs stonith create sbd fence_sbd devices=/dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 op monitor interval=600 timeout=15
    
  2. [1] Modifier les paramètres de configuration SBD.
    sudo pcs property set stonith-timeout=210
    sudo pcs property set stonith-enabled=true
    
  3. [A] Valider le fichier de configuration SBD.
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [A] Activez les services nécessaires.
    sudo systemctl enable sbd iscsi iscsid
    
  2. [A] Activez le watchdog logiciel.
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [1] Mettre à jour le InitiatorName du nœud 1.
    sudo vi /etc/iscsi/initiatorname.iscsi
    [...]
    InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1
    
  4. [2] Mettre à jour le InitiatorName du nœud 2.
    # Node 2
    sudo vi /etc/iscsi/initiatorname.iscsi
    [...]
    InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2
    
  5. [A] Redémarrez les services iSCSI.
    sudo systemctl restart iscsi iscsid
    
  6. [A] Montez les cibles iSCSI depuis tous les serveurs hôtes iSCSI.
    for hostServer in sbd-iscsi1 sbd-iscsi2 sbd-iscsi3; do
       iscsiadm -m discovery --type=st --portal=${hostServer}:3260 
       iscsiadm -m node -T iqn.2006-04.ascsnw1.local:ascsnw1 --login --portal=${hostServer}:3260
       iscsiadm -m node --portal=${hostServer}:3260 -T iqn.2006-04.ascsnw1.local:ascsnw1 --op=update --name=node.startup --value=automatic
    done
    
  7. [A] Découvrez les identifiants des appareils iSCSI.
    1. Déterminez les points de montage iSCSI.
      lsscsi
      [0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
      [1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdb
      [2:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdc
      [3:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdd
      [4:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sde
      
    2. Obtenez les identifiants des appareils iSCSI.
      ls -l /dev/disk/by-id/scsi-3* | grep sd[c,d,e]
      lrwxrwxrwx 1 root root  9 Jul 21 18:02 /dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528 -> ../../sdd
      lrwxrwxrwx 1 root root  9 Jul 21 17:50 /dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff -> ../../sdc
      lrwxrwxrwx 1 root root  9 Jul 21 18:04 /dev/disk/by-id/scsi-360014059f135275c24647d49268123e5 -> ../../sde
      
  8. [1] Créer les dispositifs SBD.
    sudo sbd -d /dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528 -1 60 -4 120 create
    sudo sbd -d /dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff -1 60 -4 120 create
    sudo sbd -d /dev/disk/by-id/scsi-360014059f135275c24647d49268123e5 -1 60 -4 120 create
    
  1. [1] Ajoutez les appareils SBD au cluster.
    sudo pcs stonith create sbd fence_sbd \
       devices=/dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528,/dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff,/dev/disk/by-id/scsi-360014059f135275c24647d49268123e5 \
       op monitor interval=600 timeout=120
    
  2. [1] Modifier les paramètres de configuration SBD.
    sudo pcs property set stonith-timeout=210
    sudo pcs property set stonith-enabled=true
    
  3. [A] Valider le fichier de configuration SBD.
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [1] Configurez Azure Fence Agent.

    Remarque

    Lorsque vous utilisez Azure Government Cloud, vous devez spécifier cette cloud= option lors de la configuration de l’Azure Fence Agent. Par exemple, cloud=usgov pour le cloud Azure gouvernement américain.

    sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true \
       resourceGroup="<ResourceGroupName>" subscriptionId="<SubscriptionID>" \
       pcmk_host_map="sap-cl1:<AzureVMNameCL1>;sap-cl2:<AzureVMNameCL2>" \
       power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 \
       pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
       meta failure-timeout=120s op monitor interval=3600 timeout=120
    
  2. [1] Configurez le cluster pour Azure Fence Agent.

    sudo pcs property set stonith-enabled=true
    sudo pcs property set stonith-timeout=900
    

Construire un cluster Pacemaker avec plus de deux nœuds

Si vous construisez un cluster plus vaste, gardez ces considérations à l’esprit :

  1. [1] Ajustez la configuration du cluster.

    Les Votequorum - Expected votes valeurs et Votequorum - Flags - 2Node se mettent automatiquement à jour lorsque vous ajoutez un troisième nœud ou plus. Validez que le 2Node drapeau est absent et Votequorum - Expected votes correspond au nombre de nœuds dans votre cluster.

    sudo pcs quorum status
    
    Quorum information
    ------------------
    [...]
    
    Votequorum information
    ----------------------
    Expected votes:   3
    Highest expected: 3
    Total votes:      3
    Quorum:           2
    Flags:            Quorate WaitForAll
    
    Membership information
    ----------------------
    [...]
    
  2. Ajustez la configuration de la clôture.

    sudo crm resource param stonith-sbd delete pcmk_delay_max
    sudo crm resource param stonith-sbd set pcmk_action_limit -1
    
    sudo crm resource param rsc_st_azure delete pcmk_delay_max
    sudo crm resource param rsc_st_azure pcmk_action_limit -1
    

Configurer Pacemaker pour Azure événements planifiés

Scheduled Events est un service de métadonnées Azure qui donne à votre application le temps de se préparer à la maintenance des machines virtuelles. Il fournit des informations sur les événements de maintenance à venir, comme un redémarrage, afin que votre application puisse s’y préparer et limiter les perturbations.

L’agent de ressources azure-events-az surveille ce service de métadonnées. Lorsque l’agent détecte des événements et détermine qu’un autre nœud de cluster est disponible, il attribue un attribut #health-azure de santé au niveau du nœud à -1000000. Cette valeur pousse le cluster à considérer le nœud comme malsain et à migrer des ressources loin du nœud affecté. La contrainte de localisation garantit que les ressources commençant par health- sont exclues, car l’agent azure-events-az doit toujours s’exécuter sur les deux nœuds. Une fois que le nœud du cluster affecté est libéré des ressources du cluster en cours d’exécution, l’agent notifie le service de métadonnées et l’événement programmé peut continuer. Lorsque tous les événements sont terminés, l’agent de ressources remet l’attribut #health-azure à 0, marquant ainsi le nœud comme sain à nouveau.

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é. Utilisez l’agent plus récent azure-events-az pour tous les systèmes SAP hautement disponibles avec Pacemaker.

  1. Installez et mettez à jour le resource-agents paquet.

    sudo dnf install -y resource-agents
    
  2. [1] Placez le cluster en mode maintenance.

    sudo pcs property set maintenance-mode=true
    
  3. [1] Définissez la stratégie et la contrainte du nœud d’état de santé du cluster Pacemaker.

    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.

    sudo pcs property set node-health-strategy=custom
    sudo pcs constraint location 'regexp%!health-.*' \
       rule score-attribute='#health-azure' \
       "defined #uname"
    
  4. [1] Définissez la valeur initiale des attributs de cluster.

    Exécutez une commande pour chaque nœud du cluster. Pour les environnements de scale-out, incluez la machine virtuelle de créateur de majorité.

    # Node 1
    sudo crm_attribute --node sap-cl1 --name '#health-azure' --update 0
    # Node 2
    sudo crm_attribute --node sap-cl2 --name '#health-azure' --update 0
    # Node N
    sudo crm_attribute --node sap-clN --name '#health-azure' --update 0
    
  5. [1] Configurez les ressources dans Pacemaker. Les ressources doivent commencer par health-azure.

    sudo pcs resource create health-azure-events \
       ocf:heartbeat:azure-events-az \
       meta failure-timeout=120s \
       op monitor interval=10s timeout=240s \
       op start timeout=10s start-delay=90s
    
    sudo pcs resource clone health-azure-events meta allow-unhealthy-nodes=true
    
  6. Retirez le cluster Pacemaker du mode de maintenance et effacez toutes les erreurs

    sudo pcs property set maintenance-mode=false
    sudo pcs resource cleanup
    
  7. Vérifiez que health-azure-events démarre correctement sur tous les nœuds.

    sudo pcs status
    
       Cluster name: ascsnw1
       Cluster Summary:
         * Stack: corosync (Pacemaker is running)
         * Current DC: sap-cl1 (version 3.0.0-5.1.el10_0-8818a21) - partition with quorum
         * Last updated: Tue May 19 22:15:08 2026 on sap-cl1
         * Last change:  Tue Apr 21 23:11:34 2026 by root via root on sap-cl1
         * 2 nodes configured
         * 3 resource instances configured
    
       Node List:
         * Online: [ sap-cl1 sap-cl2 ]
    
       Full List of Resources:
         * sbd (stonith:fence_sbd):     Started sap-cl1
         * Clone Set: health-azure-events-clone [health-azure-events]:
           * Started: [ sap-cl1 sap-cl2 ]
    
       Daemon Status:
         corosync: active/disabled
         pacemaker: active/disabled
         pcsd: active/enabled
         sbd: active/enabled
    

    La première exécution d'une requête pour des événements programmés peut prendre jusqu'à deux 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 Événements planifiés.

Configuration d’isolation facultative

Conseil

Cette section s’applique uniquement si vous voulez configurer un appareil d’isolation spécial fence_kdump.

Si vous avez besoin de collecter des informations de diagnostic au sein de la machine virtuelle, il peut être utile de configurer un autre appareil d’isolation en fonction de l’agent d’isolationfence_kdump. L’agent fence_kdump peut détecter qu’un nœud est entré dans la récupération sur incident kdump et peut autoriser le service de récupération sur incident à se terminer, avant d’appeler d’autres méthodes d’isolation. Notez que fence_kdump n'est pas un remplacement des mécanismes de clôture traditionnels, tels que le SBD ou l'agent de clôture Azure, lorsque vous utilisez des machines virtuelles Azure.

Important

Sachez que si fence_kdump est configuré en tant qu’appareil d’isolation de premier niveau, il entraîne des retards dans les opérations d’isolation et, respectivement, dans le basculement des ressources d’application.

Si une image mémoire après incident est correctement détectée, l’isolation sera retardée jusqu’à ce que le service de récupération sur incident se termine. Si le nœud défaillant est inaccessible ou s’il ne répond pas, l’isolation est retardée pour une durée déterminée, selon le nombre d’itérations configuré et le délai d’expiration fence_kdump.

Il peut être nécessaire d’adapter le délai d’expiration de fence_kdump proposé à l’environnement spécifique.

Nous vous recommandons de configurer fence_kdump clôture uniquement si nécessaire pour collecter des diagnostics au sein de la machine virtuelle et toujours en combinaison avec des méthodes de clôture traditionnelles, telles que SBD ou Azure agent de clôture.

Les articles issus des bases de connaissances Red Hat suivants contiennent des informations importantes sur la configuration de l’isolation fence_kdump :

Exécutez les étapes facultatives suivantes pour ajouter fence_kdump en tant que configuration de clôture de premier niveau, en plus de la configuration de l’agent de clôture Azure.

  1. [A] Vérifiez que kdump est actif et configuré.

    systemctl is-active kdump
    # Expected result
    # active
    
  2. [A] Installez l’agent de clôture fence_kdump.

    sudo dnf install -y fence-agents-kdump
    
  3. [1] Créez un appareil d’isolation fence_kdump dans le cluster.

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="sap-cl1 sap-cl2" timeout=30
    
  4. [1] Configurez les niveaux d’isolation pour que le mécanisme d’isolation fence_kdump soit engagé en premier.

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="sap-cl1 sap-cl2"
    pcs stonith level add 1 sap-cl1 rsc_st_kdump
    pcs stonith level add 1 sap-cl2 rsc_st_kdump
    # Replace <stonith-resource-name> to the resource name of the STONITH resource configured in your pacemaker cluster (example based on above configuration - sbd or rsc_st_azure)
    pcs stonith level add 2 sap-cl1 <stonith-resource-name>
    pcs stonith level add 2 sap-cl2 <stonith-resource-name>
    
    # Check the fencing level configuration 
    pcs stonith level
    # Example output
    # Target: sap-cl1
    # Level 1 - rsc_st_kdump
    # Level 2 - <stonith-resource-name>
    # Target: sap-cl2
    # Level 1 - rsc_st_kdump
    # Level 2 - <stonith-resource-name>
    
  5. [A] Autorisez les ports requis pour fence_kdump via le pare-feu.

    firewall-cmd --add-port=7410/udp --permanent
    firewall-cmd --reload
    
  6. [A] Effectuez la configuration fence_kdump_nodes dans /etc/kdump.conf afin d’éviter l’échec de fence_kdump en raison d'un délai d’attente pour certaines versions kexec-tools. Pour plus d’informations, voir fence_kdump expire lorsque fence_kdump_nodes n’est pas spécifié avec la version 2.0.15 ou ultérieure de kexec-tools. L’exemple de configuration pour un cluster à deux nœuds est présenté ici. Une fois vos modifications apportées dans /etc/kdump.conf, l’image kdump doit être régénérée. Pour régénérer, redémarrez le service kdump.

    vi /etc/kdump.conf
    # On node prod-cl1-0 make sure the following line is added
    fence_kdump_nodes  prod-cl1-1
    # On node prod-cl1-1 make sure the following line is added
    fence_kdump_nodes  prod-cl1-0
    
    # Restart the service on each node
    systemctl restart kdump
    
  7. [A] Veillez à ce que le fichier d’images initramfs contienne les fichiers fence_kdump et hosts.

    lsinitrd /boot/initramfs-$(uname -r)kdump.img | egrep "fence|hosts"
    # Example output 
    # -rw-r--r--   1 root     root          208 Jun  7 21:42 etc/hosts
    # -rwxr-xr-x   1 root     root        15560 Jun 17 14:59 usr/libexec/fence_kdump_send
    
  8. Testez la configuration en bloquant un nœud.

    Important

    Si le cluster est déjà utilisé en mode productif, planifiez le test en conséquence, car le blocage d’un nœud a un impact sur l’application.

    echo c > /proc/sysrq-trigger
    

Étapes suivantes