Proxmox HA-Cluster: Quorum, Fencing und das Ende der Einzelhost-Sorgen

Ein einzelner Proxmox-Host ist praktisch — bis er ausfällt. Dann steht alles. Ein HA-Cluster mit drei Knoten ist die Antwort, aber er verlangt, dass man ein paar Konzepte verstanden hat. Hier ist, was zählt.

Die Mindestanatomie

Drei Knoten. Mit zwei Knoten gibt es kein Quorum, der Split-Brain ist vorprogrammiert. Drei Knoten können einen Ausfall verkraften und trotzdem entscheiden: Die verbleibenden zwei haben Mehrheit, die verwaisten VMs werden neu gestartet.

pvecm create <clustername>
pvecm add <ip-des-zweiten-knotens>
pvecm add <ip-des-dritten-knotens>

Fertig ist der Cluster. Aber HA braucht mehr als Corosync.

Nur zwei Knoten? Das QDevice

Nicht jeder hat Budget für drei vollwertige Server. Für diesen Fall gibt es das QDevice (corosync-qnetd): eine externe, ressourcenarme Drittinstanz — eine kleine VM oder sogar ein Raspberry Pi ausserhalb des Clusters — die als Schiedsrichter eine zusätzliche Quorum-Stimme liefert. Damit wird ein Zwei-Knoten-Cluster quorumsfähig und überlebt den Ausfall eines Knotens. Das QDevice speichert keine VMs, es stimmt nur mit ab.

Corosync: Das Quorum will Redundanz und niedrige Latenz

Corosync ist latenzempfindlich. Es gehört auf ein dediziertes, schnelles Netz und idealerweise auf zwei getrennte Ringe (link0/link1 auf verschiedenen NICs), damit ein einzelner Netzwerkfehler nicht gleich das Quorum kippt.

Fencing: Der unterschätzte Lebensretter

Fencing bedeutet: ein ausgefallener Knoten wird vom Rest des Clusters hart abgeschaltet — Strom weg, Neustart. Ohne Fencing weiss der Cluster nicht, ob der Knoten wirklich tot ist oder nur das Netzwerk hängt. Eine VM, die noch auf dem vermeintlich toten Knoten läuft, während der Cluster sie auf einem anderen startet, produziert Datenkorruption.

Wir nutzen IPMI-Fencing: das iDRAC/iLO des Servers wird vom Cluster angewiesen, den Host aus- und wieder einzuschalten. Das klingt brutal, aber es ist die einzige saubere Lösung.

Shared Storage: Ohne geht es nicht

HA ohne Shared Storage ist ein Witz. Die VM-Disk muss auf einem Storage liegen, den alle Knoten erreichen. Wir fahren Ceph dafür — im Storage-VLAN mit Jumbo Frames, wie im Netzwerk-Artikel beschrieben. Alternativ geht ZFS-Replikation, aber das ist kein synchroner Shared Storage, sondern asynchrone Kopie.

HA-Groups: VMs gezielt platzieren

Über HA-Groups mit Prioritäten legt man fest, auf welchen Knoten eine VM bevorzugt läuft und wohin sie im Fehlerfall ausweicht — etwa damit lastintensive VMs nicht alle auf demselben Ersatzknoten landen.

Was wir falsch gemacht haben

• Zu wenig Corosync-Redundanz: Wir hatten Corosync auf dem gleichen physischen Interface wie den Storage-Traffic. Bei Jumbo-Frame-Problemen hing nicht nur Storage, sondern auch das Quorum. Jetzt läuft Corosync über eine zweite, separate NIC.
• HA ohne Test: Nach dem Aufbau nicht den Stecker gezogen. Macht man genau einmal. Beim ersten Ernstfall stellte sich heraus, dass Fencing nicht griff, weil iDRAC-Zugangsdaten falsch hinterlegt waren.

Was HA nicht kann

Anwendungsfehler nicht auffangen. Wenn das ERP abstürzt, weil eine fehlerhafte Transaktion läuft, hilft kein Cluster. HA fängt Hardware- und Host-Ausfälle — der Rest ist Anwendungswissen.

Fazit

Ein Proxmox-HA-Cluster ist der Endpunkt der Virtualisierungsreise. Drei Knoten (oder zwei plus QDevice), Shared Storage, Fencing — dann laufen VMs auch nachts um drei weiter, wenn niemand zusieht. Der Bau dauert einen Tag. Das Testen den nächsten.