Überprüfen der SUSE HAE-Repositories

1. Überprüfen Sie, ob die Repositorys von SUSE Linux (R) Enterprise High Availability Extension aktiviert sind, indem Sie den folgenden Befehl auf beiden Knoten ausführen.

   zypper repos --show-enabled-only | grep High
   

   Überspringen Sie die folgenden Schritte, wenn die Ausgabe die SLE HAE-Repositories sowohl für Pool als auch für Updates enthält. Beispiel:

   • SUSE_Linux_Enterprise_High_Availability_Extension_ppc64le:SLE-Product-HA15-SP6-Pool
   • SUSE_Linux_Enterprise_High_Availability_Extension_ppc64le:SLE-Product-HA15-SP6-Updates

2. Wenn die HAE-Repositories nicht aufgelistet sind, verwenden Sie yast2, um sie zu aktivieren.

   • Software
   • Zusatzprodukte
   • Hinzufügen
   • Erweiterungen und Module vom Registrierungsserver
     • Yast2 schleifen über beide Repositories Pool und Updates
     • Beide Repositories hinzufügen
   • Beenden Sie die Anwendung yast2

3. Wenn Sie fertig sind, führen Sie denselben Befehl auf beiden Knoten erneut aus.

   zypper repos --show-enabled-only | grep High
   

Beide SLE HAE-Repositorien sind aufgelistet.

Installation der SLE HAE-Softwarepakete

Verwenden Sie den folgenden Befehl, um die erforderlichen Softwarepakete zu installieren.

Führen Sie auf beiden Knoten den folgenden Befehl aus.

zypper install -t pattern ha_sles

Überprüfung der Hardwareanforderungen

Beachten Sie die folgenden Hardwareanforderungen für die Konfiguration eines SLE-Hochverfügbarkeitsclusters.

Ausführliche Informationen zu den Hardware-Anforderungen finden Sie in der Dokumentation zu SUSE Linux Enterprise High Availability in der Kurzanleitung zur Installation und Einrichtung.

• Zwei virtuelle Server oder logische Partitionen, die als Clusterknoten dienen.
• Ein zweiter Netzwerkkommunikationskanal oder eine gebundene Netzwerkschnittstelle für Corosync.
• Ein gemeinsam genutztes Volume, das als STONITH Block Device (SBD) Gerät verwendet werden soll.
• Ein Hardware-Watchdog-Timer für zuverlässiges Node Fencing.

Gemeinsame Speichervolumes erstellen

Verwenden Sie die Webschnittstelle IBM Cloud PowerVS, um ein oder drei freigegebene Volumes zu erstellen, die als SBD-Geräte verwendet werden sollen. SUSE empfiehlt, drei Volumes zu erstellen, um Redundanz zu gewährleisten. Diese Informationen werden bei der Erstellung einer einzelnen SBD-Platte fortgesetzt.

Wenn Sie mehrere Festplatten verwenden möchten, wiederholen Sie die folgenden Schritte je nach Bedarf für jedes Volume.

1. Rufen Sie die Seite Power Virtual Server - Storage Volumes auf.

2. Klicken Sie auf Datenträger erstellen.

3. Geben Sie im Formular Speichervolumen erstellen die folgenden Informationen ein.

   • Geben Sie einen Namen für das Volume ein.
   • Setzen Sie die Größe (GB) auf 1 (Standard).
   • Schalten Sie die Option Freigeben auf EIN.
   • Akzeptieren Sie die Allgemeinen Geschäftsbedingungen, indem Sie das entsprechende Kästchen ankreuzen.

4. Klicken Sie auf Volume erstellen, um den Vorgang abzuschließen.

   Nun müssen Sie die Volumes an beide Clusterknoten anschließen.

5. Ändern Sie die logische Partition für den ersten Clusterknoten.

6. Klicken Sie auf Vorhandenes anhängen, um das zuvor erstellte gemeinsame Volume an diesen Knoten anzuhängen.

7. Wiederholen Sie die gleichen Schritte für den zweiten Clusterknoten.

8. Führen Sie auf einem beliebigen Knoten den folgenden Befehl aus, um die Gerätenamen der 1-G-Volumes zu ermitteln.

   multipath -l | grep -B1 'size=1G'
   

   Wenn die Ausgabe des Befehls multipath -l lautet:

   36005076813810264e800000000006f10 dm-0 IBM,2145
   size=1G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
   

9. Führen Sie den folgenden Befehl aus, um den Gerätenamen zu bestätigen, der mit dem freigegebenen Volume verbunden ist.

   ls /dev/disk/by-id/wwn-0x6005076813810264e800000000006f10
   

   Das SBD-Gerät muss auf allen Clusterknoten denselben Gerätenamen haben, um den ordnungsgemäßen Betrieb des Clusters zu gewährleisten.

   Um zukünftige Schritte zu vereinfachen, exportieren Sie den SBD-Gerätepfad als Umgebungsvariable, die während der Cluster-Initialisierung verwendet wird.

   export SBD_DEVICE=/dev/disk/by-id/wwn-0x6005076813810264e800000000006f10
   

Konfigurieren des Hardware-Watchdogs

Der Hardware-Watchdog-Timer ist standardmäßig auf Power10 logischen Partitionen aktiviert. Führen Sie den folgenden Befehl aus, um seine Verfügbarkeit zu überprüfen.

ls /dev/watchdog*

Die Ausgabe listet zwei Geräte auf: /dev/watchdog und /dev/watchdog0.

Wenn kein Watchdog-Gerät aufgeführt ist, führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Kompatibilitätsmodus des Prozessors auf Power10 eingestellt ist.

LD_SHOW_AUXV=1 /bin/true | grep _PLATFORM

Achten Sie auf die folgenden Felder in der Ausgabe.

• AT_BASE_PLATFORM - zeigt den aktuellen Prozessortyp an.
• AT_PLATFORM - zeigt den Kompatibilitätsmodus des Prozessors an.

Der Kompatibilitätsmodus des Prozessors muss auf Power10 eingestellt sein. Wenn er auf eine frühere Version eingestellt ist, ist der Hypervisor-Watchdog nicht verfügbar.

Schlichter

Für einen Zwei-Knoten-Cluster wird eine dritte LPAR als Arbitrator empfohlen. Der Arbitrator ist eine logische Partition, die nicht Teil des Clusters ist. Er beherbergt den QNetd-Server als dritte Instanz, um die Ermittlung des Cluster-Quorums in Split-Brain-Szenarien zu unterstützen. Bei einer geraden Anzahl von Clusterknoten sind Arbitratoren unerlässlich, da sie eine Instanz zum Quorum hinzufügen.

Weitere Informationen finden Sie in der SUSE-Dokumentation QDevice und QNetd.

Der Arbitrator wird normalerweise eingerichtet, nachdem der Cluster in Betrieb ist. Verwenden Sie den Ansatz crm cluster init qdevice, wie in der SUSE-Dokumentation beschrieben.

Konfigurieren der Zeitsynchronisierung

Beide Clusterknoten müssen zeitlich synchronisiert werden, um einen ordnungsgemäßen Betrieb zu gewährleisten. Wenn logische Partitionen auf PowerVS, laufen, wird die Zeitsynchronisation automatisch über die Hardware Management Console (HMC) abgewickelt. Bei dieser Konfiguration ist der Chrony-Daemon nicht erforderlich.

Konfigurieren des ersten Clusterknotens

Die Installationsskripte von SUSE Linux Enterprise High Availability Extension konfigurieren automatisch viele wichtige Komponenten der Cluster-Umgebung.

sudo crm cluster init --name "$CLUSTERNAME" --sbd-device "$SBD_DEVICE"

Drücken Sie die Eingabetaste, um die Standardwerte zu übernehmen, oder geben Sie y ein und drücken Sie die Eingabetaste, wenn Sie dazu aufgefordert werden.

INFO: Loading "default" profile from /etc/crm/profiles.yml
WARNING: chronyd.service is not configured to start at system boot.
Do you want to continue anyway (y/n)? y
INFO: The user 'hacluster' will have the login shell configuration changed to /bin/bash
Continue (y/n)? y
INFO: A new ssh keypair is generated for user hacluster.
INFO: Configuring csync2
INFO: Starting csync2.socket service on ths-3
INFO: BEGIN csync2 checking files
INFO: END csync2 checking files
INFO: Configure Corosync (unicast):
  This will configure the cluster messaging layer.  You will need
  to specify a network address over which to communicate (default
  is eth0's network, but you can use the network address of any
  active interface).

Address for ring0 [10.51.0.84]
Port for ring0 [5405]
INFO: Initializing SBD
INFO: Hawk cluster interface is now running. To see cluster status, open:
INFO:   https://10.51.0.84:7630/
INFO: Log in with username 'hacluster', password 'linux'
WARNING: You should change the hacluster password to something more secure!
INFO: Starting pacemaker.service on ths-3
INFO: BEGIN Waiting for cluster
...........                                                                     INFO: END Waiting for cluster
INFO: Loading initial cluster configuration
WARNING: "stonith-enabled" in crm_config is set to true, it was false
INFO: Configure Administration IP Address:
  Optionally configure an administration virtual IP
  address. The purpose of this IP address is to
  provide a single IP that can be used to interact
  with the cluster, rather than using the IP address
  of any specific cluster node.

Do you wish to configure a virtual IP address (y/n)? y
Virtual IP []10.51.0.12
INFO: BEGIN Configuring virtual IP (10.51.0.12)
.                                                                               INFO: END Configuring virtual IP (10.51.0.12)
INFO: Configure Qdevice/Qnetd:
  QDevice participates in quorum decisions. With the assistance of
  a third-party arbitrator Qnetd, it provides votes so that a cluster
  is able to sustain more node failures than standard quorum rules
  allow. It is recommended for clusters with an even number of nodes
  and highly recommended for 2 node clusters.

Do you want to configure QDevice (y/n)? n
INFO: Done (log saved to /var/log/crmsh/crmsh.log on ths-3)

Der Cluster ist nun mit einem einzelnen Knoten in Betrieb.

Konfigurieren des zweiten Clusterknotens

Verwenden Sie die folgenden Informationen, um den zweiten Clusterknoten zu konfigurieren.

1. Melden Sie sich am zweiten Clusterknoten an.

2. Um den Knoten in den bestehenden Cluster zu integrieren, verwenden Sie den Befehl ha-cluster-join. Dieser Befehl erfordert ein Benutzerkonto und den Hostnamen des ersten Clusterknotens.

   sudo crm cluster join -u root -c $NODE1
   

3. Drücken Sie die Eingabetaste, um die Standardwerte zu übernehmen, oder geben Sie y ein und drücken Sie die Eingabetaste, wenn Sie dazu aufgefordert werden.

   WARNING: chronyd.service is not configured to start at system boot.
   Do you want to continue anyway (y/n)? y
   INFO: The user 'hacluster' will have the login shell configuration changed to /bin/bash
   Continue (y/n)? y
   INFO: A new ssh keypair is generated for user hacluster.
   INFO: Configuring csync2
   INFO: Starting csync2.socket service
   INFO: BEGIN csync2 syncing files in cluster
   INFO: END csync2 syncing files in cluster
   INFO: Merging known_hosts
   Warning: Permanently added 'ths-4' (ED25519) to the list of known hosts.
   INFO: BEGIN Probing for new partitions
   INFO: END Probing for new partitions
   Address for ring0 [10.51.0.230]
   INFO: Got SBD configuration
   INFO: Hawk cluster interface is now running. To see cluster status, open:
   INFO:   https://10.51.0.230:7630/
   INFO: Log in with username 'hacluster', password 'linux'
   WARNING: You should change the hacluster password to something more secure!
   INFO: Starting pacemaker.service on ths-4
   INFO: BEGIN Waiting for cluster
   ..                                                                              INFO: END Waiting for cluster
   INFO: BEGIN Adjusting sbd related timeout values
   WARNING: "stonith-timeout" in crm_config is set to 83, it was 43
   INFO: END Adjusting sbd related timeout values
   INFO: Set property "priority" in rsc_defaults to 1
   WARNING: "priority-fencing-delay" in crm_config is set to 60, it was 0
   INFO: BEGIN Reloading cluster configuration
   INFO: END Reloading cluster configuration
   INFO: Done (log saved to /var/log/crmsh/crmsh.log on ths-4)
   

4. Um zu überprüfen, ob der SLE-Cluster läuft, führen Sie den folgenden Befehl aus.

   sudo crm status
   

   Wenn keine Fehler aufgetreten sind, zeigt der Abschnitt Node Liste in der Ausgabe beide Knoten und sind als Online aufgeführt.

   Node List:
     * Online: [ ths-3 ths-4 ]
   

   Im Abschnitt Ressourcen sind zwei Ressourcen aufgeführt, die sich im Status Gestartet befinden, was bedeutet, dass sie aktiv sind und ordnungsgemäß laufen.

   Full List of Resources:
     * stonith-sbd	(stonith:external/sbd):	 Started ths-3
     * admin-ip	(ocf::heartbeat:IPaddr2):	 Started ths-3
   

Festlegen eines Passworts für die Hacluster-Benutzer-ID

Führen Sie auf beiden Knoten den folgenden Befehl aus, um das Passwort für das Hacluster-Benutzerkonto festzulegen.

passwd hacluster

Prüfen des SBD-Status

Verwenden Sie die folgenden Informationen, um zu überprüfen, ob die Variable SBD_DEVICE gesetzt ist.

Um den Status der SBD-Slots von einem der Clusterknoten aus zu überprüfen, führen Sie den folgenden Befehl aus.

sbd -d $SBD_DEVICE list

Die Ausgabe listet beide Clusterknoten mit dem Status clean auf, was bedeutet, dass der SBD-Mechanismus korrekt funktioniert und keine Fencing-Aktionen anstehen.

Konfigurieren Sie die Fechtaktion

Standardmäßig wird der umzäunte Knoten nach einem Umzäunungsereignis automatisch neu gestartet.

Ein alternativer Ansatz besteht jedoch darin, den Knoten auszuschalten und ihn nach einer Untersuchung der Fehlerursache manuell zu starten.

Die manuelle Aktivierung des Knotens hat mehrere Vorteile.

• Dadurch werden unnötige Zaunschleifen vermieden, die auftreten können, wenn das Grundproblem bestehen bleibt.
• Es stellt sicher, dass jedes Fecht-Ereignis bemerkt und behandelt wird, wodurch die Stabilität und Zuverlässigkeit des Clusters verbessert wird.

Um die Fencing-Aktion zum Ausschalten des Knotens zu konfigurieren, verwenden Sie den folgenden Befehl.

sudo crm configure set cib-bootstrap-options.stonith-action off

Überprüfen Sie die aktuelle Clusterkonfiguration mit dem folgenden Befehl.

sudo crm configure show

Prüfung von Fechtvorgängen

Um die STONITH-Konfiguration zu testen, müssen Sie manuell eine Fencing-Aktion auf einem der Nodes auslösen.

1. Führen Sie den folgenden Befehl aus, um NODE2 manuell zu fencesen.

   crm node fence ${NODE2}
   

2. Geben Sie y ein, und drücken Sie die Eingabetaste, um fortzufahren, wenn die folgende Meldung angezeigt wird, die dann stoppt NODE2:

   Fencing ths-4 will shut down the node and migrate any resources that are running on it! Do you want to fence ths-4  (y/n)? y
   

3. Aktivieren Sie NODE2, warten Sie, bis er sich dem Cluster wieder anschließt, und testen Sie das Fencing aus der entgegengesetzten Richtung.

   Führen Sie unter NODE2 den folgenden Befehl aus.

   crm status
   

4. Wenn beide Knoten als Online im Cluster-Status angezeigt werden, warten Sie etwa eine Minute, um die Stabilität zu gewährleisten. Starten Sie dann von NODE2 aus eine Fencing-Aktion auf NODE1, indem Sie den folgenden Befehl ausführen, der Folgendes bewirkt NODE1:

   crm node fence ${NODE1}
   

5. Aktivieren Sie NODE1 und starten Sie dann die Clusterdienste auf dem Knoten.