Proxmox VE: Cluster und Hochverfügbarkeit

Aus maxTechCorner

Auf einen Blick

Gilt fürProxmox VE 9.x (aktuelle 9.2) ab zwei Knoten, Corosync mit Kronosnet, HA-Manager, Proxmox Datacenter Manager 1.0
BereichServer-Software
Dauerca. 2–4 Stunden für Cluster, QDevice und HA-Grundkonfiguration
Rechteroot@pam auf allen Knoten, Zugriff auf Switches und Netzplanung
StandOktober 2026

Einen Proxmox-VE-Cluster mit Hochverfügbarkeit einrichten heißt, mehrere Knoten per Corosync zu koppeln und VMs bei einem Ausfall automatisch neu zu starten. Dieser Artikel zeigt Planung und Aufbau des Clusters mit redundantem Corosync-Netz, den Zwei-Knoten-Betrieb mit QDevice, den HA-Manager mit Fencing, Affinitätsregeln und Lastausgleich sowie Live-Migration und die zentrale Verwaltung mehrerer Cluster mit dem Proxmox Datacenter Manager.

Aufbau eines Proxmox-VE-Clusters mit Hochverfügbarkeit: Knoten, redundantes Corosync-Netz mit zwei Links, gemeinsamer Storage und QDevice für Zwei-Knoten-Cluster liefern Quorum und Daten; der HA-Manager mit Watchdog-Fencing startet HA-Ressourcen nach einem Knotenausfall auf anderen Knoten neu, verteilt Last über den Cluster Resource Scheduler und berücksichtigt Affinitätsregeln. Für Wartung gibt es Wartungsmodus und clusterweites HA-Disarm.

Planung: Knoten, Quorum und Corosync-Netz

Ein Proxmox-Cluster ist ein Verbund gleichberechtigter Knoten mit gemeinsamer Konfiguration unter /etc/pve. Die Kommunikation übernimmt Corosync; jeder Knoten hat standardmäßig eine Stimme. Nur die Seite mit der Mehrheit der Stimmen, das Quorum, darf Änderungen vornehmen – ohne Quorum schaltet ein Knoten die Clusterkonfiguration auf schreibgeschützt.

Knoten Stimmen Ausfall verkraftbar Empfehlung
2 2 (+1 QDevice) ohne QDevice keiner, mit QDevice ein Knoten für kleine Standorte mit QDevice
3 3 ein Knoten Mindestgröße für HA und Ceph
4 4 (+1 QDevice) ein Knoten, mit QDevice zwei QDevice sinnvoll
  • Latenz: Corosync braucht zwischen allen Knoten Latenzen unter 5 ms (LAN-Niveau). Cluster über WAN-Standorte scheiden damit meist aus.
  • Eigenes Netz: Corosync ist zeitkritisch und gehört auf ein eigenes, physisch getrenntes Netz; eine dedizierte 1-Gbit/s-Karte genügt meist.
  • Zwei Links: Corosync (Kronosnet) unterstützt bis zu acht Links. Planen Sie mindestens zwei auf getrennten Netzen, z. B. Link 0 auf einem eigenen Switch und Link 1 über das Management-Netz.
  • Ports: UDP 5405–5412 zwischen allen Knoten, dazu SSH (TCP 22) für Clusteraktionen.
  • Bonds: Für Corosync keine Modi balance-rr, balance-xor, balance-tlb oder balance-alb; bei LACP bond-lacp-rate fast. Besser sind zwei unabhängige Links.
  • Zeit und Namen: Alle Knoten brauchen eine synchrone Uhrzeit (NTP) und feste IP-Adressen. Der Clustername lässt sich später nicht mehr ändern.
  • Storage: HA braucht gemeinsamen Storage (z. B. Ceph, NFS, iSCSI) oder ZFS-Replikation, bei der im Fehlerfall die Daten seit der letzten Replikation fehlen.
  • Stromausfall: Nach einem Totalausfall starten Gäste erst wieder mit Quorum – eine USV gehört zu jedem HA-Cluster.

Proxmox-Cluster erstellen und Knoten aufnehmen

Voraussetzung sind identisch installierte Knoten mit gleicher Hauptversion (siehe Proxmox VE: Installation und Grundkonfiguration) und eingerichteten Netzen für Corosync. Ein beitretender Knoten darf noch keine Gäste enthalten, da seine Konfiguration unter /etc/pve durch die des Clusters ersetzt wird.

Weboberfläche: Auf dem ersten Knoten Datacenter › Cluster › Create Cluster, Namen sowie Link 0 und Link 1 wählen. Mit Join Information die Beitrittsdaten kopieren und auf den weiteren Knoten unter Datacenter › Cluster › Join Cluster einfügen, root-Passwort des ersten Knotens eingeben, eigene Link-Adressen zuordnen.

Kommandozeile (Beispiel mit zwei Corosync-Netzen; der Link mit der höheren Priorität trägt den Verkehr): 

# Auf Knoten pve1: Cluster mit zwei Links anlegen
pvecm create kmu-cluster --link0 10.10.10.1,priority=20 --link1 10.20.20.1,priority=10

# Auf Knoten pve2: Cluster beitreten (IP von pve1, eigene Link-Adressen)
pvecm add 10.10.10.1 --link0 10.10.10.2 --link1 10.20.20.2

# Zustand prüfen
pvecm status
pvecm nodes

In der Ausgabe von pvecm status muss Quorate: Yes stehen; die Zahl der Stimmen muss zur Knotenzahl passen. Ohne gesetzte Prioritäten nutzt Corosync den Link mit der niedrigsten Nummer.

Knoten entfernen: Knoten leer räumen und ausschalten, dann auf einem verbleibenden Knoten pvecm delnode pve4. Mit alter Konfiguration darf er nicht wieder ans Netz.

Zwei-Knoten-Cluster mit QDevice

Zwei Knoten ohne dritte Stimme haben kein Quorum mehr, sobald einer ausfällt – HA kann dann nichts tun. Abhilfe schafft ein QDevice: ein externer, kleiner Dienst (corosync-qnetd), der als Schiedsrichter eine zusätzliche Stimme liefert. Er läuft auf einem Debian-System außerhalb des Clusters, etwa einem Mini-PC oder dem Proxmox Backup Server auf eigener Hardware. 

# Auf dem externen Server (Debian)
apt install corosync-qnetd

# Auf allen Clusterknoten
apt install corosync-qdevice

# Auf einem Clusterknoten (kopiert den SSH-Schlüssel auf den QDevice-Server)
pvecm qdevice setup 10.10.10.50
pvecm status
  • Der QDevice-Server muss auf TCP-Port 5403 erreichbar sein; zeigt pvecm status den Zustand NA (not alive), liegt es meist an Firewall oder Routing.
  • Für Cluster mit ungerader Knotenzahl rät Proxmox derzeit vom QDevice ab, weil es dort (N−1) Stimmen erhält und selbst zum kritischen Punkt wird.
  • Vor dem Hinzufügen oder Entfernen von Knoten das QDevice mit pvecm qdevice remove entfernen und danach neu einrichten.

HA-Manager: Ressourcen, Fencing und Regeln

Der HA-Manager startet HA-Ressourcen nach einem Knotenausfall auf einem anderen Knoten neu – keine unterbrechungsfreie Spiegelung, typischerweise vergehen rund zwei Minuten. Voraussetzungen sind mindestens drei Stimmen, gemeinsamer oder replizierter Storage und redundante Hardware (Netzteile, Netzwerk, Platten).

Fencing per Watchdog

Damit eine VM nie auf zwei Knoten gleichzeitig läuft, arbeitet Proxmox mit Fencing über Watchdog-Timer: Ein Knoten, der das Quorum verliert, startet nach Ablauf des Watchdogs (60 Sekunden) neu. Erst danach übernehmen die anderen Knoten seine HA-Ressourcen. Ohne Hardware-Watchdog nutzt Proxmox den Software-Watchdog softdog des Kernels. Einen Hardware-Watchdog (z. B. Intel TCO) tragen Sie in /etc/default/pve-ha-manager ein: 

WATCHDOG_MODULE=iTCO_wdt

Die Dienste pve-ha-crm, pve-ha-lrm und watchdog-mux nie manuell beenden – das kann einen sofortigen Neustart des Knotens auslösen.

Ressourcen hinzufügen

In der Weboberfläche unter Datacenter › HA auf Add klicken oder per Kommandozeile: 

ha-manager add vm:100 --state started --max_restart 1 --max_relocate 1
ha-manager add ct:200 --state started
ha-manager status
Option Standard Bedeutung
state started Sollzustand: started, stopped, disabled oder ignored (HA lässt die Ressource dann in Ruhe)
max_restart 1 Neustartversuche auf demselben Knoten
max_relocate 1 Versuche, die Ressource auf einen anderen Knoten zu verschieben
failback 1 Rückkehr auf den bevorzugten Knoten, sobald er wieder verfügbar ist

Ist eine VM unter HA, leitet auch qm start bzw. qm stop den Wunsch an den HA-Stack weiter.

Affinitätsregeln statt HA-Gruppen

Seit Proxmox VE 9.0 sind HA-Gruppen veraltet und werden in Node-Affinity-Regeln umgewandelt. Dazu kommen Resource-Affinity-Regeln, die Gäste zusammenhalten oder trennen – etwa zwei Domänencontroller, die nie auf demselben Knoten laufen sollen. 

# VM 100 bevorzugt auf pve1, sonst pve2 (höhere Zahl = höhere Priorität)
ha-manager rules add node-affinity bevorzugt-vm100 --resources vm:100 --nodes pve1:2,pve2:1

# Domänencontroller getrennt halten
ha-manager rules add resource-affinity dc-getrennt --affinity negative --resources vm:110,vm:111

Node-Affinity-Regeln sind standardmäßig nicht strikt (--strict 1 stoppt die Ressource, wenn keiner der genannten Knoten verfügbar ist); Resource-Affinity-Regeln sind standardmäßig strikt. Widersprüchliche Regeln erkennt der HA-Manager und deaktiviert sie.

Verhalten beim Herunterfahren

Die Shutdown Policy unter Datacenter › Options › HA Settings steuert das Verhalten beim Herunterfahren: conditional (Standard), freeze, failover oder migrate (Gäste vorher live verschieben).

Lastausgleich mit CRS und HA-Wartung

Der Cluster Resource Scheduler (CRS) entscheidet, auf welchem Knoten eine HA-Ressource bei Wiederherstellung oder Regeländerung landet. Einstellung unter Datacenter › Options › Cluster Resource Scheduling bzw. in /etc/pve/datacenter.cfg:

Modus Arbeitsweise
basic (Standard) verteilt nach Anzahl der HA-Ressourcen je Knoten
static berücksichtigt konfigurierte CPU- und RAM-Werte der Gäste
dynamic berücksichtigt die tatsächliche Last der Knoten (neu in Proxmox VE 9.2)

Mit Proxmox VE 9.2 kam der dynamische Lastausgleich hinzu: Ein automatischer Balancer prüft etwa alle zehn Sekunden die Verteilung und verschiebt HA-Gäste, wenn das Ungleichgewicht einen Schwellwert überschreitet (Standard 30 %) und die Verschiebung eine Mindestverbesserung bringt (Standard 10 %). Der Balancer setzt den Modus static oder dynamic voraus; beide Modi gelten laut Dokumentation noch als Technologievorschau. Einzelne Ressourcen lassen sich vom automatischen Ausgleich ausnehmen. 

# Beispielzeile in /etc/pve/datacenter.cfg
crs: ha=dynamic,ha-auto-rebalance=1,ha-rebalance-on-start=1

Für KMU-Cluster mit drei Knoten reicht oft static mit ha-rebalance-on-start – den automatischen Ausgleich erst nach einer Testphase aktivieren.

Wartungsmodus für einen Knoten

# HA-Ressourcen von pve2 wegmigrieren (z. B. vor Firmware-Update)
ha-manager crm-command node-maintenance enable pve2
# nach der Wartung: Ressourcen kehren zurück
ha-manager crm-command node-maintenance disable pve2

HA clusterweit entschärfen (disarm/arm)

Für Arbeiten, bei denen das Quorum wackeln kann (Umbau des Corosync-Netzes, Switch-Tausch), bietet Proxmox VE 9.2 das clusterweite Disarm: Alle Watchdogs werden freigegeben, kein Knoten wird gefenct – HA schützt dann aber auch nicht. 

ha-manager crm-command disarm-ha freeze   # Zustände einfrieren
ha-manager crm-command disarm-ha ignore   # alternativ: Ressourcen manuell verwalten
ha-manager status                         # Fencing-/Watchdog-Zustand prüfen
ha-manager crm-command arm-ha             # nach der Wartung wieder scharf schalten

Läuft gerade ein Fencing, eine Wiederherstellung oder Migration, wird das Disarm zurückgestellt.

Live-Migration und Proxmox Datacenter Manager

Mit gemeinsamem Storage verschiebt die Live Migration eine laufende VM ohne spürbare Unterbrechung; bei lokalem Storage kopiert Proxmox die Platten mit (dauert entsprechend länger). In der Weboberfläche genügt Migrate an der VM, auf der Kommandozeile: 

qm migrate 100 pve2 --online
# Container werden per Neustart verschoben (kurze Unterbrechung)
pct migrate 200 pve2 --restart
  • Migrationsnetz: Damit der Arbeitsspeicher nicht über Corosync- oder Management-Netz läuft, ein eigenes Netz festlegen, z. B. in /etc/pve/datacenter.cfg: migration: secure,network=10.30.30.0/24. secure verschlüsselt den Transfer; insecure nur in einem vollständig vertrauenswürdigen, isolierten Netz.
  • Ports: Live-Migration nutzt TCP 60000–60050 zwischen den Knoten.
  • CPU-Typ: Bei gemischten CPU-Generationen ein gemeinsames Modell wählen (z. B. x86-64-v2-AES; eigene Modelle seit 9.2 in der Weboberfläche).

Mehrere Cluster mit dem Proxmox Datacenter Manager

Der Proxmox Datacenter Manager 1.0 (Dezember 2025, AGPLv3) verwaltet mehrere Cluster, Einzelknoten und Proxmox Backup Server zentral: Ressourcenübersicht, Update-Stand, Suche, Shell, Migration zwischen Clustern, Anmeldung über LDAP, AD oder OpenID Connect. Er läuft als eigene Installation (Debian 13) und setzt mindestens Proxmox VE 8.4 bzw. PBS 3.4 voraus. HA zwischen Standorten bietet er nicht, ist aber für Filialen mit eigenen Clustern das passende Werkzeug.

Hinweise

  • Typischer Fehler: Corosync auf demselben Link wie Backup- oder Ceph-Verkehr. Unter Last steigen die Latenzen, Knoten verlieren das Quorum und werden gefenct – die Folge sind scheinbar zufällige Neustarts.
  • Zwei Knoten ohne QDevice: Den Workaround pvecm expected 1 nur im Notfall und nie mit aktivem HA nutzen; er hebelt den Split-Brain-Schutz aus.
  • Fencing testen: Vor dem Produktivstart einen Knoten hart vom Netz nehmen und prüfen, ob die HA-Gäste nach etwa zwei Minuten auf anderen Knoten laufen.
  • Corosync-Konfiguration: Nach Änderungen an /etc/pve/corosync.conf immer config_version erhöhen.
  • Bei Betrieb und Überwachung hochverfügbarer Proxmox-Umgebungen unterstützen Sie die Managed Services von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „https://techcorner.max-it.de/index.php?title=Proxmox_VE:_Cluster_und_Hochverfügbarkeit&oldid=5508“