QDevice für ein 2‑Node Proxmox VE Cluster einrichten

Ein Zwei‑Node‑Cluster klingt zunächst einfach, doch sobald ein Node ausfällt, fehlt dem verbliebenen Node die notwendige Stimmenmehrheit (Quorum) und der Cluster schaltet sich in den read‑only‑Modus. In solchen Szenarien springt das QDevice (Quorum Device) ein: Es fungiert als leichtgewichtiger Drittanbieter, der eine zusätzliche Stimme liefert und damit das Quorum auch bei Ausfall eines Nodes aufrechterhält. Da das QDevice keine virtuellen Maschinen hostet oder Speicher bereitstellt, kann es auf einer kleinen VM, einem LXC‑Container oder einem dedizierten Mini‑Server laufen – idealerweise auf einer aktuellen Debian‑ oder Ubuntu‑Distribution, damit die Abhängigkeiten zu Proxmox VE 9 problemlos passen.

Bevor die Installation beginnt, sollten zwei bereits konfigurierte Proxmox‑VE 9‑Nodes im Cluster vorhanden sein (z.B. pve1.lab.local und pve2.lab.local). Zusätzlich wird ein drittes, leichtgewichtiges Linux‑System benötigt, das als QDevice dienen soll (z.B. qdevice.lab.local). Zwischen allen drei Maschinen muss SSH‑Zugriff mit den Root-Usern bestehen und Root‑Privilegs vorhanden sein. Eine funktionierende Namensauflösung (DNS oder /etc/hosts) sowie synchronisierte Zeit über NTP sind ebenfalls essenziell, damit Corosync korrekt kommunizieren kann.

Installation auf dem QDevice

Auf dem vorgesehenen QDevice führen wir zuerst ein Paket‑Update durch und installieren anschließend die beiden notwendigen Pakete:

apt update
apt install corosync-qnetd corosync-qdevice -y

corosync-qnetd stellt den Daemon dar, der auf dem QDevice lauscht, während corosync-qdevice die Client‑Komponente bereitstellt, die von den Proxmox‑Nodes verwendet wird, um mit dem QDevice zu kommunizieren. Nach der Installation aktivieren und starten wir den Dienst:

systemctl enable corosync-qnetd
systemctl start corosync-qnetd

Mit systemctl status corosync-qnetd lässt sich schnell prüfen, ob der Dienst aktiv und fehlerfrei läuft.

Installation auf den Proxmox‑Nodes

Auf beiden Proxmox‑Servern benötigen wir nur das Client‑Paket:

apt update
apt install corosync-qdevice -y

Kein zusätzlicher Daemon muss hier gestartet werden; die Kommunikation erfolgt über das bereits laufende qnetd auf dem QDevice.

Einbindung des QDevice in den Cluster

Nun wechseln wir zu einem der Proxmox‑Nodes (z. B. pve1) und führen den Setup‑Befehl aus:

pvecm qdevice setup qdevice.example.local

Dieser Befehl stellt eine Verbindung zum QDevice her, konfiguriert es als zusätzlichen Voters und verteilt automatisch die notwendigen Schlüssel sowie Konfigurationsdateien. Es ist wichtig, dass der Hostname oder die IP‑Adresse des QDevice von beiden Cluster‑Nodes aus auflösbar und erreichbar ist; andernfalls schlägt die Einrichtung fehl.

Überprüfung des Setups

Nach erfolgreichem Setup lässt sich der Status des Clusters mit dem bekannten Befehl abfragen:

pvecm status

Die Ausgabe sollte unter dem Abschnitt „Quorum information“ einen Eintrag für das QDevice zeigen (Node ID 0, Votes 1) und den Zustand „Quorate“ ausweisen. Beispielhafter Auszug:

Quorum information
------------------
Date: Sat Oct 18 22:05:13 2025
Quorum provider: corosync_votequorum
Nodes: 2
...
Quorate: Yes
...
Votequorum information
----------------------
Expected votes: 3
Total votes: 3
Quorum: 2
...
Membership information
----------------------
Nodeid Votes Name
1 1 pve1 (local)
2 1 pve2
0 1 Qdevice

Die Anwesenheit des QDevice mit einer Stimme und dem Quorate‑Status bestätigt, dass das Setup funktioniert.

Test der Fail‑Sicherheit

Um die Resilienz zu validieren, fahren wir einen der beiden Proxmox‑Nodes herunter (oder trennen dessen Netzwerkverbindung). Auf dem verbliebenen Node führen wir erneut pvecm status aus. Ist das Cluster weiterhin quorate und zeigt das QDevice als aktiven Voter an, hat das QDevice seine Aufgabe erfüllt: Der verbleibende Node kann weiterarbeiten, virtuelle Maschinen bleiben laufen und HA‑Operationen bleiben möglich.

Fehlerbehebung

Sollte die Einrichtung nicht wie erwartet funktionieren, empfiehlt es sich, folgende Punkte zu prüfen:

Der Port 5403/tcp muss zwischen den Proxmox‑Nodes und dem QDevice offen sein (qnetd lauscht hier standardmäßig).
Hostnamen müssen korrekt auflösen; ein fehlender DNS‑Eintrag oder fehlerhafte /etc/hosts‑Einträge führen zu Verbindungsproblemen.
Zeit synchronisieren: Alle Systeme sollten einen laufenden NTP‑Client besitzen, damit Corosync‑Zeitstempel konsistent sind.
Logs liefern oft genaue Hinweise: journalctl -u corosync-qnetd auf dem QDevice und journalctl -u corosync auf den Proxmox‑Nodes zeigen Verbindungsfehler, Authentifizierungsprobleme oder Konfigurationswidersprüche.

Fazit

Ein QDevice ist eine schlank gehaltene, aber wirkungsvolle Ergänzung für Zwei‑Node‑Proxmox‑VE‑Clustern. Es liefert die fehlende Stimme, die nötig ist, um Quorum auch bei Ausfall eines Nodes zu wahren, ohne dass ein dritter vollwertiger Proxmox‑Host erforderlich sein muss. Die Einrichtung lässt sich mit wenigen Paketen und kurzen Befehlen durchführen, und nach erfolgreichem Test bietet das System eine stabile HA‑Umgebung – ideal für kleinere Installationen, Edge‑Umgebungen oder Testlabore, bei denen Ressourcen gespart werden sollen, aber Ausfallsicherheit dennoch gefordert ist.

Referenzen

https://www.saturnme.com/how-to-install-and-configure-qdevice-for-a-2-node-proxmox-ve-cluster/