Kurzanleitung zu Installation und Einrichtung #

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

Nach der Einrichtung des Clusters mit den Bootstrap-Skripten überwachen wir den Cluster mit der grafischen HA Web Konsole (Hawk). Dabei handelt es sich um eines der Werkzeuge für die Cluster-Verwaltung, die im Lieferumfang von SUSE Linux Enterprise High Availability Extension enthalten sind. Die ordnungsgemäße Funktionsweise des Ressourcen-Failovers lässt sich ganz einfach testen, indem einer der Knoten in den Standby-Modus versetzt und geprüft wird, ob die virtuelle IP-Adresse zum zweiten Knoten migriert wird.

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.

In diesem Abschnitt erhalten Sie Informationen über die wichtigsten Systemanforderungen für das in Abschnitt 1, „Einsatzszenario“ beschriebene Szenario. Wenn Sie den Cluster für den Einsatz in einer Produktionsumgebung anpassen möchten, lesen Sie die ausführliche Liste der Systemanforderungen und Empfehlungen im Chapter 2, System Requirements and Recommendations.

Die folgende Software muss auf allen Knoten installiert werden, die dem Cluster angehören sollen:

Alle Kommandos aus dem Paket ha-cluster-bootstrap führen Bootstrap-Skripte aus, für die nur wenig Zeit und kaum manuelle Eingriffe benötigt werden.

Alle Bootstrap-Skripte protokollieren die zugehörigen Daten in der Datei /var/log/ha-cluster-bootstrap.log. In dieser Datei finden Sie alle Details des Bootstrap-Prozesses. Sämtliche Optionen, die während des Bootstrap-Prozesses festgelegt wurden, können später mit dem YaST-Cluster-Modul geändert werden. Weitere Informationen finden Sie im Section 3.1, “Manual Installation”.

Jedem Skript ist eine man-Seite zugeordnet, auf der Sie die verschiedenen Funktionen, die Optionen des Skripts und einen Überblick über die Dateien finden, die vom Skript erstellt und geändert werden können.

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

Die Pakete für die Konfiguration und Verwaltung eines Clusters mit High Availability Extension sind im Installationsschema High Availability enthalten. Damit dieses Schema verfügbar ist, müssen Sie SUSE Linux Enterprise High Availability Extension als Erweiterung von SUSE Linux Enterprise Server installieren.

Sie finden Informationen zur Installation von Erweiterungen im SUSE Linux Enterprise 12 SP5 Deployment Guide (Bereitstellungshandbuch für SUSE Linux Enterprise 12 SP2): https://documentation.suse.com/sles-12/html/SLES-all/cha-add-ons.html.

Sollte das Schema noch nicht installiert sein, installieren Sie es mit dem Befehl zypper install -t pattern ha_sles. Alternativ können Sie das Schema auch mit YaST installieren. Führen Sie dazu die folgenden Schritte aus:

Falls Sie über einen gemeinsam genutzten Speicher wie beispielsweise ein SAN (Storage Area Network) verfügen, können Sie damit Szenarien einer Systemspaltung verhindern, indem Sie SBD als Fencing-Mechanismus für Knoten konfigurieren. SBD verwendet eine Watchdog-Unterstützung und den STONITH-Ressourcenagenten external/sbd.

5.2 Einrichtung von softdog-Watchdog und SBD #

In SUSE Linux Enterprise Server ist die Watchdog-Unterstützung im Kernel standardmäßig aktiviert: Die Auslieferung erfolgt mit mehreren Kernel-Modulen, die hardwarespezifische Watchdog-Treiber bereitstellen. In der High Availability Extension 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, ist es 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.

1. Erstellen Sie mithilfe der Beschreibung im Abschnitt 5.1, „Anforderungen für SBD“, einen persistenten, gemeinsam genutzten Speicher.

2. Aktivieren Sie den softdog-Watchdog:

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

3. Testen Sie, ob das softdog-Modul richtig geladen wurde:

   root # lsmod | egrep "(wd|dog)"
   softdog                16384  1

4. Initialisieren Sie auf bob die SBD-Partition:

   root # sbd -d /dev/SBDDEVICE create

5. Starten Sie SBD, damit die Empfangsbereitschaft auf dem SBD-Gerät aktiviert ist:

   root # sbd -d /dev/SBDDEVICE watch

6. Senden Sie auf alice eine Testnachricht:

   root # sbd -d /dev/SBDDEVICE message bob test

7. Prüfen Sie auf bob mit systemctl den Status; Sie sollten die empfangene Nachricht sehen:

   root # systemctl status sbd
   [...]
   info: Received command test from alice on disk SBDDEVICE

8. Beenden Sie die Überwachung des SBD-Geräts auf bob wie folgt:

   root # systemctl stop sbd

Es wird dringend empfohlen, die ordnungsgemäße Funktionsweise des SBD-Fencing-Mechanismus zu testen, wenn die Situation einer Systemspaltung eintritt. Ein derartiger Test kann durch die Blockierung der Corosync-Cluster-Kommunikation durchgeführt werden.

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

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

Sobald der Cluster mit einem Knoten betriebsbereit ist, können Sie mit dem Bootstrap-Skript ha-cluster-join wie in Prozedur 4 beschrieben den zweiten Knoten hinzufügen. Das Skript benötigt lediglich Zugriff auf einen vorhandenen Cluster-Knoten. Es führt die grundlegende Einrichtung auf dem aktuellen Rechner automatisch durch. Ausführliche Informationen hierzu finden Sie auf der man-Seite ha-cluster-join.

Die Bootstrap-Skripte kümmern sich um die Änderung der für Cluster mit zwei Knoten spezifischen Konfiguration, wie SBD und Corosync.

Prüfen Sie den Cluster-Status in Hawk2. Unter Status › Knoten sollten zwei Knoten mit einem grün dargestellten Status angezeigt werden (siehe Abbildung 2, „Status des aus zwei Knoten bestehenden Clusters“).

Abbildung 2: Status des aus zwei Knoten bestehenden Clusters #

Prozedur 5, „Testen des Ressourcen-Failovers“ ist ein einfacher Test zur Prüfung, ob der Cluster die virtuelle IP-Adresse zu dem anderen Knoten verschiebt, wenn der Knoten, der die Ressource zurzeit ausführt, auf Standby gesetzt wird.

Ein aussagekräftiger Test umfasst jedoch gezielte Anwendungsfälle und Szenarien. Beispielsweise sollte auch Ihr Fencing-Mechanismus getestet werden, damit Situationen einer Systemspaltung vermieden werden. Falls Sie Ihren Fencing-Mechanismus nicht ordnungsgemäß eingerichtet haben, funktioniert der Cluster nicht richtig.

Bevor Sie den Cluster in einer Produktionsumgebung einsetzen, müssen Sie ihn anhand Ihrer Anwendungsfälle gründlich testen.

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.

Sie finden die sonstige Dokumentation zu diesem Produkt unter https://documentation.suse.com/sle-ha-12. Die Dokumentation beinhaltet unter anderem ein umfassendes Administrationshandbuch für SUSE Linux Enterprise High Availability Extension. Dort werden weitere Konfigurations- und Verwaltungsaufgaben beschrieben.

Copyright © 2006– 2024 SUSE LLC und Mitwirkende. Alle Rechte vorbehalten.

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 im Abschnitt „GNU Free Documentation License“.

Die SUSE-Marken finden Sie unter http://www.suse.com/company/legal/. Alle anderen Marken von Drittanbietern sind Besitz ihrer jeweiligen Eigentümer. Markensymbole (®, ™ usw.) kennzeichnen Marken von SUSE und der Tochtergesellschaften. Sternchen (*) kennzeichnen Marken von Drittanbietern.

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