Proxmox HA-Cluster aufbauen: 3 Nodes, Quorum und Live-Migration ohne Drama

Einen Proxmox-Cluster zusammenzuklicken dauert zehn Minuten. Einen Cluster zu bauen, der einen echten Node-Ausfall um drei Uhr nachts ohne Datenverlust übersteht, dauert länger — und genau die Teile, die diesen Unterschied ausmachen, werden am häufigsten übersprungen: Quorum, Fencing und Shared Storage.

Hier der Aufbau eines produktiven 3-Node-HA-Clusters, in der Reihenfolge, in der wir ihn tatsächlich umsetzen.

Warum drei Nodes das Minimum sind

Hochverfügbarkeit in Proxmox beruht auf Corosync und dem Quorum-Prinzip: Entscheidungen darf nur die Mehrheit der Nodes treffen. Mit zwei Nodes gibt es keine Mehrheit — fällt einer aus, weiß der andere nicht, ob sein Partner tot ist oder nur die Verbindung weg (Split-Brain). Beide könnten dieselbe VM starten, was im Shared Storage zu Datenkorruption führt.

Drei Nodes lösen das: Bei einem Ausfall behalten zwei die Mehrheit und handeln sicher. Wer aus Budgetgründen nur zwei Nodes hat, braucht mindestens einen QDevice (ein kleiner externer Quorum-Zeuge) als dritte Stimme — sonst ist es kein HA-Cluster, sondern zwei Server mit gemeinsamem Risiko.

Das Corosync-Netz gehört separat

Corosync ist latenzempfindlich. Wenn der Cluster-Heartbeat über dieselbe Leitung läuft wie VM-Traffic, Backups oder Storage-Replikation, führen kurze Lastspitzen zu verlorenen Heartbeats — und der Cluster „fenced“ Nodes, die in Wahrheit gesund sind. Deshalb:

• Ein dediziertes, niedrig-latentes Netz für Corosync, getrennt von Storage- und VM-Traffic.
• Idealerweise ein zweiter Corosync-Ring (redundant) über ein weiteres physisches Interface, damit der Ausfall eines Switches nicht den ganzen Cluster instabil macht.
• Nicht über WLAN, nicht über überbuchte Uplinks, nicht über denselben Bond wie Ceph.

Dieser eine Punkt verhindert die meisten „der Cluster rebootet sich grundlos“-Tickets.

Den Cluster aufsetzen

Der eigentliche Cluster-Aufbau ist unspektakulär — und das ist gut so. Auf dem ersten Node erzeugt man den Cluster, die weiteren treten bei:

• Auf Node 1: Cluster anlegen (in der GUI unter Datacenter → Cluster oder per pvecm create), dabei das dedizierte Corosync-Netz als Link angeben.
• Auf Node 2 und 3: dem Cluster beitreten (Join Information aus Node 1, oder pvecm add).
• Mit pvecm status prüfen: alle Nodes online, Quorate „Yes“, erwartete Stimmenzahl korrekt.

Wichtig: Vor dem Join sollten die Nodes saubere, eindeutige Hostnamen, synchronisierte Zeit (NTP) und funktionierende Namensauflösung haben. Zeitversatz und doppelte Hostnamen sind die zwei klassischen Join-Killer.

Shared Storage — die eigentliche HA-Voraussetzung

HA bedeutet, dass eine VM auf einem anderen Node neu startet, wenn ihr Node ausfällt. Das geht nur, wenn der neue Node die Disk der VM auch erreicht. Lokaler Storage allein reicht dafür nicht. Zwei gängige Wege:

• Ceph (hyperkonvergent): verteilter Storage über alle Nodes, jede VM-Disk liegt repliziert im Cluster. Unser Standard für echte HA — fällt ein Node aus, sind die Daten auf den anderen sofort verfügbar. Die richtige Auslegung dafür haben wir in einem eigenen Beitrag beschrieben.
• ZFS mit Replikation: günstiger und einfacher, aber asynchron — zwischen zwei Replikationsläufen kann es zu minimalem Datenverlust kommen. Gut für kleinere Umgebungen mit toleranter RPO.

Ein häufiges Missverständnis: Ein NAS per NFS macht den Storage zwar gemeinsam, aber das NAS wird dann selbst zum Single Point of Failure. Echte HA braucht auch beim Storage Redundanz.

Fencing und Watchdog — der übersprungene Teil

Bevor Proxmox eine VM auf einem anderen Node neu startet, muss sicher ausgeschlossen sein, dass sie woanders noch läuft — sonst gibt es dieselbe VM zweimal. Diesen Ausschluss leistet das Fencing. Proxmox nutzt dafür einen Hardware-Watchdog (oder den Software-Watchdog), der einen hängenden oder isolierten Node nach Ablauf eines Timers hart zurücksetzt.

• Wo vorhanden, den Hardware-Watchdog der Server-Plattform (IPMI/TCO) nutzen — zuverlässiger als der Software-Fallback.
• Den Watchdog vor dem Produktivgang testen: Node isolieren und beobachten, ob er sauch wirklich self-fenced.
• Ohne funktionierendes Fencing ist HA nicht sicher — Proxmox verweigert im Zweifel den Failover, was besser ist als doppelt laufende VMs.

HA-Gruppen und Prioritäten

Nicht jede VM soll überall laufen. Über HA-Gruppen steuert man, auf welchen Nodes eine VM bevorzugt läuft und wohin sie im Failover wandert:

• HA-Ressourcen für die VMs anlegen, die wirklich hochverfügbar sein müssen — nicht pauschal für alle.
• Gruppen mit Prioritäten definieren, damit kritische VMs auf den stärkeren Nodes landen.
• Genug Reserve einplanen: Wenn ein Node ausfällt, müssen die anderen dessen VMs zusätzlich tragen. Ein Cluster, der schon im Normalbetrieb zu 90 % ausgelastet ist, kann den Ausfall nicht auffangen.

Live-Migration testen — vor dem Ernstfall

Live-Migration verschiebt eine laufende VM ohne nennenswerte Unterbrechung auf einen anderen Node — die Grundlage für wartungsfreie Updates. Das muss vor dem Produktivgang getestet werden, nicht im Störfall improvisiert:

• Eine Test-VM live zwischen allen Nodes hin- und herschieben und Ping/Dienst dabei beobachten.
• Bei gemischten CPU-Generationen den passenden CPU-Typ wählen (oder einen gemeinsamen Nenner), sonst scheitert die Migration an fehlenden CPU-Flags.
• Einen kompletten Node in den Wartungsmodus nehmen (alle VMs evakuieren) und prüfen, ob der Cluster das sauber trägt.

Was im echten Ausfall passiert

Wenn ein Node hart ausfällt, läuft Folgendes ab: Corosync bemerkt den Verlust, die verbleibenden Nodes behalten das Quorum, der ausgefallene Node wird gefenced (Watchdog-Reset), und die HA-Manager starten die betroffenen VMs auf den verbliebenen Nodes neu. Aus VM-Sicht ist das ein unsauberer Neustart — die VM bootet, sie wird nicht live verschoben. Genau deshalb ist Anwendungs-Resilienz (Datenbank-Konsistenz, Wiederanlauf) Teil des Konzepts, nicht nur die Infrastruktur.

Stolperfallen aus echten Projekten

• Corosync auf dem Storage-Netz. Funktioniert im Test, kollabiert unter Last. Heartbeat immer trennen.
• Zwei-Node-„HA“ ohne QDevice. Kein Quorum, kein sicherer Failover. Entweder drei Nodes oder QDevice.
• Fencing nie getestet. Im Ernstfall stellt sich heraus, dass der Watchdog nie aktiv war — und der Failover bleibt aus.
• Cluster zu voll. Ohne N+1-Reserve kann der Ausfall eines Nodes nicht aufgefangen werden, die übrigen gehen in die Überlast.
• Backups vergessen. HA schützt vor Hardware-Ausfall, nicht vor Ransomware oder Fehlbedienung. HA ersetzt kein Backup — beide gehören zusammen.

Fazit

Ein belastbarer Proxmox-HA-Cluster steht und fällt mit den unsichtbaren Teilen: einem separaten Corosync-Netz, echtem Shared Storage, funktionierendem Fencing und ehrlicher Kapazitätsreserve. Wer diese vier Punkte ernst nimmt, bekommt eine Plattform, die Wartung im laufenden Betrieb erlaubt und einen Node-Ausfall in Minuten statt in Stunden abfängt.

Wenn Sie einen HA-Cluster planen oder einen bestehenden absichern wollen: unsere Proxmox-Leistung beschreibt das Vorgehen, und für den Storage-Unterbau lohnt der Blick auf die richtige Ceph-Dimensionierung. Grundbegriffe klärt das Glossar zu Proxmox VE — und für Ihren konkreten Fall sprechen Sie uns an.