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 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 -j DROP sudo iptables -A INPUT -s -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" a****@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 - Odd‑Number‑Node‑Layout - immer eine ungerade Anzahl von Nodes einsetzen (3, 5, 7). Das garantiert, dass ein eindeutiges Quorum existiert. - Redundante Netzwerk‑Links - mindestens zwei physische Switches, idealerweise mit LACP (Link‑Aggregation). So verhindern Sie, dass ein einzelner Kabeldefekt das gesamte Cluster zerschlägt. - STONITH zwingend aktivieren - ohne Fencing gibt es keine Garantie, dass ein gesperrter Node nicht wieder aktiv wird. - Quorum‑Meldungen zentral sammeln - nutzen Sie Prometheus + Alertmanager (oder Zabbix) und visualisieren Sie den pvecm status ‑Wert. - 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 | Fehler | Warum er passiert | Konsequenz | |---|---|---| expected_votes zu niedrig gesetzt | Man vergaß, den Wert nach Hinzufügen eines Nodes zu ändern | Quorum fällt sofort, Cluster bleibt offline | | Kein Fencing‑Device definiert | Annahme, dass Corosync ausreicht | Split‑Brain bei Netzwerk‑Partition | | Nur ein physischer Switch | Kosteneinsparung überbewertet | Single‑Point‑Of‑Failure → totaler Cluster‑Ausfall | Nutzung von two_node: 1 in einem 3‑Node‑Setup | Misinterpretation der Dokumentation | Quorum‑Logik bricht zusammen | | Keine Monitoring‑Alerts | Blindes Vertrauen auf pvecm status im Terminal | Late‑Stage‑Failure, lange Downtime | 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: - Cluster initialisieren ( pvecm create ) und exakt die gewünschte Anzahl an Nodes anlegen. - Corosync‑Config anpassen - expected_votes = Anzahl der Nodes,two_node = 0. - Fencing‑Device einrichten (IPMI, iLO, iDRAC) und testen. - Monitoring‑Job ( check_quorum.sh ) implementieren. - 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. Top comments (0)