DEV Community

Nova Reik
Nova Reik

Posted on

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

#proxmoxve #highavailability #corosync #itinfrastruktur

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

Ein Server-Ausfall ist für jedes IT-Team ein Albtraum – besonders wenn man keine High Availability (HA) eingerichtet hat. Ich habe in den letzten Jahren Dutzende Cluster gesehen, die „einfach mal schnell“ ohne richtige Planung deployed wurden. Das Ergebnis? Datenverlust, stundenlange Debug-Sessions oder das gefürchtete Split-Brain. In diesem Artikel zeige ich Ihnen Schritt für Schritt, wie Sie einen robusten Proxmox HA-Cluster aufbauen, wie Corosync und Quorum zusammenwirken und welche Fallstricke es zu vermeiden gilt.

Grundlagen von HA-Clustern unter Proxmox

Was ist ein HA-Cluster?

Ein HA-Cluster (High Availability) gruppiert mehrere Proxmox-Knoten so, dass Virtual Machines (VMs) und Container bei einem Ausfall eines Knotens automatisch auf einen anderen Node verschoben werden – ohne manuelles Eingreifen. Die Grundidee: Ein zentrales Koordinierungssystem überwacht die Gesundheit der Nodes und entscheidet, welcher Knoten eine VM übernehmen darf.

Beispiel: Eine Webserver-VM läuft auf Node A. Node A fällt aus. Innerhalb Sekunden startet dieselbe VM auf Node B, die gleiche IP-Adresse bleibt erhalten und die Anwendung steht weiter zur Verfügung.

Die Rolle von Corosync und PVE Manager

Die Herzstück-Software für die Cluster-Kommunikation ist Corosync (bzw. cman in älteren Versionen). Es übermittelt Herzschlagsnachrichten („I’m alive“) zwischen allen Knoten. Der Proxmox VE Manager (pve-manager) nutzt diese Informationen, um HA-Ressourcen zu orchestrieren. Wird ein Knoten nicht mehr erreicht, leitet Corosync eine Neuwahl ein – der Überlebende übernimmt.

Persönliche Einschätzung: Viele Admins denken, ein HA-Cluster sei nur ein „Failover“. Doch erst die korrekte Konfiguration des Quorums und die Trennung von Storage- und Heartbeat-Netzwerken machen ihn wirklich stabil.

Split-Brain verstehen – warum er passiert

Definition und Auswirkungen

Split-Brain beschreibt einen Zustand, in dem sich zwei oder mehr Teilsysteme gegenseitig als „tot“ betrachten und daher unabhängig agieren. Beide Seiten denken, sie sind die einzigen, die noch laufen – und versuchen gleichzeitig, dieselben Ressourcen (z.B. VMs, IPs) zu beanspruchen. Dies führt unweigerlich zu Datenkorruption, doppelten Starts oder Netzwerk-Konflikten.

In einem Proxmox-Kontext kann Split-Brain entstehen, wenn:

  • Die Heartbeat-Kommunikation zwischen Knoten unterbrochen wird (Netzwerkproblem, Firewall, Switch-Fehler).
  • Corosync-Protokoll-Nachrichten verloren gehen oder verspätet ankommen.
  • Zwei Knoten gleichzeitig versuchen, das Quorum zu erlangen (häufig bei gerader Knotenzahl ohne tiebreaker-Stimme).

Lebendiges Beispiel: Stellen Sie sich zwei Straßenbahnen vor, die sich beide sicher sein, dass die Gegenfahrbahn gesperrt ist. Sie fahren los – prallen frontal zusammen. Das Ergebnis ist katastrophal. Genauso verhält es sich mit VMs, die auf zwei Knoten gestartet werden und denselben Speicherplatz nutzen.

Wie Corosync Entscheidungen trifft

Corosync verwendet ein Mehrheitsvoting-System. Jeder Knoten erhält eine Stimme (default = 1). Um eine Entscheidung zu treffen – z.B. ob ein Knoten als tot markiert wird – braucht es eine Mehrheit (Quorum). Bei drei Knoten bedeutet das: mindestens zwei Stimmen müssen zustimmen. Wenn nur noch ein Knoten online ist, hat er nur eine Stimme – kein Quorum – und fährt vorsorglich herunter, um Dateninkonsistenzen zu vermeiden.

Beispielkonfiguration (/etc/pve/corosync.conf):

corosync {
    ... 
    quorum {
        provider: corosync_votequorum
        two_node: 1   # Nur für Zweiknoten-Setups nötig
    }
}
Enter fullscreen mode Exit fullscreen mode

Hier aktiviert two_node: 1 einen speziellen Modus, bei dem einer der beiden Knoten automatisch abstimmt, falls die Verbindung abreißt. Ohne diese Einstellung würden beide Knoten denken, sie hätten das Sagen – klassischer Split-Brain.

Quorum richtig konfigurieren

Die Grundregel: Immer ungerade Anzahl an Stimmen

Um eine klare Mehrheit zu garantieren, sollte die Gesamtzahl der Stimmen im Cluster immer ungerade sein. Das lässt sich erreichen durch:

  • Eine ungerade Anzahl physischer Knoten (3, 5, …)
  • Einbindung eines externen QDevice (QNetd), das als neutrale Stimme fungiert
  • Manuelle Anpassung der Stimmengewichtung pro Knoten (nicht empfohlen, erhöht Komplexität)

Drei-Knoten-Setup – der Goldstandard

Mit drei Proxmox-Knoten haben Sie bereits ein resilienten Setup: Auch wenn ein Knoten ausfällt, bleiben zwei übrig – genug für ein Quorum. Die Standardkonfiguration genügt hier meist:

# Prüfen der aktuellen Stimmen
pvecm status
Enter fullscreen mode Exit fullscreen mode

Ausgabe:

Version: 8.2.3
Config Version: 4
Transport: knet
Members: 3
Nodeid: 1
Ringid: 160492
Quorate: Yes
Expected votes: 3
Total votes: 3
Enter fullscreen mode Exit fullscreen mode

Solange Quorate: Yes, läuft alles glatt. Fällt ein Node aus (Members: 2), bleibt das Quorum erhalten, solange zwei Nodes erreichbar sind.

Zweiknoten-Cluster mit QDevice

Viele Homelabs oder kleine Produktivumgebungen bestehen nur aus zwei Knoten – perfekt für Failover, aber problematisch für Quorum. Die Lösung: ein QDevice (früher als „ arbitrator “ bekannt). Dieses externe Tool (oft ein einfacher Linux-Server oder sogar ein Raspberry Pi) nimmt an Abstimmungen teil und bricht Pattsituationen auf.

Installation und Einrichtung

  1. Auf einem dritten Host (oder separat) corosync-qnetd installieren: 
   apt update && apt install corosync-qnetd -y
   systemctl enable --now qnetd
Enter fullscreen mode Exit fullscreen mode
  1. Im Proxmox-Cluster das QDevice hinzufügen (von einem beliebigen Knoten): 
   pvecm qdevice setup --address <qnetd-ip> --port 5403
Enter fullscreen mode Exit fullscreen mode
  1. Erneut Status prüfen: 
   pvecm status
   # Erwartet: Expected votes: 3 (2 Nodes + 1 QDevice)
Enter fullscreen mode Exit fullscreen mode

Damit haben Sie wieder eine ungerade Stimmenanzahl und vermeiden Split-Brain auch bei vollständiger Trennung beider Proxmox-Knoten voneinander (sofern mind. einer mit dem QDevice verbunden bleibt).

Persönliche Einschätzung: Das QDevice macht einen echten Unterschied. Aber vergessen Sie nie: Es muss selbst hochverfügbar sein! Ein ausgefallener QDevice-Host eliminiert Ihren Schutzmechanismus sofort.

Praktische Beispiele & Best Practices

Beispiel 1: Netzwerk-Trennung simulieren

Testen Sie Ihr Failover, indem Sie das Heartbeat-Netzwerk eines Knotens temporär trennen (z.B. ip link set down dev bond0). Beobachten Sie über pvecm status und pcs status (falls Pacemaker genutzt wird), ob der andere Knoten das Quorum behält und die VMs übernimmt. Nach Wiederanbindung sollte alles nahtlos zurückkehren.

Beispiel 2: Monitoring mit Alerting

Richten Sie Benachrichtigungen für Cluster-Ereignisse ein. Proxmox bietet Integrationen für E-Mail, SNMP und Webhooks. Aktivieren Sie im Web-Interface unter „Datacenter → Permissions → Roles“ die Benachrichtigung für HA-Ereignisse oder nutzen Sie Tools wie Prometheus + Alertmanager, um den Gesundheitszustand von Corosync zu tracken.

Beispiel 3: Dedicated Heartbeat Interface

Verwenden Sie niemals dasselbe physische Interface für Storage- und Management-Traffic. Bilden Sie stattdessen einen separaten Bond (z.B. LACP) ausschließlich für Corosync-Herzschläge. Das reduziert drastisch das Risiko, dass Paketverluste durch Storage-Last fälschlicherweise einen Knoten als tot markieren.

Konfigurationsschnipsel (/etc/network/interfaces):

auto bond-ha
iface bond-ha inet manual
    slave eno1
    slave eno2
    bond-mode 4
    bond-miimon 100
    mtu 9000
Enter fullscreen mode Exit fullscreen mode

Und dann in /etc/pve/corosync.conf:

totem {
    interface {
        ringnumber: 0
        bindnetaddr: 10.0.10.0  # Netz des Heartbeat-Bonds
    }
}
Enter fullscreen mode Exit fullscreen mode

Häufige Fehler und ihre Vermeidung

Fehler Ursache Konsequenz Vermeidung
Keine dedizierten Heartbeat-Netze Shared Interfaces Paketverlust → falsches Tod-Markieren Separates Bonding, evtl. separates VLAN
Gerade Knotenzahl ohne QDevice 2-Knoten-Cluster, keine externe Stimme Split-Brain möglich QDevice einbinden
Firewalls blockieren UDP-Ports Ports 5404–5405 (knet) blockiert Kein Cluster-Join Ports öffnen, iptables/nftables anpassen
Zeitabweichung > 0.5 s NTP falsch konfiguriert Protokollfehler, Quorum-Probleme Alle Nodes mit exaktem NTP synchronisieren
Fehlendes Shared Storage Lokale Festplatten statt Ceph/ iSCSI VM kann nicht migriert werden ZFS-over-Network oder Ceph einsetzen

Besonders heikel ist die Kombination aus Zeitversatz und Netzwerkproblemen: Corosync validiert Timestamps; bei großen Abweichungen können Nachrichten verworfen werden.

Fazit und Ihr nächster Schritt

Ein korrekt konfiguriertes Proxmox HA-Cluster-Setup ist unverzichtbar für jede Umgebung, die Ausfälle minimieren möchte. Der Schlüssel liegt in drei Dingen:

  1. Unbedingt ungerade Stimmenzahl – egal ob über dritte Knoten oder QDevice.
  2. Separate Netzwerke für Management, Storage und Heartbeat.
  3. Regelmäßige Tests des Failovers – auch unter simulierten Netzwerkunterbrechungen.

Ihr konkreter nächster Schritt: Prüfen Sie morgen früh auf allen Proxmox-Knoten die Ausgabe von pvecm status. Falls „Expected votes“ gerade ist oder „Quorate: No“, handeln Sie sofort – binden Sie ein QDevice ein oder erweitern Sie den Cluster um einen dritten Knoten. Warten Sie nicht bis zum ersten echten Ausfall – dann bereuen Sie jede vertane Stunde Optimierung.

Ich freue mich darauf, in den Kommentaren zu lesen, wie Ihr actuales Cluster-Design aussieht und welche Erfahrungen Sie mit Split-Brain gemacht haben.

Top comments (0)