Split-Brain im Cluster: wie Quorum und Fencing es verhindern

Quorum im Cluster: Die Mehrheit der Stimmen entscheidet

Quorum ist die Mindestzahl an Stimmen, die ein Teil des Clusters braucht, um handeln zu dürfen. In Proxmox VE hat jeder Node standardmäßig eine Stimme. Den Zustand des Clusters ändern darf nur eine Gruppe von Nodes, die mehr als die Hälfte aller Stimmen auf sich vereint. Fehlt diese Mehrheit, wechselt der Cluster in einen Nur-Lese-Modus.

Die Nodes verständigen sich über die Corosync Cluster Engine. Deren Dienst votequorum zählt die Stimmen für das Corosync-Quorum und ist laut Dokumentation ausdrücklich dafür gebaut, Split-Brain zu vermeiden. Begriffe wie Corosync und HA Manager erklärt das Glossar im Bereich Wissen.

Die Mehrheitsrechnung: ⌊n/2⌋ + 1

Corosync rechnet mit einfacher Mehrheit: die Hälfte der Stimmen plus eins, abgerundet auf ganze Stimmen. Für n Nodes mit je einer Stimme gilt also Mehrheit = ⌊n/2⌋ + 1. Gleichzeitig ausfallen dürfen höchstens n − (⌊n/2⌋ + 1) Nodes.

Wichtig für die Planung: Die Mehrheit bezieht sich auf alle erwarteten Stimmen, die Corosync beim Start festlegt, nicht nur auf die gerade erreichbaren. Fällt in einem Cluster mit drei Nodes einer aus, braucht der Rest weiterhin zwei Stimmen. Ein zweiter Ausfall lässt den letzten Node ohne Mehrheit zurück.

Warum gerade Node-Zahlen ungünstig sind

Ein vierter Node bringt Kapazität, erhöht die Ausfalltoleranz aber nicht: Vier Nodes brauchen drei Stimmen und überstehen wie drei Nodes nur einen Ausfall. Zerfällt ein Cluster mit vier Nodes zudem in zwei Hälften zu je zwei Nodes, erreicht keine Hälfte die Mehrheit, und beide verlieren das Quorum. Für gerade Node-Zahlen unterstützt Proxmox deshalb ein externes Quorum-Device, dessen Stimme den Gleichstand auflöst.

Split-Brain im Cluster: was ohne Quorum passiert

Von Split-Brain spricht man, wenn ein Cluster in Teile zerfällt, die sich gegenseitig nicht mehr erreichen und unabhängig weiterarbeiten. Jeder Teil hält den anderen für ausgefallen und übernimmt dessen Aufgaben. Dann laufen dieselben virtuellen Maschinen doppelt und schreiben gleichzeitig auf dieselben Daten.

Auslöser kann eine Netztrennung sein, etwa durch einen defekten Switch oder eine unterbrochene Leitung. Die Nodes laufen weiter, nur ihre Verbindung untereinander fehlt. Von innen ist das nicht vom Ausfall der anderen Nodes zu unterscheiden.

Das Quorum löst den Konflikt mit einer einfachen Regel: Weiterarbeiten darf nur der Teil mit der Mehrheit der Stimmen. Weil die Mehrheit mehr als die Hälfte verlangt, kann es nur einen solchen Teil geben. Teilen sich die Nodes genau zur Hälfte, bleibt der Cluster konsistent, ist aber nicht mehr handlungsfähig.

In Proxmox VE wird ohne Quorum das Cluster-Dateisystem pmxcfs schreibgeschützt, das die Konfiguration aller Nodes enthält. Der Node wartet auf ein neues Quorum. Laufen auf ihm hochverfügbare VMs, grenzt er sich selbst ab.

Fencing im Cluster: den ausgefallenen Node sicher abgrenzen

Fencing stellt sicher, dass ein ausgefallener oder abgeschnittener Node garantiert nicht mehr arbeitet, bevor seine Dienste auf einem anderen Node starten. Erst dann ist ausgeschlossen, dass eine VM doppelt läuft. Ohne Fencing bliebe der Node in einem unbekannten Zustand und hätte womöglich noch Zugriff auf gemeinsamen Storage.

Quorum und Fencing arbeiten zusammen. Das Quorum entscheidet, welcher Teil des Clusters handeln darf. Fencing sorgt dafür, dass der andere Teil tatsächlich aufgehört hat, bevor der handelnde Teil dessen Dienste übernimmt.

Wie Proxmox VE abgrenzt: Selbst-Fencing per Watchdog

Fencing ist per externem Stromschalter, durch vollständiges Sperren des Netzverkehrs am Switch oder als Selbst-Fencing per Watchdog-Timer möglich. Proxmox VE nutzt das Selbst-Fencing, weil es keine zusätzliche Hardware braucht; externe Fencing-Geräte wären laut Dokumentation selbst kritische Komponenten.

Im Normalbetrieb setzt der HA Manager den Watchdog regelmäßig zurück. Ein Node ohne Quorum kann das nicht mehr. Laufen auf ihm aktive hochverfügbare Dienste, löst der Watchdog laut Dokumentation nach 60 Sekunden einen Neustart des Servers aus. Standardmäßig nutzt Proxmox VE den Software-Watchdog des Linux-Kernels (softdog); ein Hardware-Watchdog muss eigens konfiguriert werden. Den Software-Watchdog bezeichnet der Hersteller als zuverlässig, aber nicht unabhängig von der Server-Hardware. Erst wenn der Cluster-Ressourcen-Manager die Sperre des Nodes übernommen hat, gilt dieser als abgegrenzt, und seine VMs starten auf den übrigen Nodes neu.

Der Loadbalancer nimmt einen ausgefallenen Node binnen Sekunden aus der Verteilung. Die virtuellen Maschinen des Nodes starten nach dem Fencing auf einem anderen Node neu; wie lange das dauert, hängt vom Fencing und von der Startzeit des Gastsystems ab.

Proxmox 2-Node-Cluster: nur mit externem Quorum-Device

Ein Zwei-Node-Cluster hat zwei Stimmen, für die Mehrheit braucht er ebenfalls zwei. Fällt einer der beiden Nodes aus, verliert der verbleibende das Quorum, und der Cluster ist nicht mehr handlungsfähig. Hochverfügbar wird ein Proxmox 2-Node-Cluster erst mit einer dritten Stimme von außen: dem externen Quorum-Device, kurz QDevice.

Beim QDevice läuft auf jedem Node der Dienst corosync-qdevice, auf einem unabhängigen Server außerhalb des Clusters der Schiedsdienst corosync-qnetd. Er gibt seine Stimme laut Proxmox-Dokumentation immer nur einem Teil des Clusters, der damit die Mehrheit erreicht. Angebunden ist er über TCP/IP, ohne die strengen Latenzanforderungen des Cluster-Netzes. Reißt die Verbindung zwischen den Nodes ab und erreichen beide noch das QDevice, erhält nur einer von beiden die Stimme. Bei Gleichstand entscheidet laut Corosync-Dokumentation zuletzt der Tie-Breaker, standardmäßig zugunsten des Nodes mit der niedrigsten Node-ID.

Grenzen eines Zwei-Node-Clusters mit QDevice

• Eigener Ort: Das QDevice läuft auf einem unabhängigen Server, sonst fiele es mit dem Node aus, den es absichern soll.
• Eigener Ausfall: Fällt das QDevice aus, kostet der nächste Node-Ausfall das Quorum. Es gehört deshalb ins Monitoring.
• Ein Node trägt alles: Nach einem Ausfall braucht der verbliebene Node Kapazität für die Last beider Nodes.
• Replikation in Intervallen: Ohne drei Nodes für Ceph empfehlen wir für kompakte Setups meist ZFS-Replikation, die in festen Intervallen abgleicht; nach einem Failover können laut Proxmox die Daten seit dem letzten Abgleich fehlen. Mehr dazu unter Ceph oder ZFS-Replikation.
• Bei ungerader Node-Zahl nicht empfohlen: Dort erhielte das QDevice n − 1 Stimmen und würde laut Proxmox fast zum Single Point of Failure; der Hersteller rät davon derzeit ab.

Zwei-Node-Setups mit externem Quorum-Device sind bei uns möglich. Für geschäftskritische Anwendungen empfehlen wir drei oder mehr Nodes.

Cluster über zwei Standorte: Die entscheidende Stimme gehört an einen dritten Ort

Verteilt man die Nodes eines Clusters gleichmäßig auf zwei Standorte, hat bei einer Trennung keine Seite die Mehrheit. Vier Nodes, zwei je Standort, brauchen drei Stimmen; jede Seite hat nur zwei. Beide Seiten verlieren das Quorum, und Nodes mit hochverfügbaren VMs grenzen sich selbst ab. Abhilfe schafft eine Entscheidungsinstanz an einem dritten Standort, die genau einer Seite ihre Stimme gibt.

In Proxmox VE übernimmt das QDevice diese Rolle. Bei vier Nodes liefert es die fünfte Stimme; die Mehrheit liegt dann bei drei von fünf. Trennen sich die Standorte, bekommt laut Corosync-Dokumentation die Seite mit den meisten aktiven Nodes die Stimme, bei Gleichstand entscheidet zuletzt der Tie-Breaker. Fällt ein ganzer Standort aus, erreicht der andere mit dem QDevice ebenfalls drei Stimmen.

Der dritte Ort ist entscheidend: Stünde das QDevice an einem der beiden Standorte, fiele es mit ihm aus, und die andere Seite bliebe mit zwei von fünf Stimmen ohne Quorum. Dasselbe Prinzip gilt für jede gerade Node-Zahl, die sich gleichmäßig auf zwei Standorte verteilt.

Für verteilten Storage gilt dasselbe Prinzip. Die Ceph-Dokumentation sieht für zwei Rechenzentren vor, dass jeder Standort die Daten vollständig vorhält. Ein Tiebreaker-Monitor in einer dritten Zone bestimmt bei einer Trennung, welche Seite weiterarbeitet.

Wie wir Quorum und Fencing im Managed Proxmox Cluster umsetzen

Unsere Managed Proxmox Cluster bestehen standardmäßig aus drei Nodes, die das Quorum über Corosync bilden. Quorum-Planung und Absicherung gegen Split-Brain gehören zum Redundanzkonzept, das wir in der Konzeption schriftlich ausarbeiten. Vor der Inbetriebnahme testen wir den Failover vollständig, danach regelmäßig mit Protokoll.

• N+1-Auslegung: Die übrigen Nodes haben Reserve für die VMs eines ausgefallenen Nodes
• Fencing vor dem Neustart: Der HA Manager startet VMs erst danach auf einem anderen Node
• Ceph mit drei Repliken je Datenblock auf verschiedenen Nodes, Standard in Essentials und Business
• Redundantes Netz: Bonding/LACP je Node, redundante Switches, getrennte Netze für Management, Storage und öffentlichen Traffic
• 24/7-Monitoring mit Alarmierung der Rufbereitschaft und Nachbericht zu Ursache und Maßnahmen
• Schriftliche Dokumentation von Architektur, Konfiguration und Notfallplan, die Ihnen gehört

Soll eine Umgebung über mehrere Standorte reichen, gehört der Ort der entscheidenden Stimme von Anfang an in dieses Konzept. Den Ablauf beschreiben Hochverfügbarkeitskonzept und Cluster-Aufbau sowie Failover-Tests und Notfallpläne.