HA-Cluster mit Proxmox und 2 Knoten: Quorum, QDevice und Fencing richtig einrichten

Ein HA-Cluster mit Proxmox und 2 Knoten ist in der Praxis ein Sonderfall: Er ist schnell aufgebaut, aber beim Thema Quorum (Mehrheitsentscheid im Cluster) und Fencing (hartes Isolieren eines fehlerhaften Knotens, um Datenkorruption zu verhindern) deutlich anspruchsvoller als ein klassischer 3‑Knoten‑Verbund. Der Grund ist simpel: Bei genau zwei Stimmen gibt es ohne dritten „Taktgeber“ keine Mehrheit. Sobald Kommunikation oder Storage wackelt, drohen „Split Brain“-Situationen – also zwei Seiten, die jeweils glauben, sie seien die gültige Instanz.

Dieser Beitrag zeigt praxisnah, wie Sie Quorum bei zwei Proxmox‑Knoten korrekt lösen (QDevice), wie Fencing in Proxmox realistisch umgesetzt und getestet wird (inklusive Watchdog) und welche Prüf- und Rückfallstrategien im Betrieb helfen. Fokus sind Auswirkungen auf Verfügbarkeit, Datenintegrität und Betrieb – nicht Framework-Details.

HA-Cluster mit Proxmox und 2 Knoten in der Praxis

In Proxmox basiert die Clusterkommunikation auf Corosync (Cluster-Messaging) und die Cluster-Konfiguration liegt in pmxcfs (Proxmox Cluster File System, ein verteiltes, quorum-abhängiges Konfigurationsfilesystem). Für Clusterentscheidungen nutzt Corosync ein Quorum: Nur wenn eine Mehrheit erreichbar ist, gilt die Clusteransicht als „valid“ und schreibende Clusteraktionen werden erlaubt.

Bei drei Knoten ist das robust: Zwei von drei bilden eine Mehrheit. Bei zwei Knoten ist es ohne Hilfsmittel fragil: Fällt ein Knoten oder nur die Verbindung aus, bleibt eine Stimme übrig – und das ist keine Mehrheit. Der Cluster blockiert dann (im besten Fall). Im schlimmsten Fall umgehen Admins Quorum-Schutzmechanismen und riskieren Split Brain: Beide Seiten laufen weiter, schreiben auf denselben Storage oder führen widersprüchliche HA-Aktionen aus.

Wichtig für die Planung: „HA“ ist nicht nur „VM startet auf anderem Host“. HA bedeutet vor allem konsistente Entscheidungen im Fehlerfall. Dafür braucht es entweder mindestens drei Stimmen oder eine externe, kontrollierte „Drittstimme“.

Grundprinzip: QDevice als Drittstimme für Proxmox Quorum

Die saubere Lösung für zwei Proxmox‑Knoten ist ein QDevice. Dabei handelt es sich nicht um einen weiteren Proxmox‑Host, sondern um eine Quorum-Hilfe: Ein externer Dienst (qnetd, Corosync Quorum Net Daemon) stellt über Netzwerk eine zusätzliche Stimme bereit. Die Clusterknoten binden sich als Clients (qdevice) an diesen Dienst. Damit kann bei einem Ausfall oder einer Partition wieder eine Mehrheit entstehen: 1 Knoten + QDevice = 2 Stimmen (Mehrheit von 3).

Warum das funktioniert: QDevice trifft keine „HA-Entscheidungen“, sondern dient als kontrollierter Zeuge, welcher Partition die zusätzliche Stimme gegeben wird. Das reduziert Split‑Brain‑Risiko deutlich, ersetzt aber kein Fencing. Denn auch mit Quorum kann ein Knoten „noch laufen“, aber bereits unsicher sein (z. B. Storage hängt, Kernel hängt, I/O-Timeouts). Dann brauchen Sie einen Mechanismus, der sicherstellt: Nur ein Host darf weiter auf gemeinsam genutzte Ressourcen schreiben.

Voraussetzungen und Design-Check vor der Umsetzung

Bevor Sie QDevice oder Fencing konfigurieren, klären Sie die Rahmenbedingungen. Viele 2‑Knoten‑Setups scheitern nicht an Proxmox selbst, sondern an unausgesprochenen Annahmen über Netzwerk, Storage oder Stromversorgung.

1) Netzwerk: mindestens zwei Pfade, definierte Latenz, saubere MTU

Für Corosync zählt nicht „Bandbreite“, sondern stabile Latenz und geringe Paketverluste. Planen Sie idealerweise getrennte Netze (oder VLANs) für Management/Cluster (Corosync) und VM‑Traffic. Wenn Sie ein eigenes Corosync‑Interface nutzen, achten Sie auf identische MTU und konsistente Switch‑Konfiguration. „Jumbo Frames nur irgendwo“ sind ein Klassiker für sporadische Partitions.

2) Storage: Shared Storage vs. Replikation

Bei HA in Proxmox kommen häufig zwei Muster vor:

• Shared Storage (z. B. iSCSI/NFS/SAN): Beide Hosts sehen denselben Datastore. Vorteil: VM kann schnell auf dem anderen Host starten. Risiko: Split Brain kann Storage korrupt machen, wenn beide Hosts gleichzeitig schreiben.
• Replizierter Storage (z. B. ZFS-Replikation): Daten werden zwischen Hosts synchronisiert/periodisch repliziert. Vorteil: weniger „gleichzeitiges Schreiben“ auf denselben Blockdevice. Nachteil: RPO/RTO hängen von Replikationsintervallen und Failover-Prozess ab.

Für beide gilt: Ohne Fencing ist Shared Storage im 2‑Knoten‑Betrieb besonders riskant. Selbst mit QDevice sollte Fencing als „letzte Instanz“ vorgesehen werden.

3) Out-of-Band-Management und Watchdog

Für verlässliches Fencing brauchen Sie typischerweise ein Out-of-Band‑Interface wie IPMI (BMC‑Fernwartung) oder eine schaltbare PDU. Alternativ existieren storagebasierte Mechanismen (z. B. SBD), die in Proxmox‑Umgebungen aber häufig außerhalb des Standardpfads liegen. Zusätzlich sollte ein Watchdog aktiv sein: Das ist ein Hardware- oder Kernel‑Timer, der den Host neu startet, wenn das System „hängt“ und ihn nicht mehr regelmäßig „füttert“ (keepalive). Das adressiert Deadlocks, bei denen ein Host noch Strom hat, aber keine sicheren Entscheidungen mehr trifft.

Umsetzung: QDevice (qnetd) für zwei Proxmox‑Knoten einrichten

Die Empfehlung aus Betriebssicht: Betreiben Sie den QDevice‑Dienst auf einem dritten System, das unabhängig von den beiden Proxmox‑Hosts ist (anderer Stromkreis/USV, idealerweise anderes Rack/Standortsegment). Das kann eine kleine VM oder ein Mini‑Server sein. Wichtig ist weniger Performance als Erreichbarkeit und saubere Netzpfade.

Schritt 1: QNetd auf dem QDevice‑Host installieren

Beispiel für ein Debian/Ubuntu‑System als QDevice‑Host:

sudo apt update
sudo apt install -y corosync-qnetd
sudo systemctl enable --now corosync-qnetd
sudo systemctl status corosync-qnetd

Stellen Sie sicher, dass die Firewall den qnetd‑Port zulässt (standardmäßig TCP 5403). In restriktiven Netzen ist das oft der erste Stolperstein: Corosync läuft intern typischerweise über UDP/Multicast oder UDP/Unicast, qnetd dagegen über TCP.

Schritt 2: Zeit und Namensauflösung sauber machen

Cluster-Komponenten reagieren empfindlich auf Zeitdrift. Aktivieren Sie NTP/Chrony auf allen Systemen. Außerdem sollte die Namensauflösung stabil sein (DNS oder /etc/hosts), weil Zertifikate und Identitäten bei qdevice/qnetd eine Rolle spielen können.

Schritt 3: QDevice im Proxmox‑Cluster registrieren

Auf einem Proxmox‑Knoten (typischerweise dem, der den Cluster initialisiert hat) binden Sie QDevice ein. Proxmox stellt dafür pvecm (Proxmox VE Cluster Manager) bereit.

# Status prüfen
pvecm status

# QDevice hinzufügen (Hostname oder IP des QNetd-Hosts)
pvecm qdevice setup <QNETD_HOSTNAME_ODER_IP>

Der Setup‑Prozess erzeugt und verteilt notwendige Schlüssel/Zertifikate und schreibt die Corosync‑Konfiguration entsprechend um. Danach prüfen Sie erneut den Clusterstatus:

pvecm status
pvecm qdevice status

Erwartung im 2‑Knoten‑Cluster: Sie sehen neben den zwei Node‑Votes zusätzliche Quorum‑Informationen durch QDevice. Wenn QDevice nicht erreichbar ist, fällt das Quorum im Fehlerfall wieder auf das problematische 2‑Stimmen‑Modell zurück.

Typische Stolperfallen bei QDevice

• QDevice im selben Layer‑2‑Segment wie beide Nodes, aber an derselben Switch‑Kante: Fällt der Switch aus, fällt QDevice gleich mit. Der „dritte Zeuge“ ist dann nicht unabhängig.
• QDevice als VM auf dem Proxmox‑Cluster selbst: Das ist ein Zirkelschluss. Wenn der Cluster wackelt, wackelt auch die VM, die Quorum stabilisieren soll.
• Unscharfe Firewall-Regeln: qnetd benötigt stabile TCP‑Konnektivität. Paketverlust oder TLS‑Inspection auf dem Pfad kann zu sporadischen Disconnects führen.
• Zu aggressive Corosync‑Timeout‑Tuningversuche: In kleinen Netzen wirken kürzere Timeouts „schneller“, erhöhen aber Fehltrigger bei kurzen Störungen. Erst messen, dann ändern.

Fencing in Proxmox: Warum Quorum allein nicht reicht

Auch mit QDevice gilt: Quorum sagt nur, wer entscheiden darf. Es sagt nicht, ob ein anderer Knoten wirklich gestoppt ist. Genau hier kommt Fencing ins Spiel (oft auch STONITH genannt: „Shoot The Other Node In The Head“). Ziel: Wenn ein Host aus Sicht des Clusters ausfallen muss, wird er zuverlässig ausgeschaltet oder zurückgesetzt, bevor Ressourcen (VMs, Storage) auf dem anderen Host weiterlaufen.

In Proxmox wird HA über den integrierten HA Manager gesteuert. Der HA Manager kann Services (VMs/Container) verwalten und im Fehlerfall verschieben. Aber: Wenn beide Hosts gleichzeitig glauben, sie seien „aktiv“, kann HA ohne Fencing falsche Aktionen ausführen. Mit Shared Storage ist das besonders gefährlich, weil Datenblöcke parallel beschrieben werden können.

Realistische Fencing-Optionen im 2‑Knoten‑Betrieb

• IPMI/Redfish Power Off/Reboot: Der Klassiker im Serverbetrieb. Voraussetzung: BMC ist erreichbar, getrennt abgesichert, nicht über dasselbe Netz wie das Problemsegment.
• Schaltbare PDU / Smart Power: Funktioniert auch, wenn BMC instabil ist. Muss aber organisatorisch sicher betrieben werden (Zugriffsrechte, Logging).
• Watchdog + Selbstfencing: Wenn der Host intern erkennt, dass er unsicher ist (z. B. verliert Quorum/Cluster), kann er sich selbst neu starten. Das ist kein Ersatz für externes Fencing, aber erhöht Robustheit gegen „hängende“ Zustände.

Wichtig: Ein „sauberes Shutdown“ ist nicht Fencing. Fencing muss im Zweifel hart sein, weil genau im Fehlerfall „sauber“ oft nicht mehr zuverlässig funktioniert.

Watchdog in Proxmox aktivieren und prüfen (Best Practice)

Ein Watchdog ist ein Mechanismus, der das System zurücksetzt, wenn es nicht mehr reagiert. Unter Linux ist häufig /dev/watchdog über ein Kernelmodul verfügbar (z. B. iTCO_wdt bei Intel‑Plattformen). Proxmox kann Watchdog für HA nutzen, um in Deadlock-Situationen nicht „halb tot“ weiterzulaufen.

Schritt 1: Prüfen, ob ein Watchdog-Gerät verfügbar ist

ls -l /dev/watchdog* || true

# Kernelmeldungen zum Watchdog
dmesg | grep -i watchdog || true

# Geladene Module
lsmod | grep -i wdt || true

Wenn kein Gerät auftaucht, prüfen Sie BIOS/UEFI‑Optionen (Watchdog/Server Management) und passende Kernelmodule. In virtualisierten Umgebungen kann Watchdog über die VM‑Plattform bereitgestellt werden; auf Bare Metal ist es typischerweise Hardware/Chipsatz.

Schritt 2: Proxmox Watchdog-Konfiguration prüfen

Je nach Proxmox‑Version und Setup wird Watchdog über Systemdienste/HA-Komponenten aktiviert. Als grober Check im Betrieb:

systemctl status pve-ha-lrm pve-ha-crm || true
journalctl -u pve-ha-lrm -u pve-ha-crm --since "-2h" | tail -n 200

Interpretation: Sie suchen nicht „grüne“ Services, sondern Hinweise, dass HA‑Komponenten laufen und keine wiederkehrenden Timeouts/Restart-Loops auftreten. Wenn HA nicht genutzt wird, ist Watchdog trotzdem als Sicherheitsnetz sinnvoll – aber dann müssen Ihre Betriebsprozesse (Monitoring/Alerting) Host‑Hänger zuverlässig erkennen.

Praxis-Checkliste: Vor dem ersten HA-Failover testen

Bevor produktive VMs als HA‑Ressourcen laufen, führen Sie kontrollierte Tests durch. Ziel ist nicht „es klappt einmal“, sondern „wir verstehen, wann es nicht klappt und wie wir dann reagieren“.

1) Cluster- und Quorum-Status baseline

pvecm nodes
pvecm status

# Corosync-Health grob prüfen
systemctl status corosync
journalctl -u corosync --since "-1h" | tail -n 200

Achten Sie auf Paketverlust, Token-Timeouts und wiederkehrende Membership‑Wechsel. Ein 2‑Knoten‑Cluster muss „langweilig“ laufen: keine ständigen Rejoins, keine Flaps.

2) QDevice-Status und Abhängigkeit prüfen

pvecm qdevice status

# QNetd vom Node aus erreichen
nc -vz <QNETD_HOSTNAME_ODER_IP> 5403

Wenn der TCP‑Connect sporadisch scheitert, lösen Sie das vor HA‑Aktivierung. Sonst stehen Sie im Fehlerfall ohne Mehrheitsstimme da.

3) Simulierter Link-Ausfall: Corosync-Netz trennen

Trennen Sie kontrolliert das Corosync‑Interface (nicht das Management, damit Sie weiter administrieren können) und beobachten Sie, was passiert: Erhält eine Seite Quorum? Bleibt die andere Seite sauber blockiert? Genau hier zeigt sich, ob QDevice und Netzdesign funktionieren.

Beobachtung während des Tests:

watch -n 2 'pvecm status; echo; pvecm qdevice status'

Wenn beide Seiten weiterhin „aktiv“ wirken oder HA‑Aktionen unklar werden, ist das ein Warnsignal: Dann müssen Sie Fencing/Isolierung und Netzpfade noch einmal sauber planen.

Typische Fehlerbilder und Troubleshooting im Betrieb

Fehlerbild A: „Cluster hat kein Quorum“ nach kurzem Netzruckler

Ursachen: Paketverlust auf Corosync‑Pfad, Switch‑Buffer/Queue‑Probleme, MTU‑Mismatch, QoS/Policing, virtuelle Switches mit Drops. In 2‑Knoten‑Setups merkt man das sofort, weil es keine dritte Stimme gibt, die die Sicht stabilisiert.

Vorgehen:

• Corosync‑Logs auf Token‑Timeouts prüfen.
• Netzpfad messen: Drops auf NIC/Switchports, Errors, CRC, Duplex.
• Wenn möglich: zweites Corosync‑Netz (Redundanz) konfigurieren, statt Timeouts „schönzutunen“.

Fehlerbild B: QDevice ist erreichbar, aber Quorum verhält sich „unerwartet“

Ursachen: QDevice nicht unabhängig (teilt Ausfallursache), Namensauflösung/Zertifikatsprobleme, instabile TCP‑Session, asymmetrisches Routing. Prüfen Sie, ob wirklich beide Nodes stabil mit qnetd sprechen und ob qnetd selbst unterbrechungsfrei läuft.

Quick Checks:

# Auf dem QDevice-Host
systemctl status corosync-qnetd
journalctl -u corosync-qnetd --since "-2h" | tail -n 200

Fehlerbild C: VM läuft nach Failover, aber Storage ist inkonsistent oder „stuck“

Das ist der gefährliche Fall: Quorum/HA haben „irgendwie“ reagiert, aber ohne sicheres Fencing kann der alte Host noch I/O absetzen oder Locks blockieren. Je nach Storage (NFS, iSCSI, Cluster‑FS, Ceph) äußert sich das als Hänger, Dateisystemfehler oder kaputte VM‑Disks.

Maßnahmen:

• Im Zweifel: betroffenen Host hart ausschalten (Out-of-Band), bevor Sie weiter debuggen.
• Storage‑Logs prüfen (Target/Controller‑Seite). Viele Ursachen liegen nicht auf dem Hypervisor.
• HA‑Ressourcen erst wieder freigeben, wenn klar ist, dass keine „Doppelwriter“ aktiv sind.

Umsetzungsempfehlung: Minimal robustes 2‑Knoten‑HA-Design

Wenn Sie aus Budget- oder Platzgründen bei zwei Knoten bleiben müssen, ist das Ziel ein Design, das im Fehlerfall vorhersagbar reagiert. Ein praxistaugliches Minimalpaket sieht so aus:

• 2 Proxmox‑Hosts mit getrennten Netzpfaden für Corosync/Management/VM‑Traffic (mindestens logisch via VLAN, besser physisch).
• 1 unabhängiger QDevice‑Host (qnetd), nicht auf den beiden Proxmox‑Hosts betrieben.
• Out-of-Band‑Fencing (IPMI/Redfish oder PDU) als definierter Notfallprozess, inklusive Zuständigkeiten und Zugriffswegen.
• Watchdog aktiv und getestet, um Hängerzustände zu entschärfen.
• Runbooks für Partition/Storage‑Hänger: Wer schaltet wann welchen Host aus, wie wird wieder synchronisiert, wie wird Datenkonsistenz validiert?

Das ist weniger „glamourös“ als Feature-Listen, reduziert aber reale Ausfälle und vor allem Datenrisiken.

Rückfallstrategie und Recovery: Was tun, wenn Quorum/Fencing falsch reagiert?

In der Praxis müssen Sie davon ausgehen, dass es mindestens einmal zu einem unklaren Zustand kommt: Teilpartition, Storage‑Freeze, BMC nicht erreichbar, HA‑Failover hängt. Entscheidend ist dann, eine konservative Recovery‑Sequenz zu haben, die Daten schützt.

Konservative Recovery-Sequenz (bewährt im Betrieb)

1. Schreibzugriffe stoppen: Wenn Shared Storage im Spiel ist und Sie Doppelwriter vermuten, priorisieren Sie das harte Stoppen eines Knotens (OOB Power Off), bevor Sie „freundlich“ umkonfigurieren.
2. Clusterzustand stabilisieren: Erst wenn klar ist, welcher Host „Master“ sein soll, stellen Sie Corosync/Quorum wieder her (Netzpfad, qnetd‑Erreichbarkeit).
3. Storage validieren: Je nach Backend: Dateisystemchecks, Storage‑Controller‑Logs, iSCSI‑Sessions, NFS‑Locks. Ziel: keine stillen Inkonsistenzen.
4. HA-Services kontrolliert aktivieren: Nicht sofort „alles auf Autopilot“, sondern schrittweise, mit Monitoring auf I/O‑Latenz, Locks, Kernel‑Errors.

Als Operator-Regel: Lieber 10 Minuten länger sauber entscheiden als 10 Stunden Datenwiederherstellung. Zwei Knoten verzeihen keine Unklarheit.

Abschließendes Fazit: 2 Knoten sind möglich – aber nur mit Disziplin

Ein HA-Cluster mit Proxmox und 2 Knoten kann zuverlässig betrieben werden, wenn Sie die systemische Schwäche (keine natürliche Mehrheit) bewusst ausgleichen. QDevice ist dabei kein „Nice-to-have“, sondern die Grundlage, um Quorum im Fehlerfall überhaupt sinnvoll zu erreichen. Fencing und Watchdog sind die Sicherheitsnetze, die Datenkorruption und undefinierte Zustände verhindern, wenn die Realität (Storage‑Hänger, Netzflaps, halb defekte Hosts) zuschlägt.

Wenn Sie heute planen: Kalkulieren Sie QDevice und Fencing von Anfang an ein, testen Sie die kritischen Ausfälle kontrolliert und dokumentieren Sie einen konservativen Recovery‑Ablauf. So wird aus einem „kleinen“ 2‑Knoten‑Cluster ein Setup, das im Betrieb nicht von Hoffnung, sondern von klaren Zuständen lebt.

Für dieses Thema sind auch Proxmox Qdevice und Proxmox Fencing wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.