Proxmox Cluster

Selbst wenn man keine Hochverfügbarkeit braucht, kann es sinnvoll sein, zwei PVE zu einem Cluster zusammen zu fassen. Sie lassen sich dann über eine Einstiegsseite administrieren, VMs und LXCs können leichter zwischen den Knoten migrieren und auch für Monitoring-Aufgaben kann das Vorteile bieten. Hier beschreibe ich die Einrichtung eines Zwei-Knoten-Clusters, also eines Cluster aus zwei PVE. Neben den beiden PVE wird aber noch ein drittes System gebraucht, um ein Quorum zu schaffen. Ein Quorum bedeutet, dass es immer eine Mehrheit der Stimmen benötigt wird, um zu erkennen, ob ein Knoten ausgefallen ist. Bei zwei Stimmen kann ein verbleibender Knoten nicht erkennen, ob der andere ausgefallen ist oder nur die Verbindung zwischen den beiden Knoten. Der andere kann also gleichsam wie Schroedingers Katze ausgefallen sein oder auch nicht. Bei drei oder mehr Stimmen ist klar, wenn alle verbleibenden sagen, der Knoten ist ausgefallen, dann ist er das wohl auch.

Warum ist das trotzdem ein 2-Knoten-Cluster? Nun weil die dritte Stimme nicht einem dritten PVE verliehen wird, sondern irgend einem anderen Server, der nicht Teil des Clusters ist. Das kann irgend ein Server sein, den man vielleicht sowieso irgendwo noch übrig hat. Ich verwende dazu einen Proxmox Backup Server, der diese kleine Zusatzaufgabe spielend mit übernehmen kann.

Der Speicher, der von den hochverfügbar zu haltenden Ressourcen genutzt wird, muss auf beiden Knoten identisch sein. Die Hochverfügbarkeit wird durch Spiegelung der Ressourcen und Schwenken (Migrieren) von einem auf den anderen Knoten hergestellt. Mit Proxmox-Bordmitteln ohne wildes Skripting funktioniert das nur mit ZFS. Auf dem ersten Knoten wird der Speicher unter Disks/ZFS mit "Erstellen ZFS" generiert. Wenn man mehrere freie Festplatten verfügbar hat, dann kann man verschiedene RAID-Level zur Erhöhung der Ausfallsicherheit und ggf. der Durchsätze einrichten. Das ist ein Kapitel für sich.

Man wählt also die verfügbare(n) Festplatte(n) aus und das RAID-Level. Bei nur einer Platte kann man natürlich nur "Einzelne Disk" auswählen. Kompression und ashift können wie vorgeschlagen übernommen werden. Hier auf dem ersten Knoten muss das Häkchen "Storage hinzufügen" gesetzt sein. Mit Klick auf "Erstellen" wird das ZFS erstellt und direkt als lokaler Storage angebunden.

Beim zweiten Knoten verfährt man genauso. Wichtig ist, dass das ZFS den gleichen Namen erhält und dass jetzt das Häkchen "Storage hinzufügen" nicht gesetzt sein darf.

Auf der Weboberfläche des ersten Knotens unter Rechenzentrum/Cluster kann man anklicken "Erstelle Cluster". In dem sich öffnenden Dialog gibt man dem Cluster einen Namen und wählt die zu nutzende Netzwerkkarte aus. Wenn man in dem PVE zwei Netzwerkkarten zu einer ausfallsicheren Netzverbindung gebündelt hat oder ohnehin nur eine hat, dann kann man getrost diese eine nehmen. Empfohlen wird allgemein, den Clusterverkehr (den sogenannten Heartbeat) über eine separate Netzwerkverbindung zu führen. Das muss man aber nicht.

Mehr kann und muss man hier nicht einstellen. Nach Bestätigung mit dem Button "Erstellen" wird das Cluster erstellt. Es enthält allerdings bisher nur einen Knoten, was für ein Cluster doch sehr wenig ist.

Auch das Hinzufügen von PVEs als weitere Knoten zu dem Cluster geht sehr einfach. Nachdem das Cluster erst einmal erstellt wurde, kann man auf ersten Knoten die Beitrittsinformationen für das Cluster aufrufen und in die Zwischenablage kopieren.

Dann wechselt man auf die Web-GUI des zweiten Knoten und klickt dort auf "Cluster beitreten". Der darauf folgende Dialog ist wieder sehr selbsterklärend. Wenn man die Beitrittsinformationen aus der Zwischenablage in das Feld "Informationen" einfügt, dann werden IP-Adresse und Fingerabdruck des ersten Knotens im Cluster sofort erkannt und eingetragen. Hier könnte man, wenn vorhanden, eine andere Netzwerkkarte für den Cluster-Heartbeat auswählen. Es geht aber auch mit nur einer bzw. einem Bond. Falls eine Firewall im Spiel sein sollte, muss man noch den Port 5403 für den Cluster-Heartbeat auf allen beteiligten Systemen öffnen. Nun muss man noch das Root-Passwort des ersten Knotens hier eingeben und mit "Join <<NAME>>" bestätigen. Dabei wird die laufende Verbindung zum hinzuzufügenden Knoten unterbrochen, weil viele wichtige Dienste auf diesem Knoten neu gestartet werden. Man muss die Seite aktualisieren und sich neu anmelden. Alternativ kann man das Browserfenster aber auch schließen, weil man ja nun über die Web-Gui des Clusters, welche über die IP-Adresse von jedem Knoten erreichbar ist, alle Knoten administrieren kann.

Wenn hierbei keine Fehler gemacht wurden, dann haben wir ein Cluster, aber noch kein stabiles Quorum.

Die dritte Stimme soll in meinem Cluster ein Server bekommen, der ansonsten mit dem Cluster nichts zu tun hat. In meinem Fall ist das ein Proxmox Backup Server, der ohnehin in meinem Homelab seinen Dienst versieht. Ich muss dazu einfach auf dem PBS das QNet Daemon-Paket installieren. Ich melde mich dazu auf der SSH-Shell des PBS an und gebe den Befehl

apt install corosync-qnetd

ein. Mehr muss ich hier eigentlich nicht tun. Wenn ich misstrauisch bin, kann ich den Erfolg mit dem Befehl

systemctl status corosync-qnetd

überprüfen. Hier sollte neben vielen anderen Informationen, der Status

active (running)

zu lesen sein. Noch haben wir aber kein 3-Stimmen-Quorum, weil die beiden Knoten noch nicht wissen, dass der PBS hier als QDevice zur Verfügung steht.

Zunächst ist das QDevice Client-Paket auf beiden PVE-Knoten zu installieren.

apt install corosync-qdevice

Danach muss dem Cluster das QDevice noch bekannt gemacht werden. Dazu wird das Setup auf einem der beiden Knoten ausgeführt:

pvecm qdevice setup <IP-Adresse des QDevices>

Hier ist nun wichtig, dass der Knoten, auf dem das ausgeführt wird, eine SSH-Verbindung zum Server mit dem QDevice herstellen kann. Auf der Firewall muss also Port 22 geöffnet sein und Root-Login muss zugelassen werden. Wenn man das aus Sicherheitsgründen deaktiviert hat, dann muss man das temporär zurück nehmen. Nun wird das Root-Passwort des QDevice-Servers abgefragt und wenn alles funktioniert hat, dann sollte nun ein Zwei-Knoten-Cluster mit einem QDevice als dritter Stimme stehen. Das prüft man mit dem Befehl

pvecm status

der auf einem der beiden Clusterknoten ausgeführt wird. Hier sollte nun eine Ausgabe wie folgt erscheinen:

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate Qdevice 

Das Zwei-Knoten-Cluster steht nun robust zur Verfügung.

Zunächst sollte man prüfen, ob der ZFS-Speicher wirklich für beide Knoten verfügbar ist. Dazu wählt man unter "Rechenzentrum/Storage" auf der Web-GUI des Clusters das entsprechende ZFS aus. Wenn dort nur ein Knoten eingetragen sein sollte, dann lässt sich der andere einfach hinzufügen.

Die folgenden Schritte beziehen sich auf Proxmox 9.x. Unter der Version 8 war das noch völlig anders.

Unter "Rechenzentrum/HA" ist zunächst eine Ressource hinzuzufügen. Hier wählt man eine VM aus und gibt vor, wie viele Neustartversuche und wie viele Verschiebungen maximal erlaubt sind. Hier ist es sinnvoll, jeweils eine 1 stehen zu lassen. Wenn ein Schwenk einmal nicht erfolgreich ist, dann besteht ein größeres Problem, das der Aufmerksamkeit eines beherzten Administrators oder einer beherzten Administratorin bedarf. Die vorgeschlagenen Parameter können daher alle übernommen werden.

Das konkrete Verhalten bei einer Einschränkung der Verfügbarkeit muss noch definiert werden. Das geschieht mit einer Affinitätsregel für den Knoten, also unter "Rechenzentrum/HA/Affinitätsregeln". Mit einer HA Knoten-Affinität wird festgelegt, welche Präferenz bezüglich der zur Auswahl stehenden Knoten die Clusterressource, also das zu schützende Gastsystem haben soll. Eine hohe Priorität stellt dabei eine hohe Präferenz dar.

Hier wird für die VM 100 eine Priorität von 100 für Knoten 1 und eine Priorität von 10 für Knoten 2 definiert. Wenn Knoten 1 ausfällt, dann wird die VM auf Knoten 2 geschwenkt und wenn Knoten 1 wieder verfügbar ist, wird sie zurück geschwenkt. Bei gleichen Prioritäten würde sie ohne Eingriff oder Ausfall des zweiten Knotens nicht zurück migriert.

Ergänzend kann man noch mit einer Ressourcenaffinitätsregel vorgeben, dass zum Beispiel bestimmte Ressourcen beim Schwenken nicht getrennt oder im Gegenteil nicht zusammen gelegt werden dürfen. Bei einem Cluster mit mehr als zwei Knoten und Gästen, die sich gegenseitig beeinträchtigen könnten oder die möglichst nicht über Knotengrenzen und Firewalls kommunizieren sollen, kann man sich hier sicher sinnvolle Konstellationen ausdenken.

Damit das Schwenken im Bedarfsfall zügig funktioniert, muss noch für jede HA-Ressource eine Replikation eingerichtet werden. Das geschieht unter "Replizierung". Diesen Punkt kann man unter "Rechenzentrum/Replizierung" ansteuern oder bei den Parametern für die Ressource, also hier die VM. Hier wählt man das Replikationsziel aus und das Intervall. Ein kurzes Intervall stellt eine bessere Absicherung dar, kostet aber auch Ressourcen. Wenn man den Netzwerktraffic oder die Platten-Durchsätze schonen will, kann man hier noch eine Drosselung der Übertragungsbandbreite angeben. Das sollte im Normalfall nicht notwendig sein.

Wenn das nun alles ohne Fehlermeldungen durchgelaufen ist, dann haben wir ein HA-Cluster und eine entsprechend abgesicherte Ressource. Wenn in diesem Beispiel die VM auf node1 läuft und dieser ausfällt, dann wird sie auf den anderen Knoten geschwenkt. Da das Quorum zunächst ein paar Sekunden (in der Regel 60) wartet, bevor es von einem Ausfall des Knotens ausgeht und den Schwenk einleitet, steht das virtuelle System für ca. eine Minute nicht zur Verfügung. Wenn der präferierte Knoten wieder verfügar ist, schwenkt das Cluster wieder um. Das geht nun schneller, weil keine Bedenkzeit notwendig ist. Die Unterbrechung beträgt nur wenige Sekunden und die meisten Dienste bekommen das gar nicht richtig mit.

Wenn man den Schwenk der Ressourcen für geplante Wartungsarbeiten manuell antriggert, dann wird dieser Schwenk zunächst durchgeführt aber auch sofort wieder rückgängig gemacht. In den HA-Knoten-Affinitäten ist ja eine entsprechende Priorität definiert. Nun kann man vor geplanten Arbeiten und bewussten Schwenks diese Parameter manuell ändern. Eleganter ist es, den betroffenen Knoten in Wartung zu versetzen. Das geht leider nicht über die Web-GUI. Man muss die Konsole bemühen und

ha-manager crm-command node-maintenance enable <KNOTENNAME>

eingeben. Der Knoten wechselt dann in den Wartungsmodus und die Ressourcen schwenken nach kurzer Zeit. Wenn alle Ressourcen geschwenkt sind, können die Wartungsarbeiten beginnen. Nach Abschluss der Wartungsarbeiten kann man den Wartungsmodus wieder mit

ha-manager crm-command node-maintenance enable

beenden. Nach einer kurzen Bedenkzeit schwenken die Ressourcen dann wieder entsprechend der HA-Affinität zurück.