TL;DR
Routing-basiertes Failover entscheidet an der Edge, welcher erreichbare Backend-Pool eine Anfrage oder Verbindung erhält. Im Gegensatz zu DNS-Failover muss der Client nicht erst einen neuen Zielnamen auflösen. Das verkürzt den Reaktionsweg, macht Gesundheitszustände unmittelbar nutzbar und trennt öffentlichen Zugang von der eigentlichen Compute-Infrastruktur.
Einleitung
Ein DNS-Eintrag kann nicht zuverlässig abbilden, ob ein konkreter Backend-Pool gerade Requests verarbeitet. DNS verteilt Namen und Adressen, während die eigentliche Verfügbarkeitsentscheidung erst beim Verbindungsaufbau und bei der Anfrage sichtbar wird. Wird Failover ausschließlich über DNS umgesetzt, hängen Reaktionszeit und Wirksamkeit zusätzlich von TTLs, Resolvern, Caches und bestehenden Verbindungen ab. Routing-basiertes Failover setzt deshalb an einer anderen Stelle an: Die Edge nimmt den Traffic entgegen, prüft die Erreichbarkeit konfigurierter Backends und wählt den verfügbaren Pool direkt für die Weiterleitung. Das ist besonders relevant für APIs und Webanwendungen mit mehreren Betriebsstandorten oder Providern.
1. Die Failover-Entscheidung gehört an den Traffic-Eingang
Bei routing-basiertem Failover liegt die zentrale Entscheidung zwischen Client und Backend. Die Anfrage erreicht zunächst einen öffentlichen Edge-Endpunkt. Dort wird anhand des Protokolls, des Dienstes und des Zustands der Backend-Pools bestimmt, wohin der Traffic weitergeleitet wird. Fällt der primäre Pool aus oder ist er nicht erreichbar, kann die Edge auf einen alternativen Pool routen.
Bei Layer 4 erfolgt diese Entscheidung auf Ebene von Verbindungen und Transportdaten. Das eignet sich für TCP-basierte Dienste, bei denen die Edge den Inhalt der Anwendung nicht auswerten muss. Layer 7 kann zusätzlich HTTP- beziehungsweise HTTPS-Traffic verarbeiten und den jeweiligen Web- oder API-Dienst auf Anwendungsebene verteilen. Entscheidend ist in beiden Fällen: Der Client bleibt am öffentlichen Endpunkt, während sich das interne Ziel ändern kann.
2. Backend Health Checks liefern die Entscheidungsgrundlage
Failover ist nur belastbar, wenn die Edge den Zustand der Backends systematisch bewertet. Health Checks prüfen, ob ein Backend oder ein Backend-Pool erreichbar und für die Weiterleitung geeignet ist. Dabei ist zwischen Netzwerk-Erreichbarkeit und tatsächlicher Dienstverfügbarkeit zu unterscheiden: Eine offene TCP-Verbindung bedeutet nicht automatisch, dass eine API korrekte Antworten liefert.
Die Routing-Entscheidung muss außerdem mit dem Pool-Modell übereinstimmen. Ein Pool kann mehrere Backends enthalten, während ein weiterer Pool als Ausweichziel dient. Wird der primäre Pool als nicht verfügbar bewertet, routet die Edge neue Verbindungen oder Requests zum alternativen Pool. Für den Betrieb ist dabei wichtig, Zustandswechsel nachvollziehbar zu machen. Traffic- und Usage-Statistiken helfen, Auswirkungen eines Failovers zu erkennen und zwischen Backend-Problem, Routing-Ereignis und normaler Lastverteilung zu unterscheiden.
3. Direkte Edge-Entscheidung versus DNS-Failover
DNS-Failover verändert die Antwort auf eine Namensauflösung. Resolver und Clients erhalten anschließend eine andere Adresse oder ein anderes Ziel. Dieser Ansatz kann funktionieren, ist aber an den DNS-Auflösungsweg gebunden. TTLs werden nicht immer exakt eingehalten, Resolver können Antworten zwischenspeichern, und bereits bestehende Verbindungen wechseln nicht automatisch das Ziel. Zudem verteilt DNS primär Adressen; die eigentliche Backend-Gesundheit muss in die DNS-Logik integriert werden.
Routing-basiertes Failover entscheidet dagegen beim Eingang des Traffics an der Edge. Die Namensauflösung verweist weiterhin auf den öffentlichen Dienst, während die Edge den erreichbaren Backend-Pool auswählt. Dadurch bleibt die öffentliche Adresse stabil und der Failover-Pfad wird nicht durch zusätzliche DNS-Caches verlängert. DNS bleibt für Anycast DNS und Multi-Provider-DNS relevant, ersetzt aber nicht die nachgelagerte Routing-Entscheidung für konkrete Anwendungen.
4. Failover verändert auch die Betriebsarchitektur
Ein alternativer Backend-Pool ist kein rein technischer Schalter. Anwendungen müssen Zustände, Sessions, Datenhaltung und Abhängigkeiten über beide Ziele hinweg berücksichtigen. Ein stateless API-Service lässt sich meist einfacher umleiten als eine Anwendung, deren Sessions oder Schreibzugriffe an einen einzelnen Standort gebunden sind. Routing kann den Traffic verschieben, aber keine inkonsistenten Datenbestände korrigieren.
Die Edge Cloud trennt dabei den öffentlichen Zugang von der Compute-Infrastruktur. Backends können bei ayedo Managed Kubernetes, in eigenen Kubernetes Clustern oder bei anderen Providern betrieben werden. Backend Cloaking verhindert, dass interne Zielstrukturen zum öffentlichen Adressraum werden. Eine verteilte Multi-PoP-Architektur mit Aktiv-Aktiv-Prinzip reduziert zudem die Abhängigkeit von einem einzelnen Edge-Standort. Failover wird damit als Zusammenspiel aus Erreichbarkeit, Routing und Anwendungsdesign behandelt – nicht als isolierte DNS-Konfiguration.
Praxis- und Betriebsszenario
Eine API läuft parallel in zwei Kubernetes Clustern bei unterschiedlichen Providern. Beide Cluster sind über einen gemeinsamen öffentlichen Dienst erreichbar; ein Pool ist primär, der andere dient als Ausweichziel. Die Edge prüft die Backends und routet neue API-Anfragen zunächst zum erreichbaren primären Pool. Fällt dessen API-Service aus, übernimmt der alternative Pool, ohne dass Clients einen neuen DNS-Eintrag auflösen müssen.
Bei einem DNS-basierten Ansatz müsste zunächst eine andere Adresse veröffentlicht werden. Caches und bestehende Verbindungen können dazu führen, dass ein Teil des Traffics weiterhin das ausgefallene Ziel erreicht. Beim Edge-Routing bleibt der öffentliche Endpunkt unverändert. Die Anwendung muss dennoch für parallele Zustände, Datenzugriff und mögliche Wiederholungen von Requests ausgelegt sein.
FAQ
Ersetzt routing-basiertes Failover DNS vollständig?
Nein. DNS bleibt für die Namensauflösung sowie für Anycast- und Multi-Provider-Szenarien relevant. Routing-basiertes Failover übernimmt die Entscheidung, welcher Backend-Pool den bereits eingehenden Traffic verarbeitet.
Gilt Failover gleichermaßen für Layer 4 und Layer 7?
Das Grundprinzip gilt für beide Ebenen. Layer 4 arbeitet verbindungsorientiert, Layer 7 verarbeitet HTTP- beziehungsweise HTTPS-Traffic und kann Anwendungsdienste differenzierter behandeln.
Was passiert mit bestehenden Verbindungen?
Failover wirkt primär auf neue Verbindungen oder Requests. Bereits bestehende Sessions können zum ausgefallenen Backend bestehen bleiben oder fehlschlagen und müssen von Protokoll und Anwendung behandelt werden.
Fazit
Routing-basiertes Failover verschiebt die Verfügbarkeitsentscheidung an den Ort, an dem der Traffic tatsächlich verarbeitet wird. Das verkürzt den Reaktionsweg gegenüber einer reinen DNS-Umleitung und hält den öffentlichen Endpunkt stabil. Für APIs und Webanwendungen ist entscheidend, Health Checks, Backend-Pools und Anwendungszustände gemeinsam zu planen. Die ayedo Edge Cloud bildet dafür die vorgelagerte Routing- und Schutzebene – unabhängig davon, wo die eigentlichen Kubernetes oder Compute-Workloads betrieben werden.