Proxmox Cluster mit 2 Nodes Drucken

Nicht jeder Proxmox-Cluster benötigt gleich drei oder mehr Server. Gerade in kleineren Unternehmen, Homelabs oder Testumgebungen stehen häufig nur zwei Hosts zur Verfügung. Diese lassen sich problemlos zu einem gemeinsamen Proxmox-Cluster verbinden.

Allerdings gibt es bei einem Zwei-Node-Cluster eine Besonderheit: Sobald einer der beiden Hosts ausfällt, verliert der verbleibende Node normalerweise sein Quorum.

Das kann im laufenden Betrieb zu Problemen führen. Bestimmte Verwaltungsaktionen sind nicht mehr möglich, Änderungen an der Cluster-Konfiguration werden blockiert und auch die automatische Wiederherstellung hochverfügbarer virtueller Maschinen ist betroffen.

Mit einem sogenannten QDevice lässt sich dieses Problem lösen, ohne einen vollständigen dritten Proxmox-Server betreiben zu müssen.

1. Was ist das Problem bei einem Proxmox Cluster mit 2 Nodes?

Um das Problem zu verstehen, müssen wir uns zunächst ansehen, wie Proxmox entscheidet, ob ein Cluster noch funktionsfähig ist.

Proxmox verwendet dafür das sogenannte Quorum.

Jeder Node besitzt standardmäßig eine Stimme. Damit ein Cluster weiterhin Änderungen an seiner gemeinsamen Konfiguration durchführen darf, benötigt er die Mehrheit der vorgesehenen Stimmen.

Bei einem Cluster mit drei Nodes ist das relativ einfach: Zwei der drei Nodes müssen erreichbar sein, damit das Quorum erhalten bleibt.

Bei nur zwei Nodes sieht es anders aus.

Nehmen wir an, unser Cluster besteht aus:

• pve1: 192.168.10.11

• pve2: 192.168.10.12

Beide Nodes besitzen jeweils eine Stimme.

Solange beide Hosts erreichbar sind, verfügt der Cluster über zwei von zwei Stimmen und besitzt damit Quorum.

Fällt allerdings einer der Hosts aus, bleibt nur noch eine Stimme übrig.

Das reicht nicht mehr aus.

Der Grund dafür ist das Mehrheitsprinzip: Eine von zwei Stimmen ist keine Mehrheit.

Warum macht Proxmox das überhaupt?

Auf den ersten Blick könnte man meinen, Proxmox sollte den verbleibenden Node einfach weiterarbeiten lassen.

Das Problem ist allerdings, dass ein Node nicht immer erkennen kann, warum sein Gegenüber nicht mehr erreichbar ist.

Vielleicht wurde der andere Server tatsächlich ausgeschaltet. Vielleicht funktioniert aber auch nur die Netzwerkverbindung zwischen den beiden Hosts nicht mehr.

In letzterem Fall könnten beide Nodes weiterhin laufen, ohne miteinander kommunizieren zu können.

Würden nun beide unabhängig voneinander Änderungen am Cluster durchführen oder dieselben virtuellen Maschinen starten, könnte eine sogenannte Split-Brain-Situation entstehen.

Bei gemeinsam genutztem Storage wäre das besonders kritisch.

Das Quorum verhindert solche widersprüchlichen Zustände, indem nur eine ausreichend große Cluster-Partition Änderungen vornehmen darf.

2. Was passiert, wenn ein Zwei-Node-Cluster das Quorum verliert?

Ein fehlendes Quorum bedeutet nicht automatisch, dass alle bereits laufenden virtuellen Maschinen sofort heruntergefahren werden.

Die Auswirkungen betreffen zunächst vor allem die Cluster-Verwaltung.

Proxmox verwendet für die gemeinsame Konfiguration das Proxmox Cluster File System pmxcfs, das unter /etc/pve eingebunden ist.

Verliert ein Node das Quorum, wird dieses Dateisystem für normale Änderungen schreibgeschützt.

Dadurch lassen sich beispielsweise bestimmte Konfigurationsänderungen oder neue Cluster-Aktionen nicht mehr durchführen.

Auch das Starten zusätzlicher VMs und HA-Operationen kann dadurch verhindert werden.

Den aktuellen Zustand können wir auf einem Proxmox-Node mit folgendem Befehl überprüfen:

pvecm status

In einem Zwei-Node-Cluster ohne QDevice könnten die relevanten Informationen nach dem Ausfall eines Nodes beispielsweise so aussehen:

Quorate:          No

Expected votes:   2
Total votes:      1
Quorum:           2

Entscheidend ist die Zeile:

Quorate: No

Der Cluster besitzt keine ausreichende Mehrheit mehr.

Für einen reinen Testcluster mag das noch akzeptabel sein. Wer seine beiden Hosts jedoch produktiv betreiben und auch beim Ausfall eines Nodes möglichst handlungsfähig bleiben möchte, sollte sich mit einem QDevice beschäftigen.

3. Was ist ein QDevice?

Ein QDevice ist vereinfacht gesagt eine zusätzliche Instanz, die bei der Quorum-Entscheidung hilft.

Dafür muss kein dritter Proxmox-Server eingerichtet werden.

Es genügt ein separater Linux-Host, der den Dienst corosync-qnetd ausführt.

Dieser externe Dienst arbeitet mit den QDevice-Diensten auf den Proxmox-Nodes zusammen und kann dem Cluster eine zusätzliche Stimme bereitstellen.

Unser Cluster besteht damit aus:

Proxmox Node 1 ───── Proxmox Node 2
       │                     │
       │                     │
       └────── QDevice ──────┘
              (QNetd)

Damit stehen insgesamt drei Stimmen zur Verfügung:

Für das Quorum sind weiterhin zwei Stimmen erforderlich.

Fällt jetzt einer der Proxmox-Nodes aus, kann der verbleibende Node zusammen mit dem QDevice die benötigte Mehrheit erreichen.

Das QDevice ist dabei kein zusätzlicher Cluster-Node im eigentlichen Sinne. Es betreibt weder virtuelle Maschinen noch stellt es Storage bereit.

Seine Aufgabe besteht ausschließlich darin, bei der Quorum-Entscheidung zu helfen.

Was passiert bei einer Netzwerkunterbrechung?

Besonders interessant wird das QDevice, wenn beide Proxmox-Nodes zwar weiterhin laufen, aber ihre Verbindung zueinander verlieren.

In dieser Situation darf das QDevice seine Stimme nicht einfach beiden Seiten geben.

Stattdessen entscheidet der externe QNetd-Dienst, welcher Cluster-Partition die zusätzliche Stimme zugeteilt wird.

Dadurch kann nur eine Seite das erforderliche Quorum erhalten.

Welche Seite gewinnt, hängt vom verwendeten Entscheidungsalgorithmus und dessen Konfiguration ab. Die Standardkonfiguration ist nicht als Garantie dafür zu verstehen, dass immer derselbe bevorzugte Node gewinnt.

4. Voraussetzungen für ein QDevice

Für die Einrichtung benötigen wir einen bereits funktionierenden Proxmox-Cluster mit zwei Nodes.

Wie dieser erstellt wird, haben wir in unserer Anleitung Proxmox Cluster erstellen – Schritt für Schritt beschrieben.

Zusätzlich benötigen wir einen dritten Linux-Host für den QNetd-Dienst.

Für unsere Beispielumgebung verwenden wir folgende Adressen:

Als Betriebssystem für den QDevice-Host verwenden wir Debian.

Das QDevice benötigt vergleichsweise wenig Rechenleistung und kann deshalb auch auf einer kleinen virtuellen Maschine betrieben werden.

Wichtig ist allerdings, wo diese virtuelle Maschine läuft.

Wenn unser QDevice auf pve1 betrieben wird und genau dieser Host ausfällt, verlieren wir gleichzeitig den Proxmox-Node und den externen Quorum-Voter.

Damit hätten wir das eigentliche Problem nicht gelöst.

Das QDevice sollte deshalb möglichst auf unabhängiger Infrastruktur betrieben werden, beispielsweise auf einem separaten Virtualisierungshost oder einem kleinen eigenständigen Linux-System.

Auch die Netzwerkverbindung muss entsprechend zuverlässig sein.

Für die Kommunikation mit QNetd wird standardmäßig TCP-Port 5403 verwendet. Zusätzlich benötigen wir während der Einrichtung SSH-Zugriff auf den externen Server.

5. QDevice unter Debian installieren

Wir beginnen mit dem externen Linux-Host.

Dort melden wir uns als Administrator an und aktualisieren zunächst die Paketlisten:

apt update

Anschließend installieren wir den QNetd-Dienst:

apt install corosync-qnetd

Nach erfolgreicher Installation sollte der Dienst verfügbar sein.

Seinen Status überprüfen wir mit:

systemctl status corosync-qnetd

Im Idealfall sehen wir hier:

Active: active (running)

Damit ist der externe QNetd-Server grundsätzlich vorbereitet.

Die weitere Zertifikats- und Cluster-Einrichtung übernehmen wir gleich über Proxmox.

6. QDevice auf den Proxmox-Nodes vorbereiten

Nun wechseln wir zurück zu unseren beiden Proxmox-Hosts.

Auf beiden Nodes muss das Paket corosync-qdevice installiert sein.

Dazu führen wir auf pve1 und pve2 jeweils Folgendes aus:

apt update
apt install corosync-qdevice

Anschließend überprüfen wir noch einmal den Cluster-Status:

pvecm status

Beide Nodes sollten online sein und der Cluster muss Quorum besitzen.

Die Einrichtung des QDevice sollte nicht begonnen werden, während der Cluster bereits Kommunikationsprobleme hat oder ein Node ausgefallen ist.

7. QDevice mit dem Proxmox Cluster verbinden

Die eigentliche Integration ist erfreulich einfach.

Wir melden uns auf einem beliebigen Node unseres funktionierenden Proxmox-Clusters an, beispielsweise auf pve1.

Dort führen wir folgenden Befehl aus:

pvecm qdevice setup 192.168.10.50

Die IP-Adresse bezeichnet unseren externen QNetd-Server.

Proxmox verbindet sich nun per SSH mit diesem Server und richtet die benötigte Kommunikation sowie Zertifikate ein.

Während dieses Vorgangs muss die SSH-Authentifizierung für root auf dem externen Host möglich sein. Dafür sollte nach Möglichkeit ein geeigneter SSH-Schlüssel verwendet werden. Alternativ kann ein passwortbasierter Root-Zugang vorübergehend für die Einrichtung erlaubt werden.

Nach erfolgreicher Einrichtung sollte der Vorgang mit einer entsprechenden Erfolgsmeldung abgeschlossen werden.

Anschließend benötigen wir auf dem QDevice-Server keinen dauerhaft aktivierten passwortbasierten SSH-Root-Login mehr.

Die eigentliche Kommunikation der QDevice-Dienste erfolgt über die dafür vorgesehene Verbindung zum QNetd-Server.

8. QDevice und Quorum überprüfen

Nach der Einrichtung kontrollieren wir erneut den Cluster-Status:

pvecm status

Jetzt sollte sich die Anzahl der erwarteten Stimmen verändert haben.

Ein funktionierender Zwei-Node-Cluster mit QDevice kann beispielsweise folgende Werte anzeigen:

Expected votes:   3
Total votes:      3
Quorum:           2

Flags:            Quorate Qdevice

In der Mitgliederübersicht erscheint zusätzlich das QDevice.

Damit wissen wir, dass der externe Quorum-Voter erfolgreich in den Cluster eingebunden wurde.

Außerdem können wir auf den Proxmox-Nodes prüfen, ob der QDevice-Dienst läuft:

systemctl status corosync-qdevice

Auf dem externen Server überprüfen wir bei Bedarf erneut:

systemctl status corosync-qnetd

Falls Proxmox das QDevice als nicht erreichbar meldet, sollten wir insbesondere die Netzwerkverbindung und TCP-Port 5403 kontrollieren.

9. Was passiert jetzt bei einem Ausfall?

Um zu verstehen, welche Vorteile das QDevice tatsächlich bringt, betrachten wir einige typische Situationen.

Damit wird auch eine wichtige Einschränkung deutlich:

Ein QDevice macht aus zwei Proxmox-Nodes noch keinen vollständig hochverfügbaren Cluster.

Es löst zunächst das Problem der fehlenden dritten Quorum-Stimme.

Damit virtuelle Maschinen nach einem Host-Ausfall tatsächlich auf dem anderen Node gestartet werden können, müssen zusätzliche Voraussetzungen erfüllt sein.

Dazu gehören insbesondere eine funktionierende HA-Konfiguration, geeigneter Storage und ausreichend freie Ressourcen auf dem verbleibenden Host.

10. QDevice ist nicht gleich High Availability

Dieser Unterschied wird gerade bei kleineren Proxmox-Installationen häufig übersehen.

Angenommen, wir betreiben eine virtuelle Maschine auf pve1.

Nun fällt der gesamte Host aus.

Dank unseres QDevice kann pve2 weiterhin Quorum besitzen.

Das bedeutet allerdings noch nicht, dass die virtuelle Maschine automatisch auf pve2 gestartet wird.

Dafür muss der zweite Host auch Zugriff auf die benötigten VM-Daten haben.

Bei lokalem Storage ist das nicht ohne Weiteres möglich.

Eine Lösung kann beispielsweise ein externer Shared Storage sein. Je nach Anforderungen kommen auch Storage-Replikation und andere Konzepte infrage, wobei mögliche Datenverluste zwischen Replikationszeitpunkten berücksichtigt werden müssen.

Zusätzlich benötigt Proxmox eine korrekt eingerichtete HA-Konfiguration, die den Ausfall erkennt und die betroffene Ressource auf einem anderen Node wiederherstellt.

In einem produktiven Zwei-Node-Cluster muss außerdem genügend Kapazität auf dem verbleibenden Host vorhanden sein, um die vorgesehenen Workloads übernehmen zu können.

Wer beide Nodes bereits im Normalbetrieb vollständig auslastet, hat im Fehlerfall entsprechend wenig Spielraum.

11. Typische Fehler bei der QDevice-Einrichtung

QDevice wird als „Not Alive“ angezeigt

In diesem Fall kann der Proxmox-Node den externen QNetd-Dienst nicht korrekt erreichen.

Mögliche Ursachen sind eine Firewall, eine fehlerhafte IP-Adresse oder ein nicht gestarteter Dienst.

Zunächst überprüfen wir auf dem externen Server:

systemctl status corosync-qnetd

Danach kontrollieren wir, ob die Verbindung auf TCP-Port 5403 möglich ist.

SSH-Verbindung während der Einrichtung schlägt fehl

Das Kommando pvecm qdevice setup benötigt während der Konfiguration administrativen SSH-Zugriff auf den externen Host.

Wenn die Verbindung abgelehnt wird, sollten SSH-Konfiguration und Authentifizierung überprüft werden.

Auch Probleme mit der SSH-Host-Key-Verifikation können den Vorgang verhindern.

QDevice läuft als VM auf einem der beiden Nodes

Technisch kann eine solche Installation unter Umständen funktionieren. Für einen zuverlässigen Betrieb ist sie jedoch ungeeignet.

Fällt der Host aus, auf dem die QDevice-VM läuft, steht gleichzeitig der zusätzliche Quorum-Voter nicht mehr zur Verfügung.

Deshalb sollte das QDevice unabhängig von den beiden Proxmox-Nodes betrieben werden.

QDevice funktioniert, aber HA startet keine VM neu

Hier liegt die Ursache nicht zwingend beim QDevice.

Zunächst muss überprüft werden, ob der verbleibende Node tatsächlich Quorum besitzt.

Anschließend sollten HA-Status, Storage-Erreichbarkeit und die Konfiguration der betroffenen VM kontrolliert werden.

Das QDevice stellt lediglich die notwendige Quorum-Entscheidung bereit. Die eigentliche Wiederherstellung von VMs ist Aufgabe der Proxmox-HA-Dienste.

12. QDevice wieder entfernen

Wenn wir unseren Cluster später erweitern möchten, müssen wir eine Besonderheit beachten.

Proxmox empfiehlt, ein vorhandenes QDevice vor dem Hinzufügen oder Entfernen von Cluster-Nodes zunächst zu entfernen.

Dazu verwenden wir auf einem Cluster-Node:

pvecm qdevice remove

Erst anschließend nehmen wir die geplanten Änderungen an der Node-Anzahl vor.

Wird der Cluster beispielsweise von zwei auf drei Nodes erweitert, ist das externe QDevice normalerweise nicht mehr erforderlich.

Drei reguläre Nodes besitzen bereits eine ausreichende Stimmenverteilung, um den Ausfall eines einzelnen Nodes zu verkraften.

13. Zwei oder drei Proxmox-Nodes – was ist sinnvoller?

Für ein Homelab oder einen kleinen Cluster kann die Kombination aus zwei Proxmox-Nodes und einem QDevice durchaus sinnvoll sein.

Wer hauptsächlich die gemeinsame Verwaltung nutzen möchte und bereits zwei geeignete Hosts besitzt, muss nicht zwangsläufig einen vollständigen dritten Server anschaffen.

Für größere produktive Umgebungen würde ich allerdings eher zu mindestens drei regulären Proxmox-Nodes tendieren.

Das gilt insbesondere dann, wenn zusätzlich verteilte Storage-Systeme wie Ceph betrieben werden sollen.

Ein QDevice ersetzt keinen dritten Storage-Node. Für eine übliche hochverfügbare Ceph-Konfiguration sind deshalb weiterhin mindestens drei geeignete Storage-Hosts sinnvoll.

Für Lern- und Schulungsumgebungen sind dagegen beide Varianten interessant.

Ein Zwei-Node-Cluster zeigt sehr anschaulich, warum Quorum überhaupt benötigt wird. Durch das nachträgliche Einrichten eines QDevice lässt sich anschließend nachvollziehen, wie sich das Verhalten des Clusters bei Ausfällen verändert.

14. Zwei-Node-Cluster in einer Proxmox-Schulungsumgebung testen

Viele Cluster-Konzepte werden erst wirklich verständlich, wenn man sie selbst ausprobiert.

Das gilt besonders für Quorum und Split-Brain-Situationen.

Wer einen Zwei-Node-Cluster in einer isolierten Umgebung aufbaut, kann beispielsweise folgende Tests durchführen:

• Cluster aus zwei Nodes erstellen

• Quorum-Status kontrollieren

• QDevice einrichten

• Einen Node kontrolliert herunterfahren

• Verhalten des verbleibenden Nodes beobachten

• QNetd-Dienst stoppen und wieder starten

• Auswirkungen auf das Quorum vergleichen

Solche Tests sollte man natürlich nicht unvorbereitet auf produktiven Systemen durchführen.

Für Schulungen, Workshops oder eigene Experimente bietet sich deshalb eine separate Testumgebung an.

Mit unserer Proxmox-Schulungsumgebung lassen sich mehrere Proxmox-Nodes für einen frei wählbaren Zeitraum bereitstellen.

Die Teilnehmer können die Installation und Cluster-Konfiguration selbst durchführen und anschließend gezielt unterschiedliche Szenarien untersuchen. Für QDevice-Tests wird zusätzlich ein geeigneter unabhängiger Linux-Host benötigt.

Fazit

Ein Proxmox-Cluster mit zwei Nodes ist technisch problemlos möglich. Wer damit allerdings mehr als nur die gemeinsame Verwaltung realisieren möchte, sollte sich frühzeitig mit dem Quorum beschäftigen.

Ohne zusätzliche Stimme verliert der verbleibende Node normalerweise das Quorum, sobald sein Gegenüber ausfällt.

Ein QDevice schafft hier Abhilfe, indem es über einen externen QNetd-Server eine dritte Stimme bereitstellt.

Damit kann ein einzelner Proxmox-Node auch nach dem Ausfall des anderen Hosts weiterhin Quorum besitzen – vorausgesetzt, er erhält die zusätzliche Stimme des QDevice.

Für kleine Cluster ist das eine sinnvolle Lösung. Wer darüber hinaus automatische VM-Wiederherstellung, verteilten Storage oder höhere Verfügbarkeit benötigt, muss allerdings auch die übrige Infrastruktur entsprechend planen.

Weiterführende Artikel

• Proxmox Cluster – der vollständige Guide

• Proxmox Cluster erstellen – Schritt-für-Schritt-Anleitung

• Proxmox Node zu einem Cluster hinzufügen (folgt)

• Corosync in Proxmox erklärt (folgt)

• Proxmox HA einrichten und testen (folgt)

Technische Referenz: Proxmox VE – Cluster Manager und QDevice