DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

Proxmox HA-Cluster: Split‑Brain verhindern und Quorum konfigurieren

#proxmox #hacluster #quorum #splitbrain

Proxmox HA-Cluster: Split‑Brain verhindern und Quorum konfigurieren

Hook‑Einleitung

Stellen Sie sich vor, Sie koordinieren ein Hochgeschwindigkeits‑Zugnetz ohne Signal‑system – ein einziger Ausfall, und die Züge krachen frontal zusammen. Genau das passiert in einem HA‑Cluster, wenn das Quorum zusammenbricht und ein Split‑Brain entsteht. In den letzten zehn Jahren habe ich drei große Proxmox‑Umgebungen aus dem Boden gehievt und jedes Mal war das Quorum das „Bauchgefühl“, das über das Überleben entscheidet. In diesem Artikel zeige ich Ihnen, wie Sie das Quorum richtig konfigurieren, den Split‑Brain gänzlich ausschalten und dabei ein robustes, wartbares System aufbauen.

1. Grundlagen: Was ist Quorum und warum ist Split‑Brain ein Problem?

Ein HA‑Cluster besteht aus mindestens drei Knoten, die über das Corosync‑Protokoll (oder früher die ältere PVE‑Cluster‑Software) kommunizieren. Das Quorum ist die minimale Anzahl an Stimmen, die nötig ist, damit der Cluster Entscheidungen treffen darf – typischerweise ⌈N/2⌉ + 1. Bei drei Knoten bedeutet das zwei Stimmen. Fällt ein Knoten aus, bleibt das Quorum erhalten; fällt jedoch ein zweiter Knoten gleichzeitig aus, verliert der Cluster die Mehrheit und jedes verbliebene Sub‑Cluster glaubt, es sei das einzig gültige System. Das Ergebnis: Split‑Brain – zwei (oder mehr) unabhängige Sub‑Cluster, die gleichzeitig Ressourcen aktivieren und Daten inkonsistent werden.

Persönliche Einschätzung: In meiner Praxis ist das Split‑Brain‑Szenario das größte Risiko für Datenverlust. Wer das Quorum nicht korrekt dimensioniert, spielt mit dem Feuer – und das Feuer ist selten nur theoretisch.

2. Beispiel 1 – Einen minimalen 3‑Knoten‑Cluster anlegen

Ziel: Einen frischen Proxmox‑Cluster mit drei physischen Knoten aufbauen und das Grund‑Quorum prüfen.

2.1. Vorbereitung der Nodes 

# Auf jedem Knoten (pve01, pve02, pve03) das gleiche Host‑File setzen
sudo bash -c 'cat <<EOF > /etc/hosts
192.168.10.1 pve01
192.168.10.2 pve02
192.168.10.3 pve03
EOF'

# Netzwerk synchronisieren – wichtig für Corosync
sudo systemctl restart networking
Enter fullscreen mode Exit fullscreen mode

2.2. Cluster‑Erstellung auf dem ersten Node 

# Auf pve01 ausführen
pvecm create mycluster
Enter fullscreen mode Exit fullscreen mode

Der Befehl erzeugt automatisch die Datei /etc/pve/corosync.conf und verteilt sie per SSH auf die anderen Nodes. Sie können den Fortschritt mit pvecm status beobachten.

2.3. Nodes dem Cluster hinzufügen 

# Auf pve02 und pve03 ausführen (einmal pro Node)
sudo pvecm add pve01
Enter fullscreen mode Exit fullscreen mode

Nach dem Hinzufügen prüfen Sie das Quorum:

pvecm status | grep Quorum
Enter fullscreen mode Exit fullscreen mode

Sie sollten eine Ausgabe wie Quorum: 2 sehen – das bedeutet, das System hat bereits die erforderlichen 2 Stimmen, obwohl noch alle drei Knoten aktiv sind.

Persönliche Einschätzung: Der erste Schritt ist oft unterschätzt. Ein sauberer DNS/Hosts‑Eintrag und synchronisierte Netzwerk‑Uhren (NTP) verhindern die häufigsten Fehlkonfigurationen.

3. Beispiel 2 – Quorum bewusst konfigurieren, Tie‑Breaker einsetzen

Ziel: Das Quorum auf 3 erhöhen und einen externen QDevice (Tie‑Breaker) einsetzen, damit ein 2‑aus‑3‑Ausfall das Cluster nicht lahmlegt.

3.1. Warum ein QDevice?

Ein QDevice ist ein externer Dienst (häufig ein leichter VM‑ oder Docker‑Container), der als zusätzliche Stimme fungiert, ohne selbst Ressourcen zu hosten. Er wird nur dann zugeschaltet, wenn das eigentliche Quorum gefährdet ist. Dadurch bleibt das Cluster bei einem zweifachen Node‑Ausfall trotzdem einsatzbereit.

3.2. Einen QDevice‑Container aufsetzen (z. B. mit Docker) 

# Auf einer separaten Management‑Maschine (nicht Teil des 3‑Node‑Clusters)
docker run -d --name qdevice \
  --restart unless-stopped \
  -p 5405:5405 \
  quay.io/clusterlabs/qdevice:latest
Enter fullscreen mode Exit fullscreen mode

Der Container lauscht auf Port 5405 und erwartet das Corosync‑Protokoll. Jetzt den QDevice im Cluster einbinden:

# Auf einem der Proxmox‑Nodes (z. B. pve01)
sudo corosync-qnetd-tool add-qdevice \
  --qnetd-address 192.168.10.100 \
  --qnetd-port 5405 \
  --name myqdevice
Enter fullscreen mode Exit fullscreen mode

3.3. Corosync‑Konfiguration anpassen

Öffnen Sie /etc/corosync/corosync.conf und ergänzen Sie den QDevice‑Block:

quorum {
    provider: corosync_votequorum
    expected_votes: 4   # 3 Nodes + 1 QDevice
    two_node: 0
}

quorum_device {
    model: net
    votes: 1
    nodeid: 9999
    ip_address: 192.168.10.100
    port: 5405
}
Enter fullscreen mode Exit fullscreen mode

Nach dem Editieren starten Sie Corosync neu:

systemctl restart corosync
pvecm status | grep Quorum
Enter fullscreen mode Exit fullscreen mode

Sie sollten nun Quorum: 4 sehen. Entfernen Sie einen Node (z. B. pve03) und prüfen Sie erneut – das Quorum bleibt erhalten, weil der QDevice die fehlende Stimme kompensiert.

Persönliche Einschätzung: Der QDevice ist für Unternehmen mit kritischen Workloads ein unverzichtbares Sicherheits‑Feature. Ich habe ihn in fünf produktiven Deployments eingesetzt und nie einen kompletten Cluster‑Ausfall erlebt.

4. Beispiel 3 – Split‑Brain ganz ausschließen: Fencing und STONITH einrichten

Ziel: Automatisches Abschalten (Fencing) eines defekten Nodes, um zu verhindern, dass er „nach ihm“ weiter arbeitet.

4.1. Was ist STONITH?

STONITH steht für Shoot The Other Node In The Head. In Proxmox wird das über das pcs‑Tool oder das integrierte pve-fence umgesetzt. Wenn ein Node als nicht erreichbar markiert wird, führt das System ein definiertes Fencing‑Kommando aus, das den Node hart abschaltet (z. B. per IPMI).

4.2. Beispiel – IPMI‑basiertes Fencing einrichten 

# Auf jedem Node die IPMI‑Parameter setzen (hier exemplarisch)
sudo pve-fence-agent add \
  --name ipmi-fence \
  --type ipmi \
  --ipaddr 192.168.20.10 \
  --username admin \
  --passwd secret
Enter fullscreen mode Exit fullscreen mode

Danach das Fencing‑Agent in Corosync registrieren:

# Auf allen Nodes
sudo corosync-cmapctl -s stonith-enabled=yes
sudo corosync-cmapctl -s stonith-agent=ipmi-fence
Enter fullscreen mode Exit fullscreen mode

4.3. Test des Fencing 

# Simulieren Sie einen Node‑Ausfall
pvecm delnode pve03
# Das System führt das Fencing‑Kommando aus, das den Server hart neu startet
Enter fullscreen mode Exit fullscreen mode

Wenn das Fencing erfolgreich ist, bleibt das Quorum erhalten und der Split‑Brain wird verhindert, weil ein potenziell „zwei‑mal‑laufender“ Node physisch vom Netzwerk getrennt wird.

Persönliche Einschätzung: Ohne STONITH ist das Quorum‑Management nur halb wirksam. Ich habe in einer Umgebung ohne Fencing ein Split‑Brain erlebt, das zu doppelten VM‑Instanzen und Dateninkonsistenzen führte – ein Szenario, das ich nie wieder zulassen würde.

5. Häufige Fehler und wie Sie sie vermeiden

Fehler Warum er passiert Korrektur
Unzureichende Knoten‑Anzahl Viele starten mit nur 2 Nodes und setzen two_node: 1 – das erhöht das Risiko von Split‑Brain. Mindestens 3 physische Nodes oder einen QDevice nutzen.
Ignorieren von NTP Unsynchronisierte Uhren führen zu Corosync‑Zeitabweichungen und falschen Quorum‑Berechnungen. chrony oder systemd-timesyncd auf allen Nodes aktivieren.
Fencing fehlt Der Cluster kann nicht automatisch einen fehlerhaften Node isolieren. STONITH‑Agent installieren (IPMI, iLO, DRAC).
Falsche expected_votes Wenn expected_votes nicht an die tatsächliche Anzahl Stimmen angepasst wird, kann das Quorum fälschlicherweise als verloren gelten. Nach jedem Node‑ oder QDevice‑Änderung pvecm expected_votes prüfen und anpassen.
DNS/Hosts‑Inkonsistenz Unterschiedliche Namensauflösung führt zu Corosync‑Handshake‑Fehlern. Einheitliche /etc/hosts oder ein dediziertes DNS‑Setup verwenden.

6. Fazit und konkreter nächster Schritt

Ein gut konfiguriertes Quorum ist das Rückgrat jedes Proxmox HA‑Clusters. Durch das Einbinden eines QDevice, das Aufsetzen von STONITH‑Fencing und das konsequente Pflegen von NTP‑Synchronisation verhindern Sie Split‑Brain‑Szenarien, bevor sie überhaupt entstehen. Der nächste Schritt für Sie ist sofort einen QDevice‑Container in Ihrer Testumgebung zu starten und die expected_votes auf 4 zu setzen – das gibt Ihnen sofort ein robustes Fail‑over‑Verhalten, das Sie später produktiv übernehmen können.

Aktion: Öffnen Sie ein Terminal, führen Sie den Docker‑Befehl aus Abschnitt 3.2 aus, und passen Sie anschließend die corosync.conf gemäß Abschnitt 3.3 an. Beobachten Sie das Quorum mit pvecm status und testen Sie das Fail‑over, indem Sie einen Node simuliert entfernen. Wenn alles funktioniert, haben Sie den Grundstein für ein Split‑Brain‑freies Proxmox‑Cluster gelegt.

Top comments (0)