19.5 Grundkonfiguration der Clusterkomponenten
Um das Hochverfügbarkeits-Setup in Betrieb nehmen zu können, müssen Sie noch zwei Komponenten konfigurieren. Die erste Komponente ist ein Benachrichtigungssystem, mit dem die einzelnen Knoten eines Clusters die Möglichkeit haben, Nachrichten über ihren aktuellen Status untereinander auszutauschen und festzustellen, ob einer der Knoten eventuell ausgefallen ist und nicht mehr antwortet. In diesem Fall müssen die Ressourcen, die der ausgefallene Knoten bereitgestellt hat, auf einem anderen Knoten neu gestartet werden. Diese Arbeit übernimmt die zweite Komponente, der Cluster Resource Manager.
19.5.1 Pacemaker und Corosync: das Benachrichtigungssystem
Die Kontrolle der Lebenszeichen und die Abwicklung des Nachrichtenverkehrs zwischen den Clusterknoten übernimmt Corosync in Zusammenarbeit mit Pacemaker.
Die Konfigurationsdatei anpassen
Die Datei liegt auf Debian- und Ubuntu-Systemen unter /etc/corosync/ und heißt corosync.conf.
Unter openSUSE Leap muss zunächst die Beispieldatei corosync.conf.example, die unter /etc/corosync/ zu finden ist, nach corosync.conf kopiert werden.
Unter CentOS wird die Konfigurationsdatei mit dem Programm pcs erzeugt – überspringen Sie daher den folgenden Teil, und fahren Sie ab »Vorbereitung für CentOS« weiter fort.
Öffnen Sie die Datei, und scrollen Sie bis zu dem Konfigurationsblock herunter, der mit interface {…} beginnt. Ändern Sie den Wert hinter bindnetaddr in die IP-Adresse des Clusterknotens, auf dem Sie sich gerade befinden.
Der Block sieht danach so aus:
interface {
ringnumber: 0
bindnetaddr: 10.0.0.1
mcastaddr: 239.255.1.1
mcastport: 5405
ttl: 1
}
Listing 19.20 Interfacekonfiguration für das Clustermessaging
[✓] Die vorgegebene Multicast-Adresse mcastaddr: 239.255.1.1 muss auf allen Clusterknoten, die in einem Verbund arbeiten sollen, gleich sein. Wenn Sie mehrere Cluster betreiben, vergeben Sie für jeden Cluster eine andere Multicast-Adresse.
Schließen Sie nun die Konfigurationsdatei auf diesem Knoten, und passen Sie die Konfigurationsdatei auf dem zweiten Knoten nach dem gleichen Muster an. Mit Ausnahme der bindnetaddr-Einstellung, in der die IP-Adresse des jeweiligen Knotens steht, soll die Datei auf beiden Knoten identisch sein.
Bei openSUSE Leap müssen Sie kontrollieren, ob in der Sektion quorum die Direktive expected_votes: 2 gesetzt ist – anderenfalls verweigert Corosync den Start.
Vorbereitungen für CentOS
Leider arbeitet CentOS elementar anders als die übrigen Distributionen. Daher müssen Sie, bevor wir das Programm pcs einsetzen können, noch einen Cluster erzeugen. Führen Sie dafür auf beiden Knoten die folgenden Befehle aus, jeweils einen nach dem anderen:
$ systemctl enable pcsd
$ systemctl start pcsd
$ sudo passwd hacluster
$ sudo pcs cluster auth node1
Username: hacluster
Password: <PASSWORD>
node1: Authorized
$ sudo pcs cluster auth node2
Username: hacluster
Password: <PASSWORD>
node2: Authorized
Listing 19.21 EDie Authentifizierung eines Clusters unter »CentOS« einrichten
Mit diesen Befehlen aktivieren und starten Sie den Cluster und setzen das Passwort für den Benutzer hacluster, der zentral zur Authentifizierung der Nodes verwendet wird. Bei dem Kommando pcs cluster auth <NODE> werden Sie nach der Authentifizierung für diesen Node gefragt – geben Sie hier das soeben vergebene Passwort des hacluster-Benutzers an.
Anschließend müssen Sie noch einen Cluster anlegen und zwei Konfigurationen (da wir nur zwei Nodes betreiben) absetzen – diese Befehle müssen nur auf einem Node ausgeführt werden:
$ sudo pcs cluster setup --start --name MyCluster node1 node2 --transport udp
[…]
Listing 19.22 Erstellen und Konfigurieren eines Clusters unter »CentOS«
»authkey« erzeugen und verteilen
Die Clusterknoten weisen sich untereinander durch einen Schlüssel aus. Dieser Schlüssel wird auf einem beliebigen Knoten erzeugt und dann auf alle anderen Clusterknoten kopiert. So erzeugen Sie den Schlüssel:
$ corosync-keygen
Listing 19.23 »authkey« erzeugen
Die fertige Schlüsseldatei hat den Namen authkey bekommen. Sie liegt im Corosync-Konfigurationsverzeichnis. Kopieren Sie sie auf den zweiten Knoten und dort ins gleiche Verzeichnis.
[+] Zu langsam? Installieren Sie »haveged«!
Falls die Erstellung eines Keys ewig benötigt, verfügt Ihr System über zu wenig Entropie. Installieren Sie einfach das Paket haveged, und schon müssen Sie beim Erzeugen von Keys keine Kaffeepause mehr einlegen.
Die Konfiguration des Benachrichtigungssystems ist damit abgeschlossen, es kann gestartet werden. Sie starten das System mit dem Kommando systemctl restart corosync. Zusätzlich sollten Sie prüfen, ob der Ressourcenmanager Pacemaker bereits gestartet ist. Falls nicht, führen Sie systemctl restart pacemaker aus, um dies nachzuholen.
Da der Cluster diese Dienste stets benötigt, sollten Sie auch sicherstellen, dass sie beim Systemstart automatisch gestartet werden. Führen Sie daher zur Sicherheit die Befehle aus Listing 19.24 aus:
$ systemctl enable corosync
$ systemctl enable pacemaker
Listing 19.24 Dienste beim Systemstart starten
19.5.2 Pacemaker: der Ressourcenmanager
Unter Debian, Ubuntu und openSUSE Leap erfolgt die Konfiguration über das Programm crm. Unter CentOS wurde dies durch pcs ersetzt. Die Programme arbeiten ähnlich, aber nicht gleich – daher werden wir Ihnen die Unterschiede jeweils darstellen.
Unter einer Ressource versteht man alles, was im Fehlerfall auf einen anderen Knoten umziehen muss: IP-Adressen, Dienste, DRBD-Devices.
Pacemaker verwaltet den Start, den Stopp und die kontrollierte Migration der Ressourcen und kann dabei auch Abhängigkeiten berücksichtigen.
Sie haben zwar noch keine Ressourcen konfiguriert, aber Ihre beiden Nodes kennt Pacemaker bereits. Geben Sie einmal auf der Kommandozeile den Befehl crm status ein (unter CentOS: pcs status). Sie erhalten eine solche Ausgabe:
root@node2:~# crm status ### CentOS: pcs status
Stack: corosync
Current DC: node2 (version 1.1.18-2b07d5c5a9) - partition with quorum
Last updated: Wed Sep 5 18:04:30 2018
Last change: Wed Sep 5 18:03:46 2018 by root via cibadmin on node2
2 nodes configured
0 resources configured
Online: [ node1 node2 ]
No resources
Listing 19.25 CRM-Status, Nodes ohne Ressourcen
In der letzten Zeile sehen Sie, dass Ihre beiden Nodes zur Verfügung stehen (Online).
Pacemaker: den Status im Blick behalten
Der Befehl crm_mon erzeugt die gleiche Ausgabe wie crm status, allerdings wird die Ausgabe laufend aktualisiert. So können Sie immer verfolgen, welchen Status Ihre Nodes und Ressourcen gerade haben. Für CentOS mit pcs existiert diese Möglichkeit leider nicht.
Nodes online und offline schalten
Wenn Sie einen Node, beispielsweise wegen notwendiger Wartungsarbeiten, aus dem Cluster herausnehmen müssen, bietet Pacemaker Ihnen dafür eine einfache Möglichkeit.
Geben Sie auf dem betreffenden Node dieses Kommando ein:
# Debian/Ubuntu/openSUSE Leap
crm node standby
# CentOS
pcs cluster standby
Listing 19.26 Einen Knoten auf »Standby« schalten
Wenn Sie gerade nicht auf dem Node eingeloggt sind, den Sie auf Standby schalten wollen, können Sie die Aktion trotzdem ausführen. Geben Sie das Kommando auf einem anderen Clusterknoten ein, und hängen Sie den Namen des Knotens an, den Sie stoppen möchten, so wie in Listing 19.27 dargestellt:
# Debian/Ubuntu/openSUSE Leap
crm node standby node2
#CentOS
pcs cluster standby node2
Listing 19.27 Einen Knoten remote auf »Standby« schalten
Die Ausgabe von crm status zeigt die Zustandsänderung an:
root@node2:~# crm status ### CentOS: pcs status
Last updated: Thu May 26 11:31:19 2016 Last change: […]
Stack: corosync
Current DC: node1 (version 1.1.14-70404b0) - partition with quorum
2 nodes and 0 resources configured
Node node2: standby
Online: [ node1 ]
Full list of resources:
Listing 19.28 CRM-Status, ein Node im Standby-Betrieb
Nach Abschluss der Arbeiten können Sie den Knoten mit dem folgenden Befehl wieder in den Cluster integrieren:
# Debian/Ubuntu/openSUSE Leap
crm node online
# CentOS
pcs cluster unstandby
Listing 19.29 Den Knoten wieder aktivieren
19.5.3 Quorum deaktivieren
In der Ausgabe des Befehls crm status taucht unter anderem diese Zeile auf:
Current DC: node1 (version 1.1.14-70404b0) - partition with quorum
Listing 19.30 Quorum in der Statusausgabe
Ein Quorum ist ein Datenbestand, der für alle Knoten stets zugänglich ist und den aktuellen Status des Clusters enthält. Dazu zählt beispielsweise, welcher Knoten für eine bestimmte Ressource aktuell die Master-Rolle innehat, und vieles mehr.
Sollte es zu einer Split-Brain-Situation kommen (Teile des Clusters können nicht mehr miteinander kommunizieren und wissen nicht, ob ihre Nachbarknoten noch funktionieren oder nicht), kann anhand des Quorums sehr schnell entschieden werden, wie viele Knoten des Clusters deaktiviert werden und welche weiterarbeiten dürfen.
Unser Beispiel-Cluster hat aber nur zwei Knoten – in einer Split-Brain-Situation ist von Anfang an klar, dass bei einem Ausfall der Kommunikationsverbindung zwischen den Knoten nur einer von beiden weiterarbeiten darf, um Inkonsistenzen im Datenbestand zu verhindern.[ 24 ] Ein Quorum ist deshalb in 2-Node-Clustern überflüssig. Sie können es mit diesem Befehl deaktivieren:
# Debian/Ubuntu/openSUSE Leap
crm configure property stonith-enabled=false
crm configure property no-quorum-policy=ignore
#CentOS (bereits bei den Vorbereitungen umgesetzt)
pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore
Listing 19.31 Quorum deaktivieren
Die Pacemaker-Shell
Pacemaker bringt eine eigene Shell mit. Mit ihr sind alle CRM-Befehle, die als Kommandozeilenparameter funktionieren, auch über eine Menüstruktur verfügbar (auf CentOS mit pcs gibt es diese Möglichkeit leider nicht).
Ein Beispiel: Einen Node können Sie auf der Kommandozeile, wie Sie gerade gesehen haben, mit dem Befehl crm node standby offline schalten. Mit der CRM-Shell geht das wie folgt:
-
Geben Sie auf der Kommandozeile crm ohne weitere Parameter ein. Der Prompt ändert sich in crm(live)#.
-
Um einen Überblick über Ihre Möglichkeiten zu bekommen, tippen Sie help. Sie erhalten diese Ausgabe:
[…]
Available commands:
cd Navigate the level structure
help Show help (help topics for list of topics)
ls List levels and commands
quit Exit the interactive shell
[…]Listing 19.32 Auszug der verfügbaren Kommandos oder Untermenüs
Zum Teil sind dies Befehle, die Sie ausführen können (status kennen Sie bereits), zum Teil können Sie auch tiefer in die Menüstruktur einsteigen.
-
Geben Sie auf der Kommandozeile einmal node ein. Sie befinden sich jetzt in einem Untermenü, in dem Sie die Knoten Ihres Clusters verwalten können. Der Kommandozeilenprompt hat sich in crm(live)node# geändert. Wieder zeigt help Ihnen an, welche Möglichkeiten Sie haben:
Node management and status commands.
Commands:
attribute Manage attributes
clearstate Clear node state
delete Delete node
fence Fence node
maintenance Put node into maintenance mode
online Set node online
ready Put node into ready mode
show Show node
standby Put node into standby
status Show nodes' status as XML
status-attr Manage status attributes
utilization Manage utilization attributes
cd Navigate the level structure
help Show help (help topics for list of topics)
ls List levels and commands
quit Exit the interactive shell
up Go back to previous levelListing 19.33 Verfügbare Kommandos im »node«-Untermenü
Hier finden Sie unter anderem die Kommandos standby und online wieder, die Sie auf der Kommandozeile bereits benutzt haben.
Durch Eingabe von standby oder online können Sie den aktuellen Knoten stoppen und wieder starten. Mit quit verlassen Sie die CRM-Shell, und mit up gelangen Sie in die nächsthöhere Menüebene zurück.