BGP-Routing und Backend-Failover sauber trennen

TL;DR

BGP-Routing entscheidet, über welchen Netzwerkpfad ein Client die Edge erreicht. Es sagt jedoch nichts darüber aus, ob ein konkretes Backend funktionsfähig ist. Diese Aufgabe übernehmen Health Checks und Backend-Failover innerhalb der Edge Cloud. Die Trennung beider Fehlerdomänen verhindert falsche Erwartungen und vereinfacht die Betriebsanalyse.

Eine häufige Fehlannahme in verteilten Architekturen lautet: Wenn eine Anwendung nicht erreichbar ist, müsse das Routing versagt haben. Tatsächlich liegen Fehler oft hinter der Edge – etwa bei einem ausgefallenen Backend, einem fehlerhaften Service oder einer gestörten Cluster-Anbindung. Umgekehrt kann ein korrekt arbeitendes Backend nutzlos sein, wenn der Pfad zur Edge nicht funktioniert.

BGP-Routing und Backend-Failover lösen daher unterschiedliche Probleme. BGP bestimmt die Erreichbarkeit eines IP-Präfixes über das Netzwerk. Die Edge Cloud entscheidet anschließend, ob und an welches Backend eine Anfrage weitergeleitet wird. Diese Unterscheidung ist für Architektur, Monitoring und Incident Response wesentlich.

1. BGP bestimmt den Weg zur Edge

BGP, das Border Gateway Protocol, verteilt Routing-Informationen zwischen autonomen Systemen. Wird eine IP-Adresse oder ein Präfix über BGP angekündigt, kann das Internet einen Pfad zu diesem Ziel berechnen. Dabei geht es um die Erreichbarkeit der Netzwerkadresse – nicht um den Zustand der Anwendung dahinter.

In einer Anycast-Architektur kann dasselbe Präfix an mehreren Edge-Standorten angekündigt werden. Das Routing führt einen Client typischerweise zu einer aus Netzwerksicht geeigneten Edge-Instanz. Die konkrete Auswahl hängt von BGP-Entscheidungen und der Sicht des jeweiligen Netzes ab. BGP kennt dabei weder den HTTP-Status eines Backends noch die Bereitschaft eines Kubernetes-Service .

Das ist eine klare Fehlerdomäne: Fällt eine Edge-Ankündigung oder ein Netzwerkpfad aus, betrifft das die Erreichbarkeit der Edge. Ein gesundes Backend kann in diesem Fall nicht helfen, weil der Traffic die Edge nicht erreicht. Bei der ayedo Edge Cloud bilden eigenes Autonomous System und eigene Netzwerk-Infrastruktur die Grundlage für diese externe Erreichbarkeit.

2. Health Checks bewerten die Backend-Erreichbarkeit

Sobald eine Anfrage die Edge erreicht, beginnt eine andere Zuständigkeit. Health Checks prüfen, ob ein Backend aus Sicht der Edge erreichbar und für Traffic geeignet ist. Je nach Konfiguration kann dabei beispielsweise ein Netzwerkdienst oder ein HTTP-/HTTPS-Endpunkt geprüft werden. Entscheidend ist: Die Prüfung bewertet den Zustand des Ziels hinter der Edge, nicht den BGP-Pfad des Clients.

Ein erfolgreiches BGP-Routing bedeutet deshalb nur, dass der Traffic an der Edge ankommen kann. Es garantiert nicht, dass der ausgewählte Upstream antwortet, ein Dienst korrekt arbeitet oder eine Anwendung fachlich funktionsfähig ist. Umgekehrt kann ein Backend gesund sein, obwohl einzelne externe Routingpfade zur Edge gestört sind.

Health Checks schaffen eine technische Grundlage für automatisierte Entscheidungen. Sie liefern der Edge Informationen darüber, welche Backends für die Traffic-Verteilung verfügbar sind. Für den Betrieb müssen Checks deshalb realistisch konfiguriert sein: Ein erreichbarer Port beweist weniger als ein sinnvoller Anwendungsendpunkt, während zu tiefe Prüfungen unnötige Abhängigkeiten erzeugen können.

3. Backend-Failover ist keine BGP-Entscheidung

Backend-Failover beschreibt die Reaktion der Edge auf ein nicht verfügbares oder als ungesund erkanntes Backend. Statt weitere Anfragen an dieses Ziel zu senden, kann die Edge auf ein anderes verfügbares Backend ausweichen. Das kann innerhalb eines Clusters, zwischen Umgebungen oder über Providergrenzen hinweg relevant sein – abhängig von der gewählten Architektur.

Diese Entscheidung trifft die Edge Cloud anhand ihrer Backend- und Health-Check-Konfiguration. BGP ist daran nicht beteiligt. Eine Änderung der Backend-Auswahl erfordert weder zwingend eine neue Route noch eine Änderung der öffentlichen IP-Erreichbarkeit. Genau darin liegt der betriebliche Vorteil: Der öffentliche Einstiegspunkt kann stabil bleiben, während sich die interne Zielauswahl verändert.

Die Trennung reduziert außerdem die Reichweite von Fehlern. Ein fehlerhaftes Backend muss nicht automatisch eine globale Routingänderung auslösen. Das vermeidet unnötige Konvergenzzeiten und hält externe Netzwerkanpassungen von anwendungsnahen Recovery-Mechanismen fern. Backend-Failover ersetzt jedoch kein gutes Deployment- oder Cluster-Design. Es verteilt Traffic nur auf Ziele, die tatsächlich als verfügbar erkannt werden.

4. Zwei Fehlerdomänen, getrennte Betriebsindikatoren

Für die Fehlersuche müssen Routing- und Backend-Signale getrennt ausgewertet werden. Ein BGP- oder Edge-Erreichbarkeitsproblem zeigt sich beispielsweise dadurch, dass Requests bestimmte Edge-Zugänge nicht erreichen. Ein Backend-Problem zeigt sich dagegen häufig erst nach erfolgreicher Annahme des Traffics: Health Checks schlagen fehl, Verbindungen zum Upstream werden abgewiesen oder Antworten bleiben aus.

Diese Unterscheidung beeinflusst auch Alarmierung und Verantwortlichkeiten. Netzwerk- und Edge-Verantwortliche analysieren Präfix-Ankündigungen, Pfade und Edge-Erreichbarkeit. Plattform- oder Anwendungsteams untersuchen Backend-Zustände, Services, Pods und Abhängigkeiten. Gemeinsame Dashboards sollten deshalb Traffic-Verteilung, Health-Check-Ergebnisse und Backend-Failover sichtbar machen, ohne daraus einen einzigen Verfügbarkeitsindikator zu bilden.

Architektonisch erlaubt die ayedo Edge Cloud, den öffentlichen Eingang unabhängig von der Compute-Infrastruktur zu betreiben. Sie kann Traffic per Anycast annehmen, Backends prüfen und bei Bedarf umverteilen – auch bei eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern . Die Edge bleibt damit die Zuständigkeit für Eingang und Weiterleitung, während die Compute-Umgebung die Workloads ausführt.

Szenario: Unterschiedliche Reaktionen auf denselben Ausfall

Angenommen, ein Unternehmen betreibt einen Kubernetes-Service in zwei Umgebungen. Beide Backends sind über einen stabilen öffentlichen Edge-Einstieg erreichbar. Fällt ein Service in Umgebung A aus, schlagen die Health Checks für dieses Backend fehl. Die Edge nimmt Umgebung A aus der Traffic-Verteilung und leitet Anfragen an Umgebung B weiter. BGP bleibt unverändert.

Fällt dagegen die Erreichbarkeit einer Edge-Ankündigung oder eines Netzwerkpfads aus, kann der Traffic die zuständige Edge nicht zuverlässig erreichen. Dann hilft Backend-Failover in der Edge nicht weiter. Ein alternatives Backend wird erst relevant, wenn eine Edge den Request annehmen und die Backend-Auswahl durchführen kann. Die Maßnahmen liegen somit in unterschiedlichen Betriebsprozessen.

FAQ

Kann Backend-Failover eine BGP-Störung kompensieren?

Nein. Backend-Failover greift erst, wenn eine Edge den Traffic angenommen hat. Ist der Weg zur Edge gestört, muss die Ursache im Routing, in der Edge-Erreichbarkeit oder im vorgelagerten Netzwerk untersucht werden.

Muss für jedes Backend-Failover das Routing geändert werden?

Nein. Die Edge kann die Zielauswahl anhand von Health Checks und Backend-Konfigurationen ändern, während der öffentliche Einstiegspunkt unverändert bleibt.

Was sollte ein Alarm zuerst unterscheiden?

Ob Requests die Edge erreichen und ob die Edge gesunde Backends findet. Diese beiden Signale trennen Routingprobleme von Backend- und Anwendungsproblemen.

Fazit

BGP-Routing und Backend-Failover gehören in unterschiedliche Schichten. BGP entscheidet über den Weg zur Edge; Health Checks und Backend-Failover entscheiden über die Nutzung verfügbarer Ziele hinter der Edge. Diese Architekturklärung verbessert Monitoring, Zuständigkeiten und Incident Response. Eine Plattform wie die ayedo Edge Cloud verbindet beide Ebenen im Betrieb, ersetzt sie aber nicht durch dieselbe Mechanik: Netzwerk-Erreichbarkeit und Backend-Verfügbarkeit bleiben getrennte Fehlerdomänen.