HA-Cluster mit Proxmox aufbauen: Hochverfügbarkeit Schritt für Schritt

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?.

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 unten mehr).
• Zuverlässiges, schnelles Netzwerk. Die Cluster-Kommunikation läuft über Corosync und reagiert empfindlich auf Latenz. 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.
• 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.

Schritt 1: Cluster erstellen

Auf dem ersten Node legen Sie den Cluster an:

pvecm create mein-cluster

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 IP ist die eines bereits vorhandenen Node):

pvecm add 10.0.0.1

Danach erscheinen alle Nodes in der Weboberfläche unter „Datacenter" und teilen sich die Konfiguration über das Cluster-Dateisystem pmxcfs.

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.

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:

Faustregel: Ab drei Nodes mit schnellem Netz ist Ceph der Goldstandard. 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.

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). Konkret:

1. In der Weboberfläche unter Datacenter → HA die gewünschten VMs/Container als HA-Ressourcen hinzufügen.
2. Optional HA-Groups definieren, um festzulegen, auf welchen Nodes eine VM bevorzugt laufen soll (Affinität, Prioritäten).
3. 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.

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. Standardmäßig kommt das softdog-Kernelmodul zum Einsatz: Verliert ein Node das Quorum, läuft sein Watchdog ab und der Node rebootet sich selbst, bevor die HA-Ressourcen anderswo anlaufen. Für höhere Anforderungen lässt sich ein Hardware-Watchdog oder Out-of-Band-Fencing (IPMI/iLO) ergänzen.

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 prüfen Sie, ob die HA-VMs innerhalb der erwarteten Zeit auf einem anderen Node neu starten. Dokumentieren Sie zudem, wie sich ein Node manuell fencen lässt.

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).
• 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 - bleibt Pflicht.

Betrieb und Unterstützung

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. Wenn Sie eine Proxmox-Einrichtung auf Hetzner planen oder den Cluster nicht selbst betreiben möchten, übernehmen wir Konzeption, Aufbau und Betrieb - Details auf unserer Seite zu Proxmox & Private Cloud.