Einrichten von Pacemaker unter Red Hat Enterprise Linux in Azure

In diesem Artikel wird beschrieben, wie Sie einen einfachen Pacemaker-Cluster unter Red Hat Enterprise Server (RHEL) konfigurieren. Die Anweisungen beziehen sich auf RHEL 7, RHEL 8 und RHEL 9.

Voraussetzungen

Lesen Sie zuerst die folgenden SAP-Hinweise und Artikel:

RHEL High Availability-Dokumentation
Azure spezifische RHEL-Dokumentation
- Support-Richtlinien für RHEL-Hochverfügbarkeitscluster – Microsoft Azure-VMs als Mitglieder des Clusters.
- Gestaltungsrichtlinie für RHEL High Availability Cluster – Microsoft Azure Virtual Machines als Cluster-Mitglieder.
RHEL-Dokumentation für SAP-Angebote

Übersicht

Wichtig

Pacemaker-Cluster, die sich über mehrere virtuelle Netzwerke (VNets) bzw. Subnetze erstrecken, sind nicht durch Standardsupportrichtlinien abgedeckt.

Es gibt zwei Optionen für Azure zum Konfigurieren des Fencings in einem Pacemaker-Cluster für RHEL: Azure Fence-Agent, der einen fehlgeschlagenen Knoten über die Azure-APIs neu startet, oder die Verwendung eines SBD-Geräts.

Wichtig

In Azure verwendet der RHEL-Hochverfügbarkeitscluster mit speicherbasiertem Fencing (fence_sbd) einen softwareemulierten Watchdog. Es ist wichtig, Durch Software emulierter Watchdog: Bekannte Einschränkungen und Unterstützungsrichtlinien für RHEL High Availability-Cluster – sbd und fence_sbd zu lesen, wenn Sie SBD als Fencingmechanismus auswählen.

Verwenden Sie ein SBD-Gerät

Hinweis

Der Fencingmechanismus mit SBD wird unter RHEL 8.8 und höher sowie RHEL 9.0 und höher unterstützt.

Sie können das SBD-Gerät mit einer der beiden folgenden Optionen konfigurieren:

SBD mit einem iSCSI-Zielserver

Das SBD-Gerät erfordert mindestens eine zusätzliche virtuelle Maschine (VM), die als iSCSI-Zielserver (Internet Small Computer System Interface) fungiert und ein SBD-Gerät bereitstellt. Diese iSCSI-Zielserver können jedoch für andere Pacemaker-Cluster freigegeben werden. Die Verwendung eines SBD-Geräts hat den Vorteil, dass bei lokaler Verwendung von SBD-Geräten keine Änderungen am Betrieb des Pacemaker-Clusters erforderlich sind.

Sie können für einen Pacemaker-Cluster bis zu drei SBD-Geräte verwenden, um ein SBD-Gerät verfügbar zu machen, z. B. während des Betriebssystempatchings des iSCSI-Zielservers. Wenn Sie pro Pacemaker mehr als ein SBD-Gerät verwenden möchten, müssen Sie sicherstellen, dass mehrere iSCSI-Zielserver bereitgestellt werden und von jedem eine Verbindung mit einem SBD-Gerät hergestellt wird. Es wird empfohlen, entweder ein SBD-Gerät oder drei SBD-Geräte zu verwenden. Pacemaker kann einen Clusterknoten nicht automatisch umgrenzen, wenn nur zwei SBD-Geräte konfiguriert sind und eines davon nicht verfügbar ist. Wenn Sie in der Lage sein möchten, einen Clusterknoten bei einem inaktiven iSCSI-Zielserver zu umgrenzen, müssen Sie drei SBD-Geräte und folglich drei iSCSI-Zielserver verwenden. Das ist die resilienteste Konfiguration, wenn Sie SBDs verwenden.

Wichtig

Wenn Sie Linux-Pacemaker-Clusterknoten und SBD-Geräte bereitstellen und konfigurieren möchten, lassen Sie das Routing zwischen Ihren VMs und den VMs, auf denen die SBD-Geräte gehostet werden, nicht über andere Geräte laufen, wie z. B. ein virtuelles Netzwerkgerät (NVA).

Wartungsereignisse und andere Probleme mit dem NVA können sich negativ auf die Stabilität und Zuverlässigkeit der gesamten Clusterkonfiguration auswirken. Weitere Informationen finden Sie unter Benutzerdefinierte Routingregeln.
SBD mit Azure freigegebenem Datenträger

Um ein SBD-Gerät zu konfigurieren, müssen Sie mindestens einen Azure gemeinsam genutzten Datenträger an alle virtuellen Computer anfügen, die Teil des Pacemaker-Clusters sind. Der Vorteil des SBD-Geräts mithilfe eines Azure gemeinsam genutzten Datenträgers besteht darin, dass Sie keine zusätzlichen virtuellen Computer bereitstellen und konfigurieren müssen.

Im Folgenden finden Sie einige wichtige Überlegungen zu SBD-Geräten bei der Konfiguration mit Azure Shared Disk:
- Ein Azure gemeinsam genutzter Datenträger mit Premium SSD wird als SBD-Gerät unterstützt.
- SBD-Geräte, die einen Azure freigegebenen Datenträger verwenden, werden auf RHEL 8.8 und höher unterstützt.
- SBD-Geräte, die einen Azure Premium-Freigabedisk verwenden, werden auf lokal redundanten Speicher (LRS) und zonenredundanten Speicher (ZRS) unterstützt.
- Wählen Sie abhängig vom typ Ihrer Bereitstellung den geeigneten redundanten Speicher für einen Azure freigegebenen Datenträger als SBD-Gerät aus.
- Ein SBD-Gerät, das LRS für einen Azure Premium Shared Disk (skuName - Premium_LRS) verwendet, wird nur mit einer regionalen Bereitstellung wie einem Verfügbarkeitssatz unterstützt.
- Ein SBD-Gerät, das ZRS für einen Azure Premium-Freigegebenen Datenträger (skuName - Premium_ZRS) verwendet, wird zusammen mit einer zonalen Bereitstellung wie der Verwendung von Verfügbarkeitszonen oder einem Skalierungssatz mit FD=1 empfohlen.
- Ein ZRS für verwaltete Datenträger ist derzeit in den Regionen verfügbar, die im Dokument Regionale Verfügbarkeit aufgeführt sind.
- Der Azure freigegebene Datenträger, den Sie für SBD-Geräte verwenden, muss nicht groß sein. Der Wert maxShares bestimmt, von wie vielen Clusterknoten der freigegebene Datenträger verwendet werden kann. Sie können z. B. P1- oder P2-Datenträgergrößen für Ihr SBD-Gerät in einem Zwei-Knoten-Cluster wie SAP ASCS/ERS oder SAP HANA Scale-up verwenden.
- Für HANA-Skalierungslösung mit HANA-Systemreplikation (HSR) und Pacemaker können Sie einen gemeinsam genutzten Azure-Datenträger für SBD-Geräte in Clustern mit bis zu fünf Knoten pro Replikationsstandort gestützt auf den aktuellen Grenzwert von maxShares verwenden.
- Es wird nicht empfohlen, ein Azure Shared Disk SBD-Gerät in Pacemaker-Clustern zu verwenden.
- Wenn Sie mehrere freigegebene Azure-Datenträger-SBD-Geräte verwenden, überprüfen Sie den Grenzwert für die maximale Anzahl von Datenträgern, die an eine virtuelle Maschine angefügt werden können.
- Weitere Informationen zu Einschränkungen für Azure freigegebene Datenträger erhalten Sie, indem Sie den Abschnitt "Einschränkungen" in der Azure-Dokumentation zu freigegebenen Datenträgern sorgfältig überprüfen.

Azure-Fence-Agent verwenden

Sie können Fencing mithilfe eines Azure Zaun-Agenten einrichten. Azure-Fence-Agent erfordert verwaltete Identitäten für die Cluster-VMs oder einen Dienstprinzipal oder eine verwaltete Systemidentität (MSI), die den Neustart fehlgeschlagener Knoten über Azure-APIs ermöglicht. Azure Zaun-Agent erfordert nicht die Bereitstellung zusätzlicher virtueller Computer.

SBD mit einem iSCSI-Zielserver

Befolgen Sie die Anweisungen in den nächsten Abschnitten, um ein SBD-Gerät zu verwenden, das einen iSCSI-Zielserver für Fencing verwendet.

Einrichten des iSCSI-Zielservers

Sie müssen zunächst die virtuellen Computer für das iSCSI-Ziel erstellen. Sie können iSCSI-Zielserver für mehrere Pacemaker-Cluster freigeben.

Stellen Sie virtuelle Computer bereit, die auf der unterstützten RHEL-Betriebssystemversion ausgeführt werden, und stellen Sie eine Verbindung über SSH her. Die virtuellen Computer müssen nicht groß sein. VM-Größen wie Standard_E2s_v3 oder Standard_D2s_v3 sind ausreichend. Stellen Sie sicher, dass Sie für den Betriebssystemdatenträger Storage Premium verwenden.
Es ist nicht erforderlich, RHEL für SAP mit Hochverfügbarkeit und Update Services oder RHEL für ein Betriebssystemimage für SAP-Apps für den iSCSI-Zielserver zu verwenden. Stattdessen kann ein RHEL-Standard-Betriebssystemimage verwendet werden. Der Unterstützungslebenszyklus variiert jedoch zwischen verschiedenen Betriebssystem-Produktversionen.
Führen Sie auf allen virtuellen iSCSI-Zielcomputern folgende Befehle aus.
1. Aktualisieren Sie RHEL.
```
sudo yum -y update
```
  Hinweis
  
  Möglicherweise müssen Sie den Knoten nach einem Update oder Upgrade des Betriebssystems neu starten.
2. Installieren Sie das iSCSI-Zielpaket.
```
sudo yum install targetcli
```
3. Starten und Konfigurieren des Ziels für den Beginn am Startzeitpunkt.
```
sudo systemctl start target
sudo systemctl enable target
```
4. Öffnen von Port 3260 in der Firewall
```
sudo firewall-cmd --add-port=3260/tcp --permanent
sudo firewall-cmd --add-port=3260/tcp
```

Erstellen Sie ein iSCSI-Gerät auf dem iSCSI-Zielserver

Führen Sie zum Erstellen der iSCSI-Datenträger für Ihre SAP-Systemcluster die folgenden Befehle auf jedem virtuellen iSCSI-Zielcomputer aus. Das Beispiel veranschaulicht die Erstellung von SBD-Geräten für mehrere Cluster mit einem einzelnen iSCSI-Zielservers für mehrere Cluster. Das SBD-Gerät ist auf dem Betriebssystemdatenträger konfiguriert. Stellen Sie daher sicher, dass genügend Speicherplatz vorhanden ist.

ascsnw1: stellt den ASCS/ERS-Cluster von NW1 dar
dbhn1: stellt den Datenbankcluster von HN1 dar
sap-cl1 und sap-cl2: Hostnamen der NW1 ASCS/ERS-Clusterknoten
hn1-db-0 und hn1-db-1: Hostnamen der Datenbankclusterknoten

Ändern Sie in den folgenden Anweisungen den Befehl bei Bedarf mit Ihren spezifischen Hostnamen und SIDs.

Erstellen Sie den Stammordner für alle SBD-Geräte.
```
sudo mkdir /sbd
```

Erstellen Sie das SBD-Gerät für die ASCS/ERS-Server des Systems NW1.

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.sap-cl1.local:sap-cl1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.sap-cl2.local:sap-cl2

Erstellen Sie das SBD-Gerät für den Datenbankcluster des Systems HN1.

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

Speichern Sie die targetcli-Konfiguration.
```
sudo targetcli saveconfig
```

Überprüfen Sie, ob alles korrekt eingerichtet wurde.

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- sbddbhn1 ................................................................... [/sbd/sbddbhn1 (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.dbhn1.local:dbhn1 ..................................................................................... [TPGs: 1]
  | | o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
  | |   o- acls .......................................................................................................... [ACLs: 2]
  | |   | o- iqn.2006-04.hn1-db-0.local:hn1-db-0 .................................................................. [Mapped LUNs: 1]
  | |   | | o- mapped_lun0 ............................................................................... [lun0 fileio/sbdhdb (rw)]
  | |   | o- iqn.2006-04.hn1-db-1.local:hn1-db-1 .................................................................. [Mapped LUNs: 1]
  | |   |   o- mapped_lun0 ............................................................................... [lun0 fileio/sbdhdb (rw)]
  | |   o- luns .......................................................................................................... [LUNs: 1]
  | |   | o- lun0 ............................................................. [fileio/sbddbhn1 (/sbd/sbddbhn1) (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/sbdascsers (rw)]
  |     | o- iqn.2006-04.sap-cl2.local:sap-cl2 .................................................................... [Mapped LUNs: 1]
  |     |   o- mapped_lun0 ........................................................................... [lun0 fileio/sbdascsers (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]

Richten Sie das SBD-Gerät mit iSCSI-Zielserver ein

[A]: Gilt für alle Knoten. [1]: Gilt nur für Knoten 1. [2]: Gilt nur für Knoten 2.

Verbinden Sie auf den Clusterknoten das iSCSI-Gerät, das im vorherigen Abschnitt erstellt wurde, und ermitteln Sie es. Führen Sie die folgenden Befehle für die zu erstellenden Knoten des neuen Clusters aus.

[A] Installieren oder Aktualisieren Sie iSCSI-Initiatoren auf allen Clusterknoten.
```
sudo yum install -y iscsi-initiator-utils
```
[A] Installieren Sie Cluster- und SBD-Pakete auf allen Clusterknoten.
```
sudo yum install -y pcs pacemaker sbd fence-agents-sbd
```
[A] Aktivieren Sie den iSCSI-Dienst.
```
sudo systemctl enable iscsid iscsi
```

[1] Ändern Sie den Initiatornamen auf dem ersten Knoten des Clusters.

sudo vi /etc/iscsi/initiatorname.iscsi

# Change the content of the file to match the access control ists (ACLs) you used when you created the iSCSI device on the iSCSI target server (for example, for the ASCS/ERS servers)
InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1

[2] Ändern Sie den Initiatornamen auf dem zweiten Knoten des Clusters.

sudo vi /etc/iscsi/initiatorname.iscsi

# Change the content of the file to match the access control ists (ACLs) you used when you created the iSCSI device on the iSCSI target server (for example, for the ASCS/ERS servers)
InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2

[A] Starten Sie den iSCSI-Dienst neu, um die Änderung zu übernehmen.
```
sudo systemctl restart iscsid 
sudo systemctl restart iscsi
```

[A] Stellen Sie eine Verbindung mit den iSCSI-Geräten her. Im folgenden Beispiel ist 10.0.0.17 die IP-Adresse des iSCSI-Zielservers und 3260 der Standardport. Der Zielname iqn.2006-04.ascsnw1.local:ascsnw1 wird beim Ausführen des ersten Befehls iscsiadm -m discovery aufgelistet.

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

[A] Wenn Sie mehrere SBD-Geräte verwenden, stellen Sie auch eine Verbindung mit dem zweiten iSCSI-Zielserver her.

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

[A] Wenn Sie mehrere SBD-Geräte verwenden, stellen Sie auch eine Verbindung mit dem dritten iSCSI-Zielserver her.

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

[A] Stellen Sie sicher, dass die iSCSI-Geräte verfügbar sind, und notieren Sie sich den Gerätenamen. Im folgenden Beispiel werden drei iSCSI-Geräte ermittelt, indem der Knoten mit drei iSCSI-Zielservern verbunden wird.

lsscsi

[0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sde
[1:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[1:0:0:2]    disk    Msft     Virtual Disk     1.0   /dev/sdc
[1:0:0:3]    disk    Msft     Virtual Disk     1.0   /dev/sdd
[2:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdf
[3:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdh
[4:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdg

[A] Rufen Sie die IDs der iSCSI-Geräte ab.

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

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:85d254ed-78e2-4ec4-8b0d-ecac2843e086 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_85d254ed-78e2-4ec4-8b0d-ecac2843e086 -> ../../sdf

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

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:87122bfc-8a0b-4006-b538-d0a6d6821f04 -> ../../sdh
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d -> ../../sdh
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_87122bfc-8a0b-4006-b538-d0a6d6821f04 -> ../../sdh

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

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:d2ddc548-060c-49e7-bb79-2bb653f0f34a -> ../../sdg
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65 -> ../../sdg
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_d2ddc548-060c-49e7-bb79-2bb653f0f34a -> ../../sdg

Mit dem Befehl werden für jedes SBD-Gerät drei Geräte-IDs aufgelistet. Es wird empfohlen, die ID zu verwenden, die mit scsi-3 beginnt. Im vorherigen Beispiel lauten die IDs:

/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2
/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d
/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65

[1] Erstellen Sie das SBD-Gerät.

Verwenden Sie die Geräte-ID der iSCSI-Geräte, um die neuen SBD-Geräte auf dem ersten Clusterknoten zu erstellen.
```
sudo sbd -d /dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2 -1 60 -4 120 create
```

Erstellen Sie auch das zweite und dritte SBD-Gerät, wenn Sie mehr als eins verwenden möchten.

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

[A] Passen Sie die SDB-Konfiguration an.

Öffnen Sie die SBD-Konfigurationsdatei.
```
sudo vi /etc/sysconfig/sbd
```

Ändern Sie die Eigenschaft des SBD-Geräts, aktivieren Sie die Pacemaker-Integration, und ändern Sie den Startmodus von SBD.

[...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2;/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d;/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65"
[...]
SBD_PACEMAKER=yes
[...]
SBD_STARTMODE=always
[...]
# # In some cases, a longer delay than the default "msgwait" seconds is needed. So, set a specific delay value, in seconds. See, `man sbd` for more information. 
SBD_DELAY_START=186
[...]

[A] Führen Sie den folgenden Befehl aus, um das Modul softdog zu laden.
```
modprobe softdog
```
[A] Führen Sie den folgenden Befehl aus, um sicherzustellen, dass softdog nach einem Knotenneustart automatisch geladen wird.
```
echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load
```
[A] Wenn SBD_DELAY_START auf einen Wert festgelegt wird, verzögert sich der Start des SBD-Diensts beim Systemstart. Wenn das systemd TimeoutSec des SBD-Dienstes auf seinem Standardwert (90 Sekunden) bleibt, kann es vorkommen, dass der Dienst vor dem Start in den Timeout geht. Daher muss TimeoutSec auf einen Wert erhöht werden, der größer als SBD_DELAY_START ist.
```
sudo mkdir /etc/systemd/system/sbd.service.d
echo -e "[Service]\nTimeoutSec=223" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
sudo systemctl daemon-reload

systemctl show sbd | grep -i timeout
# TimeoutStartUSec=3min 43s
# TimeoutStopUSec=3min 43s
# TimeoutAbortUSec=3min 43s
```

SBD mit einem freigegebenen Azure Datenträger

Dieser Abschnitt gilt nur, wenn Sie ein SBD-Gerät mit einem Azure gemeinsam genutzten Datenträger verwenden möchten.

Konfigurieren Sie einen freigegebenen Azure-Datenträger mit PowerShell

Führen Sie die folgende Anweisung aus, um einen Azure freigegebenen Datenträger mit PowerShell zu erstellen und anzufügen. Wenn Sie Ressourcen mithilfe des Azure CLI oder des Azure Portals bereitstellen möchten, können Sie auch auf Deploy a ZRS disk verweisen.

$ResourceGroup = "MyResourceGroup"
$Location = "MyAzureRegion"
$DiskSizeInGB = 4
$DiskName = "SBD-disk1"
$ShareNodes = 2
$LRSSkuName = "Premium_LRS"
$ZRSSkuName = "Premium_ZRS"  
$vmNames = @("prod-cl1-0", "prod-cl1-1")  # VMs to attach the disk

# ZRS Azure shared disk: Configure an Azure shared disk with ZRS for a premium shared disk
$zrsDiskConfig = New-AzDiskConfig -Location $Location -SkuName $ZRSSkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$zrsDataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $zrsDiskConfig

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

# LRS Azure shared disk: Configure an Azure shared disk with LRS for a premium shared disk
$lrsDiskConfig = New-AzDiskConfig -Location $Location -SkuName $LRSSkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$lrsDataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $lrsDiskConfig

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

Einrichten eines Azure-SBD-Geräts für ein freigegebenes Speicherlaufwerk

[A] Installieren Sie Cluster- und SBD-Pakete auf allen Clusterknoten.
```
sudo yum install -y pcs pacemaker sbd fence-agents-sbd
```

[A] Vergewissern Sie sich, dass der angefügte Datenträger verfügbar ist.

lsblk

# NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
# sda                 8:0    0    4G  0 disk
# sdb                 8:16   0   64G  0 disk
# ├─sdb1              8:17   0  500M  0 part /boot
# ├─sdb2              8:18   0   63G  0 part
# │ ├─rootvg-tmplv  253:0    0    2G  0 lvm  /tmp
# │ ├─rootvg-usrlv  253:1    0   10G  0 lvm  /usr
# │ ├─rootvg-homelv 253:2    0    1G  0 lvm  /home
# │ ├─rootvg-varlv  253:3    0    8G  0 lvm  /var
# │ └─rootvg-rootlv 253:4    0    2G  0 lvm  /
# ├─sdb14             8:30   0    4M  0 part
# └─sdb15             8:31   0  495M  0 part /boot/efi
# sr0                11:0    1 1024M  0 rom

lsscsi

# [0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
# [0:0:0:2]    cd/dvd  Msft     Virtual DVD-ROM  1.0   /dev/sr0
# [1:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
# [1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdc

[A] Rufen Sie die Geräte-ID des angefügten freigegebenen Datenträgers ab.
```
ls -l /dev/disk/by-id/scsi-* | grep -i sda

# lrwxrwxrwx 1 root root  9 Jul 15 22:24 /dev/disk/by-id/scsi-14d534654202020200792c2f5cc7ef14b8a7355cb3cef0107 -> ../../sda
# lrwxrwxrwx 1 root root  9 Jul 15 22:24 /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107 -> ../../sda
```
Dies ist die Geräte-ID in der Befehlsliste für den angefügten freigegebenen Datenträger. Es wird empfohlen, die ID zu verwenden, die mit scsi-3 beginnt. In diesem Beispiel lautet die ID /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107.

[1] Erstellen Sie das SBD-Gerät.

# Use the device ID from step 3 to create the new SBD device on the first cluster node
sudo sbd -d /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107 -1 60 -4 120 create

[A] Passen Sie die SDB-Konfiguration an.

Öffnen Sie die SBD-Konfigurationsdatei.
```
sudo vi /etc/sysconfig/sbd
```

Ändern Sie die Eigenschaft des SBD-Geräts, aktivieren Sie die Pacemaker-Integration, ändern Sie den Startmodus von SBD und passen Sie den Wert SBD_DELAY_START an.

[...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107"
[...]
SBD_PACEMAKER=yes
[...]
SBD_STARTMODE=always
[...]
# In some cases, a longer delay than the default "msgwait" seconds is needed. So, set a specific delay value, in seconds. See, `man sbd` for more information. 
SBD_DELAY_START=186
[...]

[A] Führen Sie den folgenden Befehl aus, um das Modul softdog zu laden.
```
modprobe softdog
```
[A] Führen Sie den folgenden Befehl aus, um sicherzustellen, dass softdog nach einem Knotenneustart automatisch geladen wird.
```
echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load
```
[A] Wenn SBD_DELAY_START auf einen Wert festgelegt wird, verzögert sich der Start des SBD-Diensts beim Systemstart. Wenn das systemd TimeoutSec des SBD-Dienstes auf seinem Standardwert (90 Sekunden) bleibt, kann es vorkommen, dass der Dienst vor dem Start in den Timeout geht. Daher muss TimeoutSec auf einen Wert erhöht werden, der größer als SBD_DELAY_START ist.
```
sudo mkdir /etc/systemd/system/sbd.service.d
echo -e "[Service]\nTimeoutSec=223" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
sudo systemctl daemon-reload

systemctl show sbd | grep -i timeout
# TimeoutStartUSec=3min 43s
# TimeoutStopUSec=3min 43s
# TimeoutAbortUSec=3min 43s
```

Konfiguration des Azure Fence Agents

Das Fencing-Gerät verwendet entweder eine verwaltete Identität für Azure-Ressourcen oder einen Dienstprinzipal, um sich gegenüber Azure zu autorisieren. Je nach Identitätsverwaltungsmethode folgen Sie den entsprechenden Verfahren:

Konfigurieren der Identitätsverwaltung

Verwenden Sie eine verwaltete Identität oder einen Dienstprinzipal.
- Verwaltete Identität
- Dienstprinzipal
Zum Erstellen einer verwalteten Identität (MSI) erstellen Sie eine systemseitig zugewiesene verwaltete Identität für jede VM im Cluster. Sollte bereits eine systemseitig zugewiesene verwaltete Identität vorhanden sein, wird diese verwendet. Verwenden Sie vorerst keine benutzerseitig zugewiesenen verwalteten Identitäten mit Pacemaker. Ein Zaungerät basierend auf verwalteter Identität wird auf RHEL 7.9 und RHEL 8.x/RHEL 9.x/RHEL 10.x unterstützt.
Führen Sie die folgenden Schritte aus, um einen Dienstprinzipal zu erstellen, wenn Sie keine verwaltete Identität verwenden.
1. Wechseln Sie zum portal Azure.
2. Öffnen Sie den Bereich Microsoft Entra ID.
3. Navigieren Sie zu Eigenschaften, und notieren Sie sich die Verzeichnis-ID. Dies ist die Mandanten-ID.
4. Wählen Sie App registrations aus.
5. Wählen Sie Neue Registrierung aus.
6. Geben Sie unter Name einen Namen ein, und wählen Sie Nur Konten in diesem Organisationsverzeichnis aus.
7. Wählen Sie unter Anwendungstyp die Option Web aus, geben Sie eine Anmelde-URL ein (beispielsweise http://localhost)), und wählen Sie Hinzufügen aus. Die Anmelde-URL wird nicht verwendet und kann eine beliebige gültige URL sein.
8. Wählen Sie Zertifikate und Geheimnisse und anschließend Neuer geheimer Clientschlüssel aus.
9. Geben Sie eine Beschreibung für einen neuen Schlüssel ein, wählen Sie Zwei Jahre aus, und wählen Sie anschließend Hinzufügen aus.
10. Notieren Sie sich den Wert. Dieser wird als Kennwort für den Dienstprinzipal verwendet.
11. Wählen Sie Übersicht. Notieren Sie sich die Anwendungs-ID. Er wird als Benutzername des Dienstprinzipals (Anmelde-ID in den folgenden Schritten) verwendet.
Erstellen einer benutzerdefinierten Rolle für den Fence-Agent

Sowohl die verwaltete Identität als auch der Dienstprinzipal verfügen nicht über berechtigungen, um standardmäßig auf Ihre Azure Ressourcen zuzugreifen. Sie müssen der verwalteten Identität oder dem Dienstprinzipal Berechtigungen zum Starten und Beenden (Ausschalten) aller VMs im Cluster erteilen. Wenn Sie die benutzerdefinierte Rolle noch nicht erstellt haben, können Sie sie mit PowerShell oder dem Azure CLI erstellen.

Verwenden Sie folgenden Inhalt für die Eingabedatei. Sie müssen den Inhalt an Ihre Abonnements anpassen. Ersetzen Sie also xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx und yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy durch die IDs Ihres Abonnements. Wenn Sie nur über ein einzelnes Abonnement verfügen, entfernen Sie den zweiten Eintrag in 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": []
}
```
Zuweisen der benutzerdefinierten Rolle

Verwenden Sie eine verwaltete Identität oder einen Dienstprinzipal.
- Verwaltete Identität
- Dienstprinzipal
Weisen Sie die benutzerdefinierte Rolle Linux Fence Agent Role, die im letzten Abschnitt erstellt wurde, jeder verwalteten Identität der Cluster-VMs zu. Jeder systemseitig zugewiesenen verwalteten Identität muss die Rolle für jede Cluster-VM-Ressource zugewiesen werden. Weitere Informationen finden Sie unter Weisen Sie einer verwalteten Identität Zugriffsrechte auf eine Ressource zu, indem Sie das Azure-Portal verwenden. Vergewissern Sie sich, dass die Rollenzuweisung der verwalteten Identitäten der einzelnen VMs alle Cluster-VMs enthält.

Wichtig

Beachten Sie, dass sich die Zuweisung und Aufhebung der Autorisierung mit verwalteten Identitäten bis zum Inkrafttreten verzögern kann.

Weisen Sie die benutzerdefinierte Rolle Linux Fence Agent Role, die im letzten Abschnitt erstellt wurde, dem Dienstprinzipal zu. Verwenden Sie nicht mehr die Besitzerrolle. Weitere Informationen finden Sie unter Zuweisen von Azure-Rollen über das Azure-Portal.

Stellen Sie sicher, dass Sie die Rolle beiden Clusterknoten zuweisen.

Clusterinstallation

Befehls- oder Konfigurationsunterschiede zwischen RHEL 7 und RHEL 8 bzw. RHEL 9 sind im Dokument markiert.

[A] Installieren Sie das RHEL-Hochverfügbarkeits-Add-On.
```
sudo yum install -y pcs pacemaker nmap-ncat
```
[A] Installieren Sie unter RHEL 9.x die Ressourcen-Agents für die Cloudbereitstellung.
```
sudo yum install -y resource-agents-cloud
```
[A] Installieren Sie das Zaun-Agents-Paket, wenn Sie ein Fencing-Gerät basierend auf Azure Zaun-Agent verwenden.
```
sudo yum install -y fence-agents-azure-arm 
```
Wichtig

Wir empfehlen die folgenden Versionen des Azure Zaun-Agents (oder höher) für Kunden, die verwaltete Identitäten für Azure Ressourcen anstelle von Dienstprinzipalnamen für den Zaun-Agent verwenden möchten:
- RHEL 8.4: fence-agents-4.2.1-54.el8.
- RHEL 8.2: fence-agents-4.2.1-41.el8_2.4
- RHEL 8.1: fence-agents-4.2.1-30.el8_1.4
- RHEL 7.9: fence-agents-4.2.1-41.el7_9.4.
Wichtig

Auf RHEL 9 empfehlen wir die folgenden Paketversionen (oder höher), um Probleme mit dem Azure Zaun-Agent zu vermeiden:
- fence-agents-4.10.0-20.el9_0.7
- fence-agents-common-4.10.0-20.el9_0.6
- ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm
Überprüfen Sie die Version des Azure Zaunagenten. Führen Sie bei Bedarf eine Aktualisierung auf die erforderliche Mindestversion oder auf eine höhere Version durch.
```
# Check the version of the Azure Fence Agent
sudo yum info fence-agents-azure-arm
```
Wichtig

Wenn Sie den Azure Zaun-Agent aktualisieren müssen und wenn Sie eine benutzerdefinierte Rolle verwenden, müssen Sie die benutzerdefinierte Rolle aktualisieren, um die Aktion powerOff einzuschließen. Weitere Informationen finden Sie unter Erstellen einer benutzerdefinierten Rolle für den Fence-Agent.
[A] Einrichten der Auflösung des Hostnamens.

Sie können entweder einen DNS-Server verwenden oder die Datei /etc/hosts auf allen Knoten ändern. In diesem Beispiel wird die Verwendung der Datei /etc/hosts gezeigt. Ersetzen Sie die IP-Adresse und den Hostnamen in den folgenden Befehlen.

Wichtig

Wenn Sie Hostnamen in der Clusterkonfiguration verwenden, ist eine zuverlässige Hostnamenauflösung unerlässlich. Die Clusterkommunikation ist nicht erfolgreich, wenn die Namen nicht verfügbar sind. Dies kann zu Verzögerungen bei Clusterfailovern führen.

Durch die Verwendung von /etc/hosts wird Ihr Cluster vom DNS (einem weiteren möglichen Single Point of Failure) unabhängig.
```
sudo vi /etc/hosts
```
Fügen Sie in /etc/hosts die folgenden Zeilen ein. Ändern Sie die IP-Adresse und den Hostnamen Ihrer Umgebung entsprechend.
```
# 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
```
[A] Ändern Sie das hacluster-Kennwort in das gleiche Kennwort.
```
sudo passwd hacluster
```
[A] Fügen Sie Firewallregeln für Pacemaker hinzu.

Fügen Sie jeglicher Clusterkommunikation zwischen den Clusterknoten die folgenden Firewallregeln hinzu.
```
sudo firewall-cmd --add-service=high-availability --permanent
sudo firewall-cmd --add-service=high-availability
```
[A] Aktivieren Sie grundlegende Clusterdienste.

Führen Sie die folgenden Befehle aus, um den Pacemaker-Dienst zu aktivieren und zu starten.
```
sudo systemctl start pcsd.service
sudo systemctl enable pcsd.service
```

[1] Erstellen Sie einen Pacemaker-Cluster.

Führen Sie die folgenden Befehle aus, um die Knoten zu authentifizieren und den Cluster zu erstellen. Legen Sie das Token auf „30.000“ fest, um die Wartung mit Speicherbeibehaltung zu ermöglichen. Weitere Informationen finden Sie in diesem Artikel für Linux.

Wenn Sie einen Cluster auf RHEL 7.x aufbauen, verwenden Sie die folgenden Befehle:

sudo pcs cluster auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup --name nw1-azr prod-cl1-0 prod-cl1-1 --token 30000
sudo pcs cluster start --all

Wenn Sie einen Cluster auf RHEL 8.x/RHEL 9.x/RHEL 10.x erstellen, verwenden Sie die folgenden Befehle:

sudo pcs host auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup nw1-azr prod-cl1-0 prod-cl1-1 totem token=30000
sudo pcs cluster start --all

Überprüfen Sie den Clusterstatus, indem Sie den folgenden Befehl ausführen:

# Run the following command until the status of both nodes is online
sudo pcs status

# Cluster name: nw1-azr
# WARNING: no stonith devices and stonith-enabled is not false
# Stack: corosync
# Current DC: prod-cl1-1 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
# Last updated: Fri Aug 17 09:18:24 2018
# Last change: Fri Aug 17 09:17:46 2018 by hacluster via crmd on prod-cl1-1
#
# 2 nodes configured
# 0 resources configured
#
# Online: [ prod-cl1-0 prod-cl1-1 ]
#
# No resources
#
# Daemon Status:
#   corosync: active/disabled
#   pacemaker: active/disabled
#   pcsd: active/enabled

[A] Legen Sie die erwarteten Stimmen fest.
```
# Check the quorum votes 
pcs quorum status

# If the quorum votes are not set to 2, execute the next command
sudo pcs quorum expected-votes 2
```
Tipp

Wenn Sie einen Cluster mit mehreren Knoten (also einen Cluster mit mehr als zwei Knoten) erstellen, legen Sie die Stimmen nicht auf „2“ fest.

[1] Lassen Sie gleichzeitige Fence-Aktionen zu.

sudo pcs property set concurrent-fencing=true

Erstellen eines Fencinggeräts im Pacemaker-Cluster

Tipp

Um Fence Races innerhalb eines Pacemaker-Clusters mit zwei Knoten zu vermeiden, können Sie die Clustereigenschaft priority-fencing-delay konfigurieren. Diese Eigenschaft führt zu einer zusätzlichen Verzögerung beim Einfassen eines Knotens mit einer höheren Gesamtressourcenpriorität, wenn ein Split-Brain-Szenario auftritt. Weitere Informationen finden Sie unter "Kann Pacemaker den Clusterknoten mit den wenigsten laufenden Ressourcen isolieren?"
Die Eigenschaft priority-fencing-delay gilt ab der Pacemaker-Version 2.0.4-6.el8 und in einem Cluster mit zwei Knoten. Wenn Sie die Clustereigenschaft priority-fencing-delay konfigurieren, müssen Sie die Eigenschaft pcmk_delay_max nicht festlegen. Wenn die Pacemaker-Version allerdings niedriger als 2.0.4-6.el8 ist, muss die Eigenschaft pcmk_delay_max festgelegt werden.
Anweisungen zum Festlegen der priority-fencing-delay Clustereigenschaft finden Sie in den entsprechenden SAP ASCS/ERS- und SAP HANA Ha-Skalierungsdokumenten.

Befolgen Sie basierend auf dem ausgewählten Fencing-Mechanismus nur einen Abschnitt für relevante Anweisungen: SBD als Fencing-Gerät oder Azure-Fence-Agent als Fencing-Gerät.

SBD als Fencinggerät

[A] Aktivieren Sie den SBD-Dienst.
```
sudo systemctl enable sbd
```

[1] Führen Sie die folgenden Befehle aus, um das SBD-Gerät mithilfe von iSCSI-Zielservern oder Azure Shared Disk zu konfigurieren.

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

# Replace the device IDs with your device ID. 
pcs stonith create sbd fence_sbd \
devices=/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2,/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d,/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65 \
op monitor interval=600 timeout=15

[1] Starten Sie den Cluster neu.
```
sudo pcs cluster stop --all

# It would take time to start the cluster as "SBD_DELAY_START" is set to "yes"
sudo pcs cluster start --all
```
Hinweis

Wenn beim Starten des Pacemaker-Clusters folgender Fehler auftritt, können Sie die Meldung ignorieren. Alternativ können Sie den Cluster mit dem Befehl pcs cluster start --all --request-timeout 140 starten.

Fehler: Alle Knoten node1/node2 können nicht gestartet werden: Es kann keine Verbindung mit node1/node2 hergestellt werden, überprüfen Sie, ob pcsd dort ausgeführt wird, oder versuchen Sie, ein höheres Timeout mit --request-timeout-Option festzulegen (Timeout nach 60.000 Millisekunden mit 0 empfangenen Bytes)

Azure Zaun-Agent als Fencinggerät

[1] Nachdem Sie beiden Clusterknoten Rollen zugewiesen haben, können Sie die Fencinggeräte im Cluster konfigurieren.
```
sudo pcs property set stonith-timeout=900
sudo pcs property set stonith-enabled=true
```

[1] Führen Sie den entsprechenden Befehl aus, je nachdem, ob Sie eine verwaltete Identität oder einen Dienstprinzipal für den Azure Zaun-Agent verwenden.

Hinweis

Wenn Sie Azure Government Cloud verwenden, müssen Sie beim Konfigurieren des Zaun-Agents cloud= Option angeben. Beispiel: cloud=usgov für die Azure Government Cloud der US-Regierung. Ausführliche Informationen zur RedHat-Unterstützung für Azure Government Cloud finden Sie unter Support Policies for RHEL High Availability Clusters – Microsoft Azure Virtual Machines as Cluster Members.

Tipp

Die Option pcmk_host_map ist nur erforderlich, wenn die RHEL-Hostnamen und die Azure-VM-Namen nicht identisch sind. Geben Sie die Zuordnung im Format hostname:vm-name an. Weitere Informationen finden Sie unter Welches Format soll ich verwenden, um Knotenzuordnungen für Fencing-Geräte in pcmk_host_map anzugeben?

Verwaltete Identität
Dienstprinzipal

Verwenden Sie für RHEL 7.xden folgenden Befehl, um das Fencinggerät zu konfigurieren:

sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \ 
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
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

Verwenden Sie für RHEL 8.x/9.x/10.x den folgenden Befehl, um das Zaungerät zu konfigurieren:

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
meta failure-timeout=120s \
op monitor interval=3600

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
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

Verwenden Sie für RHEL 7.xden folgenden Befehl, um das Fencinggerät zu konfigurieren:

sudo pcs stonith create rsc_st_azure fence_azure_arm login="login ID" passwd="password" \
resourceGroup="resource group" tenantId="tenant ID" subscriptionId="subscription id" \
pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
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

Verwenden Sie für RHEL 8.x/9.x/10.x den folgenden Befehl, um das Zaungerät zu konfigurieren:

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm username="login ID" password="password" \
resourceGroup="resource group" tenantId="tenant ID" subscriptionId="subscription id" \
pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
meta failure-timeout=120s \
op monitor interval=3600

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm username="login ID" password="password" \
resourceGroup="resource group" tenantId="tenant ID" subscriptionId="subscription id" \
pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
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

Wenn Sie ein Fencing-Gerät auf Basis der Dienstprinzipal-Konfiguration verwenden, lesen Sie Änderung von SPN zu MSI für Pacemaker-Cluster mithilfe von Azure Fencing und erfahren Sie, wie Sie auf die Konfiguration verwalteter Identitäten umstellen.

Die Überwachungs- und Fencingvorgänge sind deserialisiert. Das bedeutet: Wenn ein länger andauernder Überwachungsvorgang und ein gleichzeitiges Fencingereignis vorliegen, kommt es zu keiner Verzögerung beim Clusterfailover, da der Überwachungsvorgang bereits ausgeführt wird.

Tipp

Der Azure Zaun-Agent erfordert ausgehende Verbindungen mit öffentlichen Endpunkten. Weitere Informationen sowie mögliche Lösungen finden Sie unter Konnektivität öffentlicher Endpunkte für VMs, die Azure Load Balancer Standard in SAP-Hochverfügbarkeitsszenarien verwenden.

Konfigurieren von Pacemaker für geplante Azure-Ereignisse

Azure bietet scheduled events. Geplante Ereignisse werden über den Metadatendienst bereitgestellt und geben der Anwendung Zeit, sich auf solche Ereignisse vorzubereiten.

Ressourcen-Agent azure-events-az überwacht geplante Azure Ereignisse. Wenn Ereignisse erkannt werden und der Ressourcen-Agent feststellt, dass ein anderer Clusterknoten verfügbar ist, wird das Integritätsattribut #health-azure auf Knotenebene auf -1000000 festgelegt.

Wenn dieses spezielle Clusterintegritätsattribut für einen Knoten festgelegt wird, wird der Knoten vom Cluster als fehlerhaft eingestuft, und alle Ressourcen werden vom betroffenen Knoten migriert. Die Standorteinschränkung stellt sicher, dass Ressourcen mit einem Namen, der mit „health-“ beginnt, ausgeschlossen werden, da der Agent in diesem fehlerhaften Zustand ausgeführt werden muss. Sobald der betroffene Clusterknoten frei von ausgeführten Clusterressourcen ist, kann das geplante Ereignis seine Aktion ausführen, z. B. neustarten, ohne dass Ressourcen ausgeführt werden müssen.

Das #heath-azure-Attribut wird beim Start des Pacemakers auf 0 zurückgesetzt, nachdem alle Ereignisse verarbeitet wurden, wodurch der Knoten wieder als fehlerfrei markiert wird.

[A] Stellen Sie sicher, dass das Paket für den azure-events-az-Agent bereits installiert und auf dem neuesten Stand ist.
```
RHEL 8.x: sudo dnf info resource-agents
RHEL 9.x: sudo dnf info resource-agents-cloud
```
Mindestversionsanforderungen:
- RHEL 8.4: resource-agents-4.1.1-90.13
- RHEL 8.6: resource-agents-4.9.0-16.9
- RHEL 8.8: resource-agents-4.9.0-40.1
- RHEL 9.0: resource-agents-cloud-4.10.0-9.6
- Ab RHEL 9.2: resource-agents-cloud-4.10.0-34.1

[1] Konfigurieren Sie die Ressourcen in Pacemaker.

#Place the cluster in maintenance mode
sudo pcs property set maintenance-mode=true

[1] Legen Sie die Strategie und Einschränkung für den Pacemaker-Clusterintegritätsknoten fest.

sudo pcs property set node-health-strategy=custom

# For RHEL 8.x/9.x
sudo pcs constraint location 'regexp%!health-.*' \
rule score-attribute='#health-azure' \
defined '#uname'
# For RHEL 10.x
sudo pcs constraint location 'regexp%!health-.*' \
rule score-attribute='#health-azure' \
"defined #uname"

Wichtig

Definieren Sie keine anderen, mit health- beginnenden Ressourcen im Cluster (außer denjenigen, die in den nächsten Schritten beschrieben werden).

[1] Legen Sie den Anfangswert der Clusterattribute fest. Führen Sie diesen Schritt für jeden Clusterknoten und für Umgebungen mit horizontaler Skalierung aus (einschließlich der Majority Maker-VM).
```
sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0
sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0
```

[1] Konfigurieren Sie die Ressourcen in Pacemaker. Achten Sie darauf, dass die Ressourcen mit health-azure beginnen.

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

# For RHEL 8.x/9.x
sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true
# For RHEL 10.x
sudo pcs resource clone health-azure-events meta allow-unhealthy-nodes=true

Beenden Sie den Wartungsmodus für den Pacemaker-Cluster.
```
sudo pcs property set maintenance-mode=false
```
Beseitigen Sie alle Fehler während der Aktivierung, und vergewissern Sie sich, dass die health-azure-events-Ressourcen erfolgreich auf allen Clusterknoten gestartet wurden.
```
sudo pcs resource cleanup
```
Die erste Abfrageausführung für geplante Ereignisse kann bis zu zwei Minuten dauern. Pacemaker-Tests mit geplanten Ereignissen können Aktionen für Neustart oder erneutes Bereitstellen für die Cluster-VMs verwenden. Weitere Informationen finden Sie unter Geplante Ereignisse.

Optionale Fencingkonfiguration

Tipp

Dieser Abschnitt ist nur relevant, wenn Sie das spezielle Fencinggerät fence_kdump konfigurieren möchten.

Wenn Diagnoseinformationen innerhalb der VM gesammelt werden müssen, kann es hilfreich sein, ein weiteres Fencinggerät basierend auf dem Fence-Agent fence_kdump zu konfigurieren. Der fence_kdump-Agent kann erkennen, ob ein Knoten in die kdump-Absturzwiederherstellung eingetreten ist, und den Abschluss des Absturzwiederherstellungsdiensts ermöglichen, bevor andere Fencingmethoden aufgerufen werden. Beachten Sie, dass fence_kdump kein Ersatz für herkömmliche Zaunmechanismen wie sbD oder Azure Zaunagent ist, wenn Sie Azure VMs verwenden.

Wichtig

Wenn fence_kdump als Fencinggerät der ersten Ebene konfiguriert ist, führt dies zu Verzögerungen bei den Fencingvorgängen bzw. zu Verzögerungen beim Failover der Anwendungsressourcen.

Bei erfolgreicher Erkennung eines Absturzabbilds wird das Fencing verzögert, bis der Absturzwiederherstellungsdienst ausgeführt wurde. Wenn der fehlerhafte Knoten nicht erreichbar ist oder nicht antwortet, wird das Fencing auf der Grundlage der ermittelten Zeit, der konfigurierten Anzahl von Iterationen und des fence_kdump-Timeouts verzögert. Weitere Informationen finden Sie unter Wie kann ich fence_kdump in einem Red Hat Pacemaker-Cluster konfigurieren?

Das vorgeschlagene fence_kdump-Timeout muss möglicherweise an die jeweilige Umgebung angepasst werden.

Es wird empfohlen, fence_kdump Fencing nur zu konfigurieren, wenn dies erforderlich ist, um Diagnosen innerhalb der VM zu sammeln und immer in Kombination mit herkömmlichen Zaunmethoden wie SBD oder Azure Zaun-Agent zu verwenden.

Die folgenden Red Hat-KB-Artikel enthalten wichtige Informationen zum Konfigurieren des fence_kdump-Fencings:

Erfahren Sie , wie kann ich fence_kdump in einem Red Hat Pacemaker-Cluster konfigurieren?
Konfigurieren/Verwalten von Fencingebenen im RHEL-Cluster mit Pacemaker
fence_kdump-Fehler „Timeout nach X Sekunden“ in einem RHEL 6- oder RHEL 7-Hochverfügbarkeitscluster mit „kexec-tools“ vor Version 2.0.14
Informationen zum Ändern des Standardtimeouts finden Sie unter Wie kann ich kdump für die Verwendung mit dem RHEL 6, 7, 8 HA-Add-On konfigurieren?
Informationen zum Reduzieren der Failoververzögerung bei der Verwendung von fence_kdump finden Sie unter Kann ich die erwartete Verzögerung des Failovers beim Hinzufügen der fence_kdump-Konfiguration verringern?

Führen Sie die folgenden optionalen Schritte aus, um fence_kdump zusätzlich zur Konfiguration des Azure Fence-Agents als erste Ebene der Zaunkonfiguration hinzuzufügen.

[A] Vergewissern Sie sich, dass kdump aktiv ist und konfiguriert wurde.
```
systemctl is-active kdump
# Expected result
# active
```
[A] Installieren Sie den Fence-Agent fence_kdump.
```
yum install fence-agents-kdump
```

[1] Erstellen Sie ein Fencinggerät vom Typ fence_kdump im Cluster.

pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30

[1] Konfigurieren Sie Fencingebenen so, dass der Fencingmechanismus fence_kdump zuerst aktiviert wird.

pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1"
pcs stonith level add 1 prod-cl1-0 rsc_st_kdump
pcs stonith level add 1 prod-cl1-1 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 prod-cl1-0 <stonith-resource-name>
pcs stonith level add 2 prod-cl1-1 <stonith-resource-name>

# Check the fencing level configuration 
pcs stonith level
# Example output
# Target: prod-cl1-0
# Level 1 - rsc_st_kdump
# Level 2 - <stonith-resource-name>
# Target: prod-cl1-1
# Level 1 - rsc_st_kdump
# Level 2 - <stonith-resource-name>

[A] Lassen Sie die erforderlichen Ports für fence_kdump in der Firewall zu.

firewall-cmd --add-port=7410/udp
firewall-cmd --add-port=7410/udp --permanent

[A] Führen Sie die fence_kdump_nodes-Konfiguration in /etc/kdump.conf durch, um fence_kdump-Timeoutfehler für einige Versionen von kexec-tools zu vermeiden. Weitere Informationen finden Sie unter fence_kdump-Timeout, wenn „fence_kdump_nodes“ nicht mit kexec-tools, Version 2.0.15 oder höher angegeben wird sowie unter fence_kdump-Fehler „Timeout nach X Sekunden“ in einem RHEL 6- oder RHEL 7-Hochverfügbarkeitscluster mit „kexec-tools“ vor Version 2.0.14. Hier wird die Beispielkonfiguration für einen Cluster mit zwei Knoten gezeigt. Nachdem Sie eine Änderung in /etc/kdump.conf vorgenommen haben, muss das kdump-Image neu generiert werden. Starten Sie dazu den kdump-Dienst neu.
```
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] Stellen Sie sicher, dass die initramfs-Imagedatei die Dateien fence_kdump und hosts enthält. Weitere Informationen finden Sie unter Wie kann ich fence_kdump in einem Red Hat Pacemaker-Cluster konfigurieren?

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

Testen Sie die Konfiguration, indem Sie einen Knoten zum Absturz bringen. Weitere Informationen finden Sie unter Wie kann ich fence_kdump in einem Red Hat Pacemaker-Cluster konfigurieren?

Wichtig

Wenn der Cluster bereits in der Produktion genutzt wird, planen Sie den Test entsprechend, da ein Absturz eines Knotens Auswirkungen auf die Anwendung hat.
```
echo c > /proc/sysrq-trigger
```

Nächste Schritte

Siehe Azure Virtual Machines Planung und Implementierung für SAP.
Siehe Azure Virtual Machines-Bereitstellung für SAP.
Siehe Azure Virtual Machines DBMS-Bereitstellung für SAP.
Informationen zum Einrichten von HA und Planen der Notfallwiederherstellung von SAP HANA auf Azure virtuellen Computern finden Sie unter High Availability of SAP HANA on Azure Virtual Machines.

Feedback

War diese Seite hilfreich?

Last updated on 2026-03-10

Freigeben über

Einrichten von Pacemaker unter Red Hat Enterprise Linux in Azure

Voraussetzungen

Übersicht

Verwenden Sie ein SBD-Gerät

Azure-Fence-Agent verwenden

SBD mit einem iSCSI-Zielserver

Einrichten des iSCSI-Zielservers

Erstellen Sie ein iSCSI-Gerät auf dem iSCSI-Zielserver

Richten Sie das SBD-Gerät mit iSCSI-Zielserver ein

SBD mit einem freigegebenen Azure Datenträger

Konfigurieren Sie einen freigegebenen Azure-Datenträger mit PowerShell

Einrichten eines Azure-SBD-Geräts für ein freigegebenes Speicherlaufwerk

Konfiguration des Azure Fence Agents

Clusterinstallation

Erstellen eines Fencinggeräts im Pacemaker-Cluster

SBD als Fencinggerät

Azure Zaun-Agent als Fencinggerät

Konfigurieren von Pacemaker für geplante Azure-Ereignisse

Optionale Fencingkonfiguration

Nächste Schritte

Feedback

Zusätzliche Ressourcen