Failover an der Edge: Routing, Zustände und Grenzen

TL;DR

Edge-Failover ist keine einzelne Umschaltentscheidung. Anycast, Routing-Konvergenz, Backend Health Checks und Protokollzustände greifen in mehreren Schritten ineinander. Sie lösen unterschiedliche Fehlerklassen und haben eigene zeitliche Grenzen. Wer diese Ebenen vermischt, überschätzt die Geschwindigkeit, Reichweite und Automatisierung eines Failovers.

Ein Edge-Failover besteht aus mehreren Zustandsänderungen: Ein Backend kann aus dem Pool genommen werden, während das Anycast-Netzwerk weiterhin erreichbar ist. Umgekehrt kann ein Routing- oder PoP-Problem den öffentlichen Zugang beeinflussen, obwohl die Backends selbst gesund arbeiten. Erst die getrennte Betrachtung dieser Ebenen macht sichtbar, welche Ausfälle tatsächlich automatisch behandelt werden können.

1. Anycast und Routing lösen ein anderes Problem als Backend-Failover

Anycast stellt dieselbe IP-Adresse über mehrere Netzwerkstandorte bereit. Das Anycast-Netzwerk verteilt eingehenden Traffic auf Basis der jeweils gültigen Routing-Informationen. Fällt ein Edge-Standort oder ein relevanter Netzwerkpfad aus, kann sich die bevorzugte Route ändern. Die Clients senden dann nach der Routing-Konvergenz zu einem anderen erreichbaren Einstiegspunkt.

Das ist jedoch kein Health Check für die Anwendung. Routing erkennt nicht automatisch, ob ein bestimmtes Backend HTTP-Fehler produziert, Datenbankverbindungen verliert oder nur einen einzelnen API-Pfad nicht mehr bedienen kann. Diese Zustände liegen auf einer anderen Ebene.

Die ayedo Edge Cloud nutzt ein eigenes Autonomous System und eigene Netzwerk-Infrastruktur in einer verteilten Multi-PoP-Architektur. Das schafft die Grundlage für Anycast und ein Aktiv-Aktiv-Modell. Es bedeutet aber nicht, dass jede Anfrage bei jedem Fehler ohne Unterbrechung neu zugestellt wird. Routing-Entscheidungen und bestehende Transportverbindungen haben jeweils eigene Zustände.

2. Backend Health Checks steuern den Traffic-Pool

Backend Health Checks prüfen, ob ein Ziel aus Sicht der Edge weiterhin für neue Verbindungen oder Requests geeignet ist. Je nach Protokoll und Konfiguration können dabei unterschiedliche Kriterien relevant sein: Erreichbarkeit auf Layer 4, eine erfolgreiche Anwendungskommunikation auf Layer 7 oder ein definierter Health-Endpunkt.

Erkennt die Edge ein fehlerhaftes Backend, kann sie dieses aus der Verteilung nehmen oder einen Failover auf andere Backends einleiten. Das ist Backend-Failover, nicht Routing-Failover. Die öffentliche Anycast-Adresse bleibt dabei grundsätzlich dieselbe; geändert wird die Auswahl innerhalb der Edge-Plattform.

Wichtig ist der zeitliche Verlauf: Ein Health Check läuft in Intervallen und benötigt möglicherweise mehrere fehlerhafte Prüfungen, bevor ein Statuswechsel erfolgt. Nach der Wiederherstellung darf ein Backend ebenfalls nicht zwingend sofort wieder produktiv werden. Schwellenwerte, Prüfintervalle und Wiederanlaufverhalten sollen Fehlentscheidungen vermeiden, begrenzen aber die Reaktionsgeschwindigkeit. Ein zu aggressiver Check kann bei kurzen Lastspitzen unnötige Failover auslösen.

3. Failover besteht aus Zuständen, nicht aus einem Schalter

Die Aussage „das System schaltet bei Ausfall automatisch um“ ist technisch unvollständig. Zunächst muss ein Fehler erkannt werden. Danach wird ein neuer Zustand bewertet und verteilt: etwa ein als unhealthy markiertes Backend, ein geänderter Routing-Pfad oder ein anderer erreichbarer Edge-Standort. Erst anschließend kann neuer Traffic entsprechend behandelt werden.

Dabei unterscheiden sich neue und bestehende Verbindungen. Eine bereits etablierte TCP-Verbindung kann nicht beliebig an ein anderes Backend verschoben werden, weil ihr Verbindungszustand am bisherigen Pfad und Ziel hängt. Bei HTTP können Wiederholungen oder neue Verbindungen einen alternativen Pfad nutzen; das hängt jedoch vom Client, vom Protokoll und von der Anwendung ab. Nicht jede Anfrage ist gefahrlos wiederholbar.

Auch TLS-Sessions, langlebige Verbindungen, WebSockets und zustandsbehaftete Anwendungen setzen dem Failover Grenzen. TLS Termination an der Edge kann den Übergang vereinfachen, ersetzt aber keine Zustandsstrategie im Backend. Failover verschiebt Traffic – es repliziert keine Anwendungssitzung und korrigiert keine inkonsistenten Daten.

4. Reichweite und Automatisierungsgrad müssen konkret bewertet werden

Ein automatischer Failover kann nur die Fehlerklasse behandeln, für die ein Mechanismus Zustände erfassen und eine alternative Route oder ein alternatives Ziel bestimmen kann. Ein ausgefallener Service-Endpunkt ist eine andere Situation als ein vollständiger Provider-Ausfall, ein Fehler im Routing oder eine Überlastung aller verfügbaren Backends.

Auch die Reichweite ist begrenzt. Backend Health Checks können ein Ziel aus dem Traffic-Pool entfernen, aber sie beweisen nicht, dass eine gesamte Anwendung fachlich korrekt arbeitet. Anycast kann den Zugang über eine andere Netzwerkroute ermöglichen, garantiert jedoch nicht, dass dort eine gesunde Anwendung verfügbar ist. Routing-Konvergenz wiederum benötigt Zeit, und Resolver, Clients oder bestehende Sessions können alte Zustände weiterverwenden.

Deshalb sollte Failover als Prozess mit beobachtbaren Übergängen modelliert werden: Erkennung, Bewertung, Steuerung und Stabilisierung. Dazu gehören Health- und Traffic-Statistiken, definierte Zuständigkeiten und Tests für Teil- und Gesamtausfälle. Wirtschaftlich entscheidet diese Präzision darüber, ob ein Ausfall begrenzt wird oder nur zwischen mehreren Komponenten weitergereicht wird.

Szenario: Backend-Ausfall ohne Edge-Ausfall

Eine API läuft aktiv auf zwei Kubernetes-Clustern , die bei unterschiedlichen Providern betrieben werden. Beide Cluster sind über die ayedo Edge Cloud erreichbar. Ein Cluster verliert seine Datenbankverbindung; die Nodes und das Netzwerk bleiben jedoch erreichbar. Ein passiver TCP-Check würde den Fehler möglicherweise nicht erkennen. Ein passender Layer-7-Health-Check kann dagegen feststellen, dass der Service fachlich nicht mehr verfügbar ist, und das Backend aus der Verteilung nehmen.

Die Anycast-Adresse bleibt unverändert. Für neue Requests übernimmt das verbleibende Backend. Bereits offene Verbindungen können trotzdem fehlschlagen, und Requests mit nicht idempotenten Schreiboperationen dürfen nicht blind wiederholt werden. Fällt dagegen ein Edge-PoP oder ein Routing-Pfad aus, liegt die Fehlerbehandlung auf der Anycast- und Routing-Ebene – unabhängig davon, ob beide Backends gesund sind.

FAQ

Ist Anycast allein ein Failover-Mechanismus?

Nein. Anycast verteilt Erreichbarkeit über Routing-Pfade. Es ersetzt weder Backend Health Checks noch die Prüfung, ob eine Anwendung fachlich korrekt arbeitet.

Wie schnell ist Edge-Failover?

Das hängt von Erkennungsintervallen, Schwellwerten, Routing-Konvergenz, Verbindungszuständen und Clientverhalten ab. Eine pauschale Umschaltzeit lässt sich technisch nicht seriös angeben.

Funktioniert Failover auch bei zustandsbehafteten Anwendungen?

Nur eingeschränkt. Die Edge kann Traffic umleiten, aber Sitzungen, Transaktionen und Datenkonsistenz müssen durch die Anwendung und ihre Backend-Architektur abgesichert werden.

Fazit

Edge-Failover ist eine Kette aus Zustandsbewertung und Verkehrssteuerung, kein einzelner Schalter. Anycast und Routing adressieren Erreichbarkeit auf Netzwerkebene; Health Checks steuern die Auswahl gesunder Backends. Die ayedo Edge Cloud verbindet diese Ebenen in einer providerunabhängig nutzbaren Edge-Plattform, ohne die Grenzen von Sessions, Routing-Konvergenz oder Anwendungszuständen aufzuheben. Belastbare Failover-Architekturen planen deshalb nicht nur den Wechsel, sondern auch Erkennung, Rückkehr und fachliche Konsistenz.