Freigeben über

Einrichten von Pacemaker unter SUSE Linux Enterprise Server in Azure

  • Artikel

In diesem Artikel wird erläutert, wie Pacemaker unter SUSE Linux Enterprise Server (SLES) in Azure eingerichtet wird.

Übersicht

In Azure haben Sie zwei Optionen zum Einrichten von Fencing im Pacemaker-Cluster für SLES. Sie können einen Azure-Fence-Agent verwenden, der einen fehlerhaften Knoten über die Azure-APIs neu startet, oder Sie können ein SBD-Gerät verwenden.

Verwenden Sie ein SBD-Gerät

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 Internet Small Computer System Interface ( iSCSI) 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 eine ordnungsgemäße Funktion auch dann sicherzustellen, wenn ein SBD-Gerät nicht mehr verfügbar ist (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 jedes SBD-Gerät über einen iSCSI-Zielserver verbunden 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.

    Diagramm von Pacemaker in der SLES-Übersicht.

    Wichtig

    Wenn Sie Linux-Pacemaker-Clusterknoten und SBD-Geräte planen und bereitstellen, lassen Sie das Routing zwischen Ihren VMs und den VMs, auf denen die SBD-Geräte hosten, nicht über andere Geräte laufen, 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 einem freigegebenen Azure-Datenträger:

    Zum Konfigurieren eines SBD-Geräts muss mindestens ein einzelner freigegebener Azure-Datenträger an alle VMs angefügt werden, die Teil des Pacemaker-Clusters sind. Der Vorteil von SBD-Geräten mit freigegebenem Azure-Datenträger besteht darin, dass Sie keine zusätzlichen VMs bereitstellen müssen.

    Diagramm: SBD-Gerät mit freigegebenem Azure-Datenträger für Pacemaker-Cluster unter SLES.

    Hier sind einige wichtige Überlegungen zu SBD-Geräten bei Verwendung eines freigegebenen Azure-Datenträgers:

    • Ein freigegebener Azure-Datenträger mit SSD Premium wird als SBD-Gerät unterstützt.
    • SBD-Geräte, die einen freigegebenen Azure-Datenträger verwenden, werden unter SLES High Availability 15 SP01 und höher unterstützt.
    • SBD-Geräte mit freigegebenem Azure-Premium-Datenträger werden auf lokal redundantem Speicher (LRS) und zonenredundantem Speicher (ZRS) unterstützt.
    • Wählen Sie abhängig vom Typ Ihrer Bereitstellung den geeigneten redundanten Speicher für einen freigegebenen Azure-Datenträger als SBD-Gerät aus.
    • Ein SBD-Gerät mit LRS für freigegebene Azure-Premium-Datenträger (skuName: Premium_LRS) wird nur bei der Bereitstellung in einer Verfügbarkeitsgruppe unterstützt.
    • Ein SBD-Gerät mit ZRS für freigegebene Azure-Premium-Datenträger (skuName: Premium_LRS) wird für eine Bereitstellung in Verfügbarkeitszonen empfohlen.
    • Ein ZRS für verwaltete Datenträger ist derzeit in allen Regionen mit Verfügbarkeitszonen nicht verfügbar. Weitere Informationen finden Sie im ZRS-Abschnitt "Einschränkungen" unter Redundanzoptionen für verwaltete Datenträger.
    • Der freigegebene Azure-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. In Clustern mit zwei Knoten wie SAP ASCS/ERS oder SAP-HANA-Hochskalierung können beispielsweise P1- oder P2-Datenträgergrößen für das SBD-Gerät verwendet werden.
    • Für horizontale HANA-Skalierung mit HANA-Systemreplikation (HSR) und Pacemaker kann aufgrund des aktuellen Grenzwerts von maxShares ein freigegebener Azure-Datenträger für SBD-Geräte in Clustern mit bis zu vier Knoten pro Replikationsstandort verwendet werden.
    • Es wird nicht empfohlen, ein SBD-Gerät mit freigegebenem Azure-Datenträger über Pacemaker-Cluster anzufügen.
    • Wenn Sie mehrere SBD-Geräte mit freigegebenem Azure-Datenträger verwenden, überprüfen Sie den Grenzwert für die maximale Anzahl von Datenträgern, die an eine VM angefügt werden können.
    • Weitere Informationen zu Einschränkungen für freigegebene Azure-Datenträger finden Sie im Abschnitt "Einschränkungen" der Dokumentation zu freigegebenen Azure-Datenträgern.

Verwenden Sie einen Azure-Fence-Agent

Sie können Fencing mithilfe eines Azure-Fence-Agents einrichten. Der Azure-Fence-Agent erfordert verwaltete Identitäten für die Cluster-VMs oder einen Dienstprinzipal, der den Neustart ausgefallener Knoten über Azure-APIs verwaltet. Der Azure-Fence-Agent erfordert keine Bereitstellung zusätzlicher VMs.

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.

  1. Stellen Sie neue VMs mit SLES 12 SP3 oder höher bereit und stellen Sie über SSH eine Verbindung mit ihnen her. Die 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.

  2. Führen Sie auf iSCSI-Ziel-VMs die folgenden Befehle aus:

    a. Aktualisieren Sie SLES.

    sudo zypper update

    Hinweis

    Möglicherweise müssen Sie das Betriebssystem nach einem Update oder Upgrade neu starten.

    b. Entfernen Sie Pakete.

    Um ein bekanntes Problem mit targetcli und SLES 12 SP3 zu vermeiden, deinstallieren Sie die folgenden Pakete. Fehlermeldungen bezüglich nicht auffindbarer Pakete können Sie ignorieren.

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

    c. Installieren Sie die iSCSI-Zielpakete.

    sudo zypper install targetcli-fb dbus-1-python

    d. Aktivieren Sie den iSCSI-Zieldienst.

    sudo systemctl enable targetcli
sudo systemctl start targetcli

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

Führen Sie zum Erstellen der iSCSI-Datenträger für die Cluster, die von Ihren SAP-Systemen verwendet werden sollen, die folgenden Befehle auf allen iSCSI-Ziel-VMs aus. In diesem Beispiel werden SBD-Geräte für mehrere Cluster erstellt. Es zeigt, wie Sie einen iSCSI-Zielserver für mehrere Cluster verwenden würden. Die SBD-Geräte werden auf dem Betriebssystemdatenträger platziert. Stellen Sie sicher, dass Sie über ausreichend Speicherplatz verfügen.

  • nfs: Identifiziert den NFS-Cluster.
  • ascsnw1: Identifiziert den ASCS-Cluster von NW1.
  • dbnw1: Identifiziert den Datenbankcluster von NW1.
  • nfs-0 and nfs-1: Die Hostnamen der NFS-Clusterknoten.
  • nw1-xscs-0 and nw1-xscs-1: Die Hostnamen der NW1-ASCS-Clusterknoten.
  • nw1-db-0 and nw1-db-1: Die Hostnamen der Datenbankclusterknoten.

Ersetzen Sie in den folgenden Anweisungen die Hostnamen Ihrer Clusterknoten und die SID Ihres SAP-Systems.

  1. Erstellen Sie den Stammordner für alle SBD-Geräte.

    sudo mkdir /sbd

  2. Erstellen Sie das SBD-Gerät für den NFS-Server.

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

  3. Erstellen Sie das SBD-Gerät für den ASCS-Server des SAP-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.nw1-xscs-0.local:nw1-xscs-0
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.nw1-xscs-1.local:nw1-xscs-1

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

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

  5. Speichern Sie die targetcli-Änderungen.

    sudo targetcli saveconfig

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

    sudo targetcli ls

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

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

Stellen Sie vom Cluster aus eine Verbindung mit dem iSCSI-Gerät her, das Sie im letzten Schritt erstellt haben. Führen Sie die folgenden Befehle für die zu erstellenden Knoten des neuen Clusters aus.

Hinweis

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

  1. [A] Installieren Sie das iSCSI-Paket.

    sudo zypper install open-iscsi

  2. [A] Stellen Sie eine Verbindung mit den iSCSI-Geräten her. Aktivieren Sie zunächst die iSCSI- und SBD-Dienste.

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

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

    sudo vi /etc/iscsi/initiatorname.iscsi

  4. [1] Ändern Sie den Inhalt der Datei so, dass er den Zugriffssteuerungslisten (ACLs) entspricht, die Sie beim Erstellen des iSCSI-Geräts auf dem iSCSI-Zielserver verwendet haben (z.B. für den NFS-Server).

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

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

    sudo vi /etc/iscsi/initiatorname.iscsi

  6. [2] Ändern Sie den Inhalt der Datei so, dass er den ACLs entspricht, die Sie beim Erstellen des iSCSI-Geräts auf dem iSCSI-Zielserver verwendet haben.

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

  7. [A] Starten Sie den iSCSI-Dienst neu, um die Änderung zu übernehmen.

    sudo systemctl restart iscsid
sudo systemctl restart iscsi

  8. [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. iqn.2006-04.nfs.local:nfs ist einer der Zielnamen, die aufgelistet werden, wenn Sie den ersten Befehl iscsiadm -m discovery ausführen.

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

  9. [A] Wenn Sie mehrere SBD-Geräte verwenden möchten, 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.nfs.local:nfs --login --portal=10.0.0.18:3260
sudo iscsiadm -m node -p 10.0.0.18:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

  10. [A] Wenn Sie mehrere SBD-Geräte verwenden möchten, 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.nfs.local:nfs --login --portal=10.0.0.19:3260
sudo iscsiadm -m node -p 10.0.0.19:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

  11. [A] Stellen Sie sicher, dass die iSCSI-Geräte verfügbar sind, und notieren Sie sich den Gerätenamen (/dev/sde im folgenden Beispiel).

    lsscsi

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

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

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

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

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

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

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

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

    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-36001405afb0ba8d3a3c413b8cc2cca03
    • /dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df
    • /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf

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

    a. 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-36001405afb0ba8d3a3c413b8cc2cca03 -1 60 -4 120 create

    b. 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-360014053fe4da371a5a4bb69a419a4df -1 60 -4 120 create
sudo sbd -d /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf -1 60 -4 120 create

  14. [A] Passen Sie die SDB-Konfiguration an.

    a. Öffnen Sie die SBD-Konfigurationsdatei.

    sudo vi /etc/sysconfig/sbd

    b. Ä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-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]

    Hinweis

    Wenn der Eigenschaftswert von SBD_DELAY_START auf "Nein" festgelegt ist, ändern Sie den Wert in "Ja". Sie müssen auch die SBD-Dienstdatei überprüfen, um sicherzustellen, dass der Wert von TimeoutStartSec größer ist als der Wert von SBD_DELAY_START. Weitere Informationen finden Sie unter SBD-Dateikonfiguration

  15. [A] Erstellen Sie die softdog-Konfigurationsdatei.

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

  16. [A] Laden Sie das Modul.

    sudo modprobe -v softdog

SBD mit einem freigegebenen Azure-Datenträger

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

Erstellen Sie einen freigegebenen Azure-Datenträger mit PowerShell und fügen Sie ihn an

  1. Passen Sie die Werte für Ihre Ressourcengruppe, Azure-Region, VMs, logische Gerätenummern (LUNs) usw. an.

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

  2. Definieren Sie die Größe des Datenträgers, basierend auf der verfügbaren Datenträgergröße für SSD Premium. In diesem Beispiel wird die P1-Datenträgergröße mit 4G angegeben.

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

  3. Definieren Sie mit dem Parameter -MaxSharesCount die maximale Anzahl von Clusterknoten, um den freigegebenen Datenträger für das SBD-Gerät anzufügen.

    $ShareNodes = 2

  4. Verwenden Sie für ein SBD-Gerät, das LRS für einen freigegebenen Azure Premium-Datenträger verwendet, den folgenden Speicher SkuName:

    $SkuName = "Premium_LRS"

  5. Verwenden Sie für ein SBD-Gerät, das ZRS für einen freigegebenen Azure Premium-Datenträger verwendet, den folgenden Speicher SkuName:

    $SkuName = "Premium_ZRS"

  6. Richten Sie einen freigegebenen Azure-Datenträger ein.

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

  7. Fügen Sie den Datenträger an die Cluster-VMs an.

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

    a. Fügen Sie den freigegebenen Azure-Datenträger dem Clusterknoten 1 hinzu.

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

    b. Fügen Sie den freigegebenen Azure-Datenträger dem Clusterknoten 2 hinzu.

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

Wenn Sie Ressourcen mithilfe der Azure CLI oder des Azure-Portal bereitstellen möchten, finden Sie unter Bereitstellen eines ZRS-Datenträgers weitere Informationen.

Richten Sie ein SBD-Gerät mit freigegebenem Azure-Datenträger ein

  1. [A] Aktivieren Sie die SBD-Dienste.

    sudo systemctl enable sbd

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

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

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

  3. [A] Rufen Sie die IDs der angefügten Datenträger ab.

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

    Die Befehle listen Geräte-IDs für das SBD-Gerät auf. Es wird empfohlen, die ID zu verwenden, die mit scsi-3 beginnt. Im vorherigen Beispiel lautet die ID /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19.

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

    Verwenden Sie die Geräte-ID aus Schritt 2, um die neuen SBD-Geräte auf dem ersten Clusterknoten zu erstellen.

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

  5. [A] Passen Sie die SDB-Konfiguration an.

    a. Öffnen Sie die SBD-Konfigurationsdatei.

    sudo vi /etc/sysconfig/sbd

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

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

    Hinweis

    Wenn der Eigenschaftswert von SBD_DELAY_START auf "Nein" festgelegt ist, ändern Sie den Wert in "Ja". Sie müssen auch die SBD-Dienstdatei überprüfen, um sicherzustellen, dass der Wert von TimeoutStartSec größer ist als der Wert von SBD_DELAY_START. Weitere Informationen finden Sie unter SBD-Dateikonfiguration

  6. Erstellen Sie die softdog-Konfigurationsdatei.

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

  7. Laden Sie das Modul.

    sudo modprobe -v softdog

Verwenden Sie einen Azure-Fence-Agent

Dieser Abschnitt gilt nur, wenn Sie ein Fencinggerät mit einem Azure-Fence-Agent verwenden möchten.

Erstellen eines Azure-Fence-Agent-Geräts

Dieser Abschnitt gilt nur, wenn Sie ein Fencinggerät verwenden, das auf einem Azure-Fence-Agent basiert. Das Fencinggerät verwendet entweder eine verwaltete Identität oder einen Dienstprinzipal zur Autorisierung bei Microsoft Azure.

Zum Erstellen einer verwalteten Identität (MSI) erstellen Sie eine systemseitig zugewiesene verwaltete Identität für jeden virtuellen Computer im Cluster. Sollte bereits eine systemseitig zugewiesene verwaltete Identität vorhanden sein, wird diese verwendet. Benutzerseitig zugewiesene verwaltete Identitäten sollten derzeit nicht mit Pacemaker verwendet werden. Der auf verwalteten Identitäten basierende Azure-Fence-Agent wird für SLES 12 SP5 und SLES 15 SP1 und höher unterstützt.

[1] Erstellen einer benutzerdefinierten Rolle für den Fence Agent.

Standardmäßig verfügen weder die verwaltete Identität noch der Dienstprinzipal über Berechtigungen zum Zugriff auf Ihre Azure-Ressourcen. Sie müssen der verwalteten Identität oder dem Dienstprinzipal Berechtigungen zum Starten und Beenden (Aufheben der Zuordnung) aller VMs im Cluster gewähren. Wenn Sie die benutzerdefinierte Rolle noch nicht erstellt haben, können Sie dazu PowerShell oder die Azure CLIverwenden.

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 Ihre eigenen Abonnement-IDs. Wenn Sie nur über ein Abonnement verfügen, entfernen Sie den zweiten Eintrag unter AssignableScopes.

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

[A] Zuweisen der benutzerdefinierten Rolle

Verwenden Sie eine verwaltete Identität oder einen Dienstprinzipal.

Weisen Sie jeder verwalteten Identität der Cluster-VMs die benutzerdefinierte Rolle „Linux-Fence-Agent-Rolle“ zu, die im letzten Abschnitt erstellt wurde. Jeder systemseitig zugewiesenen verwalteten Identität muss die Rolle für jede Cluster-VM-Ressource zugewiesen werden. Ausführliche Schritte finden Sie unter Zuweisen des Zugriffs einer verwalteten Identität auf eine Ressource über das Azure-Portal. Überprüfen Sie, ob die Rollenzuweisung der verwalteten Identitäten der einzelnen virtuellen Computer 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.

Installieren Sie den Cluster

Hinweis

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

  1. [A] Aktualisieren Sie den SLES.

    sudo zypper update

    Hinweis

    Überprüfen Sie für SLES 15 SP4 die Versionen der crmsh- und pacemaker-Pakete, um sicherzustellen, dass sie die Mindestversionsanforderungen erfüllen:

    • crmsh-4.4.0+20221028.3e41444-150400.3.9.1 oder höher
    • pacemaker-2.1.2+20211124.ada5c3b36-150400.4.6.1 oder höher

    Wichtig

    • SLES 12 SP5: Wenn python-azure-core-1.23.1-2.12.8 installiert ist, kann der Azure-Fence-Agent möglicherweise nicht in einem Pacemaker-Cluster gestartet werden, wobei die Fehlermeldung „Azure Resource Manager Python SDK nicht gefunden oder kein Zugriff darauf möglich“ in /var/log/messages angezeigt wird. Befolgen Sie die Anweisungen unter SUSE KBA 21532, um weitere Details zu erhalten.
    • SLES 15 SP4+: Nach dem Aktualisieren des Betriebssystems verwenden die Azure-Bibliotheken für Python möglicherweise den Python 3.11-Interpreter, wodurch der Azure-Fence-Agent nicht in einem Pacemaker-Cluster gestartet werden kann. Die Fehlermeldung „Azure Resource Manager Python SDK nicht gefunden oder kein Zugriff darauf möglich“ wird in /var/log/messages angezeigt. Befolgen Sie die Anweisungen unter SUSE KBA 21504, um weitere Details zu erhalten.

  2. [A] Installieren Sie die Komponente, die Sie für die Clusterressourcen benötigen.

    sudo zypper in socat

  3. [A] Installieren Sie die Komponente azure-lb, die Sie für die Clusterressourcen benötigen.

    sudo zypper in resource-agents

    Hinweis

    Überprüfen Sie die Version des Pakets resource-agents und stellen Sie sicher, dass die Mindestversionsanforderungen erfüllt sind:

    • SLES 12 SP4/SP5: Die Version muss resource-agents-4.3.018.a7fb5035-3.30.1 oder höher sein.
    • SLES 15/15 SP1: Die Version muss resource-agents-4.3.0184.6ee15eb2-4.13.1 oder höher sein.

  4. [A] Konfigurieren Sie das Betriebssystem.

    a. Pacemaker erstellt gelegentlich viele Prozesse, wodurch die zulässige Anzahl ausgeschöpft werden kann. In einem solchen Fall schlägt ein Heartbeat zwischen den Clusterknoten möglicherweise fehl und führt zu einem Failover Ihrer Ressourcen. Es wird empfohlen, die maximale Anzahl der zulässigen Prozesse zu erhöhen, indem Sie den folgenden Parameter einstellen:

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

# Change the DefaultTasksMax
#DefaultTasksMax=512
DefaultTasksMax=4096

# Activate this setting
sudo systemctl daemon-reload

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

    b. Reduzieren Sie die Größe des Änderungscaches. Weitere Informationen finden Sie unter Low write performance on SLES 11/12 servers with large RAM (Niedrige Schreibleistung auf SLES 11/12-Servern mit großem Arbeitsspeicher).

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

    c. Stellen Sie sicher, dass vm.swappiness auf 10 festgelegt ist, um Austauschverwendung zu verringern und Arbeitsspeicher zu bevorzugen.

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

  5. [A] Überprüfen Sie die cloud-netconfig-azure-Paketversion.

    Überprüfen Sie die installierte Version des Pakets cloud-netconfig-azure, indem Sie zypper info cloud-netconfig-azure ausführen. Wenn die Version älter als 1.3 ist, wird empfohlen, das Paket cloud-netconfig-azure auf die neueste verfügbare Version zu aktualisieren.

    Tipp

    Wenn die Version in Ihrer Umgebung 1.3 oder höher ist, ist es nicht mehr notwendig, die Verwaltung von Netzwerkschnittstellen durch das Cloud-Netzwerk-Plug-In zu unterdrücken.

    Nur wenn die Version von cloud-netconfig-azure niedriger als 1.3 ist, ändern Sie die Konfigurationsdatei für die Netzwerkschnittstelle wie im folgenden Code dargestellt, um zu verhindern, dass das Cloud-Netzwerk-Plug-In die virtuelle IP-Adresse entfernt (Pacemaker muss die Zuweisung steuern). Weitere Informationen finden Sie unter SUSE KB 7023633.

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

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

  6. [1] Aktivieren Sie den SSH-Zugriff.

    sudo ssh-keygen

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

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

  7. [2] Aktivieren Sie den SSH-Zugriff.

    sudo ssh-keygen

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

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

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

  8. [1] Aktivieren Sie den SSH-Zugriff.

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

  9. [A] Installieren Sie das Paket fence-agents, wenn Sie ein Fencinggerät verwenden, das auf dem Azure-Fence-Agent basiert.

    sudo zypper install fence-agents

    Wichtig

    Die Version des installierten Pakets fence-agents muss 4.4.0 oder höher sein, um von den schnelleren Failoverzeiten mit dem Azure-Fence-Agent zu profitieren, wenn ein Clusterknoten umgrenzt werden muss. Wenn Sie eine frühere Version ausführen, wird empfohlen, das Paket zu aktualisieren.

    Wichtig

    Wenn eine verwaltete Identität verwendet wird, muss die installierte Version des fence-agents-Pakets wie folgt lauten –

    • SLES 12 SP5: fence-agents 4.9.0+git.1624456340.8d746be9-3.35.2 oder höher
    • SLES 15 SP1 und höher: Fence-Agents 4.5.2+git.1592573838.1eee0863 oder höher

    Frühere Versionen funktionieren nicht ordnungsgemäß mit der Konfiguration verwalteter Identitäten.

  10. [A] Installieren Sie das fence-agents-azure-arm-Paket.

    Sie müssen für SLES 12 SP5, wenn Sie die fence-agents-Version 4.9.0+git.1624456340.8d746be9-3.41.3 oder höher verwenden, und für SLES 15 SP4 und neuer das fence-agents-azure-arm-Paket installieren. Dieses Paket enthält alle erforderlichen Abhängigkeiten.

    # On SLES 12 SP5 with fence-agents version 4.9.0+git.1624456340.8d746be9-3.41.3 or higher. You might need to activate the public cloud extension first
SUSEConnect -p sle-module-public-cloud/12/x86_64
sudo zypper install fence-agents-azure-arm

# On SLES 15 SP4 and later. You might need to activate the public cloud extension first. In this example, the SUSEConnect 
SUSEConnect -p sle-module-public-cloud/15.4/x86_64
sudo zypper install fence-agents-azure-arm

  11. [A] Installieren Sie das Azure Python SDK- und Azure Identity-Python-Modul.

    Sie müssen für SLES 12 SP5, wenn Ihre fence-agents-Version niedriger als 4.9.0+git.1624456340.8d746be9-3.41.3 ist, und für SLES 15 SP3 und niedriger die zusätzlichen Pakete unten installieren.

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

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

    Wichtig

    In Abhängigkeit von Ihrer Version und Ihrem Imagetyp müssen Sie möglicherweise die Public-Cloud-Erweiterung für Ihre Betriebssystemversion aktivieren, bevor Sie das Azure Python SDK installieren können. Sie können die Erweiterung überprüfen, indem Sie SUSEConnect ---list-extensions ausführen. So erzielen Sie schnellere Failoverzeiten mit dem Azure-Fence-Agent:

    • Installieren Sie unter SLES 12 SP5 die Version 4.6.2 oder höher des python-azure-mgmt-compute-Pakets.
    • Wenn Ihr Paket python-azure-mgmt-compute oder python3-azure-mgmt-compute die Version 17.0.0-6.7.1 hat, folgen Sie den Anweisungen in SUSE KBA, um die Fence-Agents-Version zu aktualisieren und die Azure-Identity-Clientbibliothek für das Python-Modul zu installieren, falls sie fehlt.

  12. [A] Richten Sie die Hostnamenauflösung ein.

    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 veranschaulicht.

    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 schlägt fehl, 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 /etc/hosts die folgenden Zeilen hinzu. Ä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

  13. [1] Installieren Sie den Cluster.

    • Wenn Sie SBD-Geräte für das Fencing verwenden (entweder für den iSCSI-Zielserver oder den freigegebenen Azure-Datenträger):

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

    • Wenn Sie keine SBD-Geräte für das Fencing verwenden:

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

  14. [2] Fügen Sie den Knoten dem Cluster hinzu.

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

  15. [A] Ändern Sie das hacluster-Kennwort in das gleiche Kennwort.

    sudo passwd hacluster

  16. [A] Passen Sie die corosync-Einstellungen an.

    sudo vi /etc/corosync/corosync.conf

    a. Überprüfen Sie den folgenden Abschnitt in der Datei, und passen Sie ihn an, wenn die Werte nicht vorhanden oder unterschiedlich sind. Achten Sie darauf, das Token auf 30000 zu ändern, um eine speichererhaltende Wartung zu ermöglichen. Weitere Informationen finden Sie im Artikel "Wartung für VMs in Azure" für Linux oder Windows.

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

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

    b. Starten Sie den corosync-Dienst neu.

    sudo service corosync restart

Erstellen eines Fencinggeräts im Pacemaker-Cluster

Tipp

  • Um Fence-Rennen innerhalb eines Zweiknoten-Pacemaker-Clusters zu vermeiden, können Sie die zusätzliche 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 Details finden Sie im Administratorhandbuch zur Hochverfügbarkeitserweiterung für SUSE Linux Enterprise Server.
  • Die Anweisung zum Festlegen der Clustereigenschaft „priority-fencing-delay“ finden Sie in den jeweiligen SAP ASCS/ERS- (gilt nur für ENSA2) und SAP HANA-Hochverfügbarkeitsdokumenten für die Hochskalierung.

  1. [1] Wenn Sie ein SDB-Gerät (iSCSI-Zielserver oder freigegebener Azure-Datenträger) als Fencinggerät verwenden, führen Sie die folgenden Befehle aus. Aktivieren Sie die Verwendung eines Fencinggeräts, und legen Sie die Verzögerung der Umgrenzung fest.

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

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

  2. [1] Wenn Sie einen Azure-Fence-Agent für Fencing verwenden, führen Sie die folgenden Befehle aus. Nachdem Sie beiden Clusterknoten Rollen zugewiesen haben, können Sie die Fencinggeräte im Cluster konfigurieren.

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

    Hinweis

    Die Option „pcmk_host_map“ ist im Befehl nur erforderlich, wenn die Hostnamen und die Namen der Azure-VMs nicht identisch sind. Geben Sie die Zuordnung im Format hostname:vm-name an.

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

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

sudo crm configure property stonith-timeout=900

Wenn Sie das Fencinggerät basierend auf der Konfiguration des Dienstprinzipals verwenden, lesen Sie Wechseln von SPN zu MSI für Pacemaker-Cluster mit Azure-Fencing, und erfahren Sie, wie Sie zur Konfiguration mit verwalteter Identität konvertieren.

Wichtig

Die Überwachungs- und Fencingvorgänge sind deserialisiert. Wenn ein länger andauernder Überwachungsvorgang und ein gleichzeitiges Fencingereignis vorliegen, tritt daher keine Verzögerung beim Clusterfailover auf, da der Überwachungsvorgang bereits ausgeführt wird.

Tipp

Der Azure-Fence Agent erfordert ausgehende Konnektivität mit den öffentlichen Endpunkten, wie zusammen mit möglichen Lösungen in Konnektivität öffentlicher Endpunkte für VMs, die Standard-ILB verwenden beschrieben.

Konfigurieren Sie Pacemaker für geplante Azure-Ereignisse

Azure verfügt über geplante Ereignisse. Geplante Ereignisse werden über den Metadatendienst bereitgestellt und geben der Anwendung Zeit, sich auf solche Ereignisse vorzubereiten. Der Ressourcenagent azure-events-az überwacht auf geplante Azure-Ereignisse. Wenn Ereignisse erkannt werden und der Ressourcenagent feststellt, dass ein anderer Clusterknoten verfügbar ist, wird ein Clusterintegritätsattribut festgelegt. Wenn das Clusterintegritätsattribut für einen Knoten festgelegt wird, wird die Standorteinschränkung ausgelöst, und alle Ressourcen, deren Name nicht mit „health-“ beginnt, werden mit dem geplanten Ereignis vom Knoten weg migriert. Sobald der betroffene Clusterknoten frei von laufenden Clusterressourcen ist, wird das geplante Ereignis bestätigt und kann seine Aktion ausführen, z. B. das Neustarten.

Wichtig

Zuvor wurde in diesem Dokument die Verwendung des Ressourcenagents azure-events beschrieben. Der neue Ressourcenagent azure-events-az unterstützt Azure-Umgebungen, die in verschiedenen Verfügbarkeitszonen bereitgestellt werden, vollständig. Es wird empfohlen, den neueren Agent „azure-events-az“ für alle hochverfügbaren SAP-Systeme mit Pacemaker zu verwenden.

  1. [A] Stellen Sie sicher, dass das Paket für den Azure-Events-Agent bereits installiert und auf dem neuesten Stand ist.

    sudo zypper info resource-agents

    Mindestversionsanforderungen:

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

  2. [1] Konfigurieren Sie die Ressourcen in Pacemaker.

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

  3. [1] Festlegen der Strategie und Einschränkung des Pacemaker-Clusterintegritätsknotens

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

    Wichtig

    Definieren Sie keine anderen, mit „health-“ beginnenden Ressourcen im Cluster, außer den Ressourcen, die in den nächsten Schritten der Dokumentation beschrieben werden.

  4. [1] Legen Sie den Anfangswert der Clusterattribute fest. Führen Sie es für jeden Clusterknoten aus. Für Umgebungen mit horizontale Skalierung 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

  5. [1] Konfigurieren Sie die Ressourcen in Pacemaker. Wichtig: Die Ressourcen müssen mit „health-azure“ beginnen.

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

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

    Hinweis

    Beim Konfigurieren der Ressource „health-azure-events“ kann die folgende Warnmeldung ignoriert werden.

    WARNUNG: health-azure-events: unbekanntes Attribut „allow-unhealthy-nodes“.

  6. Nehmen Sie den Pacemaker-Cluster aus dem Wartungsmodus heraus

    sudo crm configure property maintenance-mode=false

  7. Löschen Sie alle Fehler während der Aktivierung, und überprüfen Sie, dass die Ressourcen für „health-azure-events“ erfolgreich auf allen Clusterknoten gestartet wurden.

    sudo crm resource cleanup

    Die erste Abfrageausführung für geplante Ereignisse kann bis zu 2 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 in der Dokumentation zu geplanten Ereignissen.

    Hinweis

    Nachdem Sie die Pacemaker-Ressourcen für den Azure-Events-Agent konfiguriert haben, erhalten Sie beim Aktivieren bzw. Deaktivieren des Wartungsmodus für den Cluster ggf. Warnmeldungen wie diese:

    WARNUNG: cib-bootstrap-options: unbekanntes Attribut „hostName_hostname“
    WARNING: cib-bootstrap-options: unknown attribute 'azure-events_globalPullState'
    WARNING: cib-bootstrap-options: unknown attribute 'hostName_ hostname'
    Diese Warnmeldungen können ignoriert werden.

Nächste Schritte