Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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
Lisez la documentation sur la haute disponibilité (HA) RHEL
- Configuration et gestion des clusters de haute disponibilité.
- Stratégies de prise en charge pour les clusters haute disponibilité RHEL – sbd et fence_sbd.
- Stratégies de prise en charge pour les clusters haute disponibilité RHEL – fence_azure_arm.
- Limitations connues de la surveillance émulée par logiciel.
- Exploration des composants de la haute disponibilité de Red Hat Enterprise Linux – sbd et fence_sbd.
- Guide de conception pour les clusters à haute disponibilité RHEL – Considérations relatives à sbd
- Considérations relatives à l’adoption de RHEL 8 – Haute disponibilité et clusters
documentation RHEL spécifique à Azure
Documentation RHEL pour les offres SAP
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.
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 SSDSKU 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.
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.
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
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.
Installez les dernières mises à jour, et redémarrez si nécessaire.
sudo dnf -y updateInstallez le package cible iSCSI.
sudo dnf install -y targetcliActivez et lancez le service iSCSI.
sudo systemctl start target sudo systemctl enable targetOuvre 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
- Créez le dossier racine de tous les appareils SBD.
sudo mkdir /sbd - 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 - 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 - Enregistrez la configuration.
sudo targetcli saveconfig - 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
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.
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": [] }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
[A] Mettez à jour le système d’exploitation et redémarrez si nécessaire.
sudo dnf -y update[A] Installez les packages de cluster nécessaires.
sudo dnf install -y nmap-ncat pcs pacemaker resource-agents resource-agents-cloud[A] Installer les paquets de clôture requis.
sudo dnf install -y sbd fence-agents-sbdsudo dnf install -y sbd fence-agents-sbd iscsi-initiator-utilssudo dnf install -y fence-agents-azure-arm[A] Configurez le DNS.
Vous pouvez utiliser un serveur DNS ou modifier
/etc/hostssur 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-cl2sudo 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[A] Mettez à jour le
haclustermot de passe pour qu’il soit identique sur tous les nœuds.sudo passwd hacluster[A] Mettez à jour le pare-feu.
sudo firewall-cmd --add-service=high-availability --permanent sudo firewall-cmd --reload[A] Activez les services Pacemaker.
sudo systemctl start pcsd.service sudo systemctl enable pcsd.service[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 --allConfigurez 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.
-
[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 -
[A] Activez le service de minuterie.
sudo systemctl daemon-reload sudo systemctl enable pacemaker.timer -
[1] Désactivez les services Pacemaker.
sudo pcs cluster disable --all
-
[A] Configurez le service de minuterie.
Validez le cluster.
-
[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 -
[A] Validez les services.
systemctl list-unit-files pacemaker.timer pacemaker.service corosync.service pcsd.serviceUNIT FILE STATE PRESET corosync.service disabled disabled pacemaker.service disabled disabled pacemaker.timer enabled disabled pcsd.service enabled disabled
-
[1] Valider le cluster Pacemaker.
Configurez la clôture
-
[A] Activez le service SBD.
sudo systemctl enable sbd -
[A] Activez le watchdog logiciel.
echo softdog | sudo tee /etc/modules-load.d/softdog.conf sudo modprobe softdog -
[A] Découvrez l’ID de l’appareil iSCSI.
- 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 - 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
- Déterminer le point de montage en fonction du numéro LUN
-
[1] Créez l’appareil SBD.
sudo sbd -d /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 -1 60 -4 120 create
-
[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 -
[1] Modifier les paramètres de configuration SBD.
sudo pcs property set stonith-timeout=210 sudo pcs property set stonith-enabled=true -
[A] Valider le fichier de configuration SBD.
sudo vi /etc/sysconfig/sbd[...] SBD_DELAY_START=no [...] SBD_PACEMAKER=yes [...] SBD_STARTMODE=always [...]
-
[A] Activez les services nécessaires.
sudo systemctl enable sbd iscsi iscsid -
[A] Activez le watchdog logiciel.
echo softdog | sudo tee /etc/modules-load.d/softdog.conf sudo modprobe softdog -
[1] Mettre à jour le
InitiatorNamedu nœud 1.sudo vi /etc/iscsi/initiatorname.iscsi [...] InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1 -
[2] Mettre à jour le
InitiatorNamedu nœud 2.# Node 2 sudo vi /etc/iscsi/initiatorname.iscsi [...] InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2 -
[A] Redémarrez les services iSCSI.
sudo systemctl restart iscsi iscsid -
[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 -
[A] Découvrez les identifiants des appareils iSCSI.
- 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 - 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
- Déterminez les points de montage iSCSI.
-
[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] 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 -
[1] Modifier les paramètres de configuration SBD.
sudo pcs property set stonith-timeout=210 sudo pcs property set stonith-enabled=true -
[A] Valider le fichier de configuration SBD.
sudo vi /etc/sysconfig/sbd[...] SBD_DELAY_START=no [...] SBD_PACEMAKER=yes [...] SBD_STARTMODE=always [...]
[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=usgovpour 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[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] Ajustez la configuration du cluster.
Les
Votequorum - Expected votesvaleurs etVotequorum - Flags - 2Nodese mettent automatiquement à jour lorsque vous ajoutez un troisième nœud ou plus. Validez que le2Nodedrapeau est absent etVotequorum - Expected votescorrespond 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 ---------------------- [...]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 -1sudo 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.
Installez et mettez à jour le
resource-agentspaquet.sudo dnf install -y resource-agents[1] Placez le cluster en mode maintenance.
sudo pcs property set maintenance-mode=true[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"[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[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=90ssudo pcs resource clone health-azure-events meta allow-unhealthy-nodes=trueRetirez le cluster Pacemaker du mode de maintenance et effacez toutes les erreurs
sudo pcs property set maintenance-mode=false sudo pcs resource cleanupVérifiez que
health-azure-eventsdé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/enabledLa 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 :
- Découvrez comment configurer fence_kdump dans un cluster Red Hat Pacemaker ?
- Consultez Guide pratique pour configurer/gérer les niveaux d’isolation dans un cluster RHEL avec Pacemaker.
- Pour plus d’informations sur la modification du délai d’expiration par défaut, consultez Comment configurer kdump pour une utilisation avec le module complémentaire RHEL 6, 7, 8 HA ?
- Pour plus d’informations sur la réduction du délai de basculement lorsque vous utilisez
fence_kdump, voir Puis-je réduire le délai attendu de basculement lors de l’ajout de fence_kdump configuration ?
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.
[A] Vérifiez que
kdumpest actif et configuré.systemctl is-active kdump # Expected result # active[A] Installez l’agent de clôture
fence_kdump.sudo dnf install -y fence-agents-kdump[1] Créez un appareil d’isolation
fence_kdumpdans le cluster.pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="sap-cl1 sap-cl2" timeout=30[1] Configurez les niveaux d’isolation pour que le mécanisme d’isolation
fence_kdumpsoit 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>[A] Autorisez les ports requis pour
fence_kdumpvia le pare-feu.firewall-cmd --add-port=7410/udp --permanent firewall-cmd --reload[A] Effectuez la configuration
fence_kdump_nodesdans/etc/kdump.confafin d’éviter l’échec defence_kdumpen raison d'un délai d’attente pour certaines versionskexec-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 servicekdump.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[A] Veillez à ce que le fichier d’images
initramfscontienne les fichiersfence_kdumpethosts.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_sendTestez 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
- Planification et mise en œuvre de Machines Virtuelles Microsoft Azure pour SAP.
- Déploiement de Machines Virtuelles Microsoft Azure pour SAP.
- Déploiement de DBMS sur des machines virtuelles Azure pour SAP.
- Haute disponibilité pour NFS Simple Mount sur les machines virtuelles Azure sur Red Hat Enterprise Linux.
- Pour découvrir comment établir une haute disponibilité et planifier la reprise après sinistre de SAP HANA sur des VMs Azure, consultez la section Haute disponibilité de SAP HANA sur des machines virtuelles Azure.