SUSE Linux Enterprise High Availability 15 SP6

Kurzanleitung zur Installation und Einrichtung #

Veröffentlicht: 29. September 2024

Dieses Dokument führt Sie durch die Einrichtung eines sehr einfachen Clusters mit zwei Knoten. Dabei werden Bootstrap-Skripte verwendet, die von der crm-Shell bereitgestellt werden. Bei diesem Vorgang müssen Sie unter anderem eine virtuelle IP-Adresse als Cluster-Ressource konfigurieren und SBD im gemeinsam genutzten Speicher als Knoten-Fencing-Mechanismus (Abriegelung) verwenden.

Versionsgeschichte: SUSE Linux Enterprise High Availability – Dokumentation

Es wird die Genehmigung erteilt, dieses Dokument unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder (optional) Version 1.3 zu vervielfältigen, zu verbreiten und/oder zu verändern; die unveränderlichen Abschnitte hierbei sind der Urheberrechtshinweis und die Lizenzbedingungen. Eine Kopie dieser Lizenz (Version 1.2) finden Sie in Abschnitt „GNU Free Documentation License“.

Die SUSE Marken finden Sie im https://www.suse.com/company/legal/. Die Rechte für alle Marken von Drittanbietern liegen bei den jeweiligen Eigentümern. Markensymbole (®, ™ usw.) kennzeichnen Marken von SUSE und seinen verbundenen Unternehmen. Sternchen (*) kennzeichnen Marken von Drittanbietern.

Alle Informationen in diesem Buch wurden mit größter Sorgfalt zusammengestellt. Auch hierdurch kann jedoch keine hundertprozentige Richtigkeit gewährleistet werden. Weder SUSE LLC, ihre Tochtergesellschaften, die Autoren noch die Übersetzer können für mögliche Fehler und deren Folgen haftbar gemacht werden.

1 Einsatzszenario #

Mit den in diesem Dokument beschriebenen Verfahren erhalten Sie eine Minimaleinrichtung eines Clusters mit zwei Knoten, die folgende Eigenschaften aufweist:

Zwei Knoten: alice (IP: 192.168.1.1) und bob (IP: 192.168.1.2), die über das Netzwerk miteinander verbunden sind.
Eine virtuelle IP-Adresse (192.168.1.10) nach dem Floating-IP-Prinzip, über die Clients eine Verbindung mit dem Service herstellen können, und zwar unabhängig davon, auf welchem physischen Knoten er ausgeführt wird. Diese IP-Adresse wird für die Verbindung mit dem grafischen Verwaltungswerkzeug Hawk2 verwendet.
Ein gemeinsam genutztes Speichergerät für den Einsatz als SBD-Fencing-Mechanismus Dies vermeidet Systemspaltungsszenarien.
Failover der Ressourcen von einem Knoten zum anderen, wenn der aktive Host ausfällt (Aktiv/Passiv-Einrichtung)

Sie können den aus zwei Knoten bestehenden Cluster zu Testzwecken oder als anfängliche Cluster-Minimalkonfiguration verwenden, die später erweitert werden kann. Bevor Sie den Cluster in einer Produktionsumgebung einsetzen, müssen Sie ihn Ihren Anforderungen entsprechend ändern (siehe Administration Guide).

2 Systemanforderungen #

In diesem Abschnitt erhalten Sie Informationen über die wichtigsten Systemanforderungen für das in Abschnitt 1 beschriebene Szenario. Zur Anpassung des Clusters für die Verwendung in einer Produktionsumgebung beachten Sie die vollständige Liste im Chapter 2, System requirements and recommendations.

2.1 Hardware #

Server

Zwei Server mit der Software, die in Abschnitt 2.2, „Software-Anforderungen“ angegeben ist.

Bei den Servern kann es sich um Bare Metal-Server oder um virtuelle Rechner handeln. Sie müssen nicht unbedingt mit identischer Hardware (Arbeitsspeicher, Festplattenspeicher usw.) ausgestattet sein, die gleiche Architektur wird jedoch vorausgesetzt. Plattformübergreifende Cluster werden nicht unterstützt.

Kommunikationskanäle

Mindestens zwei TCP/IP-Kommunikationsmedien pro Cluster-Knoten. Die Netzwerkausstattung muss die Kommunikationswege unterstützen, die Sie für die Cluster-Kommunikation verwenden möchten: Multicast oder Unicast. Die Kommunikationsmedien sollten eine Datenübertragungsrate von mindestens 100 MBit/s unterstützen. Für eine unterstützte Cluster-Einrichtung sind mindestens zwei redundante Kommunikationspfade erforderlich. Dies lässt sich durch folgende Methoden erreichen:

Netzwerkgerätekopplung (bevorzugt)
Über einen zweiten Kommunikationskanal in Corosync

Knoten-Fencing/STONITH

Eine Fencing-Lösung für Knoten (STONITH), um Systemspaltungsszenarien zu vermeiden. Dazu kann entweder ein physisches Gerät (ein Netzschalter) oder ein Mechanismus wie SBD (STONITH nach Festplatte) in Kombination mit einem Watchdog verwendet werden. SBD kann entweder mit gemeinsam genutztem Speicher oder im festplattenlosen Modus verwendet werden. In diesem Dokument wird die Verwendung von SBD mit gemeinsam genutztem Speicher beschrieben. Die folgenden Voraussetzungen müssen erfüllt sein:

Ein gemeinsam genutztes Speichergerät muss vorhanden sein. Informationen zur Einrichtung von gemeinsam genutztem Speicher finden Sie unter Storage Administration Guide for SUSE Linux Enterprise Server. Wenn Sie nur grundlegenden gemeinsam genutzten Speicher für Testzwecke benötigen, lesen Sie Anhang A, Grundlegender iSCSI-Speicher für SBD.
Der Pfad zum gemeinsam genutzten Speichergerät muss auf allen Knoten im Cluster persistent und konsistent sein. Verwenden Sie feste Gerätenamen wie /dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345.
Das SBD-Gerät darf kein hostbasiertes RAID, LVM oder DRBD* verwenden.

Weitere Informationen zu STONITH finden Sie im Chapter 12, Fencing and STONITH. Weitere Informationen zu SBD finden Sie im Chapter 13, Storage protection and SBD.

2.2 Software-Anforderungen #

Alle Knoten benötigen mindestens die folgenden Module und Erweiterungen:

Basesystem Module 15 SP6
Server Applications Module 15 SP6
SUSE Linux Enterprise High Availability 15 SP6

2.3 Sonstige Anforderungen und Empfehlungen #

Zeitsynchronisierung

Cluster-Knoten müssen mit einem NTP-Server außerhalb des Clusters synchronisiert werden. Ab SUSE Linux Enterprise High Availability 15 ist chrony Standardimplementation von NTP. Weitere Informationen finden Sie im Administration Guide for SUSE Linux Enterprise Server 15 SP6.

Der Cluster funktioniert möglicherweise nicht ordnungsgemäß, wenn die Knoten nicht synchronisiert sind oder wenn sie zwar synchronisiert sind, aber unterschiedliche Zeitzonen konfiguriert sind. Darüber hinaus wird die Analyse von Protokolldateien und Cluster-Berichten erheblich erschwert, wenn keine Synchronisierung erfolgt. Wenn Sie die Bootstrap-Skripte verwenden, werden Sie gewarnt, falls NTP noch nicht konfiguriert wurde.

Hostname und IP-Adresse

Verwenden Sie statische IP-Adressen.
Nur die primäre IP-Adresse wird unterstützt.
Listen Sie alle Cluster-Knoten in der Datei /etc/hosts mit ihrem vollständig qualifizierten Hostnamen und der Kurzform des Hostnamens auf. Es ist sehr wichtig, dass sich die Cluster-Mitglieder untereinander anhand der Namen finden können. Wenn die Namen nicht verfügbar sind, tritt ein Fehler bei der internen Cluster-Kommunikation auf.

SSH

Alle Cluster-Knoten müssen in der Lage sein, über SSH aufeinander zuzugreifen. Werkzeuge wie crm report (zur Fehlerbehebung) und History Explorer von Hawk2 erfordern einen passwortfreien SSH-Zugriff zwischen den Knoten, da sie andernfalls nur Daten vom aktuellen Knoten erfassen können.

Wenn Sie die Bootstrap-Skripte für die Einrichtung des Clusters verwenden, werden die SSH-Schlüssel automatisch erstellt und kopiert.

3 Überblick über die Bootstrap-Skripte #

Mit den folgenden Befehlen können Bootstrap-Skripte ausgeführt werden, für die nur wenig Zeit und kaum manuelle Eingriffe benötigt werden.

Mit crm cluster init können die grundlegenden Parameter definiert werden, die für eine Cluster-Kommunikation erforderlich sind. Sie erhalten dadurch einen aktiven Cluster mit einem Knoten.
Mit crm cluster join können Sie Ihrem Cluster weitere Knoten hinzufügen.
Mit crm cluster remove können Sie Knoten aus Ihrem Cluster entfernen.

Die von den Bootstrap-Skripten festgelegten Optionen sind möglicherweise nicht mit den Standardeinstellungen von Pacemaker identisch. In /var/log/crmsh/crmsh.log können Sie überprüfen, welche Einstellungen die Bootstrap-Skripte geändert haben. Sämtliche Optionen, die während des Bootstrap-Prozesses festgelegt wurden, können später mit dem YaST-Cluster-Modul geändert werden. Ausführliche Informationen finden Sie unter Chapter 4, Using the YaST cluster module.

Das Bootstrap-Skript crm cluster init prüft und konfiguriert die folgenden Komponenten:

NTP

Prüft, ob NTP zum Starten beim Booten konfiguriert ist. Wenn das nicht der Fall ist, wird eine Meldung angezeigt.

SSH

Erstellt SSH-Schlüssel für die passwortfreie Anmeldung zwischen Cluster-Knoten.

Csync2

Konfiguriert Csync2 für die Replikation der Konfigurationsdateien auf allen Knoten in einem Cluster.

Corosync

Konfiguriert das Cluster-Kommunikationssystem.

SBD/Watchdog

Es prüft, ob ein Watchdog vorhanden ist, und fragt Sie, ob SBD als Fencing-Mechanismus für Knoten konfiguriert werden soll.

Virtual Floating IP

Fragt Sie, ob eine virtuelle IP-Adresse für die Cluster-Verwaltung mit Hawk2 konfiguriert werden soll.

Firewall

Öffnet die Ports in der Firewall, die für die Cluster-Kommunikation benötigt werden.

Clustername

Definiert einen Namen für den Cluster. Standardmäßig lautet dieser hacluster. Dies ist optional und für die meisten GeoCluster sinnvoll. In der Regel gibt der Cluster-Name den geografischen Standort an, was das Auffinden einer Site in einem GeoCluster erleichtert.

QDevice/QNetd

Fragt Sie, ob QDevice oder QNetd zur Teilnahme an Quorum-Entscheidungen konfiguriert werden sollen. Wir empfehlen die Verwendung von QDevice und QNetd für Cluster mit einer geraden Anzahl von Knoten und insbesondere für Cluster mit zwei Knoten.

Diese Konfiguration wird hier nicht behandelt, Sie können sie jedoch später wie im Chapter 14, QDevice and QNetd beschrieben einrichten.

Anmerkung: Cluster-Konfiguration für verschiedene Plattformen

Das crm cluster init-Skript erkennt die Systemumgebung (z. B. Microsoft Azure) und passt bestimmte Clustereinstellungen basierend auf dem Profil für diese Umgebung an. Weitere Informationen finden Sie in der Datei /etc/crm/profiles.yml.

4 Installieren der Hochverfügbarkeitspakete #

Die Pakete zum Konfigurieren und Verwalten eines Clusters sind im High Availability-Installationsschema enthalten. Dieses Schema ist nur verfügbar, wenn SUSE Linux Enterprise High Availability installiert ist.

Sie können sich beim SUSE Customer Center registrieren und SUSE Linux Enterprise High Availability während oder nach der Installation von SUSE Linux Enterprise Server installieren. Weitere Informationen finden Sie im Deployment Guide für SUSE Linux Enterprise Server.

Vorgehen 1: Installieren des Hochverfügbarkeitsschemas #

Installieren Sie das Hochverfügbarkeitsschema über die Kommandozeile:
```
# zypper install -t pattern ha_sles
```
Installieren Sie das Hochverfügbarkeitsschema auf allen Rechnern, die Teil Ihres Clusters sein sollen.
Anmerkung: Installation der Softwarepakete auf allen Knoten
Für eine automatisierte Installation von SUSE Linux Enterprise Server 15 SP6 und SUSE Linux Enterprise High Availability 15 SP6 müssen Sie zum Klonen von bestehenden Knoten AutoYaST verwenden. Weitere Informationen finden Sie im Section 3.2, “Mass installation and deployment with AutoYaST”.

5 Verwenden von SBD als Fencing-Mechanismus für Knoten #

Bevor Sie SBD mit dem Bootstrap-Skript konfigurieren können, müssen Sie auf jedem Knoten einen Watchdog aktivieren. SUSE Linux Enterprise Server wird mit mehreren Kernelmodulen ausgeliefert, die hardwarespezifische Watchdog-Treiber bereitstellen. In SUSE Linux Enterprise High Availability wird der SBD-Daemon als die Softwarekomponente verwendet, die Daten in den Watchdog „einspeist“.

Im folgenden Verfahren wird der softdog-Watchdog verwendet.

Wichtig: softdog-Einschränkungen

Der softdog-Treiber geht davon aus, dass noch mindestens eine CPU ausgeführt wird. Wenn alle CPUs ausgefallen sind, kann der im softdog-Treiber enthaltene Code, der das System neu starten soll, nicht ausgeführt werden. Ein Hardware-Watchdog arbeitet hingegen auch dann, wenn alle CPUs ausgefallen sind.

Bevor Sie den Cluster in einer Produktionsumgebung verwenden, wird dringend empfohlen, das softdog-Modul durch das am besten zu Ihrer Hardware passende Hardwaremodul zu ersetzen.

Falls für Ihre Hardware jedoch kein passender Watchdog verfügbar ist, kann das softdog-Modul als Kernel-Watchdog-Modul verwendet werden.

Vorgehen 2: Aktivieren des softdog-Watchdog für SBD #

Aktivieren Sie den softdog-Watchdog auf jedem Knoten:

# echo softdog > /etc/modules-load.d/watchdog.conf
# systemctl restart systemd-modules-load

Testen Sie, ob das softdog-Modul richtig geladen wurde:
```
# lsmod | grep dog
softdog           16384  1
```

6 Einrichtung des ersten Knotens #

Richten Sie den ersten Knoten mit dem Skript crm cluster init ein. Dies dauert nicht lange und erfordert nur wenige manuelle Eingriffe.

Vorgehen 3: Einrichten des ersten Knotens (alice) mit dem Skript crm cluster init #

Melden Sie sich beim ersten Cluster-Knoten als root-Benutzer oder als Benutzer mit sudo-Rechten an.
Wichtig: SSH-Schlüssel-Zugriff
Im Cluster wird der passwortfreie SSH-Zugriff für die Kommunikation zwischen den Knoten verwendet. Das crm cluster init-Skript sucht nach SSH-Schlüsseln und generiert diese, falls sie noch nicht vorhanden sind.
In den meisten Fällen müssen die root- oder sudo-SSH-Schlüssel des Benutzers auf dem Knoten vorhanden sein (oder generiert) werden.
Alternativ können die sudo-SSH-Schlüssel eines Benutzers auf einem lokalen Computer vorhanden sein und über die SSH-Agent-Weiterleitung an den Knoten übergeben werden. Dies erfordert eine zusätzliche Konfiguration, die für dieses minimale Setup nicht beschrieben ist. Weitere Informationen finden Sie in Section 5.5.1, “Logging in”.
Starten Sie das Bootstrap-Skript:
```
# crm cluster init --name CLUSTERNAME
```
Ersetzen Sie den Platzhalter CLUSTERNAME durch einen aussagekräftigen Namen, wie den geografischen Standort Ihres Clusters (z. B. amsterdam). Dies ist besonders hilfreich, wenn daraus später ein GeoCluster erstellt werden soll, da eine Site so leicht identifizierbar ist.
Falls Sie für Ihre Cluster-Kommunikation Multicast anstelle von Unicast (Standard) benötigen, verwenden Sie hierzu die Option --multicast (oder -U).
Das Skript führt eine Prüfung im Hinblick auf die NTP-Konfiguration und einen Hardware-Watchdog-Service durch. Sofern erforderlich, generiert es die öffentlichen und privaten SSH-Schlüssel, die für den SSH-Zugriff und die Csync2-Synchronisierung verwendet werden, und startet die entsprechenden Services.
Konfigurieren Sie die Cluster-Kommunikationsschicht (Corosync):
1. Geben Sie eine Netzwerkadresse ein, an die eine Bindung erfolgen soll. Das Skript schlägt standardmäßig die Netzwerkadresse eth0 vor. Alternativ dazu können Sie auch eine andere Netzwerkadresse wie beispielsweise die Adresse bond0 eingeben.
2. Übernehmen Sie den vorgeschlagenen Port (5405) oder geben Sie einen anderen ein.
Richten Sie SBD als Fencing-Mechanismus für Knoten ein:
1. Bestätigen Sie mit y, dass Sie SBD verwenden möchten.
2. Geben Sie einen persistenten Pfad zu der Partition Ihres Blockgeräts ein, die Sie für SBD verwenden möchten. Der Pfad muss bei allen Knoten im Cluster konsistent sein.
  Das Skript erstellt eine kleine Partition auf dem Gerät, die für SBD verwendet wird.
Konfigurieren Sie eine virtuelle IP-Adresse für die Cluster-Verwaltung mit Hawk2:
1. Bestätigen Sie mit y, dass Sie eine virtuelle IP-Adresse konfigurieren möchten.
2. Geben Sie eine nicht verwendete IP-Adresse ein, die Sie als Verwaltungs-IP für Hawk2 verwenden möchten: 192.168.1.10
  Sie können auch eine Verbindung mit der virtuellen IP-Adresse herstellen, statt sich an einem einzelnen Cluster-Knoten mit Hawk2 anzumelden.
Wählen Sie aus, ob QDevice und QNetd konfiguriert werden soll. Für die in diesem Dokument beschriebene Minimaleinrichtung verzichten Sie zunächst darauf und geben n ein. Sie können QDevice und QNetd später einrichten, wie in Chapter 14, QDevice and QNetd beschrieben.

Schließlich startet das Skript den Cluster-Service, um den Cluster online zu schalten und Hawk2 zu aktivieren. Die URL, die für Hawk2 verwendet werden muss, wird auf dem Bildschirm angezeigt.

Sie verfügen jetzt über einen aktiven Cluster mit einem Knoten. Gehen Sie wie folgt vor, um seinen Status anzuzeigen:

Vorgehen 4: Anmelden an der Hawk2-Weboberfläche #

Starten Sie auf einem beliebigen Rechner einen Webbrowser und aktivieren Sie JavaScript und Cookies.
Geben Sie als URL die virtuelle IP-Adresse ein, die Sie mit dem Bootstrap-Skript konfiguriert haben:
```
https://192.168.1.10:7630/
```
Anmerkung: Warnmeldung bezüglich des Zertifikats
Wenn bei Ihrem ersten Zugriff auf die URL eine Warnmeldung hinsichtlich des Zertifikats angezeigt wird, wird ein eigensigniertes Zertifikat verwendet. Eigensignierte Zertifikate gelten standardmäßig nicht als vertrauenswürdig.
Bitten Sie den Cluster-Operator um die Details des Zertifikats, damit Sie es überprüfen können.
Falls Sie dennoch fortfahren möchten, können Sie im Browser eine Ausnahme hinzufügen und die Warnmeldung auf diese Weise umgehen.
Geben Sie im Anmeldebildschirm von Hawk2 den Benutzernamen und das Passwort des Benutzers ein, der mit dem Bootstrap-Skript erstellt wurde (Benutzer hacluster, Passwort linux).
Wichtig: Sicheres Passwort
Ersetzen Sie das Standardpasswort möglichst schnell durch ein sicheres Passwort:
```
# passwd hacluster
```
Klicken Sie auf Anmelden. Die Hawk2-Weboberfläche zeigt standardmäßig den Bildschirm „Status“ an:
Abbildung 1: Status des aus einem Knoten bestehenden Clusters in Hawk2 #

7 Hinzufügen des zweiten Knotens #

Fügen Sie dem Cluster mit dem Bootstrap-Skript crm cluster join einen zweiten Knoten hinzu. Das Skript benötigt lediglich Zugriff auf einen vorhandenen Cluster-Knoten. Es führt die grundlegende Einrichtung auf dem aktuellen Rechner automatisch durch.

Weitere Informationen finden Sie im Handbuch auf der Seite zum crm cluster join --help-Befehl.

Vorgehen 5: Hinzufügen des zweiten Knotens (bob) mit crm cluster join #

Melden Sie sich beim zweiten Cluster-Knoten als root-Benutzer oder als Benutzer mit sudo-Rechten an.
Starten Sie das Bootstrap-Skript:
Wenn Sie den ersten Knoten als root-Benutzer einrichten, können Sie diesen Befehl ohne zusätzliche Parameter ausführen:
```
# crm cluster join
```
Wenn Sie den ersten Knoten als sudo-Benutzer einrichten, geben Sie für diesen Benutzer die Option -c an:
```
> sudo crm cluster join -c USER@alice
```
Wenn NTP nicht für das Starten zur Boot-Zeit konfiguriert ist, wird eine Nachricht angezeigt. Das Skript sucht auch nach einem Hardware-Watchdog-Gerät. Sie erhalten eine Warnmeldung, wenn keines vorhanden ist.
Wenn Sie für alice noch nicht die Option -c angegeben haben, werden Sie zur Eingabe der IP-Adresse des ersten Knotens aufgefordert.
Falls Sie den passwortfreien SSH-Zugriff zwischen beiden Rechnern noch nicht konfiguriert haben, werden Sie zur Eingabe des Passworts für den ersten Knoten aufgefordert.
Nach der Anmeldung am angegebenen Knoten kopiert das Skript die Corosync-Konfiguration, konfiguriert SSH und Csync2, bringt den aktuellen Rechner als neuen Cluster-Knoten online und startet den für Hawk2 benötigten Dienst.

Prüfen Sie den Cluster-Status in Hawk2. Unter Status › Knoten sollten zwei Knoten mit einem grün dargestellten Status angezeigt werden:

Abbildung 2: Status des aus zwei Knoten bestehenden Clusters #

8 Testen des Clusters #

Mit den folgenden Tests können Sie Probleme bei der Einrichtung des Clusters feststellen. Ein realistischer Test beinhaltet jedoch spezifische Anwendungsfälle und Szenarien. Bevor Sie den Cluster in einer Produktionsumgebung einsetzen, müssen Sie ihn anhand Ihrer Anwendungsfälle gründlich testen.

Mit dem Kommando sbd -d DEVICE_NAME list führen Sie alle Knoten auf, die für SBD sichtbar sind. Für das in diesem Dokument beschriebene Setup sollte die Ausgabe sowohl alice als auch bob anzeigen.
Abschnitt 8.1, „Testen des Ressourcen-Failovers“ ist ein einfacher Test zur Prüfung, ob der Cluster die virtuelle IP-Adresse zu dem anderen Knoten verschiebt, falls der Knoten, der die Ressource zurzeit ausführt, auf standby gesetzt wird.
Abschnitt 8.2, „Testen mit dem Kommando crm cluster crash_test“ simuliert Clusterausfälle und meldet die Ergebnisse.

8.1 Testen des Ressourcen-Failovers #

Ein schneller Test ist das folgende Verfahren zur Prüfung auf Ressourcen-Failover:

Vorgehen 6: Testen des Ressourcen-Failovers #

Öffnen Sie ein Terminal und setzen Sie ein Ping-Signal für 192.168.1.10 ab, Ihre virtuelle IP-Adresse:
```
# ping 192.168.1.10
```
Melden Sie sich bei Hawk2 an.
Prüfen Sie unter Status › Ressourcen, auf welchem Knoten die virtuelle IP-Adresse (Ressource admin_addr) ausgeführt wird. Bei diesem Verfahren wird davon ausgegangen, dass die Ressource auf alice ausgeführt wird.
Versetzen Sie alice in den Standby-Modus:
Abbildung 3: Knoten alice im Standby-Modus #
Klicken Sie auf Status › Ressourcen. Die Ressource admin_addr wurde zu bob migriert.

Während der Migration sollte ein ununterbrochener Fluss an Ping-Signalen an die virtuelle IP-Adresse zu beobachten sein. Dies zeigt, dass die Cluster-Einrichtung und die Floating-IP ordnungsgemäß funktionieren. Brechen Sie das ping-Kommando mit Strg–C ab.

8.2 Testen mit dem Kommando `crm cluster crash_test` #

Das Kommando crm cluster crash_test löst Cluster-Ausfälle aus, um Probleme zu ermitteln. Es empfiehlt sich, dieses Kommando vor Verwendung des Clusters in der Produktion auszuführen, um sicherzustellen, dass alles wie erwartet funktioniert.

Das Kommando unterstützt folgende Prüfungen:

--split-brain-iptables: Simuliert ein Systemspaltungsszenario durch Blockieren des Corosync-Ports. Prüft, ob ein Knoten umgrenzt werden kann wie erwartet.
--kill-sbd/--kill-corosync/ --kill-pacemakerd: Beendet die Daemons für SBD, Corosync und Pacemaker. Nachdem Sie einen dieser Tests ausgeführt haben, finden Sie einen Bericht im Verzeichnis /var/lib/crmsh/crash_test/. Der Bericht enthält eine Testfallbeschreibung, eine Vorgangsprotokollierung und eine Erläuterung möglicher Ergebnisse.
--fence-node NODE: Umgrenzt einen spezifischen Knoten, der von der Kommandozeile aus weitergeleitet wurde.

Weitere Informationen finden Sie im crm cluster crash_test --help.

Beispiel 1: Testen des Clusters: Knoten-Fencing #

# crm_mon -1
Stack: corosync
Current DC: alice (version ...) - partition with quorum
Last updated: Fri Mar 03 14:40:21 2020
Last change: Fri Mar 03 14:35:07 2020 by root via cibadmin on alice

2 nodes configured
1 resource configured

Online: [ alice bob ]
Active resources:

 stonith-sbd    (stonith:external/sbd): Started alice

# crm cluster crash_test --fence-node bob

==============================================
Testcase:          Fence node bob
Fence action:      reboot
Fence timeout:     60

!!! WARNING WARNING WARNING !!!
THIS CASE MAY LEAD TO NODE BE FENCED.
TYPE Yes TO CONTINUE, OTHER INPUTS WILL CANCEL THIS CASE [Yes/No](No): Yes
INFO: Trying to fence node "bob"
INFO: Waiting 60s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

Um den Änderungsstatus für bobwährend des Tests zu beobachten, melden Sie sich bei Hawk2 an und navigieren Sie zu Status › Nodes.

9 Nächste Schritte #

Die Bootstrap-Skripte ermöglichen das schnelle Einrichten eines grundlegenden Hochverfügbarkeits-Clusters, der zu Testzwecken verwendet werden kann. Um einen solchen Cluster jedoch in einen funktionierenden Hochverfügbarkeits-Cluster zu überführen, der in einer Produktionsumgebung eingesetzt werden kann, sind weitere Schritte erforderlich.

Empfohlene Schritte zum Abschließen der Einrichtung eines Hochverfügbarkeits-Clusters #

Hinzufügen weiterer Knoten

Fügen Sie dem Cluster mit einer der folgenden Methoden weitere Knoten hinzu:

Für einzelne Knoten verwenden Sie das Skript crm cluster join, wie in Abschnitt 7, „Hinzufügen des zweiten Knotens“ beschrieben.
Für die Masseninstallation von mehreren Knoten verwenden Sie AutoYaST, wie in Section 3.2, “Mass installation and deployment with AutoYaST” beschrieben.

Ein regulärer Cluster kann bis zu 32 Knoten enthalten. Mit dem Service pacemaker_remote können Hochverfügbarkeits-Cluster über diese Grenze hinaus um zusätzliche Knoten erweitert werden. Weitere Einzelheiten finden Sie unter Pacemaker Remote Quick Start.

Konfigurieren von QDevice

Wenn der Cluster über eine gerade Anzahl von Knoten verfügt, konfigurieren Sie QDevice und QNetd für die Teilnahme an Quorum-Entscheidungen. QDevice bietet eine konfigurierbare Anzahl von Votes, sodass ein Cluster mehr Knotenausfälle bewältigen kann, als die Standard-Quorum-Regeln erlauben. Weitere Informationen finden Sie im Chapter 14, QDevice and QNetd.

Aktivieren eines Hardware-Watchdog

Ersetzen Sie das softdog-Modul durch das am besten zu Ihrer Hardware passende Hardwaremodul, bevor Sie den Cluster in einer Produktionsumgebung verwenden. Weitere Informationen finden Sie im Section 13.6, “Setting up the watchdog”.

10 Weitere Informationen #

Mehr Dokumentation zu diesem Produkt ist unter https://documentation.suse.com/sle-ha/ verfügbar. Weitere Konfigurations- und Verwaltungsaufgaben finden Sie im umfassenden Administration Guide.