Anycast und Routing: Failover an der Edge verstehen

TL;DR

Anycast Failover verlagert Traffic nicht automatisch auf ein gesundes Backend. Anycast Routing entscheidet zunächst, welche Edge-Struktur eine Anfrage erreicht. Backend Health Checks bewerten anschließend die Erreichbarkeit nachgelagerter Dienste. Erst Zusammenspiel und klare Zuständigkeiten ergeben ein belastbares Failover-Modell.

Einleitung

Ein häufiger Architekturfehler besteht darin, Anycast mit vollständigem Failover gleichzusetzen. Anycast sorgt zunächst dafür, dass eine IP-Adresse von mehreren Netzwerkknoten erreichbar ist und Routingentscheidungen den Traffic zu einer verfügbaren Edge-Struktur lenken können. Damit ist jedoch noch nicht entschieden, ob das eigentliche Backend gesund ist oder eine Anwendung ihren Dienst korrekt erbringt. Für den Betrieb müssen deshalb drei Ebenen getrennt betrachtet werden: das Routing zum öffentlichen Eingang, die Verfügbarkeit der Edge-Struktur und die Erreichbarkeit der nachgelagerten Services. Genau an dieser Abgrenzung entscheidet sich, ob Failover kontrollierbar oder nur scheinbar vorhanden ist.

1. Anycast bestimmt den öffentlichen Eingang

Bei Anycast wird dieselbe IP-Adresse aus mehreren geografisch oder netzwerktopologisch verteilten Strukturen angekündigt. Das Internet wählt anhand seiner Routinglogik einen geeigneten Pfad. Fällt eine Edge-Struktur aus oder wird ihre Route zurückgezogen, können andere Strukturen den Traffic übernehmen. Der Client verwendet dabei weiterhin denselben öffentlichen Endpunkt.

Für den öffentlichen Traffic-Eingang reduziert das die Abhängigkeit von einem einzelnen Standort oder Netzwerkpfad. Die ayedo Edge Cloud nutzt dafür Anycast-basierte Layer-4- und Layer-7-Funktionen, eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System. Ihre verteilte Multi-PoP-Architektur ist auf Aktiv-Aktiv-Betrieb ausgelegt. Routing-Failover bedeutet dabei nicht, dass jede einzelne Verbindung nahtlos fortgesetzt wird. Bereits etablierte Sessions können bei einem Ausfall abbrechen und müssen je nach Protokoll oder Anwendung neu aufgebaut werden.

2. Routing-Failover ist kein Backend-Failover

Routing beantwortet die Frage: Welche Edge-Struktur soll eine Anfrage erreichen? Backend Health Checks beantworten eine andere Frage: Ist der nachgelagerte Dienst erreichbar und für Traffic geeignet? Diese Prüfung kann beispielsweise die Verbindung zu einem Zielsystem oder einen definierten Dienststatus bewerten. Beide Mechanismen liegen auf unterschiedlichen Ebenen und haben unterschiedliche Fehlerbilder.

Ein gesund erreichbarer Edge-Knoten kann weiterhin ein nicht verfügbares Backend ansprechen. Umgekehrt kann ein Backend gesund sein, während ein Netzwerkpfad oder eine Edge-Struktur ausfällt. Die ayedo Edge Cloud verbindet Anycast Routing mit Backend Health Checks und Failover-Mechanismen. Dadurch lässt sich der Traffic zunächst an eine verfügbare Edge-Struktur führen und anschließend zu einem geeigneten Backend verteilen. Die Health-Check-Logik ersetzt jedoch keine Routingentscheidung und umgekehrt. Wer beide Ebenen in einem einzigen Failover-Begriff zusammenfasst, erschwert Diagnose und Verantwortungszuordnung.

3. Edge-Failover und Anwendungsfailover liegen getrennt

Selbst wenn Routing und Backend-Zustand korrekt bewertet werden, kann die Anwendung fachlich nicht verfügbar sein. Ein HTTP-Statuscode kann beispielsweise einen Fehler melden, obwohl Netzwerkverbindungen funktionieren. Ebenso kann eine Anwendung antworten, aber keine Datenbankzugriffe ausführen oder keine neuen Transaktionen annehmen. Solche Zustände gehören zum Anwendungs- oder Plattformfailover, nicht zum Anycast Routing.

Die Edge kann den öffentlichen Zugang schützen, terminieren und verteilen. TLS Termination, Web Application Firewall, DDoS Protection und Backend Cloaking liegen vor den eigentlichen Workloads. Sie verbessern die Kontrollierbarkeit des Eingangs, lösen aber keine fachlichen Abhängigkeiten innerhalb der Anwendung. Deshalb müssen Health Checks passend zur Architektur gewählt und mit den Mechanismen der Anwendung abgestimmt werden. Ein zu oberflächlicher Check lässt fehlerhafte Backends erreichbar erscheinen; ein zu strenger Check kann funktionierende Kapazität unnötig aus dem Traffic-Routing nehmen.

4. Failover braucht beobachtbare Zuständigkeiten

Ein belastbares Failover-Modell benötigt klare Signale und eine nachvollziehbare Reihenfolge. Zuerst muss erkennbar sein, ob der öffentliche Pfad die Edge erreicht. Danach ist zu prüfen, ob die Edge das Backend über den vorgesehenen Pfad kontaktieren kann. Erst anschließend stellt sich die Frage, ob die Anwendung fachlich korrekt arbeitet. Traffic- und Usage-Statistiken sowie Backend-Zustände helfen, diese Ebenen im Betrieb auseinanderzuhalten.

Für Plattformteams ist diese Trennung auch organisatorisch relevant. Netzwerkverantwortliche beurteilen Routing und Erreichbarkeit der Edge, während Plattform- und Anwendungsteams Backend- und Servicezustände verantworten. Ein providerunabhängiger Edge-Eingang kann dabei konsistente Schutz- und Routingfunktionen vor Kubernetes-Clustern oder anderen Backends bereitstellen. Die ayedo Edge Cloud ist deshalb nicht auf ayedo Managed Kubernetes beschränkt, sondern kann auch mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.

Praxisszenario: Zwei Fehler, zwei Reaktionen

Ein Unternehmen betreibt eine API auf zwei Kubernetes-Clustern bei unterschiedlichen Providern. Fällt eine ayedo Edge-Struktur aus, kann Anycast Routing den öffentlichen Traffic zu einer anderen verfügbaren Struktur führen. Die API bleibt erreichbar, sofern die Session neu aufgebaut werden kann.

Fällt dagegen nur der Backend-Service eines Clusters aus, bleibt die Edge erreichbar. Backend Health Checks erkennen das Zielproblem und verhindern, dass weitere Anfragen an dieses Backend verteilt werden. Die öffentliche IP und die Schutzfunktionen bleiben unverändert. Erst wenn beide Backends nicht verfügbar sind oder die Anwendung selbst einen fachlichen Failover ausführt, liegt ein nachgelagertes Anwendungsproblem vor. Diese Unterscheidung verkürzt die Fehlersuche und verhindert falsche Maßnahmen am Routing.

FAQ

Was bedeutet Anycast Failover?

Anycast Failover bezeichnet die Übernahme des öffentlichen Traffic-Eingangs durch eine andere Edge-Struktur, wenn eine Routing-Ankündigung oder ein erreichbarer Pfad ausfällt.

Erkennen Anycast-Routen defekte Backends?

Nein. Anycast Routing bewertet den Pfad zur Edge. Ob ein Backend nutzbar ist, wird über separate Backend Health Checks und Failover-Regeln bestimmt.

Bleiben bestehende Verbindungen bei Edge-Failover erhalten?

Nicht grundsätzlich. Bei einem Wechsel der Edge-Struktur können bestehende Sessions abbrechen. Das Verhalten hängt vom Protokoll, der Sessionverwaltung und der Anwendung ab.

Fazit

Anycast Failover ist ein Mechanismus für den öffentlichen Zugang, nicht für die gesamte Verfügbarkeitslogik einer Anwendung. Routing, Edge-Zustand, Backend Health Checks und fachliches Anwendungsfailover müssen getrennt modelliert und gemeinsam betrieben werden. Die ayedo Edge Cloud ordnet diese Ebenen in einer verteilten Aktiv-Aktiv-Architektur ein und kann den Traffic-Eingang vor unterschiedlichen Backend- und Kubernetes-Umgebungen konsistent bereitstellen.