Proxmox 2-Node-Cluster mit QDevice: Quorum ohne dritten Server

Zwei Server sind in vielen Umgebungen gesetzt: Mehr Budget gibt es nicht, ausfallen darf trotzdem nichts. Genau an dieser Stelle scheitern viele Proxmox-Setups am Quorum. Dieser Guide zeigt, wie ein QDevice aus zwei Nodes einen stabilen Cluster macht - und wo die ehrlichen Grenzen liegen. Die Grundlagen für größere Cluster behandelt der Guide zum HA-Cluster-Aufbau.

Warum zwei Nodes kein Quorum haben

Corosync entscheidet nach dem Mehrheitsprinzip: Nur der Teil des Clusters, der mehr als die Hälfte der Stimmen hält, darf Änderungen schreiben. Bei zwei Nodes hat jeder genau eine Stimme. Fällt ein Node aus oder reißt die Verbindung zwischen beiden ab, hält keine Seite die Mehrheit - der Cluster wird read-only. Keine VM-Starts, keine Konfigurationsänderungen, kein Failover. Ausgerechnet in dem Ausfall, für den der zweite Server angeschafft wurde, blockiert der Cluster.

Was ein QDevice ist

Ein QDevice besteht aus zwei Teilen: dem Daemon corosync-qdevice auf jedem Cluster-Node und dem externen Arbitrator corosync-qnetd auf einem dritten Host. Proxmox unterstützt ausschließlich den Algorithmus „QDevice Net" (Proxmox-Cluster-Doku). Der Arbitrator verbindet sich über TCP/IP, unterliegt keiner Corosync-Latenzanforderung und darf deshalb außerhalb des Cluster-LANs stehen. Jede erreichbare Linux-Maschine genügt - typischerweise eine kleine VM an einem anderen Standort. Der Raspberry Pi ist gängige Community-Praxis, aber keine offizielle Empfehlung der Doku.

Für die Planung wichtig: Proxmox unterstützt QDevices für Cluster mit gerader Node-Zahl und empfiehlt sie ausdrücklich für 2-Node-Cluster. Bei ungeraden Node-Zahlen rät die Doku ab. Das QDevice liefert dort N-1 Stimmen, und fällt der qnetd aus, darf kein weiterer Node mehr ausfallen.

Schritt 1: Externen QDevice-Host bereitstellen

Wählen Sie eine Linux-Maschine, die beide Nodes per TCP/IP erreichen. Da keine Latenzanforderung besteht, ist ein anderer Standort sogar sinnvoll: Der Arbitrator überlebt dann den Ausfall des Serverraums, den er absichern soll.

Schritt 2: corosync-qnetd installieren

Auf dem externen Host:

apt install corosync-qnetd

Schritt 3: corosync-qdevice auf beiden Nodes installieren

Auf beiden Proxmox-Nodes:

apt install corosync-qdevice

Schritt 4: QDevice einrichten

Auf einem der beiden Nodes:

pvecm qdevice setup <IP-des-Arbitrators>

Der Befehl richtet die Zertifikate ein und nimmt das QDevice in die Corosync-Konfiguration auf.

Schritt 5: Quorum und Failover testen

pvecm status sollte nun drei erwartete Stimmen zeigen, inklusive der Qdevice-Zeile. Fahren Sie testweise einen Node herunter: Der verbleibende Node hält mit dem QDevice zwei von drei Stimmen und bleibt beschlussfähig.

Finger weg von den Abkürzungen

Drei verbreitete „Lösungen" ersetzen das QDevice nicht:

• two_node: 1: Das Corosync-Flag birgt Fence-Races und Split-Brain-Risiko und ist in der PVE-Doku nicht als Muster vorgesehen.
• auto_tie_breaker: laut votequorum-Manpage inkompatibel mit einem QDevice - nicht kombinieren.
• pvecm expected 1: ein reines Notfall-Kommando, um einen einzelnen Node wieder beschlussfähig zu machen, keine Dauerkonfiguration.

HA und Storage auf zwei Nodes

Die HA-Doku verlangt „mindestens drei Cluster-Nodes" für verlässliches Quorum (Proxmox-HA-Doku). Das QDevice liefert diese dritte Stimme, HA funktioniert damit technisch - drei echte Nodes bleiben aber die dokumentierte Empfehlung. Zum Fencing: Verliert ein Node das Quorum, fenced er sich nach 60 Sekunden selbst per Watchdog, erst danach startet HA die Gäste auf dem anderen Node neu.

Beim Storage scheidet Ceph aus, es braucht mindestens drei Nodes. Das Muster für zwei Nodes ist ZFS plus Storage-Replikation (pvesr): Sie funktioniert nur mit ZFS, repliziert asynchron im Standardintervall von 15 Minuten (minimal 1 Minute). Beim Failover kann daher das letzte Delta verloren gehen - HA ist erlaubt, aber der Workload muss diesen möglichen Datenverlust verkraften.

Unser Vorgehen bei WZ-IT

Wir bauen 2-Node-Cluster mit QDevice regelmäßig: Quorum-Design, Replikations-Intervalle passend zum Workload, Failover-Tests vor der Übergabe - als Proxmox-Setup mit Dokumentation oder im Managed Proxmox ab 179,90 € pro Node und Monat inklusive Monitoring von Nodes und Arbitrator. Ob zwei Nodes plus QDevice für Ihren Fall reichen oder ein dritter Node die bessere Investition ist, klären wir gern in einem kostenlosen Erstgespräch.