Site icon bintorosoft.com

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

Red Snapper

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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?

Typische Fallstricke und wie man sie vermeidet

Praktische Leitlinien: Data Center Failover in Telco Clouds richtig designen

Exit mobile version