Split-Brain Prevention: Topologie-Patterns für HA Cluster und RR

Split-Brain Prevention ist in Telco- und Provider-Umgebungen ein zentrales Designziel, weil ein „doppelaktiver“ Zustand oft gefährlicher ist als ein kurzer Ausfall. Ein Split-Brain entsteht, wenn ein HA-Cluster oder ein Control-Plane-System (z. B. Route Reflector Cluster, Controller, Datenbank-Backends) bei einer Partition oder bei inkonsistenter Sicht auf den Systemzustand gleichzeitig zwei aktive Instanzen zulässt. In der Praxis führt das zu widersprüchlichen Entscheidungen: Services werden doppelt bereitgestellt, Policies laufen auseinander, State wird inkonsistent, oder Routing wird instabil – mit Symptomen, die schwer zu diagnostizieren sind (Flapping, Route Oscillation, selektive Erreichbarkeit, Session-Churn). Besonders in Telco-Topologien ist das Risiko hoch, weil mehrere Netz- und Plattformdomänen zusammenwirken: DCI/Backbone kann partiell ausfallen, Management- und Telemetry-Pfade können getrennt werden, und dennoch sind Teile der Infrastruktur „erreichbar“. Genau deshalb muss Split-Brain Prevention als Topologie-Pattern verstanden werden: Quorum-Design, Fencing-Mechanismen, Failure Domains, Management-Pfade, Timeouts, sowie klare Rollen und Hierarchien in HA-Clustern und in RR-Designs. Ein professionelles Konzept entscheidet bewusst: In welchem Zweifelzustand ist es besser, auf „sicher offline“ zu gehen, statt inkonsistent online zu bleiben? Und wie beweisen wir, dass diese Entscheidung im echten Netzfall greift – mit messbaren SLOs und wiederholbaren Tests? Dieser Artikel zeigt praxisnah, wie Sie Split-Brain verhindern: mit bewährten Topologie-Patterns für HA-Cluster und Route Reflector (RR) Architekturen, mit klaren Quorum- und Fencing-Ansätzen, und mit Betriebsmechanismen, die den Ernstfall beherrschbar machen.

Split-Brain verstehen: Partition ist nicht gleich Ausfall

Viele Teams planen Ausfälle als „Node down“ oder „Link down“. Split-Brain entsteht dagegen häufig bei Partitionen: Die Systeme leben, können aber nicht zuverlässig miteinander kommunizieren oder haben unterschiedliche Sicht auf die Umgebung. In Telco-Netzen sind solche Situationen realistisch: DCI isoliert zwei Rechenzentren, ein Metro-Hub verliert einen Pfad, Management-VRF ist gestört, oder ein Security-Change blockiert Heartbeats. Ein Split-Brain ist deshalb kein exotischer Randfall, sondern ein typisches Risiko in redundanten, segmentierten Topologien.

• DCI-Partition: Sites sind intern gesund, aber zwischen den Sites fehlen Heartbeats oder Quorum-Kommunikation.
• Management-Partition: Datenpfad funktioniert, Management-/Control-Pfad ist gestört; Cluster entscheidet falsch.
• Asymmetrische Erreichbarkeit: A sieht B, B sieht A nicht; führt zu widersprüchlichen Aktivitätsentscheidungen.
• Time drift: Zeitquellenprobleme verfälschen Timeouts und Wahlverfahren, besonders bei verteilten Systemen.

Leitprinzip: Im Zweifel ist Inkonsistenz teurer als Downtime

Ein kurzer, kontrollierter Ausfall ist oft akzeptabler als ein inkonsistenter Zustand, der Daten beschädigt oder Routing destabilisiert. Split-Brain Prevention ist daher häufig ein „Safety-first“-Design.

Wo Split-Brain in Telco-Umgebungen typischerweise auftritt

Split-Brain ist nicht nur ein HA-Problem klassischer Servercluster. In Telco-Clouds und Provider-Netzen gibt es mehrere Komponentenklassen, die besonders betroffen sind: stateful Netzwerkfunktionen, Controller/Orchestratoren, Datenbanken/State Stores, und Control-Plane-Knoten wie Route Reflectors oder Policy-Controller. Auch wenn RR selbst kein „Active/Standby“ im klassischen Sinn ist, können Partitionen zu inkonsistenter Route-Distribution führen, die ähnliche Auswirkungen hat: unterschiedliche Teile des Netzes lernen unterschiedliche Routen, wodurch Reachability partiell bricht.

• HA-Cluster (Active/Active oder Active/Standby): Firewalls, Load Balancer, CGNAT, BNG/BRAS, DPI/Proxy.
• Control-/Management-Systeme: SDN-Controller, Orchestratoren, PKI/AAA, Telemetry-Controlplanes.
• State Stores: Datenbanken, Session Stores, Policy Stores, Inventar/CMDB-Kernsysteme.
• RR-Topologien: Multi-Cluster RR, hierarchische RR-Designs, Region-übergreifende iBGP-Topologien.

Anti-Pattern: „Wir haben zwei Sites, also sind wir sicher“

Zwei Sites ohne Quorum- und Fencing-Design erhöhen oft das Split-Brain-Risiko. Redundanz ohne Entscheidungsmechanik ist keine HA, sondern eine Einladung zur Doppelaktivität.

Die drei Säulen der Split-Brain Prevention: Quorum, Fencing, Failure Domains

Split-Brain Prevention lässt sich auf drei Grundmechanismen zurückführen. Erstens Quorum: Wer darf aktiv sein? Zweitens Fencing: Wie wird die „verlierende“ Seite zuverlässig vom Dienst getrennt? Drittens Failure Domains: Wie schneiden Sie Topologie so, dass Partitionen erwartbar sind und Quorum-Pfade nicht mit normalen Datenpfaden kollidieren?

• Quorum: Mehrheitsentscheidungen verhindern, dass beide Seiten gleichzeitig „gewinnen“.
• Fencing: Harte Durchsetzung der Entscheidung (z. B. Service deaktivieren, Ports sperren, VIP withdraw).
• Failure Domains: Physische und logische Trennung (Power, Fabric, DCI, Management), damit Quorum robust bleibt.

Ein minimales Quorum-Modell

$\mathrm{Active}ist\mathrm{zulässig},wenn\mathrm{Votes}\ge \mathrm{Majority}$

Die Mehrheit kann aus Nodes, Instanzen oder externen Witness-Komponenten bestehen. Wichtig ist, dass die Mehrheit nicht von einer einzigen Failure Domain abhängt.

Quorum-Patterns: 2-Nodes, 3-Nodes und Witness-Design

Die größte Split-Brain-Falle sind 2-Node-Cluster ohne externen Entscheider. Wenn beide Seiten bei Partition „denken“, sie wären allein, werden beide aktiv. Deshalb sind 2-Node-Setups in Telco-HA nur dann verantwortbar, wenn es einen dritten „Vote“ gibt: einen Witness, der unabhängig erreichbar ist. In Multi-Region-Designs wird dieser Witness oft in einer dritten Zone/Region platziert.

• 2-Node + Witness: Zwei aktive/standby Nodes plus externer Witness als dritter Vote; reduziert Split-Brain stark.
• 3-Node Quorum: Drei gleichwertige Nodes (oder Controlplane-Instanzen) in getrennten Failure Domains.
• 5-Node Quorum: Für große, kritische Systeme; toleriert mehr Ausfälle, erhöht aber Betriebskomplexität.
• Witness-Platzierung: Nicht im gleichen DC, nicht am gleichen DCI-Pfad, idealerweise in separater Zone mit unabhängiger Anbindung.

Designregel: Witness muss unabhängiger sein als die Sites

Ein Witness im gleichen DCI-Failure Domain löst das Problem nicht. Er muss so platziert sein, dass eine DCI-Partition nicht gleichzeitig den Witness isoliert.

Fencing-Patterns: Wie man Doppelaktivität technisch verhindert

Quorum entscheidet, wer aktiv sein darf. Fencing sorgt dafür, dass die Entscheidung durchgesetzt wird. In Telco-HA ist Fencing häufig „netzbasiert“: VIPs werden withdrawn, Anycast-Ankündigungen gestoppt, Service-Interfaces gesperrt oder Traffic wird über Policies umgelenkt. Wichtig: Fencing muss zuverlässig sein – „soft fencing“ über Logik allein ist riskant, wenn Partitionen genau diese Logik stören.

• VIP/Anycast Withdraw: Die verlierende Seite kündigt VIP/Service Prefixe nicht mehr an; Traffic fließt weg.
• Service Interface Shutdown: Ports oder VRFs werden deaktiviert, um Datenpfad-Zugriff zu verhindern.
• Policy Fencing: BGP Communities/LocalPref setzen die Seite auf „drain“; wirkt gut, braucht aber stabile Control Plane.
• Out-of-Band Fencing: Managementpfad sperrt oder rebootet die Instanz; sehr effektiv, aber muss selbst resilient sein.

Anti-Pattern: Fencing nur über Heartbeats

Wenn Heartbeats ausfallen, ist genau der Moment, in dem Sie Fencing brauchen. Reines Heartbeat-basiertes Fencing ohne unabhängigen Entscheidungs- und Durchsetzungspfad ist gefährlich.

Topologie-Patterns für HA-Cluster: Active/Standby sauber und wartungsfähig

Active/Standby ist in Telco-Netzen verbreitet, weil es Ownership klar macht. Split-Brain Prevention bedeutet hier: Es darf nicht passieren, dass beide Seiten gleichzeitig „Primary“ werden. Topologisch erreichen Sie das über klare Quorum-Regeln, über deterministische Failover-Trigger, und über Pfadkonsistenz, damit Failover nicht neue Fehlerbilder erzeugt (MTU/QoS, Symmetrie).

• Dual-Homing + deterministische Primary: Primär-/Sekundärrolle statisch definieren, Failover nur bei klaren Kriterien.
• Witness-gestütztes Failover: Failover nur, wenn Quorum bestätigt, dass die andere Seite wirklich verloren ist.
• Symmetrie sichern: Stateful Firewalls/CGNAT brauchen symmetrische Pfade oder State-Sync; Topologie muss das erzwingen.
• Maintenance Domains: Cluster so schneiden, dass Rolling Upgrades ohne Doppelaktivität möglich sind.

Designregel: Failover und Failback getrennt planen

Failback ist oft riskanter als Failover. Ohne Hysterese kann es zu Ping-Pong kommen, was Split-Brain-ähnliche Zustände erzeugt (wechselnde Active-Seite). Planen Sie Failback wie einen Progressive Rollout.

Topologie-Patterns für HA-Cluster: Active/Active ohne Split-Brain

Active/Active erhöht die Anforderungen. Hier geht es nicht nur um „wer ist aktiv“, sondern oft um „wer ist für welchen Traffic aktiv“. Sharding reduziert Split-Brain-Risiko: Jede Seite ist nur für definierte Shards „write-primary“, die andere ist hot-standby oder read-only. Zusätzlich braucht Active/Active klare Partition-Regeln: Was passiert bei DCI-Partition? Wer stoppt welche Shards? Wie wird verhindert, dass beide Seiten denselben Shard bedienen?

• Shard-by-Design: Definierte Zuständigkeiten pro Region/Kundensegment; verhindert Doppelbearbeitung.
• Quorum-gestützte Ownership: Shard-Ownership nur bei Mehrheit; bei Partition wird die Minderheit gefenced.
• Anycast mit Health-Gates: Anycast ist nicht automatisch sicher; Ankündigungen müssen an echte Servicegesundheit gekoppelt sein.
• Partition Mode: Definierte „degraded modes“: besser nur ein Teil aktiv als beide inkonsistent aktiv.

Anti-Pattern: Active/Active ohne Sharding und ohne Fencing

„Beide Sites sind aktiv“ klingt gut, ist aber ohne klare Ownership und Fencing eine klassische Split-Brain-Falle – besonders bei stateful Diensten.

RR-Split-Brain im weiteren Sinne: Inkonsistente Route-Distribution verhindern

Route Reflectors sind keine klassischen HA-Cluster, aber sie können in Partitionen ähnliche Probleme erzeugen: unterschiedliche Teile des Netzes sehen unterschiedliche Routen, was zu partieller Erreichbarkeit und schwer erklärbaren Pfadwechseln führt. In großen Telco Backbones sind RR-Topologien daher so zu designen, dass Partitionen nicht zu „zwei Wahrheiten“ führen. Das erreicht man über Hierarchien, Failure Domain Cuts und konsistente iBGP-Policy.

• RR-Hierarchie: Regionale RR-Cluster mit übergeordneten RRs; begrenzt Failure Domains.
• Redundanz pro Domäne: Mindestens zwei RRs pro Domäne, aber nicht in derselben Failure Domain (Power/Fabric).
• Client-Design: Clients peeren mit mehreren RRs in unterschiedlichen Domänen, um Partitionen abzufedern.
• Route Policy Guardrails: Max-Prefix, Route Leak Schutz, konsistente Communities verhindern Eskalationen bei Instabilität.

Designregel: RR-Topologie muss Partitionen „überleben“

Ein RR-Design ist gut, wenn bei Partitionen entweder konsistente Routenverfügbarkeit erhalten bleibt oder die Degradation klar begrenzt ist (z. B. nur eine Region betroffen) – statt globaler Instabilität.

Topologische Trennung: Management, Quorum und Datenpfad dürfen nicht dieselbe Achillesferse teilen

Split-Brain entsteht oft, weil Quorum- und Fencing-Kommunikation über denselben Pfad läuft wie Datenverkehr oder über eine gemeinsam geteilte Infrastruktur. Wenn dieser Pfad partiell ausfällt, sind Entscheidungen falsch. Deshalb sollten Quorum- und Fencing-Pfade bewusst getrennt werden: Management-VRF/OOB, separate Fabrics, unabhängige DCI-Pfade, und klare SRLG-Analyse.

• OOB/Management-VRF: Quorum- und Fencing-Channel in separater Domain mit QoS-Priorisierung.
• DCI-Diversität: Mehrere physisch diverse Verbindungen, getrennte Transitrouten, getrennte Provider.
• SRLG-Mapping: Gemeinsame Risiken sichtbar machen (Trasse, Facility, Patchpanel, Fabric).
• Time Architecture: NTP/PTP stabil; Time drift kann Quorum-Timeouts verfälschen.

Anti-Pattern: Quorum über „best effort“ Pfade

Wenn Quorum-Kommunikation in Congestion droppt oder durch Security-Changes blockiert wird, entstehen falsche Failoverentscheidungen. Quorum-Kommunikation braucht Priorität und Stabilität.

Timeouts, Hysterese und „Stability Windows“: Split-Brain durch Flapping verhindern

Neben Partitionen ist Flapping ein häufiger Split-Brain-Treiber: Links oder Heartbeats sind instabil, Rollen wechseln hin und her, und Services werden mehrfach umgeschaltet. Das ist praktisch ein „zeitlicher Split-Brain“. Hier helfen Hysterese, Mindestdauern, und stabilitätsbasierte Entscheidungen.

• Hold-down Timer: Nach Failover eine Mindestzeit warten, bevor Failback erlaubt ist.
• Stability Window: Rollenwechsel nur, wenn der Zustand über X Sekunden/Minuten stabil ist.
• Mehrfaktor-Health: Nicht nur ein Heartbeat, sondern mehrere Signale (Service-Health, Routing-Health, Quorum).
• Rate Limits: Begrenzen, wie oft Rollen wechseln dürfen, um Kaskaden zu verhindern.

Designregel: Schnell ist nicht immer besser

Extrem aggressive Timeouts können Failover beschleunigen, aber auch Fehlentscheidungen erhöhen. In Telco-HA ist die beste Einstellung die, die SLOs erfüllt und zugleich Stabilität wahrt.

Tests und Nachweis: Split-Brain Prevention muss geübt werden

Ein Split-Brain-Design ist nur so gut wie seine Tests. Besonders wichtig sind Partition-Szenarien: DCI isoliert, Managementpfad gestört, asymmetrische Erreichbarkeit. Diese Szenarien sollten als Failure Scenario Workshops und als kontrollierte Chaos-Experimente durchgeführt werden – mit klaren Stop/Go-Gates und messbaren SLIs.

• Partition Tests: DCI down, Management down, Heartbeat blockiert; prüfen, welche Seite aktiv bleibt.
• Fencing Tests: Verify, dass VIP/Anycast wirklich withdrawn wird und dass Traffic sauber umschwenkt.
• RR Tests: RR-Knoten isolieren, Prefix-Consistency und Reachability prüfen, kein globaler Route-Churn.
• Failback Tests: Kontrolliertes Failback in Wellen, keine Ping-Pong-Zustände.

Evidence-by-Design: Expected vs. Observed dokumentieren

Notieren Sie für jedes Szenario: Erwartete Rollenentscheidung, beobachtete Rollenentscheidung, SLO-Impact, und Ursachen. So wird Split-Brain Prevention auditierbar und verbessert sich iterativ.

Typische Fallstricke und wie man sie vermeidet

• 2-Node ohne Witness: Lösung: Witness oder dritter Vote in unabhängiger Failure Domain.
• Fencing nicht zuverlässig: Lösung: netzbasiertes Withdraw plus OOB-Fallback, deterministische Durchsetzung.
• Quorum und Datenpfad teilen Risiken: Lösung: Management/OOB, DCI-Diversität, SRLG-Analyse.
• Active/Active ohne Ownership: Lösung: Sharding, Write-Ownership, Quorum-gestützte Zuweisung.
• Flapping erzeugt Ping-Pong: Lösung: Hysterese, Hold-downs, Stability Windows, Rate Limits.
• RR-Design zu flach: Lösung: hierarchische RR-Topologie, domänenbasierte Redundanz, Policy Guardrails.
• Keine Partition-Tests: Lösung: regelmäßige Workshops/Chaos-Experimente mit Stop-Gates und klarer Dokumentation.

Praktische Leitlinien: Topologie-Patterns für Split-Brain Prevention

• Quorum sauber designen: 2-Node nur mit Witness; Witness in unabhängiger Failure Domain platzieren.
• Fencing durchsetzen: VIP/Anycast Withdraw, Service-Interface Shutdown und OOB-Fencing als zuverlässige Muster kombinieren.
• Failure Domains schneiden: PoP/Region/DCI/SRLG als reale Risiken modellieren und Quorum-Pfade davon entkoppeln.
• Active/Active sharden: Write-Ownership definieren, Partition-Mode Regeln festlegen, Minderheit automatisch fencen.
• RR-Hierarchie nutzen: Regionale RR-Cluster, übergeordnete RRs, Clients zu mehreren RRs in getrennten Domänen.
• Stabilität priorisieren: Hysterese, Hold-downs, Stability Windows gegen Ping-Pong und falsche Failovers.
• Observability verpflichtend: Rollenstatus, Quorum-Health, Routing-Health, SLO/SLI und Telemetry-Pipeline-SLOs messen.
• Partitionen testen: DCI/Management/Asymmetrie gezielt durchspielen, Expected vs. Observed dokumentieren und Backlog pflegen.