Proxmox HA-Cluster ohne Split‑Brain: Quorum richtig konfigurieren

Hook: Stellen Sie sich vor, Sie planen ein großes Familienfest und plötzlich entscheiden sich die Kinder, wer das letzte Stück Kuchen bekommt – und treffen dabei gegensätzliche Entscheidungen. Das Ergebnis? Chaos, beleidigte Gesichter und ein zerstörtes Festmahl. Genau so wirkt ein Split‑Brain in Ihrem Proxmox‑Cluster: zwei Teile denken, sie seien die einzig legitime Führungsebene. In diesem Artikel zeige ich Ihnen, wie Sie das Quorum richtig konfigurieren und das Split‑Brain‑Syndrom ein für alle Mal ausschalten.

Grundlagen des HA‑Clusters in Proxmox

Ein High‑Availability‑Cluster (HA‑Cluster) besteht aus mindestens drei physischen Nodes, welche über das Corosync‑Protokoll miteinander kommunizieren. Corosync bildet das Herzstück des Quorums: Jede Node hat eine bestimmte Stimmgewichtung („votes“). Nur wenn die Mehrheit (mehr als 50 % der Stimmen) erreichbar ist, gilt das Cluster als gesund und kann Ressourcen (VMs, Container) automatisch failover‑fähig bereitstellen.

Meine persönliche Einschätzung: Viele Proxmox‑Einsteiger starten mit einem 2‑Node‑Setup, weil Sie Kosten sparen wollen. Das ist ein fataler Fehler – das Quorum fehlt und Split‑Brain‑Risiko steigt exponentiell. Drei Nodes sind das Minimum, um ein robustes Quorum zu gewährleisten.

Split‑Brain verstehen und Ursachen

Ein Split‑Brain entsteht, wenn das Netzwerk partitioniert wird und jede Partition glaubt, sie sei die alleinige Mehrheit. Typische Ursachen:

1. Netzwerk‑Ausfall zwischen zwei Switches.
2. Falsch konfigurierte Corosync‑Votes – z. B. ein Node mit 0 Votes, der trotzdem Dienste hostet.
3. Veraltete Corosync‑Versionen, die bei Partitionen nicht korrekt abstimmen.

Im Endeffekt laufen Sie Gefahr, dass dieselbe VM auf zwei Nodes gleichzeitig aktiv ist – Dateninkonsistenzen, Dateisystem‑Korruption und im schlimmsten Fall ein kompletter Datenverlust.

Meine persönliche Einschätzung: Ich habe in meinem Homelab schon zweimal erlebt, wie ein kleiner Kabelbruch zu zwei gleichzeitig laufenden PostgreSQL‑Instanzen führte. Das war der Grund, warum ich heute nie weniger als drei Nodes mit korrekt abgestimmten Stimmen verwende.

Quorum richtig konfigurieren – Beispiel 1: Drei‑Node‑Cluster aufbauen

Ziel: Ein neues 3‑Node‑HA‑Cluster mit 1 Vote pro Node erstellen.

# Auf jedem Node das Proxmox‑Paket installieren (falls noch nicht geschehen)
sudo apt-get update && sudo apt-get install -y proxmox-ve

# Auf dem ersten Node das Cluster initialisieren
sudo pvecm create pve‑ha-cluster

# Auf Node 2 und Node 3 dem Cluster beitreten (IP des ersten Nodes angeben)
sudo pvecm add 192.168.1.10

Nach dem pvecm add wird automatisch die Corosync‑Konfiguration ausgetauscht. Prüfen Sie, ob jede Node 1 Vote hat:

cat /etc/pve/corosync.conf | grep vote
# Ausgabe sollte für jede Node etwa so aussehen:
#     node {
#         name: node1
#         votes: 1
#     }

Damit ist das Quorum auf 3 Votes (3 × 1) gesetzt. Die erforderliche Mehrheit sind 2 Votes.

Meine persönliche Einschätzung: Die meisten Probleme entstehen, wenn Administratoren nach dem Hinzufügen eines neuen Nodes vergessen, die Corosync‑Konfiguration zu aktualisieren. Ein kurzer pvecm status nach jedem Schritt erspart später nächtliche Fehlersuchen.

Split‑Brain verhindern – Beispiel 2: Stimmenverteilung und Fencing (STONITH) einbinden

Eine weitere Möglichkeit, Split‑Brain zu verhindern, ist das Fencing (STONITH – Shoot‑The‑Other‑Node‑In‑The‑Head). Sobald ein Node nicht mehr erreichbar ist, wird er automatisch neu gestartet oder abgeschaltet, sodass das verbleibende Cluster eine eindeutige Mehrheit hat.

Schritt 1: STONITH‑Device anlegen

# Beispiel: IPMI‑Controller eines Dell‑Servers
sudo pveha configure stonith ipmi \
    --node node1 \
    --ipmi_user admin \
    --ipmi_password secret \
    --ipmi_addr 192.168.1.50

Wiederholen Sie den Befehl für jeden Node im Cluster. Proxmox legt dann einen STONITH‑Agenten an, der im Notfall den fehlerhaften Server neu startet.

Schritt 2: Votes anpassen (optional)

Manche Setups setzen den Master‑Node mit 2 Votes, die beiden Slave‑Nodes mit je 1 Vote. Das erhöht die Stabilität, weil der Master im Normalbetrieb stärker vertreten ist.

# Editieren Sie die Corosync‑Datei manuell
sudo nano /etc/pve/corosync.conf

# Beispiel‑Snippet
node {
    name: node1
    votes: 2
}
node {
    name: node2
    votes: 1
}
node {
    name: node3
    votes: 1
}

Speichern und den Cluster neu starten:

sudo systemctl restart corosync

Schritt 3: Testen Sie das Fencing

# Simulierter Netzwerk‑Ausfall von node2 (aus Node1 heraus)
sudo pvecm node down node2
# Erwartete Reaktion: STONITH wird ausgelöst und node2 neu gestartet

Meine persönliche Einschätzung: Ein korrekt konfiguriertes STONITH ist das Rückgrat eines produktiven HA‑Clusters. Ich habe in über 30 Einsätzen beobachtet, dass ein fehlendes Fencing die häufigste Ursache für Split‑Brain‑Fehler ist. Nehmen Sie sich die Zeit, die IPMI‑Zugänge zu testen – ein falsches Passwort kostet Sie im Notfall Daten.

Monitoring und automatischer Failover – Beispiel 3: Systemd‑Watchdog + Proxmox‑Alerts

Ein weiteres Sicherheitsnetz besteht aus Watchdog‑Checks, die die Cluster‑Gesundheit überwachen und im Zweifel ein automatisches Failover starten.

# Aktivieren Sie den systemd‑Watchdog (auf allen Nodes)
sudo mkdir -p /etc/systemd/watchdog.conf.d
cat <<EOF | sudo tee /etc/systemd/watchdog.conf.d/20-proxmox.conf
[Watchdog]
WatchdogSec=30s
EOF

# Reload systemd
sudo systemctl daemon-reload

Danach konfigurieren Sie in Proxmox eine Alert‑Rule, die bei Verlust von Quorum eine E‑Mail versendet und gleichzeitig das HA‑Failover erzwingt:

pveam update
pveam download local my-alertscript.sh
# Skript (my-alertscript.sh) prüft /etc/pve/.members und startet einen Failover, falls nötig.

Im Web‑Interface gehen Sie zu Datacenter → HA → Alerts und legen ein neues Alert‑Script an, das my-alertscript.sh ausführt.

Meine persönliche Einschätzung: Nur Monitoring ist nicht genug – das System muss automatisch reagieren können. Der systemd‑Watchdog sorgt dafür, dass ein Node, der nicht mehr reagiert, vom Kernel neu gestartet wird, bevor der Netzwerk‑Split‑Brain‑Mechanismus überhaupt greift.

Häufige Fehler und wie Sie sie vermeiden

Meine persönliche Einschätzung: Die meisten Katastrophen lassen sich durch ein systematisches Check‑List‑Review vor dem produktiven Einsatz vermeiden. Ich empfehle, jedes neue Node‑Add‑ oder Update‑Szenario mit einem „Quorum‑Dry‑Run“ zu testen – simulieren Sie den Ausfall eines Nodes und prüfen Sie, ob das Cluster weiterhin konsistent bleibt.

Fazit und konkreter nächster Schritt

Ein Proxmox‑HA‑Cluster ist kein Set‑and‑Forget‑Projekt. Der Schlüssel zum Erfolg liegt in drei Dingen:

1. Mindestens drei Nodes mit korrekt abgestimmten Votes.
2. Fencing (STONITH) für jeden Node, damit ein evtl. fehlerhafter Server sofort isoliert wird.
3. Monitoring & automatischer Failover, damit Sie nicht erst im Alarm‑Dashboard reagieren, sondern das System proaktiv handelt.

Konkreter nächster Schritt:

1. Loggen Sie sich auf Ihrem Master‑Node ein.
2. Führen Sie pvecm status aus und notieren Sie die aktuelle Vote‑Verteilung.
3. Erstellen Sie ein STONITH‑Device für jeden Node (pveha configure stonith ipmi …).
4. Testen Sie das Failover mit pvecm node down <node> und prüfen Sie, ob das verbleibende Cluster das Quorum behält.
5. Implementieren Sie ein systemd‑Watchdog und ein Alert‑Script, das Sie per E‑Mail über Quorum‑Verluste informiert.

Damit haben Sie nicht nur Split‑Brain aus dem Spiel genommen, sondern auch ein resilienteres, selbstheilendes Proxmox‑Umfeld geschaffen – bereit für kritische Produktions‑Workloads.

Autor: Ein langjähriger Linux‑ und Proxmox‑Enthusiast, der in vielen Kundenprojekten Split‑Brain‑Katastrophen erfolgreich verhindert hat.