Proxmox HA-Cluster: Split‑Brain verhindern & Quorum richtig konfigurieren

Hook – Warum ein HA-Cluster ohne Quorum wie ein wankender Turm ist

Stellen Sie sich vor, Sie bauen ein Haus aus Holz und vergessen, die Balken zu verankern. Jeder Windstoß – ein ausgefallener Node – lässt das Dach knarren, und plötzlich diskutieren die Balken darüber, wer das Dach jetzt halten soll. Genau das passiert in einem Proxmox‑HA‑Cluster, wenn das Quorum nicht ordentlich konfiguriert ist: Split‑Brain, Datenverlust und nächtliche Schlaflosigkeit. In diesem Artikel zeige ich Ihnen, wie man das Fundament stabilisiert, das Quorum richtig einstellt und Split‑Brain praktisch aus dem Spiel nimmt – mit echten Befehlen, Konfigurationsbeispielen und meiner persönlichen Note nach jedem Abschnitt.

Was ist ein Proxmox HA-Cluster und warum ist Quorum das Herzstück?

Ein HA‑Cluster (High Availability) besteht aus mindestens drei physikalischen Nodes, die über Corosync (bzw. das integrierte Cluster‑Transport‑System) miteinander kommunizieren. Das Quorum definiert, ab wann ein Konsens erreicht ist – das ist die Mindestzahl an Stimmen, die nötig ist, damit der Cluster Entscheidungen treffen darf (z. B. VM‑Migration, Neustart, Ressourcenfreigabe).

Beispiel 1 – Minimal‑Cluster mit drei Nodes

# Auf jedem Node das Proxmox‑Paket installieren (Debian‑Basis)
sudo apt-get update && sudo apt-get install -y proxmox-ve

# Auf dem ersten Node ein Cluster initialisieren
sudo pvecm create my-ha-cluster

# Auf den beiden anderen Nodes dem Cluster beitreten
sudo pvecm add <IP_DES_MASTER_NODES>

Nachdem die drei Nodes im Cluster sind, kann man den aktuellen Quorum‑Status prüfen:

pvecm status

Die Ausgabe zeigt u. a. Quorum: 2 (bei drei Nodes = 2 Stimmen). Wenn ein Node ausfällt, bleibt das Quorum erhalten, weil 2 / 3 noch > 50 % sind.

Persönliche Einschätzung

In der Praxis setze ich selten mehr als drei Nodes, weil der administrative Overhead sonst exponentiell wächst. Drei Nodes geben bereits das notwendige 2‑of‑3‑Quorum, das ich in produktiven Umgebungen als „Goldstandard“ betrachte. Wer mehr Skalierung braucht, sollte aber von Anfang an ein ungerades × Node‑Layout planen.

Split‑Brain: Das Monster im Cluster

Split‑Brain entsteht, wenn zwei (oder mehr) Teilgruppen des Clusters unabhängig voneinander denken, sie hätten das Quorum. Das Ergebnis? Doppelter Start derselben VM, inkonsistente Daten und ein wahnsinniges Debugging‑marathon.

Beispiel 2 – Simulierter Netzwerk‑Partition

# Auf Node 1 das Netzwerk für 30 Sekunden blockieren (simuliert ein Outage)
sudo iptables -A INPUT -s <IP_NODE2> -j DROP
sudo iptables -A INPUT -s <IP_NODE3> -j DROP
sleep 30
sudo iptables -F

Während dieser Zeit sehen Node 1 und Node 2 jeweils nur die anderen beiden Nodes. Wenn die Partition zufällig zu 2‑vs‑1 führt, kann Node 2 (mit 2 Stimmen) das Quorum behalten, während Node 1 glaubt, er habe das Quorum (1 Stimme, weil es seine eigene Stimme mitzählt). In manchen Fehlkonfigurationen akzeptiert Proxmox das falsche Quorum und startet VMs auf beiden Partitionen – klassisches Split‑Brain.

Persönliche Einschätzung

Ich habe in meinem Homelab bereits zwei Fälle erlebt, bei denen ein defekter Switch das gleiche Szenario ausgelöst hat. Das größte Learning: Netzwerk‑Redundanz ist kein Nice‑to‑have, sondern ein Muss. Ohne redundante Switches und physische Pfade kann jedes einzelne Gerät das gesamte Cluster zum Stillstand bringen.

Quorum richtig konfigurieren – Schritt für Schritt

1. Corosync‑Konfiguration anpassen

Die Datei /etc/pve/corosync.conf steuert, wie Stimmen gezählt werden. Hier ein Minimal‑Beispiel für ein 3‑Node‑Cluster mit auto‑join und vote‑weight‑Einstellungen:

totem {
    version: 2
    cluster_name: my-ha-cluster
    token: 3000
    token_retransmits_before_loss_const: 10
    join: 60
    interface {
        ringnumber: 0
        bindnetaddr: 10.0.0.0
        mcastaddr: 239.255.1.1
        mcastport: 5405
    }
}
quorum {
    provider: corosync_votequorum
    two_node: 0   # 0 = klassisches Quorum, 1 = Two‑Node‑Modus
    wait_for_all: 0
    expected_votes: 3
    last_man_standing: 0
}

nodelist {
    node {
        nodeid: 1
        quorum_votes: 1
        name: node1
        address: 10.0.0.1
    }
    node {
        nodeid: 2
        quorum_votes: 1
        name: node2
        address: 10.0.0.2
    }
    node {
        nodeid: 3
        quorum_votes: 1
        name: node3
        address: 10.0.0.3
    }
}

Wichtig: expected_votes muss die tatsächliche Anzahl der Nodes widerspiegeln. Wenn Sie später einen Node hinzufügen, passen Sie den Wert an und starten Sie Corosync neu:

systemctl restart corosync

2. STONITH (Shoot‑The‑Other‑Node‑In‑The‑Head) aktivieren

Fencing ist die sicherste Methode, um Split‑Brain zu verhindern: Wenn ein Node seine Verbindung verliert, wird er automatisch ausgeschaltet, sodass er nicht mehr konkurrieren kann.

# Beispiel: IPMI‑basiertes Fencing über iLO (Dell) oder iDRAC (HP)
# Installiere das Fence-Agent-Paket
apt-get install -y fence-agents

# Erstelle eine neue Fencing‑Resource in Proxmox
pveum roleadd FencingAdmin -privs "SDN.Modify,Datacenter.Audit"

# Konfiguration in /etc/pve/fence.cfg (einfaches Beispiel)
node: node1
fence_type: ipmi
ipaddr: 192.168.1.100
login: admin
passwd: secret
port: 623

Danach testen Sie das Fencing:

# Simulierter Power‑Off von node2
fence_ipmilan -a 192.168.1.101 -l admin -p secret -o off

Wenn das Fencing funktioniert, wird das Quorum sofort neu berechnet und Split‑Brain kann nicht auftreten.

Persönliche Einschätzung

Ich habe die Erfahrung gemacht, dass kein Cluster ohne funktionierendes Fencing überlebt. Selbst bei einem 3‑Node‑Setup reicht es nicht, sich auf das reine Corosync‑Quorum zu verlassen – ein kurzzeitig ausgefallener Netzwerk‑Port würde sonst sofort zu Split‑Brain führen.

3. Quorum‑Monitoring automatisieren

Ein kurzer Cron‑Job, der den Quorum‑Status prüft und bei Problemen Alarm schlägt, spart Stunden Debugging‑Zeit.

#!/bin/bash
# /usr/local/bin/check_quorum.sh
status=$(pvecm status | grep -i quorum | awk '{print $2}')
if [[ "$status" -ne 2 ]]; then
    echo "[WARN] Quorum-Problem! aktuelle Stimmen: $status" | mail -s "Proxmox Quorum Alert" admin@example.com
fi

Mit chmod +x und crontab -e hinzufügen:

*/5 * * * * /usr/local/bin/check_quorum.sh

Jetzt erhalten Sie alle 5 Minuten ein Status‑Mail, falls das Quorum unter das gewünschte Niveau fällt.

Fünf praktische Tipps, um Split‑Brain zu vermeiden

1. Odd‑Number‑Node‑Layout – immer eine ungerade Anzahl von Nodes einsetzen (3, 5, 7). Das garantiert, dass ein eindeutiges Quorum existiert.
2. Redundante Netzwerk‑Links – mindestens zwei physische Switches, idealerweise mit LACP (Link‑Aggregation). So verhindern Sie, dass ein einzelner Kabeldefekt das gesamte Cluster zerschlägt.
3. STONITH zwingend aktivieren – ohne Fencing gibt es keine Garantie, dass ein gesperrter Node nicht wieder aktiv wird.
4. Quorum‑Meldungen zentral sammeln – nutzen Sie Prometheus + Alertmanager (oder Zabbix) und visualisieren Sie den pvecm status‑Wert.
5. Regelmäßige Tests – führen Sie halbjährlich ein geplantes Netzwerk‑Failover‑Test aus, um zu prüfen, ob das Quorum korrekt nachzieht.

Persönliche Einschätzung

Die meisten split‑brain‑Incidents, die ich in den letzten fünf Jahren beobachtete, waren das Ergebnis von einer vernachlässigten Maßnahme: entweder ein vergessenes STONITH‑Device oder ein Switch‑Ausfall ohne Backup‑Link. Ein konsequenter Check‑list‑Ansatz reduziert das Risiko auf ein Minimum.

Häufige Fehler beim Aufbau eines Proxmox HA‑Clusters

Fazit – Ihr nächster, konkreter Schritt

Der sicherste Weg, ein Proxmox‑HA‑Cluster zu betreiben, ist, Quorum und Fencing als untrennbare Einheit zu behandeln. Wenn Sie gerade erst ansetzen, gehen Sie wie folgt vor:

1. Cluster initialisieren (pvecm create) und exakt die gewünschte Anzahl an Nodes anlegen.
2. Corosync‑Config anpassen – expected_votes = Anzahl der Nodes, two_node = 0.
3. Fencing‑Device einrichten (IPMI, iLO, iDRAC) und testen.
4. Monitoring‑Job (check_quorum.sh) implementieren.
5. Netzwerk‑Redundanz prüfen – mindestens zwei Switches, LACP‑Bundle.

Durch das Befolgen dieser fünf Punkte stellen Sie sicher, dass Ihr Cluster nie wieder in ein Split‑Brain‑Szenario gerät und dass das Quorum stets stabil bleibt. Jetzt liegt es an Ihnen: Öffnen Sie die Shell, überprüfen Sie pvecm status und starten Sie das erste HA‑Test‑VM‑Migrieren. Sobald das funktioniert, haben Sie einen echten, ausfallsicheren Proxmox‑Cluster in Betrieb.