Wenn zwei sich streiten … Two-Node-Cluster mit Proxmox VE korrekt einrichten

Proxmox VE (PVE) ist eine auf Debian basierende Open-Source Virtualisierungslösung für KVM-basierte virtuelle Maschinen und Linux-Container des österreichischen Unternehmens Proxmox Server Solutions GmbH. Neben der einfachen Installation punktet PVE vor allem mit seinem intuitiven Web-Interface zur Verwaltung der virtuellen Maschinen, Container und des Storage, sowie der hervorragenden Dokumentation.

Man kann PVE als einfachen Hypervisor auf einem Server betreiben oder im Cluster. Im Cluster-Betrieb profitiert man dann von Funktionen wie Replikation, Hochverfügbarkeit (HA) und Live-Migration von virtuellen Maschinen. Container lassen sich natürlich auch zwischen Cluster-Nodes verschieben, allerdings muss der Container dazu gestoppt werden.

Der Two-Node-Cluster

Ein Cluster ist in PVE mit wenigen Handgriffen eingerichtet, dabei gibt es allerdings einige Fallstricke, auf die man achten sollte, gerade wenn man sich im etwas „kleineren Rahmen“ bewegt. Administratoren, die große PVE-Cluster im produktiven Umfeld betreiben, sind hier jetzt eigentlich fertig und sollten sich nicht mehr zur Zielgruppe dieses Artikels zählen. Aber nehmen wir mal an, man betreibt im kleineren Umfeld einen PVE-Server, um darauf Dienste wie z. B. Nextcloud, eine Dokumentenverwaltung, einen Blog etc. bereitzustellen. Da wäre es doch nicht schlecht, einen zweiten Server zu haben, der bei Ausfall oder Wartung des Ersten dessen Dienste relativ störungsfrei übernehmen kann?

Genau hier kommt der Cluster ins Spiel. Nach dem Einrichten und Hinzufügen der beiden Nodes in den Verbund freut man sich über die erste Live-Migration, wie einfach eine Replikation der Instanzen zwischen den beiden Nodes einzurichten ist und wie bequem es ist, beide Nodes über ein gemeinsames Web-Interface zu bedienen.

Dann kommt irgendwann mal der Moment, an dem man zu Testzwecken einen der beiden Nodes herunterfährt und der Freude folgt die Ernüchterung … der verbliebene Node verhält sich nun nämlich etwas „seltsam“. VMs und Container laufen zwar weiter, können aber nicht mehr beendet werden, es können keine neuen Instanzen gestartet werden und es kann auch keinerlei Konfiguration am Cluster vorgenommen werden.

Das Quorum

Was ist passiert? Kurz gesagt, man hat nicht an das „Quorum“ gedacht. Ein Cluster braucht ein Quorum (Mehrheit), um Entscheidungen zu fällen. Unser verbliebener Node weiß nämlich im Moment nicht, was passiert ist. Er kann seinen Cluster-Partner nicht erreichen, ist aber nicht in der Lage zu entscheiden, ob das nun an ihm selbst oder am Partner liegt. Oder an einem Netzwerkausfall zwischen beiden Systemen. Der Cluster befindet sich in einer „Split Brain“ Situation. In einer HA-Umgebung wäre es jetzt fatal, die gleichen Instanzen wie auf dem vermeintlich ausgefallenen System zu starten. sollte z. B. das Netz wieder da sein, laufen plötzlich zwei Instanzen mit der gleichen IP-Adresse im Netzwerk und das wäre extrem ungünstig. Deshalb, und auch weil der Node nicht in der Lage ist, seine Konfiguration mit dem Clusterpartner zu synchronisieren, kommt es zum beschriebenen Verhalten und der Node schränkt seine Aktionen ein.

Hätte der überlebende Node jetzt noch einen weiteren Ansprechpartner im Cluster, könnte er diesen fragen, ob er den Ausfall des anderen Nodes bestätigen kann. Falls ja, kann der überlebende Node seine HA-Aktionen gefahrlos durchführen. Das Quorum ist erfüllt. Vereinfacht gesagt: Es gibt 3 Nodes, jeder hat 1 Stimme. Für einen „normalen“ Betrieb werden mindestens 2 Stimmen benötigt (Quorum 2). Ist das nicht der Fall, wird vorsichtshalber „dichtgemacht“.

Jetzt wissen wir, dass in einem PVE-Cluster mindestens drei Nodes vorhanden sein müssen, damit es beim Ausfall eines Systems nicht zu Problemen kommt. Ja, es gibt den Befehl pvecm expected 1 mit dem in einem Two-Node-Cluster auf dem überlebenden Node das Quorum temporär heruntergesetzt werden kann. Der Node wäre damit wieder voll funktionsfähig. Er benötigt ja nur noch eine Stimme und die hat er selbst. Das ist aber nur eine temporäre Lösung und auch nicht besonders sicher (Split Brain!). Muss man jetzt wirklich noch einen dritten Proxmox VE Server einrichten, den man vielleicht gar nicht benötigt und der nur unnötig Ressourcen verschwendet? Nein, muss man nicht, ein sogenanntes QDevice reicht dazu völlig aus.

Das QDevice

Ein QDevice ist ein Service, der im Cluster nur die Funktion hat, eine „externe“ Stimme bereitzustellen, um das nötige Quorum aufrechtzuerhalten. Proxmox VE verwendet hier die QDevice Net Implementierung, die aus einem QNet-Daemon und QDevice-Clients besteht. Die QDevice-Clients werden auf den Cluster-Nodes installiert, der QNet-Daemon auf einem externen System. Einzige Voraussetzung ist, dass das System eine dauerhafte Netzwerkverbindung zum Cluster hat. Das kann dann z. B. auch ein ressourcenschonender Raspberry Pi sein. Des Weiteren wird die Installation nur in Clustern mit einer geraden Anzahl an Nodes empfohlen, bei einer ungeraden Anzahl ist es zum einen gar nicht nötig, zum anderen kann es dann zu unschönen Nebenwirkungen kommen (siehe hier).

Installation

Die Installation ist mit wenigen Schritten erledigt. Zuerst wird auf dem externen System der QNet-Daemon installiert:

apt install corosync-qnetd

Dann wird auf jedem Cluster-Node das Corosync QDevice installiert:

apt install corosync-qdevice

Auf einem beliebigen Cluster-Node wird dann folgender Befehl ausgeführt:

pvecm qdevice setup <QDEVICE-IP>

QDEVICE-IP ist die IP-Adresse des externen Systems. Es ist darauf zu achten, dass das externe System zumindest temporär Root-Zugriff über SSH mit Passwort-Authentifizierung zulässt, da zur Absicherung der Cluster-Kommunikation ein SSH-Key übertragen werden muss.

Damit ist die Einrichtung auch schon erledigt. Folgender Befehl zeigt die erfolgreiche Installation:

pvecm status

[…]

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

Membership information
~~~~~~~~~~~~~~~~~~~~~~
    Nodeid      Votes    Qdevice Name
    0x00000001          1    A,V,NMW 192.168.0.1 (local)
    0x00000002          1    A,V,NMW 192.168.0.2
    0x00000000          1            Qdevice
 

Man sieht die beiden Cluster-Nodes, das externe QDevice, die Anzahl der Votes (3 Stimmen) und das benötigte Quorum (2).

Fällt nun ein Cluster-Node aus, sinkt die Zahl der „Total Votes“ auf 2, entspricht damit aber immer noch dem Quorum von 2. Damit verhält sich der 2-Node-Cluster wie ein echter 3-Node-Cluster und es gibt keine Einschränkungen beim Ausfall eines Systems.

In der Proxmox VE Dokumentation wird noch auf einen wichtigen Punkt hingewiesen: fügt man einem bestehenden 2-Node-Cluster mit QDevice einen weiteren „echten“ Node hinzu, sollte das QDevice vorher entfernt werden (pvecm qdevice remove). Es wird dann auch gar nicht mehr benötigt, das Quorum ist mit drei Cluster-Nodes ja erfüllt.

Fazit

In kleinen Umgebungen oder zu Testzwecken ist es nicht unbedingt nötig, einen vollwertigen 3-Node-Cluster einzurichten, um in den Genuss der Cluster-Funktionalität von Proxmox VE zu kommen. Ein 2-Node-Cluster mit QDevice reicht hier schon völlig aus. Der Cluster lässt sich dann sogar ressourcenschonend nur mit einem laufenden Node betreiben, falls man den zweiten nur während Wartungsarbeiten benötigt. Auf ein High-Availability-Setup muss man dann zwar verzichten, kann aber weiterhin Replication und Live-Migration nutzen, falls man mal eine VM oder einen Container von einem Node auf den anderen verschieben möchte. Bei zwei eigenständigen Proxmox VE Instanzen geht das dann nur über den Umweg Backup und Restore, sofern beide Server z. B. über NFS-Zugriff auf den Backup-Storage des jeweils andern haben. 

Seminarempfehlung