Data Center Failover: Active/Active vs. Active/Standby in Telco Clouds

Data Center Failover ist in Telco Clouds die entscheidende Fähigkeit, kritische Netz- und Plattformservices auch dann stabil bereitzustellen, wenn ein Rechenzentrum (DC) oder ein kompletter Standort ausfällt. Ob es um 5G Core Funktionen, IMS/VoLTE, BNG/BRAS in Virtualisierung, CGNAT als CNF, DDoS Scrubbing, Edge Firewalls, DNS oder Observability-Pipelines geht: Die Wahl zwischen Active/Active und Active/Standby bestimmt RTO, RPO, Betriebsaufwand, Kosten und den realen Blast Radius im Störfall. In der Praxis scheitern Failover-Konzepte selten am „Routing an sich“, sondern an Abhängigkeiten: Datenreplikation, Statefulness, Latenzbudgets über DCI, asymmetrische Pfade, MTU/QoS-Inkonsistenzen, Control-Plane-Partitionen oder schlicht fehlender Headroom im N-1. Active/Active kann Ausfälle oft schneller absorbieren und Last besser verteilen, erhöht aber Komplexität: Konsistenzmodelle, Split-Brain-Risiken und Policy-Disziplin werden zu zentralen Themen. Active/Standby ist einfacher, auditierbarer und oft stabiler für stateful Workloads, kann aber längere Umschaltzeiten und eine teure Reservekapazität bedeuten. Ein professionelles Design entscheidet nicht nach Ideologie, sondern nach Workload-Klasse, Service-SLO, State-Modell und Topologie: Welche Dienste sind stateless, welche stateful? Welche Daten müssen synchron repliziert werden? Wie viel Latenz und Jitter verträgt der Service? Und wie schnell muss die Übernahme wirklich sein? Dieser Artikel zeigt, wie Sie Active/Active und Active/Standby in Telco Clouds vergleichen, welche Topologie- und Routingmuster sich bewährt haben und wie Sie Failover so bauen, dass er messbar, testbar und betrieblich beherrschbar bleibt.

Telco Cloud Kontext: Warum Data Center Failover anders ist als klassisches IT-DR

Telco Clouds unterscheiden sich von vielen Enterprise-IT-Umgebungen durch strengere Verfügbarkeits- und Latenzanforderungen, durch hohe Zustandsdichte (Sessions, Registrations, NAT-State), und durch die Kopplung an Transport- und Edge-Topologien (Metro/Backbone/DCI). Zudem sind viele Telco-Services Teil von Service Chains: Verkehr durchläuft mehrere Netzwerkfunktionen, deren Reihenfolge und Symmetrie entscheidend sind. Ein DC-Failover ist deshalb nicht nur ein Plattformthema, sondern ein End-to-End-Thema von Routing, DCI, DNS, Security und Service-Orchestrierung.

• Latenzbudgets: DCI-Latenz beeinflusst Replikation, State-Sync und Echtzeitdienste.
• Statefulness: Viele Funktionen sind session-/zustandsbasiert und reagieren empfindlich auf Pfadwechsel.
• Service Chains: Firewalls, Load Balancer, CGNAT, DDoS, Policy-Engines müssen im Failover konsistent sein.
• Traffic Engineering: Pfadwahl (ECMP, SR-TE) und Exit-Strategien beeinflussen, wie Failover „gefühlt“ wird.

Leitprinzip: Failover ist ein Pfad- und Zustandsproblem, kein einzelner Mechanismus

Ein DC kann technisch erreichbar bleiben, während Services trotzdem ausfallen, weil State, DNS oder Routing nicht sauber umschalten. Ein gutes Design betrachtet Transport, Control Plane und Service Layer gemeinsam.

Active/Active vs. Active/Standby: Die Entscheidungsachsen

Die Kernfrage lautet nicht „welches ist besser“, sondern „welches erfüllt die Ziele mit vertretbarer Komplexität“. Die Entscheidung lässt sich entlang weniger stabiler Achsen strukturieren: gewünschte Umschaltzeit (RTO), Datenverlusttoleranz (RPO), State-Modell, Latenz über DCI, Betriebsreife und Kosten.

• RTO: Active/Active kann in vielen Fällen schneller reagieren, weil beide Sites bereits Traffic tragen.
• RPO: Active/Active erfordert oft konsistente Daten-/State-Modelle; Active/Standby kann mit klarer Primary-Ownership einfacher sein.
• Komplexität: Active/Active braucht Split-Brain-Protection, deterministische Policies und saubere Observability.
• Kosten: Active/Standby hält Kapazität „kalt“; Active/Active nutzt Kapazität effizienter, benötigt aber häufig mehr Engineering-Aufwand.
• Failure Domains: Active/Active kann Failure Domains verkleinern, wenn Sharding sauber ist; schlecht gemacht vergrößert es Blast Radius.

Ein pragmatischer Grundsatz

Je stateful und konsistenzkritischer ein Dienst ist, desto eher gewinnt Active/Standby. Je statelesser und skaliertbarer ein Dienst ist, desto eher lohnt Active/Active.

Workload-Klassen in Telco Clouds: Stateless, Stateful, „State-heavy“

Die Wahl des Failover-Modells hängt stark davon ab, wie „zustandslastig“ ein Dienst ist. In Telco-Stacks sind viele Funktionen nicht rein stateless, aber auch nicht immer streng synchron. Deshalb ist eine Klassifizierung hilfreich, um Architekturentscheidungen zu standardisieren.

• Stateless: API-Gateways, bestimmte Microservices, DNS-Resolver/Authoritatives (mit Anycast), Telemetry-Collector-Frontends.
• Stateful: Datenbanken, Subscriber-Daten, Policy Stores, Session-Handling in Kernfunktionen, Stateful Firewalls.
• State-heavy / High Churn: CGNAT State, BNG Sessions, VoLTE/IMS Registrations, massive Connection Rates (CPS).
• Control Plane kritisch: Orchestratoren, Controller, PKI/AAA, RR/Control-Komponenten, deren Ausfall die gesamte Plattform beeinflusst.

Designregel: RPO wird durch die „State-heavy“-Komponenten definiert

Sie können Teile des Stacks active/active fahren, aber wenn ein zentraler State-Store nur active/standby sinnvoll kann, prägt er die effektive DR-Architektur.

Topologie-Bausteine für DC-Failover: DCI, Underlay/Overlay und Service Edges

Unabhängig vom Failover-Modell benötigen Sie eine solide DCI-Topologie und klare Underlay/Overlay-Grenzen. DCI ist dabei nicht nur Bandbreite, sondern auch Latenz, Jitter, MTU und Failure Domain. In Telco Clouds wird DCI oft zum Engpass im Failover, weil zusätzlich zu User Traffic auch Replikation und Control-Plane-Traffic steigt.

• DCI L3 bevorzugt: L3-Interconnect begrenzt Failure Domains und reduziert L2-Churn, was im Failover stabiler ist.
• MTU-End-to-End: Overlays, EVPN, SR/MPLS oder IPsec erhöhen Overhead; im Failover entstehen sonst Blackholes.
• QoS im DCI: Replikations- und Control-Traffic dürfen User-SLOs nicht zerstören; Klassen müssen priorisiert werden.
• Edge-Anbindung: Internet/Peering/PNI/Transit, Enterprise Handover und Mobile Transport müssen zur aktiven Site passen.

Anti-Pattern: DCI nur nach Durchschnittsauslastung dimensionieren

Failover ist ein Peak-Ereignis. Wenn DCI im Normalbetrieb „ok“ ist, kann sie im Failover kollabieren. Planen Sie N-1/N-2 und prüfen Sie p95/p99 sowie Queue-Drops, nicht nur Mittelwerte.

Active/Active Architekturpattern: Sharding, Anycast und „Active/Active, aber nicht überall“

Active/Active wird in Telco Clouds selten als „alles überall“ umgesetzt. Ein typisches Pattern ist Sharding: Regionen oder Kundensegmente werden primär einer Site zugeordnet, während die andere Site als Hot-Standby für diese Shards fungiert. So nutzen Sie Kapazität aktiv, reduzieren aber Cross-Site-Konsistenzdruck und Split-Brain-Risiko.

• Shard-by-Region: Region A primär in DC1, Region B primär in DC2; gegenseitige Übernahme bei Ausfall.
• Shard-by-Service: Bestimmte Dienste active/active (DNS, API), andere active/standby (state-heavy Stores).
• Anycast for Edge Services: DNS oder stateless Frontends mit Anycast-IP in beiden DCs; Routing liefert Nähe und Failover.
• Policy Consistency: Identische Sicherheits- und Routingregeln in beiden DCs, sonst entstehen asymmetrische Fehler.

Designregel: Active/Active braucht klare „Write Ownership“

Wenn beide Sites gleichzeitig schreiben dürfen, müssen Konflikte gelöst werden. Häufig ist es besser, Schreibrechte zu shardieren und nur Lese-/Cache-Funktionen global zu machen.

Split-Brain vermeiden: Quorum, Fencing und Control-Plane-Partitionen

Das größte Risiko in Active/Active ist Split-Brain: Beide Sites halten sich für aktiv und bedienen denselben Dienst inkonsistent. In Telco Clouds ist das besonders kritisch, weil es nicht nur Daten betrifft, sondern auch Routing, Policies und Session-State. Split-Brain-Schutz ist daher Pflicht: Quorum-Mechanismen, Fencing (hartes Deaktivieren einer Seite) und klare Regeln bei DCI-Partition.

• Quorum: Entscheidungen über „active“ basieren auf mehr als nur Link-Status, z. B. Mehrheitsentscheidungen.
• Fencing: Eine Seite wird bei Unsicherheit gezielt vom Service entkoppelt, um Doppelaktivität zu verhindern.
• Partition Handling: DCI down ist nicht gleich DC down; Regeln müssen definieren, wer weiter bedient.
• Stabilität vor Verfügbarkeit: In manchen Diensten ist „kurz offline“ besser als „inkonsistent online“.

Designregel: Definieren Sie DCI-Partition als eigenes DR-Szenario

Viele Designs testen nur „DC komplett down“. In der Realität ist „DCI isoliert“ häufiger und gefährlicher. Dieser Fall muss explizit in Runbooks und Mechanismen abgebildet werden.

Active/Standby Architekturpattern: Hot Standby, Warm Standby und Kapazitätsreserven

Active/Standby ist in Telco Clouds sehr verbreitet, weil es Ownership klar macht: Es gibt eine Primary Site und eine Secondary Site. Die Secondary kann „hot“ sein (bereit, mit laufenden Services und synchroner Datenhaltung), „warm“ (Services startbar, Daten repliziert, aber nicht im vollen Betrieb) oder „cold“ (lange RTO, oft nur für kritische Notfälle). In Telco-Designs ist Hot oder Warm Standby üblich, abhängig von RTO/RPO.

• Hot Standby: Dienste laufen, aber tragen keinen oder wenig Traffic; Umschalten schnell, aber Kapazitätskosten höher.
• Warm Standby: Teile laufen, Teile werden bei Failover hochgefahren; RTO moderat, OPEX geringer.
• Cold Standby: Lange RTO; nur für seltene Notfallszenarien geeignet.
• N-1 Headroom: Secondary muss Peak-Last aufnehmen können, sonst wird Failover zur Degradation.

Anti-Pattern: Standby ohne getestete „Readiness“

Ein Standby-DC, der nie unter Last getestet wird, ist im Ernstfall eine Überraschung. Failover muss regelmäßig geübt werden, inklusive DNS/Routing/Serviceketten.

DNS im DC-Failover: Anycast, TTL und Health-Steering

DNS ist oft der schnellste Traffic-Steering-Hebel, aber auch eine häufige Fehlerquelle. Zu hohe TTLs verlängern Umschaltungen, zu niedrige TTLs erhöhen Last und Instabilität. In Telco Clouds sind Anycast-basierte DNS-Architekturen oft sehr robust: Die gleiche IP wird aus beiden DCs annonciert, Routing wählt die nächstgelegene gesunde Instanz. Für bestimmte Anwendungen wird DNS ergänzend genutzt, um Regionpräferenzen umzusetzen.

• Anycast DNS: Sehr gute Failover-Eigenschaften, wenn Routing-Health und Service-Health sauber gekoppelt sind.
• TTL-Strategie: Kritische Records moderat niedrig, nicht extrem; weniger kritische Records höher.
• Health Checks: Steuerung auf Basis echter Servicegesundheit (nicht nur „Port offen“).
• Client-Caching beachten: Manche Clients ignorieren TTLs; Failover muss daher auch ohne DNS-Wechsel funktionieren.

Designregel: DNS ist Ergänzung, nicht alleinige DR-Mechanik

Routing- und Service-Mechanismen müssen auch ohne DNS schnell stabil sein. DNS kann helfen, ist aber keine Garantie – insbesondere bei gecachten Antworten.

Routing im DC-Failover: BGP-Announcements, Anycast VIPs und Pfadsteuerung

Routing ist der zweite Haupthebel neben DNS. In Telco Clouds wird typischerweise BGP genutzt, um Prefixe oder Anycast VIPs aus dem aktiven DC zu announcen. Im Failover werden Announcements zurückgezogen und in der anderen Region aktiviert. Entscheidend ist dabei, dass Inbound- und Outbound-Pfade kontrolliert sind und dass Interconnect-Fallbacks kapazitiv passen.

• Unicast Prefix Failover: Prefixe werden nur aus der aktiven Site announced; Failover = withdraw/announce.
• Anycast VIPs: Gleiche VIPs in beiden DCs; Health entscheidet, wer announced.
• Inbound Steuerung: Prepends/Communities für Upstreams, regionale Announcements, um Hairpinning zu vermeiden.
• Outbound Steuerung: Local Preference und TE, um Egress konsistent zu halten und asymmetrische Pfade zu vermeiden.

Designregel: Interconnect ist Teil des Failovers

Wenn DC1 ausfällt, ändert sich nicht nur „wo Services laufen“, sondern auch „wo Internet/Partnerverkehr austritt“. Planen Sie Transit/Peering/PNI-Reserven und die Pfadwahl explizit.

Services und State: Session-Handling, Datenreplikation und Service Chains

Der schwierigste Teil ist der State. In Telco Clouds hängen viele Dienste an Session-Zuständen oder an Datenbanken mit strengen Konsistenzanforderungen. Active/Active kann funktionieren, wenn State sharded oder repliziert wird und Konflikte lösbar sind. Active/Standby kann einfacher sein, wenn Primary Ownership klar ist und Replikation zuverlässig ist. In beiden Fällen ist entscheidend: State ist nicht nur Datenbank, sondern auch Netzwerkstate (NAT, Firewall, Load Balancer, Policy).

• Session Continuity: Je nach Dienst können Sessions migriert werden oder müssen neu aufgebaut werden; das muss in RTO/RPO einfließen.
• Replikationsmodell: Sync vs. async; sync reduziert RPO, erhöht aber Latenzanforderungen an DCI.
• Service Chains: Failover darf keine asymmetrischen Pfade erzwingen, sonst brechen stateful Funktionen.
• Capacity im Failover: CPS/Churn Peaks nach Umschaltung müssen abgefangen werden (BNG/CGNAT/IMS).

Anti-Pattern: Failover ohne Churn-Plan

Nach einem DC-Failover können Millionen Clients neu verbinden. Wenn CPS und Session-Table-Headroom nicht geplant sind, ist der Dienst formal „online“, aber praktisch nicht nutzbar.

Observability im Failover: Nachweis und schnelle Diagnose

Ein DC-Failover muss messbar sein. Ohne klare SLIs sehen Teams nur Symptome und verlieren Zeit. Gleichzeitig muss die Observability-Pipeline selbst redundant sein: Wenn Collector, DNS-Health-Checks oder Telemetry in der ausgefallenen Site hängen, arbeiten Teams im Blindflug. Das erhöht RTO und erzeugt Fehlentscheidungen.

• Failover SLIs: Availability, p95/p99 Latenz, Loss, Error Rates, Session-Churn.
• Engpasssignale: Queue-Drops an DCI und Interconnect, Portauslastung, ECMP/LAG Member-Imbalance.
• Routing Health: Prefix-Counts, BGP Update-Rate, Anycast Reachability, Withdraw/Announce Events.
• Pipeline SLOs: Datenlücken, Collector-Health, Stream-Latenz, damit „keine Daten“ nicht als „keine Probleme“ missverstanden wird.

Designregel: Failover-Tests sind Teil der Plattformqualität

Regelmäßige Tests (Canary, progressive Rollouts, kontrollierte Drains) machen Failover vorhersehbar und reduzieren echte Incidentzeiten.

Test- und Betriebsmodell: Failover und Failback wie Rolling Upgrades behandeln

Failover ist nur die Hälfte. Failback ist oft riskanter: Wenn die ursprüngliche Site wieder verfügbar ist, kann eine unkontrollierte Rückkehr zu Ping-Pong, Congestion und State-Problemen führen. Deshalb sollten Failover und Failback als standardisierte Prozeduren behandelt werden: mit Stop/Go-Gates, schrittweisen Wellen und Rollback-Möglichkeiten.

• Canary Failover: Zuerst kleine Servicegruppe oder Shard umschalten, dann erweitern.
• Stop/Go Gates: SLOs grün, keine Drops in priorisierten Klassen, Session-Churn unter Schwelle.
• Controlled Failback: Rückkehr in Wellen, mit Hysterese, um Ping-Pong zu vermeiden.
• Postmortem & Backlog: Findings in Maßnahmen überführen (Kapazität, Policies, Runbooks, Telemetry).

Anti-Pattern: Failback als „einfach zurückschalten“

Failback ist ein Change unter Last. Behandeln Sie ihn wie einen Progressive Rollout – sonst erzeugen Sie nach dem Disaster den nächsten Incident.

Typische Entscheidungshilfen: Wann Active/Active, wann Active/Standby?

• Active/Active bevorzugen, wenn: Dienste stateless oder shardbar sind, sehr kurze RTO nötig ist, und Observability/Governance reif ist.
• Active/Standby bevorzugen, wenn: Dienste stark stateful sind, Konsistenz kritisch ist, oder wenn Betriebsrisiko minimiert werden muss.
• Hybrid wählen, wenn: Kontroll- und Edge-Services active/active sinnvoll sind, während State-Stores und High-Churn-Dienste eher standby benötigen.
• Geografie beachten: Hohe DCI-Latenz erschwert sync Replikation und Active/Active Konsistenz.

Typische Fallstricke und wie man sie vermeidet

• DCI-Engpass im Failover: Lösung: N-1/N-2 Headroom, QoS im DCI, Peak- und Failover-Tests unter Last.
• Split-Brain bei DCI-Partition: Lösung: Quorum/Fencing, klare Partition-Regeln, getestete Runbooks.
• DNS verlängert RTO: Lösung: Anycast DNS, TTL-Strategie, Health-Checks, Client-Caching berücksichtigen.
• Routing-Policies inkonsistent: Lösung: Policy-Blueprints pro Region, gleiches Community-Modell, Vorher/Nachher-Messung.
• Stateful Services brechen: Lösung: RPO/RTO pro Dienst, Session/State-Handling, Churn-Headroom, Logging-Pipeline stabilisieren.
• Observability fällt aus: Lösung: Telemetry-Domain redundant, Pipeline-SLOs, Collector-Cluster in beiden DCs.

Praktische Leitlinien: Data Center Failover in Telco Clouds richtig designen

• Ziele definieren: RTO/RPO pro Dienstklasse, daraus Active/Active vs. Active/Standby ableiten.
• Workloads klassifizieren: Stateless, stateful, state-heavy; passende Failover-Pattern pro Klasse standardisieren.
• DCI robust bauen: L3 DCI als Default, konsistente MTU/QoS, N-1/N-2 Headroom und Failure-Scenario-Tests.
• Routing und DNS koppeln: Anycast dort, wo sinnvoll; unicast Failover mit klaren BGP-Policies; DNS TTL und Health-Checks abgestimmt.
• Split-Brain verhindern: Quorum, Fencing, Partition-Playbooks und klare Ownership-Regeln.
• Service Chains stabil halten: Symmetrie, State-Sync (wo nötig), und definierte Pfade im Failover.
• Churn planen: CPS/Session-Headroom, kontrollierte Wellen, Go/No-Go Gates für Failover und Failback.
• Observability verpflichtend: SLO/SLI, Queue-Drops, Routing Health, Pipeline-SLOs; Vorher/Nachher messbar machen.
• Regelmäßig testen: Canary Failover, progressive Rollouts, Chaos/Failure Workshops, Expected vs. Observed dokumentieren.