Failover ohne DNS: Wie Anycast & BGP die RTO unter 30 Sekunden drücken

Wenn eine kritische Infrastruktur ausfällt, zählt jede Sekunde. Die Kennzahl dafür ist die RTO (Recovery Time Objective). In vielen Disaster-Recovery-Konzepten ist das Nadelöhr jedoch nicht die Serverleistung, sondern das Domain Name System (DNS).

Wer sich bei einem Standortausfall auf das Umschalten von DNS-Einträgen verlässt, kämpft gegen Caching-Zeiten (TTL) und die Trägheit globaler Nameserver. Im KRITIS-Umfeld, wo zeitsensible Datenflüsse und starre Firewall-Regeln dominieren, ist dieser Ansatz oft zu langsam und zu unzuverlässig. Die Lösung liegt eine Schicht tiefer: im Routing-Protokoll des Internets selbst.

Das Problem: Die Trägheit von DNS-basierten Failovern

Klassische Failover-Szenarien funktionieren über das Ändern von IP-Adressen im DNS. Das hat drei entscheidende Nachteile:

1. TTL-Verzögerungen: Selbst wenn die TTL (Time-To-Live) auf 60 Sekunden steht, ignorieren viele Clients oder Zwischenknoten diesen Wert und halten veraltete IP-Adressen minutenlang im Cache.
2. Firewall-Problematik: In regulierten Netzen (z. B. bei Energieversorgern) sind Firewalls oft auf feste IP-Adressen programmiert. Eine neue IP im Notfall bedeutet, dass Verbindungen blockiert werden, bis manuelle Freigaben erfolgen.
3. Koordinationsaufwand: Bei tausenden VPN-Tunneln oder Edge-Geräten führt eine IP-Änderung zu einem massiven Synchronisationsproblem über Organisationsgrenzen hinweg.

Die Lösung: Anycast und das Border Gateway Protocol (BGP)

Anstatt die IP-Adresse zu ändern, ändern wir den Weg zur IP. Bei Anycast wird dieselbe IP-Adresse (oder dasselbe IP-Präfix) gleichzeitig von mehreren geografisch getrennten Standorten im Internet angekündigt.

1. BGP als automatischer Weichensteller

Das Border Gateway Protocol (BGP) ist die Sprache, in der Router Informationen über die Erreichbarkeit von IP-Netzen austauschen. In einem Multi-Region-Setup “verkünden” beide Standorte über BGP, dass sie für eine bestimmte IP-Adresse zuständig sind. Das Internet-Routing leitet Nutzer automatisch zum geografisch nächstgelegenen, gesunden Standort.

2. Failover durch Route-Withdrawal

Fällt ein Standort komplett aus, wird das BGP-Announcement für diesen Standort zurückgezogen. Innerhalb von Sekunden “lernt” das globale Netz, dass dieser Weg nicht mehr existiert. Der gesamte Traffic schwenkt automatisch zum zweiten, aktiven Standort um.

• Der Vorteil: Die IP-Adresse bleibt identisch. Kein DNS-Eintrag muss geändert werden, keine Firewall-Regel muss angepasst werden. Die Verbindung wird auf Netzwerkebene einfach neu geroutet.

3. Bring Your Own IP (BYOIP)

Für KRITIS-Betreiber ist es oft sinnvoll, eigene, providerunabhängige IP-Adressbereiche zu nutzen. Dieses BYOIP-Konzept erlaubt es, die volle Kontrolle über das Routing zu behalten und die Erreichbarkeit der Plattform unabhängig von der Infrastruktur eines einzelnen Cloud-Providers oder Rechenzentrums zu gestalten.

Fazit: Routing schlägt Runbook

Echte Business Continuity in kritischen Umgebungen darf nicht von manuellen Prozessen oder der unzuverlässigen DNS-Verbreitung abhängen. Durch den Einsatz von Anycast und BGP wird der Failover von einer organisatorischen Aufgabe zu einer automatisierten Netzwerkfunktion. Das Ergebnis ist eine RTO, die oft unter 30 Sekunden liegt - ein Wert, der mit klassischen Methoden kaum erreichbar ist.

FAQ

Was passiert bei Anycast mit bestehenden TCP-Verbindungen während eines Failovers? Da sich der Routing-Pfad ändert, werden bestehende TCP-Verbindungen beim Umschwenken in der Regel unterbrochen und müssen vom Client neu aufgebaut werden. Da die IP jedoch gleich bleibt, geschieht dieser Neuaufbau (Re-Connect) meist so schnell, dass Nutzer oder automatisierte Systeme davon kaum etwas bemerken.

Benötige ich für Anycast eigene IP-Adressbereiche (AS-Nummer)? Idealerweise ja. Um volle Kontrolle über das BGP-Routing zu haben, ist eine eigene Autonomous System Number (ASN) und ein eigenes IP-Präfix sinnvoll. Es gibt jedoch auch Cloud-Provider und Partner, die Anycast als Service auf ihrer Infrastruktur anbieten.

Ist Anycast auch für die interne Kommunikation zwischen Standorten geeignet? Anycast wird primär für den Inbound-Traffic (von außen zur Plattform) genutzt. Für die interne Kommunikation zwischen Clustern (z. B. Datenbank-Replikation) nutzt man eher klassische Unicast-Verbindungen über dedizierte Standort-Kopplungen, um gezielt einen bestimmten Endpunkt anzusprechen.

Wie wirkt sich Anycast auf die Latenz aus? Sehr positiv. Da das Routing den Nutzer immer zum “nächsten” Standort führt, sinkt die Latenz für geografisch verteilte Nutzergruppen automatisch, ohne dass komplexe Lastverteilungs-Logiken auf Applikationsebene implementiert werden müssen.