Einrichten von Pacemaker unter SUSE Linux Enterprise Server in Azure

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 je nach Bereitstellungstyp (Verfügbarkeitsgruppe oder Verfügbarkeitszonen) den entsprechenden redundanten Speicher für einen freigegebene Azure-Datenträger als Ihr 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 fehlerhafter 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 den fett formatierten Platzhaltertext durch 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] 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
    
  2. [1] Ändern Sie den Initiatornamen auf dem ersten Knoten.

    sudo vi /etc/iscsi/initiatorname.iscsi
    
  3. [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
  4. [2] Ändern Sie den Initiatornamen auf dem zweiten Knoten.

    sudo vi /etc/iscsi/initiatorname.iscsi
    
  5. [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
    
  6. [A] Starten Sie den iSCSI-Dienst neu, um die Änderung zu übernehmen.

    sudo systemctl restart iscsid
    sudo systemctl restart iscsi
    
  7. [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
  8. [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
  9. [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
    
  10. [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
    
  11. [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-1 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
  12. [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
    
  13. [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"
    [...]
    
  14. [A] Erstellen Sie die softdog-Konfigurationsdatei.

    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    
  15. [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] 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
    
  2. [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.

  3. [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
    
  4. [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"
    [...]
    
  5. Erstellen Sie die softdog-Konfigurationsdatei.

    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    
  6. 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.

Verwenden einer verwalteten Identität

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. Azure-Zaun-Agent basierend auf verwalteter Identität wird für SLES 12 SP5 und SLES 15 SP1 und höher unterstützt.

Verwenden eines Dienstprinzipals

Gehen Sie wie folgt vor, um einen Dienstprinzipal zu erstellen:

  1. Wählen Sie im Azure-PortalAzure Active Directory>Eigenschaften aus und notieren Sie sich die Verzeichnis-ID. Dies ist die Mandanten-ID.
  2. Wählen Sie App-Registrierungen aus.
  3. Wählen Sie Neue Registrierung aus.
  4. Geben Sie einen Namen für die Registrierung ein und wählen Sie dann Nur Konten in diesem Organisationsverzeichnis aus.
  5. Wählen Sie für AnwendungstypWeb aus, geben Sie eine Anmelde-URL ein (z. B. http://localhost) und wählen Sie dann Hinzufügen aus.
    Die Anmelde-URL wird nicht verwendet und kann eine beliebige gültige URL sein.
  6. Wählen Sie Zertifikate und Geheimnisse und dann Neuer geheimer Clientschlüssel aus.
  7. Geben Sie eine Beschreibung für einen neuen Schlüssel ein, wählen Sie Läuft nie ab aus und wählen Sie dann Hinzufügenaus.
  8. Notieren Sie sich den Wert, den Sie als Kennwort für den Dienstprinzipal verwenden.
  9. Wählen Sie Übersicht aus und notieren Sie sich die Anwendungs-ID, die Sie als Benutzernamen des Dienstprinzipals verwenden.

[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 einer verwalteten Identität

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.

Verwenden eines Dienstprinzipals

Weisen Sie dem Dienstprinzipal die benutzerdefinierte Rolle Linux-Fence-Agent-Rolle zu, die Sie bereits erstellt haben. Verwenden Sie nicht mehr die Rolle Besitzer. Weitere Informationen finden Sie unter Zuweisen von Azure-Rollen über das Azure-Portal.

Stellen Sie sicher, dass Sie die benutzerdefinierte Rolle dem Dienstprinzipal in allen VM-Bereichen (Clusterknoten) zuweisen.

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
    
  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
    
  5. [A] Konfigurieren Sie cloud-netconfig-azure für den Hochverfügbarkeitscluster.

    Hinweis

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

    Ändern Sie die Konfigurationsdatei für die Netzwerkschnittstelle wie im folgenden Code dargestellt, um das Cloud-Netzwerk-Plug-In daran zu hindern, die virtuelle IP-Adresse zu entfernen (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 Sie verwaltete Identität verwenden, muss mindestens Version „fence-agents 4.5.2+git.1592573838.1eee0863“ des Pakets fence-agents installiert werden.
    SLES 15 SP1 und höher: Zaun-Agents 4.5.2+git.1592573838.1e0863 oder höher.
    Frühere Versionen funktionieren nicht ordnungsgemäß mit der Konfiguration verwalteter Identitäten.

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

    Installieren Sie das Azure Python SDK unter SLES 12 SP4 oder SLES 12 SP5:

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

    Installieren Sie das Azure Python SDK unter SLES 15 oder höher:

    # 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 SP4 oder SLES 12 SP5 die Version 4.6.2 oder höher des Pakets python-azure-mgmt-compute.
    • 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.
  11. [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
     
  12. [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 ha-cluster-init -u
      # ! 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 ha-cluster-init -u
      # ! NTP is not configured to start at system boot.
      # Do you want to continue anyway (y/n)? y
      # /root/.ssh/id_rsa already exists - overwrite (y/n)? n
      # Address for ring0 [10.0.0.6] Select Enter
      # Port for ring0 [5405] Select Enter
      # Do you wish to use SBD (y/n)? n
      #WARNING: Not configuring SBD - STONITH will be disabled.
      
      # Do you wish to configure an administration IP (y/n)? n
      
  13. [2] Fügen Sie den Knoten dem Cluster hinzu.

    sudo ha-cluster-join
     # ! NTP is not configured to start at system boot.
     # Do you want to continue anyway (y/n)? y
     # IP address or hostname of existing node (for example, 192.168.1.1) []10.0.0.6
     # /root/.ssh/id_rsa already exists - overwrite (y/n)? n
     
  14. [A] Ändern Sie das hacluster-Kennwort in das gleiche Kennwort.

    sudo passwd hacluster
     
  15. [A] Passen Sie die corosync-Einstellungen an.

    sudo vi /etc/corosync/corosync.conf
     

    a. Fügen Sie den folgenden fett formatierten Inhalt in die Datei ein, falls die Werte dort nicht vorhanden sind oder sich von den vorhandenen Werten unterscheiden. 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

  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
    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. Beachten Sie den fett formatierten Bereich des folgenden Befehls.

    Wenn Sie eine verwaltete Identität für Ihren Fence-Agent verwenden, führen Sie den folgenden Befehl (nur SLES 15 SP1 und neuer) aus:

    
    # replace the bold strings 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_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 einen Dienstprinzipal für Ihren Fence-Agent verwenden, führen Sie den folgenden Befehl aus:

    
    # replace the bold strings with your subscription ID, resource group of the VM, tenant ID, service principal application ID and password
    
    sudo crm configure primitive rsc_st_azure stonith:fence_azure_arm \
    params subscriptionId="subscription ID" resourceGroup="resource group" tenantId="tenant ID" login="application ID" passwd="password" \
    pcmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 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 ein Fencing-Gerät verwenden, basierend auf der Dienstprinzipalkonfiguration, lesen Sie Die Änderung von SPN in MSI für Pacemaker-Cluster mithilfe von Azure-Fencing und erfahren Sie, wie Sie in verwaltete Identitätskonfiguration 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 ausreichend Zeit für die Vorbereitung auf Ereignisse wie das Herunterfahren von VMs, das erneute Bereitstellen von VMs usw. Mit dem Ressourcen-Agent azure-events wird eine Überwachung auf geplante Azure-Ereignisse durchgeführt. Wenn Ereignisse erkannt werden und der Ressourcen-Agent feststellt, dass ein anderer Clusterknoten verfügbar ist, versetzt der Azure-Events-Agent den Zielclusterknoten in den Standbymodus, um den Cluster zu zwingen, Ressourcen von der VM mit ausstehenden geplanten Azure-Ereignissen zu migrieren. Um dies zu erreichen, müssen Sie zusätzliche Pacemaker-Ressourcen konfigurieren.

  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
    
  2. [1] Konfigurieren Sie die Ressourcen in Pacemaker.

    #Place the cluster in maintenance mode
    sudo crm configure property maintenance-mode=true
    
    #Create Pacemaker resources for the Azure agent
    sudo crm configure primitive rsc_azure-events ocf:heartbeat:azure-events op monitor interval=10s
    sudo crm configure clone cln_azure-events rsc_azure-events
    
    #Take the cluster out of maintenance mode
    sudo crm configure property maintenance-mode=false
    

    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:
    WARNING: cib-bootstrap-options: unknown attribute '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