Ein HA-Cluster (High Availability) mit Proxmox VE sorgt dafür, dass Ihre virtuellen Maschinen einen Hardware- oder Node-Ausfall überstehen: Fällt ein Server aus, startet Proxmox die betroffenen VMs automatisch auf einem anderen, gesunden Node neu. Diese Anleitung zeigt, wie ein solcher Cluster aufgebaut ist, welche Voraussetzungen er hat und wie Sie ihn Schritt für Schritt einrichten.
Wichtig vorab zur Einordnung: Proxmox HA ist restart-basiert, nicht unterbrechungsfrei. Es minimiert die Ausfallzeit auf die Dauer eines Neustarts, ersetzt aber kein cluster-übergreifendes „Zero-Downtime". Wer die Grundlagen sucht, findet sie in Was ist Proxmox?.
Zur Abgrenzung von HA und Standortwiederanlauf: Proxmox Disaster Recovery mit Backup, Replikation und Runbook.
Cluster oder HA: wo liegt der Unterschied?
Ein Cluster verbindet mehrere Proxmox-Nodes zu einer gemeinsamen Verwaltung: zentrale Weboberfläche, gemeinsame Konfiguration über das Cluster-Dateisystem pmxcfs, Migration von VMs und Containern zwischen den Nodes sowie clusterweite Dienste wie Firewall und HA (Proxmox-Cluster-Doku). HA ist einer dieser Dienste: Der HA-Manager startet VMs und Container, die als HA-Ressourcen konfiguriert sind, nach einem Node-Ausfall auf einem anderen Node neu.
Daraus folgt: Ein Cluster lässt sich ohne HA betreiben, HA dagegen setzt einen Cluster voraus. Die HA-Doku nennt als Voraussetzungen mindestens drei Cluster-Nodes für verlässliches Quorum, Shared Storage für VMs und Container sowie Hardware-Redundanz (Proxmox-HA-Doku). Die folgenden sieben Schritte bauen beides auf.
Voraussetzungen
Ein produktiver HA-Cluster braucht ein solides Fundament:
- Mindestens drei Nodes. Quorum (die Beschlussfähigkeit des Clusters) erfordert die Mehrheit der Stimmen. Mit drei Nodes übersteht der Cluster den Ausfall eines Nodes und bleibt beschlussfähig. Zwei Nodes sind nur mit einem QDevice als dritter Stimme sinnvoll (dazu in Schritt 3 mehr).
- Zuverlässiges, schnelles Netzwerk. Die Cluster-Kommunikation läuft über Corosync und reagiert empfindlich auf Latenz (Proxmox-Cluster-Doku, Netzwerkanforderungen). Empfohlen sind Latenzen unter 5 ms zwischen den Nodes und ein dediziertes Netzwerk (eigene NIC) nur für Corosync, getrennt vom VM- und Storage-Traffic. Die Nodes müssen sich über die UDP-Ports 5405 bis 5412 erreichen. Wie sich das auf gemieteten Servern umsetzen lässt, beschreiben die Guides für Hetzner, OVH und IONOS.
- Synchrone Uhren und gleiche Version. NTP auf allen Nodes, identische Proxmox-VE-Version, erreichbarer SSH-Port 22 zwischen den Nodes.
- HA-fähiger Storage. Die VM-Disks müssen auf mehreren Nodes verfügbar sein - über verteilten Shared-Storage (Ceph) oder über ZFS-Replikation.
- Ausreichend dimensionierte Hardware. Nach dem Ausfall eines Nodes verteilt der HA-Manager dessen Gäste auf die übrigen Nodes; die Doku verlangt, den Cluster für diesen Fall auszulegen. Hinweise zur Auslegung enthält der Guide Proxmox Hardware-Anforderungen und Sizing.
Beispielaufbau für diese Anleitung: drei Nodes pve1 bis pve3 mit Proxmox VE 9.2, getrenntes Corosync-Netz und Ceph als Storage.
| Netz | Verwendung | Beispieladressen |
|---|---|---|
| Management und VM | Weboberfläche, VM-Traffic, SSH | 10.0.0.0/24 (pve1 = 10.0.0.1) |
| Corosync | Cluster-Kommunikation, eigene physische NIC | 10.10.10.0/24 (pve1 = 10.10.10.1) |
| Ceph | Storage-Replikation, 10 GbE oder schneller | 10.20.20.0/24 |
Schritt 1: Cluster erstellen
Hostname und IP-Adresse der Nodes müssen vor dem Anlegen feststehen: Nach der Cluster-Erstellung lassen sie sich laut Doku nicht mehr ändern, ebenso wenig der Cluster-Name. Auf dem ersten Node legen Sie den Cluster an, hier mit dem Corosync-Netz als Link 0 (ohne separates Cluster-Netz entfällt --link0):
pvecm create mein-cluster --link0 10.10.10.1
Den Status prüfen Sie jederzeit mit:
pvecm status
Schritt 2: Weitere Nodes hinzufügen
Auf jedem weiteren Node treten Sie dem bestehenden Cluster bei. Die erste Adresse ist die eines bereits vorhandenen Node, --link0 setzt die eigene Adresse im Corosync-Netz (Proxmox-Cluster-Doku):
pvecm add 10.0.0.1 --link0 10.10.10.2
Auf dem dritten Node lautet die Link-0-Adresse entsprechend 10.10.10.3. Danach erscheinen alle Nodes in der Weboberfläche unter „Datacenter" und teilen sich die Konfiguration über das Cluster-Dateisystem pmxcfs. Mit pvecm status prüfen Sie den Beitritt: Bei drei Nodes zeigt der Abschnitt „Votequorum information" drei Total votes, und die Flags enthalten „Quorate".
Schritt 3: Quorum verstehen und absichern
Bei einer Netzwerk-Partitionierung dürfen nur die Nodes weiterarbeiten, die die Mehrheit der Stimmen halten; die unterlegene Seite geht in den read-only-Modus. Deshalb:
- Drei oder mehr Nodes sind die saubere Lösung.
- Bei einem 2-Node-Cluster ergänzen Sie ein QDevice: ein leichtgewichtiger Dienst (
corosync-qnetd) auf einem dritten, unabhängigen System (z. B. eine kleine VM auf anderer Hardware oder ein Raspberry Pi), das die entscheidende dritte Stimme liefert. Die vollständige Einrichtung mit Voraussetzungen und Entfernen beschreibt der Guide 2-Node-Cluster mit QDevice einrichten.
apt install corosync-qdevice
pvecm qdevice setup <QDEVICE-IP>
Schritt 4: Storage für HA - Ceph oder ZFS-Replikation
Die VM-Disks müssen den Node-Ausfall überleben. Zwei etablierte Wege:
| Ceph | ZFS-Replikation | |
|---|---|---|
| Prinzip | Verteilter Shared-Storage, synchron | Asynchrone Replikation im Intervall |
| Mindest-Nodes | 3+ | ab 2 |
| Netzwerk | 10 GbE+ empfohlen | unkritischer |
| Datenaktualität nach Ausfall | aktuell (RPO ~0) | Stand der letzten Replikation (RPO = Intervall) |
| Komplexität | höher | gering |
| Passt für | Produktion mit hoher Datenaktualität | schlanke Setups mit toleriertem Datenverlust |
Faustregel: Ab drei Nodes mit schnellem Netz eignet sich Ceph als synchroner Shared-Storage (Proxmox-Ceph-Doku). Für kleine, kostenbewusste Setups ist ZFS-Replikation eine pragmatische Near-HA-Lösung - mit dem Bewusstsein, dass beim Failover die Änderungen seit der letzten Replikation fehlen. Die Storage-Wahl vertieft der Artikel Proxmox Storage: ZFS, Ceph oder LVM; Planung und Betrieb von Ceph auf Proxmox beschreibt die Seite Proxmox Ceph.
Schritt 5: HA aktivieren
Hochverfügbarkeit verwalten zwei Dienste: der Cluster Resource Manager (pve-ha-crm, einer pro Cluster) und der Local Resource Manager (pve-ha-lrm, einer pro Node) (Proxmox-HA-Doku). Konkret:
- In der Weboberfläche unter Datacenter → HA die gewünschten VMs/Container als HA-Ressourcen hinzufügen. Auf der Kommandozeile entspricht das
ha-manager add vm:100. - Optional HA-Regeln definieren: Node-Affinitätsregeln legen fest, auf welchen Nodes eine VM bevorzugt oder ausschließlich laufen soll (inklusive Prioritäten), Ressourcen-Affinitätsregeln halten VMs zusammen oder getrennt. Die früheren HA-Groups sind seit Proxmox VE 9.0 veraltet und werden automatisch in Node-Affinitätsregeln überführt (Proxmox-HA-Doku).
- Den gewünschten Zielzustand setzen (z. B.
started).
Ab jetzt überwacht der HA-Stack die Ressourcen und startet sie bei einem Node-Ausfall automatisch neu. Seit Proxmox VE 9.2 kann der Cluster Resource Scheduler im dynamischen Modus HA-verwaltete Gäste zusätzlich anhand der aktuellen Last automatisch umverteilen (Stand Oktober 2026). Die Option ha-rebalance-on-start wählt beim Start einer HA-Ressource den bestgeeigneten Node aus und migriert die Ressource gegebenenfalls dorthin; in den lastbasierten Modi (static-load und dynamic-load) ist diese Funktion laut Doku noch Technology Preview. VMs werden beim Umverteilen per Live-Migration verschoben; LXC-Container lassen sich nicht live migrieren und werden per Restart-Migration gestoppt, verschoben und neu gestartet, mit kurzer Ausfallzeit (Proxmox-Doku zu Containern).
Die CRS-Modi, automatische Umverteilung und deren Grenzen erläutert Proxmox DRS und Lastausgleich.
Schritt 6: Fencing und Watchdog
Damit ein scheinbar toter Node nicht doch eine VM weiterbetreibt, während sie woanders startet (Split-Brain), nutzt Proxmox Watchdog-basiertes Self-Fencing (Proxmox-HA-Doku, Fencing), das ohne zusätzliche externe Hardware auskommt. Verliert ein Node das Quorum, läuft sein Watchdog ab und der Node rebootet sich selbst, bevor die HA-Ressourcen anderswo anlaufen.
Standardmäßig kommt das softdog-Kernelmodul zum Einsatz, ein Software-Watchdog: Ist kein Hardware-Watchdog verfügbar oder konfiguriert, fällt Proxmox darauf zurück. Die Doku bewertet ihn als zuverlässig, aber nicht unabhängig von der Server-Hardware und damit weniger zuverlässig als einen Hardware-Watchdog. Hardware-Watchdog-Module sind aus Sicherheitsgründen standardmäßig gesperrt. Zum Aktivieren tragen Sie das Modul in /etc/default/pve-ha-manager ein, zum Beispiel WATCHDOG_MODULE=iTCO_wdt (Proxmox-HA-Doku, Hardware-Watchdog); welches Modul zum Server passt, hängt vom Mainboard ab.
Schritt 7: Failover testen
Ein HA-Cluster ist nur so gut wie sein getesteter Ernstfall. Simulieren Sie einen Node-Ausfall (Node hart ausschalten oder vom Netz trennen) und beobachten Sie auf einem verbleibenden Node ha-manager status: Der Zustand der HA-Ressource wechselt laut Doku zu fence (der HA-Manager wartet, bis der ausgefallene Node gefenced ist), dann zu recovery (Suche nach einem neuen Node) und schließlich zu started auf einem anderen Node (Zustände der HA-Ressourcen). Prüfen Sie zusätzlich mit pvecm status, dass der Cluster beschlussfähig bleibt, und halten Sie fest, wie lange die VM nicht erreichbar war. Dokumentieren Sie zudem, wie sich ein Node manuell fencen lässt.
Wartung im HA-Cluster: Wartungsmodus und Neustarts
Auch bei Updates und Hardwarewartung greift der HA-Stack ein. Die HA-Doku unterscheidet zwei Wege (Node Maintenance):
- Shutdown-Policy für Herunterfahren und Neustarts. Sie legen unter Datacenter → Options → HA Settings fest (oder in der
datacenter.cfgüberha: shutdown_policy=<Wert>), was mit den HA-Gästen eines Nodes beim Shutdown oder Reboot geschieht. Beimigrateverschiebt der HA-Manager alle HA-Gäste auf andere Nodes und verzögert das Herunterfahren, bis sie dort laufen. Das setzt voraus, dass sich die Gäste verschieben lassen; mit lokaler Bindung, etwa durch Hardware-Passthrough, ist das nicht der Fall. Aktuell istconditionalder Standard (Shutdown Policy): Bei einem Reboot friert der HA-Stack die Gäste ein und startet sie nach dem Neustart auf demselben Node, bei einem Shutdown stoppt er sie und andere Nodes übernehmen. - Manueller Wartungsmodus für Arbeiten ohne Neustart oder Arbeiten, die nach einem einzelnen Reboot nicht enden sollen. Der Befehl markiert den Node als nicht verfügbar für HA, und alle von HA verwalteten Gäste wandern auf andere Nodes:
ha-manager crm-command node-maintenance enable NODENAME
Nach der Wartung schaltet ha-manager crm-command node-maintenance disable NODENAME den Modus ab; die Gäste, die beim Aktivieren auf dem Node liefen, werden zurückverschoben. Der Wartungsmodus bleibt nach einem Neustart des Nodes bestehen, bis Sie ihn deaktivieren. Ob der Node die Gäste abgegeben hat, erkennen Sie daran, dass keine aktive HA-Ressource mehr auf ihm liegt.
Für Arbeiten am Netzwerk oder am Corosync-Stack, die kurzzeitig das Quorum kosten können, kennt die Doku zusätzlich das Deaktivieren von HA (disarm-ha); solange HA deaktiviert ist, schützt es keine Dienste.
Den vollständigen Ablauf für reguläre Paketupdates je Node beschreibt der Cluster-Update-Guide mit HA und Neustart.
Typische Fehler
- 2-Node-Cluster ohne QDevice. Bei jedem Ausfall verliert der Cluster das Quorum und wird read-only - HA greift dann nicht zuverlässig.
- Corosync über das Storage- oder VM-Netz. Latenz-Spitzen führen zu Quorum-Verlust und unnötigen Fencing-Aktionen. Corosync gehört in ein eigenes, stabiles Netz (idealerweise redundant).
- Node mit vorhandenen VMs soll beitreten. Beim Beitritt wird die Konfiguration in
/etc/pveüberschrieben, ein beitretender Node darf keine Gäste halten. Erstellen Sie vorher von jedem Gast ein Backup mitvzdumpund stellen Sie es nach dem Beitritt unter einer neuen ID wieder her (Proxmox-Cluster-Doku). Das gilt auch, wenn der Cluster erst nachträglich aus bestehenden Einzel-Nodes entsteht. - HA mit „Zero-Downtime" verwechseln. HA bedeutet automatischer Neustart, nicht unterbrechungsfreier Betrieb.
- Kein Fencing geplant. Ohne Watchdog oder Fencing riskieren Sie Datenkorruption durch Split-Brain.
- Backups vernachlässigt. HA repliziert auch Fehler und Ransomware. Ein separates Backup - etwa mit verschlüsselten Proxmox-Backups auf einer Hetzner Storage Box oder einem Offsite-Proxmox-Backup-Server - bleibt Pflicht.
Cluster einrichten lassen oder mieten
Ein HA-Cluster ist im Aufbau überschaubar, im Dauerbetrieb aber anspruchsvoll: Quorum-Design, Corosync-Netzwerk, Storage-Strategie, Patch-Management und getestete Restores müssen sauber zusammenpassen. Je nach Ausgangslage gibt es vier Wege:
- Cluster aufbauen lassen: Proxmox-Setup vom Single Node bis zum 3-Node-Cluster.
- Cluster mieten: Managed Proxmox Hosting mit Servern und Betrieb aus einer Hand, auch als Cluster.
- Bestehenden Cluster betreiben lassen: Managed Proxmox für Wartung, Monitoring und Backup-Verantwortung.
- Ceph betreuen lassen: Proxmox Ceph für Planung und Betrieb des verteilten Storage.
Mehrere Cluster zentral zu verwalten, ist ein eigenes Thema: Proxmox Datacenter Manager für mehrere Cluster. Die einzelnen Cluster behalten ihr eigenes Quorum; PDM ersetzt kein clusterübergreifendes HA. Wer zuerst eine Einzelinstallation plant, findet den Weg in Proxmox auf Hetzner einrichten.
