Disaster Recovery Topologie beschreibt, wie ein Netzwerk und seine Services so aufgebaut werden, dass ein regionaler Ausfall nicht zum Business-Ausfall wird. In Telco- und Provider-Umgebungen ist „DR“ dabei keine einzelne Maßnahme, sondern ein Zusammenspiel aus Region Failover, DNS-Strategien, Routing-Design und Service-Architekturen (z. B. BNG/CGNAT, Firewalls, DDoS, Peering/Transit, Enterprise VPN Plattformen). Der Kern ist, dass ein Region-Ausfall anders ist als ein Link- oder Node-Ausfall: Failure Domains sind groß, Abhängigkeiten sind zahlreich (DCI, IXPs, Energie, Control Plane, Telemetry), und die Wiederherstellung muss in definierten Zeit- und Datenbudgets erfolgen. Genau deshalb scheitern viele DR-Konzepte nicht an fehlender Redundanz, sondern an fehlender Topologie-Disziplin: DNS zeigt noch auf die ausgefallene Region, BGP-Announcements sind nicht konsistent, Serviceketten sind nicht symmetrisch, Stateful Plattformen können nicht sauber übernehmen, oder das Netzwerk hat zwar einen Ersatzpfad, aber nicht genug Headroom im N-1/N-2. Ein professionelles DR-Design definiert zuerst Ziele (RTO/RPO), dann Failure Domains und Servicekanten, und erst danach konkrete Mechanismen: Anycast, aktive/aktive Region-Topologien, aktive/passive Modelle, DNS TTL-Strategien, Routing Policies, DCI-Topologien, Datenreplikation und Runbooks. Dieser Artikel zeigt praxisnah, wie Sie Disaster Recovery Topologien in Telco-Netzen so planen, dass Region Failover, DNS, Routing und Services zusammenpassen – und Resilienz nicht nur eine PowerPoint, sondern messbar und testbar wird.
DR-Grundlagen: RTO, RPO und Failure Domains als Startpunkt
Disaster Recovery beginnt mit klaren Zielen. Ohne definierte RTO/RPO werden Designs entweder überteuert (zu viel aktive Redundanz) oder riskant (zu langsames Umschalten, Datenverlust). Gleichzeitig müssen Failure Domains realistisch modelliert werden: Ein Region-Ausfall ist oft ein Mix aus Facility-Ausfall, DCI-Isolation, Interconnect-Störung und Control-Plane-Partition. DR-Topologie bedeutet, diese Risiken bewusst zu schneiden und die erwartete Übernahme zu definieren.
- RTO (Recovery Time Objective): Wie schnell muss der Service wieder nutzbar sein (Sekunden, Minuten, Stunden)?
- RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel (0, wenige Sekunden, Minuten)?
- Failure Domains: PoP, Facility, Metro, Region, DCI-Regionpaar, Interconnect-Standort, SRLG.
- Servicekanten: Wo endet der Service? Z. B. am Internet Edge, am PE, am BNG oder am Enterprise-Handover.
Leitprinzip: DR ist ein Serviceversprechen, kein Routingtrick
Ein Routing-Failover ohne funktionierende DNS-, Daten- und Serviceebene ist kein DR. Umgekehrt bringt perfekte Datenreplikation wenig, wenn Traffic nicht sauber zur aktiven Region gelangt.
Region-Topologien: Active/Active, Active/Passive und Hybrid-Modelle
DR-Topologie ist im Kern eine Wahl zwischen Betriebsmodellen. Active/Active reduziert RTO, verteilt Last und kann Failover eleganter machen, ist aber komplexer (Konsistenz, Split-Brain, Routing-Policy). Active/Passive ist einfacher und oft auditierbarer, benötigt aber mehr „kalte“ Reservekapazität und kann RTO erhöhen. Hybrid ist häufig die beste Praxis: einige Services active/active (z. B. DNS, Anycast), andere active/passive (stateful Plattformen mit strengen RPO-Anforderungen).
- Active/Active: Beide Regionen tragen Traffic; Failover ist meist schneller, aber Consistency und Policy sind anspruchsvoll.
- Active/Passive: Eine Region primär, andere standby; einfacher zu betreiben, aber Reservekapazität muss im Failover tragen.
- Hybrid: Kritische Kontrollservices active/active, stateful Workloads nach RPO/RTO differenziert.
- Region-Sharding: Services pro Region primär, gegenseitige Übernahme im DR (geografische Lastverteilung).
Designregel: Active/Active braucht klare „Source of Truth“-Regeln
Ohne definierte Ownership (z. B. welcher Dienst schreibt wo?) drohen Split-Brain und inkonsistente Zustände. Active/Passive reduziert dieses Risiko, erfordert aber sehr gute Failover-Runbooks.
DCI als Rückgrat: L2 Stretch vs. L3 DCI vs. EVPN DCI für DR
Region Failover steht und fällt mit der DCI-Topologie. Viele DR-Probleme sind in Wirklichkeit DCI-Probleme: Congestion im Failover, asymmetrische Pfade, MTU-Inkonsistenzen oder zu große Failure Domains durch L2 Stretch. Für Telco-Designs ist L3-Interconnect häufig robuster, weil Failure Domains klarer sind. L2 Stretch kann in speziellen Fällen notwendig sein, erhöht aber Komplexität und Split-Brain-Risiko.
- L3 DCI: Klarere Failure Domains, weniger Broadcast/MAC-State, einfacher zu kontrollieren; sehr geeignet für DR-Failover.
- L2 Stretch: Ermöglicht nahtlose Layer-2-Übernahme, aber erhöht Risiken (Loops, MAC-Churn, Split-Brain).
- EVPN DCI: Kann L2/L3 flexibel verbinden, erfordert jedoch sauberes Control-Plane-Design und MTU-Disziplin.
- DCI Kapazität: N-1 oder N-2 Headroom, denn im Failover steigen oft West-East- und Backhaul-Lasten.
DR-Realität: Failover macht DCI zur Engpassstelle
Im Normalbetrieb ist DCI oft moderat ausgelastet. Im Region Failover kann sie zum dominanten Engpass werden (Traffic hairpint, Datenreplikation plus Usertraffic). DR-Design braucht deshalb eine DCI-Headroom-Strategie.
Routing für Region Failover: BGP, Anycast, TE und Prefix-Strategien
Routing entscheidet, wohin Traffic fließt, wenn eine Region ausfällt. Dafür gibt es mehrere Strategien: Anycast für Dienste, die in mehreren Regionen identisch bereitstehen (z. B. DNS, bestimmte APIs), sowie unicastbasierte Failover-Strategien (z. B. Präfixe nur aus der aktiven Region announcen). In Telco-Netzen ist BGP das zentrale Werkzeug, weil es Policy und globale Steuerbarkeit bietet.
- Anycast Services: Gleiche IP in mehreren Regionen, Routing liefert „nächstes“ Ziel; ideal für DNS und stateless Services.
- Unicast Failover: Präfixe werden nur in der aktiven Region advertised; bei Failover übernimmt die andere Region (Prepend/Withdraw/Advertise).
- Policy-Steuerung: Local Preference, Communities, selective announcements und Prepends zur Inbound/Outbound-Kontrolle.
- TE im Backbone: SR-TE/MPLS-TE oder IGP-Metriken, um Region-zu-Region Pfade im Failover zu steuern.
Designregel: Inbound-Steuerung ist schwieriger als Outbound
Outbound können Sie intern sauber steuern. Inbound hängt von Upstreams/Peers ab. Deshalb braucht DR Routing mehrere Mechanismen: saubere Announcements, gutes Peering/Transit-Design und klare Testpläne.
DNS im DR: TTL, Anycast, Geo-DNS und Health-Checks
DNS ist oft der „stille“ DR-Trigger – und gleichzeitig eine der häufigsten Ursachen für verlängerte Ausfälle. Wenn TTLs zu hoch sind, zeigt DNS zu lange auf eine ausgefallene Region. Wenn TTLs zu niedrig sind, steigt die Last auf Resolver- und Authoritative-Infrastruktur. In Telco-Designs ist häufig eine Kombination sinnvoll: Anycast für Authoritative DNS, Health-Checks zur Traffic-Steuerung und differenzierte TTLs je Record-Typ.
- TTL-Strategie: Kritische Records mit moderaten TTLs (nicht extrem niedrig), weniger kritische mit höheren TTLs.
- Anycast DNS: Authoritative DNS in mehreren Regionen, Routing liefert Resilienz und kurze Wege.
- Geo-/Latency-DNS: Regionale Präferenz, aber mit robustem Fallback bei Region-Ausfall.
- Health-Checks: DNS-Antworten basierend auf realer Servicegesundheit, nicht nur „Server up“.
Anti-Pattern: TTL extrem niedrig als Ersatz für schlechtes Routing
Sehr niedrige TTLs erhöhen Betriebslast und lösen nicht alle Inbound-Probleme. Besser ist ein abgestimmtes Routing- und DNS-Konzept mit klaren Health-Checks.
Services im DR: Stateless vs. Stateful, Service Chains und Abhängigkeiten
DR scheitert häufig an Services, nicht am Transport. Ein stateless Webservice kann active/active laufen, aber ein stateful System (Subscriber Sessions, NAT-State, Firewall State, Datenbanken) benötigt klare Konsistenz- und Übernahmeregeln. Telco-spezifische Plattformen wie BNG/BRAS und CGNAT müssen besonders betrachtet werden, weil sie sowohl State als auch hohe Performanceanforderungen haben.
- Stateless Services: Eignen sich für Anycast und active/active, wenn Datenquellen resilient sind.
- Stateful Services: Benötigen Replikation, State-Sync oder kontrollierte Neuaufbauten; RPO/RTO treibt das Design.
- BNG/BRAS: Subscriber Session Handling im Failover (Reauth, Session Relocation), Churn- und CPS-Headroom.
- CGNAT: Port-Pools/State, Logging-Pipeline, Failover kann CPS-Spikes erzeugen; klare Domain-Schnitte nötig.
- Firewalls/DDoS: Symmetrie und Service Chaining; Failover darf keine asymmetrischen Pfade erzwingen.
Designregel: Services definieren die echte RTO
Routing kann in Sekunden umschalten. Wenn CGNAT/BNG/Firewall danach Minuten braucht, ist die Service-RTO der limitierende Faktor. DR-Topologie muss daher servicezentriert geplant werden.
Interconnect im DR: Peering, Transit und regionale Exits
Region Failover verändert auch Internet- und Partnerpfade. Wenn eine Region ihren IXP/PNI verliert, muss Transit übernehmen oder eine andere Region den Exit liefern. Das kann zu Hairpinning führen und die Edge massiv belasten. DR-Topologie muss daher Interconnect-Failover explizit modellieren: Welche Region übernimmt? Wie viel Transit-Headroom ist vorhanden? Welche Policies verhindern unkontrollierte Pfadwahl?
- Regionale Exits: Wenn möglich, mehrere Regionen als Internet-Edge; reduziert Hairpinning im DR.
- Transit-Headroom: Transit muss Peering-Ausfall kurzfristig tragen können, ohne SLO zu brechen.
- Policy-Konsistenz: Gleiche Communities/Pref-Modelle pro Region, damit Failover vorhersehbar bleibt.
- Peer-Strategie: Große Partner über PNIs in mehreren Regionen oder klare Fallbacks über IXPs/Transit.
Anti-Pattern: DR ohne Edge-Kapazitätsmodell
Viele DR-Pläne betrachten nur DCI und Service-Replikation. In der Realität bricht Failover oft an Interconnect-Ports, weil Traffic plötzlich anders fließt. Edge muss Teil des DR-Designs sein.
Observability und DR: Nachweis, dass Failover funktioniert
DR ist nur so gut wie seine Messbarkeit. Sie benötigen SLOs/SLIs, die Region-Failover abbilden: Availability, p95/p99 Latenz, Loss, Queue-Drops und Service-spezifische KPIs. Außerdem brauchen Sie Change- und Event-Korrelation, damit DR-Tests und echte Incidents sauber analysiert werden können.
- Path KPIs: Probes zwischen Regionen und zu Referenzzielen, um Hairpinning und DCI-Engpässe zu erkennen.
- Engpass-Telemetry: Queue-Drops und Portauslastung an DCI, Hubs und Interconnect.
- Routing Health: Prefix-Counts, BGP Update-Raten, Session Stability, Anycast Reachability.
- Service KPIs: BNG Sessions/Churn, CGNAT State/CPS, Firewall Drops/State, DNS Query Rate/Errors.
Designregel: DR braucht regelmäßige Tests mit „Expected vs. Observed“
DR, das nicht getestet wird, driftet. Jede größere Topologie- oder Policy-Änderung kann DR-Pfade verändern. Testen Sie regelmäßig und dokumentieren Sie Abweichungen.
Runbooks und Governance: DR ist ein Prozess, kein Schalter
Region Failover ist ein koordinierter Ablauf: Entscheidung, Aktivierung, Traffic-Steering, Service-Übernahme, Stabilisierung, und später Failback. Ohne klare Runbooks und Governance wird Failover zu improvisierter Incident-Arbeit. In Telco-Umgebungen sollten Runbooks domänenbasiert sein: Routing/Edge, DCI, Services, DNS, Observability.
- Trigger: Wann wird Failover ausgelöst? SLO-Verletzungen, Region-Health, DCI-Isolation, Facility-Events.
- Schritte: Reihenfolge für DNS/Routing/Services; wer macht was, mit welchen Checks.
- Stop/Go Gates: Objektive Kriterien, ob der nächste Schritt sicher ist (SLO, Headroom, Service KPIs).
- Failback: Rückkehr zur Normalregion oft riskanter als Failover; Hysterese und kontrollierte Wellen.
Failback ist der häufige DR-Fehler
Viele Designs konzentrieren sich auf Failover, aber Failback kann Ping-Pong, Congestion und State-Probleme erzeugen. Planen Sie Failback wie ein Rolling Upgrade: schrittweise, messbar, reversibel.
Typische Fallstricke und wie man sie vermeidet
- DNS zeigt zu lange auf die falsche Region: Lösung: TTL-Strategie, Anycast DNS, Health-Checks, getestet.
- Inbound-Steuerung klappt nicht: Lösung: BGP-Policy-Blueprints, Multi-Region Peering/Transit, realistische Tests.
- DCI wird Engpass: Lösung: N-1/N-2 Headroom, QoS, Peak- und Failover-Tests unter Last.
- Stateful Services brechen: Lösung: RPO/RTO pro Service, Cluster-N+1, Session/State-Handling, Logging-Headroom.
- MTU/QoS inkonsistent: Lösung: End-to-end Profile, PMTUD-Strategie, Ersatzpfad-Validierung.
- Interconnect kollabiert: Lösung: Edge-Portklassen, Transit-Fallback, regionale Exits, Policy-Konsistenz.
- Keine Tests: Lösung: regelmäßige DR-Übungen, Chaos/Failure-Workshops, Expected vs. Observed dokumentieren.
Praktische Leitlinien: Disaster Recovery Topologie für Region Failover
- Mit Zielen starten: RTO/RPO pro Serviceklasse definieren, dann Active/Active vs. Active/Passive ableiten.
- Failure Domains modellieren: Region, PoP, DCI, Interconnect, SRLG; klare Übernahmebeziehungen festlegen.
- DCI bewusst wählen: L3 DCI als robustes Default, EVPN/L2 Stretch nur mit klaren Guardrails und Split-Brain-Schutz.
- Routing-Strategie definieren: Anycast für geeignete Services, unicast Failover für andere; Policies konsistent und testbar.
- DNS integrieren: TTL-Strategie, Anycast Authoritative DNS, Health-Checks und Geo-Logik mit Fallback.
- Services DR-fähig machen: Stateful Plattformen (BNG/CGNAT/Firewalls) als eigene Domains mit N+1 und klaren Runbooks.
- Interconnect mitdenken: Multi-Region Exits, Transit-Headroom, PNI/IXP-Redundanz und klare Fallback-Policies.
- Observability verpflichtend: SLO/SLI, Queue-Drops, Routing Health, Service KPIs; Telemetry-Pipeline selbst resilient.
- Failover & Failback üben: Regelmäßige Tests, Canary-Ansätze, Stop/Go Gates und dokumentierte Expected-vs.-Observed Ergebnisse.
