Failover-Reaktionswege zwischen Edge, DNS und Backend

TL;DR:

Failover ist keine einzelne Umschaltfunktion, sondern eine Kette aus Erkennung, Entscheidung, Weiterleitung und Stabilisierung. Edge-Routing reagiert typischerweise näher am laufenden Traffic, während DNS-Failover durch TTLs, Resolver- und Client-Caches verzögert wird. Bestehende Verbindungen folgen dabei anderen Regeln als neue Requests.

Ein Failover wird häufig als Zustandswechsel beschrieben: Ein Backend fällt aus, ein alternatives Backend übernimmt. Technisch liegen dazwischen jedoch mehrere voneinander abhängige Schritte. Ein Health Check muss den Ausfall erkennen, eine Routing-Instanz muss die Information bewerten, neue Verbindungen müssen einen anderen Pfad erhalten und der Traffic muss sich stabilisieren. Wird stattdessen DNS geändert, kommen zusätzlich TTLs, Resolver-Caches und lokale Client-Caches hinzu.

Der entscheidende Unterschied liegt deshalb nicht nur in der Erkennungszeit. Relevant sind auch der Umschaltpfad, die Sichtbarkeit für bestehende Verbindungen und die Frage, an welcher Stelle der Architektur die Entscheidung getroffen wird. Failover-Reaktionswege sollten daher als Ablauf analysiert werden – nicht als Schalter mit einer pauschalen Umschaltzeit.

1. Backend Health Checks bestimmen den ersten Reaktionspunkt

Jeder Failover beginnt mit einer Beobachtung. Ein Backend Health Check prüft beispielsweise, ob ein Dienst erreichbar ist und eine erwartete Antwort liefert. Dabei ist zwischen Netzwerk-Erreichbarkeit und Anwendungszustand zu unterscheiden: Ein erreichbarer Server kann weiterhin keine funktionsfähigen Requests verarbeiten.

Erst aus mehreren Prüfergebnissen entsteht ein belastbarer Zustandswechsel. Zu aggressive Prüfungen können kurzfristige Netz- oder Lastprobleme als Ausfall interpretieren. Zu konservative Prüfungen verlängern dagegen die Zeit, in der Traffic an ein nicht funktionsfähiges Ziel geleitet wird. Prüfintervall, Timeout und die erforderliche Anzahl aufeinanderfolgender Fehler beeinflussen damit direkt die Reaktionscharakteristik.

Bei einer Edge-Plattform werden solche Health Checks vor der Weiterleitung an das Backend ausgewertet. Die Edge kann daraufhin ein Ziel aus dem aktiven Routing nehmen oder einen alternativen Pfad verwenden. Der Health Check ist aber noch kein Failover: Er liefert nur die Information, auf deren Grundlage die Routing-Entscheidung getroffen wird.

2. Edge-Routing schaltet neue Weiterleitungen gezielt um

Beim Edge-Failover bleibt der öffentliche Einstiegspunkt unverändert. Die Edge empfängt den Traffic weiterhin über die bestehende Adresse und entscheidet anhand des aktuellen Backend-Zustands, wohin neue Verbindungen oder Requests weitergeleitet werden. Dadurch entfällt die Abhängigkeit von einer erneuten DNS-Auflösung für jeden Umschaltvorgang.

Der Reaktionsweg lautet vereinfacht: Health Check erkennt einen Fehler, die Edge aktualisiert den verfügbaren Backend-Pool, anschließend werden neue Weiterleitungen auf ein alternatives Ziel gelenkt. Bei Layer 7 kann die Entscheidung auf Request-Ebene erfolgen; bei Layer 4 ist die Lebensdauer der Verbindung stärker durch TCP- oder UDP-Zustände geprägt. Ein bereits aufgebauter TCP-Kanal wird nicht automatisch zu einer anderen Gegenstelle verschoben.

Die ayedo Edge Cloud verbindet solche Backend Health Checks mit Edge-Routing in einer verteilten Multi-PoP- und Aktiv-Aktiv-Architektur. Das ist vor allem dann relevant, wenn der öffentliche Einstiegspunkt stabil bleiben soll, während Backends in unterschiedlichen Umgebungen betrieben werden – etwa in eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern . Die Edge bleibt dabei für Eingang, Schutz und Weiterleitung zuständig; die Compute-Infrastruktur bleibt der Ort der Anwendung.

3. DNS-Failover verlagert die Entscheidung zu Resolvern und Clients

Beim DNS-Failover wird nicht primär die Weiterleitung an der Edge verändert, sondern die Antwort auf eine Namensauflösung. Ein Health Check kann feststellen, dass ein Ziel nicht verfügbar ist, woraufhin DNS eine alternative Adresse liefert. Der weitere Traffic erreicht dieses Ziel jedoch erst, wenn eine neue DNS-Auflösung stattfindet.

Die konfigurierte TTL begrenzt die Gültigkeit einer Antwort, garantiert aber keine exakte Umschaltzeit. Rekursive Resolver, Betriebssysteme, Anwendungen und lokale Netzkomponenten können Antworten unterschiedlich lange zwischenspeichern oder eigene Wiederverwendungslogiken anwenden. Dadurch entsteht zwischen Zustandswechsel und tatsächlicher Nutzung des neuen Ziels eine verteilte Übergangsphase.

DNS-Failover ist sinnvoll, wenn der öffentliche Einstieg selbst zwischen unabhängigen Endpunkten wechseln soll oder wenn eine Änderung außerhalb einer einzelnen Edge-Routing-Domäne erforderlich ist. Anycast DNS und Multi-Provider-DNS können dabei die DNS-Ebene resilienter gestalten, beseitigen aber nicht die Wirkung von Caches. Bei der ayedo Edge Cloud ist DNS daher ein eigener Reaktionsweg neben dem Edge-Routing, nicht dessen Ersatz.

4. Bestehende Verbindungen machen den Unterschied sichtbar

Failover betrifft neue und bestehende Verbindungen unterschiedlich. Eine neue Verbindung kann nach der Routing-Entscheidung ein gesundes Backend erreichen. Eine bereits etablierte Verbindung bleibt dagegen zunächst an ihren bisherigen Netzwerkpfad gebunden. Fällt das Backend aus, muss der Client, ein Proxy oder die Anwendung die Verbindung beenden, erneut aufbauen oder einen Request wiederholen.

Bei HTTP über eine Edge kann die öffentliche Adresse für den Client stabil bleiben, während die interne Weiterleitung wechselt. Das vereinfacht die Wiederherstellung neuer Requests, ersetzt aber keine Transaktionslogik. Wiederholungen sind nur dann sicher, wenn die Anwendung sie verkraftet, etwa durch Idempotenz oder geeignete Request-IDs. Bei lang laufenden WebSockets, Streaming-Verbindungen oder zustandsbehafteten Sessions ist die Unterbrechung deutlich sichtbarer.

Beim DNS-Failover bleibt eine bestehende Verbindung ebenfalls auf ihrem ursprünglichen Ziel. Zusätzlich können neue Verbindungen noch die alte Adresse verwenden, solange die DNS-Antwort gecacht ist. Die Stabilisierung besteht deshalb nicht nur aus dem Umschalten, sondern auch aus Retry-Verhalten, Session-Handling, Connection Draining und der Überwachung von Fehlerraten nach der Entscheidung.

Szenario: Edge-Umschaltung oder DNS-Änderung?

Angenommen, ein API-Cluster ist nicht erreichbar, während ein zweiter Cluster betriebsbereit bleibt. Beim Edge-Failover erkennt der Health Check den Fehler, nimmt das erste Backend aus der Weiterleitung und sendet neue Requests an den zweiten Cluster. Clients behalten den bekannten öffentlichen Endpunkt; bestehende Verbindungen müssen dennoch je nach Protokoll neu aufgebaut werden.

Beim DNS-Failover wird stattdessen eine neue Zieladresse veröffentlicht. Resolver und Clients übernehmen diese Information zeitversetzt. Während der Übergangsphase erreicht ein Teil der neuen Verbindungen weiterhin das ausgefallene Ziel. Der Edge-Weg reduziert damit den Einfluss von DNS-Caches, während der DNS-Weg die Entscheidung weiter nach außen verlagert. Welche Variante passt, hängt vom gewünschten Kontrollpunkt und von der Verbindungstypik ab.

FAQ

Ist Edge-Failover immer schneller als DNS-Failover?

Nicht automatisch. Entscheidend sind Health-Check-Parameter, Routing-Aktualisierung und Protokollverhalten. DNS-Failover ist zusätzlich von TTLs und Caches abhängig, wodurch die Nutzung des neuen Ziels zeitlich stärker auseinanderlaufen kann.

Werden bestehende TCP-Verbindungen beim Failover verschoben?

Nein. Eine bestehende Verbindung ist an ihren ursprünglichen Pfad gebunden. Fällt dieser aus, sind Verbindungsabbruch, erneuter Aufbau oder ein anwendungsseitiger Retry erforderlich.

Braucht DNS-Failover zusätzlich Edge-Routing?

Nicht grundsätzlich. DNS kann zwischen eigenständigen Endpunkten umschalten. Edge-Routing ist jedoch geeigneter, wenn der öffentliche Einstieg stabil bleiben und die Weiterleitungsentscheidung zentral an der Edge erfolgen soll.

Fazit

Failover sollte als zeitlicher Ablauf modelliert werden: Erkennung durch Health Checks, Entscheidung an Edge oder DNS, Weiterleitung neuer Verbindungen und Stabilisierung der laufenden Kommunikation. Edge-Routing reduziert die Abhängigkeit von DNS-Caches, während DNS-Failover einen breiteren, aber weniger unmittelbar kontrollierbaren Umschaltpfad nutzt. Die ayedo Edge Cloud ordnet diese Mechanismen in einer Plattform für öffentlichen Traffic-Eingang, Schutz und Weiterleitung ein – unabhängig davon, wo die Backends betrieben werden.