Failover und Health Checks für Backend-Pools an der Edge

TL;DR

Backend Health Checks entscheiden nicht nur, ob ein Server erreichbar ist. Sie bestimmen, wann ein Backend Traffic erhalten darf, wann ein Pool als eingeschränkt gilt und wann Failover greift. Für die Verfügbarkeit zählt daher die Prüfstrategie: Netzwerkstatus, Protokollverhalten und fachliche Antwort müssen zum tatsächlichen Fehlerbild der Anwendung passen.

Einleitung

Ein Backend kann Verbindungen annehmen und trotzdem nicht nutzbar sein. Beispielsweise antwortet ein Webserver mit HTTP 200, obwohl die Datenbank nicht erreichbar ist und die Anwendung keine verwertbaren Ergebnisse liefert. Ein Loadbalancer, der ausschließlich TCP-Konnektivität prüft, würde dieses Backend weiterhin in die Traffic-Verteilung einbeziehen.

Damit wird Backend-Verfügbarkeit zu einer Definitionsfrage: Welche Antwort reicht aus, damit ein Backend als gesund gilt? Health Checks und Failover bilden deshalb keine rein technische Zusatzfunktion, sondern eine Betriebslogik. Sie entscheiden an der Edge, ob Traffic das Backend erreicht, auf andere Instanzen verteilt oder zurückgehalten wird. Falsch modellierte Prüfungen können Ausfälle verlängern, gesunde Ressourcen überlasten oder Fehler zwischen mehreren Schichten verteilen.

1. Backend-Verfügbarkeit ist mehr als Erreichbarkeit

Ein Health Check prüft einen definierten technischen Zustand. Auf Layer 4 kann das der erfolgreiche Aufbau einer TCP-Verbindung sein. Auf Layer 7 lässt sich zusätzlich untersuchen, ob ein HTTP- oder HTTPS-Endpunkt eine erwartete Antwort liefert. Beide Varianten beantworten jedoch unterschiedliche Fragen.

Ein TCP-Check zeigt: Der Dienst nimmt Verbindungen an. Er sagt nicht, ob Routing, Authentifizierung, abhängige Services oder die eigentliche Geschäftslogik funktionieren. Ein HTTP-Check kann dagegen Statuscode, Antwortverhalten und einen dedizierten Prüfpfad einbeziehen. Dieser Pfad sollte möglichst leichtgewichtig sein und genau die Abhängigkeiten abbilden, die für die Nutzbarkeit des Dienstes relevant sind.

Zu strenge Checks sind ebenfalls problematisch. Wenn ein Backend wegen einer optionalen Abhängigkeit aus dem Pool fällt, obwohl Kernfunktionen verfügbar sind, reduziert sich die Kapazität unnötig. Backend Health Checks müssen daher den betrieblichen Zweck des Services abbilden: Ist er für reale Requests nutzbar – nicht nur technisch erreichbar?

2. Prüfziele und Reaktionslogik bestimmen das Failover

Failover entsteht nicht allein dadurch, dass mehrere Backends konfiguriert sind. Entscheidend ist die Reaktionslogik zwischen Prüfergebnis und Traffic-Verteilung. Ein einzelner fehlgeschlagener Check sollte nicht automatisch dieselbe Konsequenz haben wie ein dauerhaft nicht erreichbarer Dienst. In der Praxis werden deshalb mehrere Beobachtungen, Prüfintervalle und Zustandswechsel berücksichtigt. Welche Schwellenwerte sinnvoll sind, hängt vom Dienst und seiner Fehlercharakteristik ab.

Wichtig ist die Trennung zwischen „unhealthy“ und „nicht vorhanden“. Ein fehlerhaftes Backend kann aus der aktiven Verteilung genommen werden, während andere Backends weiterhin Requests bedienen. Sind keine geeigneten Backends verfügbar, greift eine andere Fehlerbehandlung als beim Ausfall einer einzelnen Instanz. Diese Zustände müssen im Betrieb beobachtbar und für Bereitschaftsplanung sowie Incident Response verständlich sein.

Die ayedo Edge Cloud unterstützt Backend Health Checks und Failover innerhalb der Edge-Verarbeitung. Damit kann die Edge den Zustand eines Backend-Pools berücksichtigen, bevor sie neuen Traffic weiterleitet. Die eigentliche Anwendung bleibt dabei in der Compute-Infrastruktur; die Edge entscheidet über den öffentlichen Zugang und die Auswahl verfügbarer Backends.

3. Failover verändert die Lastverteilung

Fällt ein Backend aus dem Pool, verschwindet die Kapazität nicht – sie wird auf die verbleibenden Backends verlagert. Das kann ein kontrollierter Vorgang sein, wenn ausreichend Reserve vorhanden ist. Bei knapp dimensionierten Pools entsteht dagegen ein Kaskadeneffekt: Weniger Backends übernehmen mehr Requests, steigen in Auslastung und Latenz und scheitern möglicherweise ebenfalls.

Deshalb muss Failover zusammen mit Kapazitätsplanung betrachtet werden. Ein Pool mit drei Backends ist nicht automatisch hochverfügbar, wenn jedes Backend im Normalbetrieb bereits nahe an seiner Belastungsgrenze arbeitet. Auch Session-Zustände, Cache-Verhalten und Verbindungspools beeinflussen, ob ein Wechsel technisch verträglich ist. Stateless Services lassen sich meist einfacher verteilen als Anwendungen mit lokal gebundenen Sitzungen oder Zuständen.

An der ayedo Edge Cloud ist diese Betrachtung providerunabhängig relevant: Backends können in unterschiedlichen Umgebungen betrieben werden, etwa in eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern . Die Edge abstrahiert den öffentlichen Zugang und kann verfügbare Ziele innerhalb des konfigurierten Pools berücksichtigen. Das ersetzt jedoch keine Kapazitäts- und Abhängigkeitsplanung im Backend.

4. Health Checks müssen zum Fehlerbild passen

Ein guter Check prüft die kleinste sinnvolle Einheit, die eine belastbare Aussage über die Nutzbarkeit erlaubt. Für einen statischen Dienst reicht möglicherweise ein Protokoll- oder HTTP-Check. Für eine API sollte der Prüfpfad auch typische Routing- und TLS-Anforderungen abbilden. Ein tiefer Check über alle abhängigen Systeme kann zwar mehr Fehler erkennen, erhöht aber Laufzeit, Last und die Gefahr, dass ein temporäres Problem den gesamten Pool aus dem Verkehr nimmt.

Ebenso relevant ist die Behandlung von Fehlalarmen. Ein Check sollte nicht durch zufällige Netzwerkspitzen oder kurzfristige Überlastung sofort einen Failover auslösen. Umgekehrt darf eine Anwendung, die zwar formal antwortet, aber keine brauchbaren Ergebnisse liefert, nicht dauerhaft als gesund gelten. Die richtige Prüftiefe ist daher eine Architekturentscheidung zwischen Erkennungsgenauigkeit, Stabilität und zusätzlicher Last.

Betriebsteams sollten außerdem prüfen, ob Health Checks denselben Zugangspfad wie Endnutzer verwenden. Unterschiedliche DNS-, Routing- oder Firewall-Bedingungen können zu widersprüchlichen Ergebnissen führen. Die Traffic- und Usage-Statistiken der Edge Cloud unterstützen dabei, Veränderungen in der Verteilung und Auswirkungen eines Failovers sichtbar zu machen.

Praxis- und Betriebsszenario

Eine API läuft in zwei Backend-Pools: einer primären Umgebung und einer Reserveumgebung. Ein einfacher TCP-Check erkennt den Ausfall des API-Prozesses nicht, wenn ein vorgeschalteter Webserver weiterhin Verbindungen annimmt. Der Loadbalancer verteilt deshalb weiterhin Requests an ein funktional gestörtes Backend. Ein HTTP-Check auf einem geeigneten Readiness-Endpunkt erkennt den Zustand präziser und nimmt das Ziel bei anhaltendem Fehler aus der Verteilung.

Beim Failover steigt die Last auf der Reserveumgebung. Vorab muss geklärt sein, ob sie diese Last dauerhaft oder nur für eine Übergangszeit tragen kann. Zusätzlich sollte der Prüfpfad dokumentieren, welche Abhängigkeiten zwingend erforderlich sind. So wird aus einem pauschalen „Server erreichbar“ eine nachvollziehbare Definition von Backend-Verfügbarkeit.

FAQ

Was prüft ein Backend Health Check?

Je nach Konfiguration prüft er beispielsweise TCP-Erreichbarkeit oder die Antwort eines HTTP-/HTTPS-Endpunkts. Maßgeblich ist, welche Aussage über die tatsächliche Nutzbarkeit des Backends benötigt wird.

Wann greift Loadbalancer Failover?

Failover greift, wenn ein Backend gemäß der definierten Prüf- und Zustandslogik nicht mehr als nutzbar gilt. Der Traffic wird dann auf verfügbare Ziele im Pool verteilt.

Verhindert Failover jeden Anwendungsausfall?

Nein. Failover kann den Ausfall einzelner Backends abfedern. Es löst jedoch keine gemeinsamen Fehler in Datenbanken, Abhängigkeiten, Konfigurationen oder der gesamten Compute-Umgebung.

Fazit

Backend Health Checks sind eine betriebliche Definition von Nutzbarkeit. Sie beeinflussen, wann Traffic weitergeleitet, umverteilt oder blockiert wird – und damit direkt die Verfügbarkeit und Belastung der verbleibenden Ressourcen. Entscheidend sind passende Prüfziele, nachvollziehbare Zustandswechsel und ausreichende Reservekapazität. Die ayedo Edge Cloud ordnet diese Logik an der öffentlichen Eingangsschicht ein und ermöglicht Failover für Backend-Pools unabhängig davon, wo die eigentlichen Workloads betrieben werden.