Failover und Health Checks für Backend-Pools planen

TL;DR

Loadbalancing Failover ist keine automatische Garantie für Hochverfügbarkeit. Entscheidend ist, welche Fehler ein Health Check erkennt, wie schnell er reagiert und welche Ziele danach noch erreichbar sind. Eine belastbare Failover Architektur trennt technische Erreichbarkeit von fachlicher Betriebsfähigkeit und definiert das Verhalten für L4- und L7-Traffic eindeutig.

Einleitung

Ein Backend kann erreichbar sein und trotzdem keine Anfragen verarbeiten. Ein offener TCP-Port sagt wenig darüber aus, ob eine Anwendung Datenbankverbindungen aufbauen, Requests vollständig beantworten oder ihre fachlichen Abhängigkeiten bedienen kann. Genau an dieser Stelle scheitern viele Failover-Konzepte: Der Loadbalancer erkennt nur den Ausfall des Prozesses, nicht den Ausfall der Anwendung.

Backend Health Checks müssen deshalb zur Fehlerdomäne des jeweiligen Services passen. Gleichzeitig braucht Failover klare Regeln: Wann gilt ein Ziel als nicht verfügbar? Auf welchen Pool wird ausgewichen? Wie wird verhindert, dass ein kurzzeitiger Fehler eine Failover-Kaskade auslöst? Diese Fragen gehören zum Betriebsdesign und nicht erst in die Störungsanalyse.

1. Health Checks bewerten unterschiedliche Verfügbarkeiten

Ein Health Check kann auf verschiedenen Ebenen ansetzen. Bei einem L4-Service wird typischerweise geprüft, ob eine TCP-Verbindung zu einer Adresse und einem Port aufgebaut werden kann. Das erkennt etwa einen nicht erreichbaren Host oder einen nicht laufenden Listener. Für viele Anwendungen reicht dieser Check jedoch nicht aus: Ein Prozess kann Verbindungen akzeptieren, obwohl seine Request-Verarbeitung blockiert ist.

L7-Health-Checks prüfen dagegen das Verhalten eines HTTP- oder HTTPS-Endpunkts. Neben dem Statuscode können Pfad, Protokoll und Antwortverhalten relevant sein. Ein sinnvoller Prüfpunkt sollte eine für den Betrieb aussagekräftige Funktion abbilden, aber keine unnötig tiefen Abhängigkeiten aufrufen. Wird beispielsweise bei jedem Check ein komplexer Geschäftsprozess gestartet, kann der Check selbst zusätzliche Last erzeugen.

Für die Failover-Planung sind außerdem Fehlerintervalle, Wiederholungen und die Rückkehr eines Backends wichtig. Zu aggressive Prüfungen reagieren schnell, können bei kurzen Netzstörungen aber gesunde Ziele aus dem Pool entfernen. Zu großzügige Werte verlängern die Zeit, in der Traffic an ein bereits gestörtes Backend gelangt.

2. Failover braucht definierte Fehler- und Rückkehrregeln

Failover bedeutet nicht lediglich, Traffic an „ein anderes Backend“ zu senden. Zuerst muss festgelegt werden, welche Ziele zur gleichen Verfügbarkeitsdomäne gehören. Ein Pool kann mehrere Instanzen derselben Anwendung enthalten, alternativ können getrennte Pools für unterschiedliche Standorte, Cluster oder Provider vorgesehen werden. Diese Struktur bestimmt, wie viel Ausfall ein System tatsächlich toleriert.

Ebenso wichtig ist die Rückkehr in den Normalbetrieb. Wenn ein Backend nach einem kurzen Fehler sofort wieder Traffic erhält, kann ein instabiler Dienst zwischen verfügbar und nicht verfügbar wechseln. Dieses Flapping erschwert die Diagnose und belastet zusätzlich die Anwendung. Eine kontrollierte Wiederaufnahme sollte deshalb erst erfolgen, wenn das Ziel wieder zuverlässig antwortet.

Bei L4- und L7-Loadbalancing unterscheiden sich zudem die Folgen bestehender Verbindungen. Neue Verbindungen lassen sich leichter auf gesunde Ziele verteilen. Bereits etablierte Sessions können dagegen abbrechen oder an Zustandsabhängigkeiten scheitern. Failover muss daher berücksichtigen, ob die Anwendung stateless arbeitet, Sessions extern hält oder Verbindungszustände an ein bestimmtes Backend bindet.

3. Failover ist Teil der Edge-Architektur

Die ayedo Edge Cloud bewertet Backend-Ziele über Health Checks und kann Traffic innerhalb von Backend-Pools verteilen oder bei Ausfällen auf verfügbare Ziele ausweichen. Das gilt im Kontext ihres Anycast-basierten Layer-4- und Layer-7-Loadbalancings. Die Edge Cloud übernimmt dabei den öffentlichen Eingang und die Weiterleitung; die eigentlichen Anwendungen laufen weiterhin in der Compute-Infrastruktur.

Diese Trennung ist für die Failover Architektur entscheidend. Ein ausgefallener Kubernetes-Pod , ein nicht erreichbarer Cluster oder ein gestörter Provider sind unterschiedliche Fehlerbilder. Die Edge kann den öffentlichen Traffic-Eingang und die Auswahl erreichbarer Backends steuern, ersetzt aber keine Redundanz innerhalb der Anwendung oder ihrer Datenhaltung. Ein zweiter Pool hilft nicht, wenn beide Pools dieselbe ausgefallene Datenbank verwenden.

Durch die verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip wird die Edge selbst nicht als einzelner Übergabepunkt betrachtet. Anycast-Routing, Backend Health Checks und Failover müssen dennoch gemeinsam geplant werden: Ein Ziel kann aus Sicht eines Edge-Standorts erreichbar sein, während ein anderer Pfad Fehler zeigt. Für den Betrieb sind deshalb zentrale Statistiken und klare Zustandsdefinitionen erforderlich.

4. Fehlererkennung muss zum Ausfallverhalten passen

Ein guter Health Check beantwortet nicht die Frage „Lebt der Server?“, sondern „Kann dieses Ziel diese Art von Traffic derzeit sinnvoll verarbeiten?“. Für einen API-Endpunkt kann ein authentifizierungsfreier Readiness-Pfad geeignet sein. Für eine transaktionale Anwendung muss zusätzlich geprüft werden, ob kritische Abhängigkeiten verfügbar sind. Dabei ist zwischen Readiness, Liveness und echter Service-Verfügbarkeit zu unterscheiden.

Failover sollte außerdem nicht blind über alle Anfragen erfolgen. Bei nicht idempotenten Schreiboperationen kann ein Timeout unklar lassen, ob die Verarbeitung bereits gestartet oder abgeschlossen wurde. Ein Retry auf ein zweites Backend kann dann zu Doppelverarbeitung führen. Die Edge kann den Traffic weiterleiten, aber die Anwendung muss Wiederholbarkeit, Idempotenz und Fehlerantworten sauber definieren.

Für den Betrieb gehören daher folgende Fragen in das Design: Welche Fehler lösen Failover aus? Welche Antworten bleiben beim ursprünglichen Backend? Wie wird ein Pool vollständig ungesund behandelt? Und wie werden Fehlentscheidungen sichtbar? Ohne diese Regeln entsteht zwar technische Umschaltung, aber keine kontrollierte Hochverfügbarkeit.

Betriebsszenario: Primärer Cluster und Ausweichpool

Eine API läuft primär in einem Kubernetes-Cluster und zusätzlich in einem getrennten Cluster bei einem anderen Provider. Beide Umgebungen werden als Backend-Ziele einer Edge-Konfiguration angebunden. Ein L7-Check prüft einen dedizierten Readiness-Endpunkt. Dieser bestätigt, dass die API Requests annehmen kann und ihre unmittelbar notwendigen Abhängigkeiten verfügbar sind.

Fällt der primäre Pool aus, verteilt die Edge neue Requests an den Ausweichpool. Bestehende Verbindungen werden nicht automatisch fachlich fortgesetzt; Clients müssen mit Timeouts und Wiederholungen umgehen können. Vor der Aktivierung des Designs wird außerdem geprüft, ob beide Cluster dieselben Datenstände, Konfigurationen und Sicherheitsanforderungen erfüllen. Sonst verlagert das Failover den Ausfall lediglich an eine andere Stelle.

FAQ

Sind TCP-Checks für Backend Health Checks ausreichend?

Nur für die Erreichbarkeit eines Ports. Sie erkennen nicht zuverlässig, ob die Anwendung Requests verarbeiten kann. Für HTTP-Services ist ein passender L7-Check meist aussagekräftiger.

Was passiert, wenn alle Backends eines Pools ausfallen?

Das Verhalten muss vorab definiert werden, etwa eine Fehlerantwort oder ein Ausweichen auf einen separaten Pool. Ohne Regel bleibt der Ausfall zwar erkennbar, aber betrieblich unkontrolliert.

Verhindert Failover den Verlust laufender Sessions?

Nein. Failover verteilt vor allem neue Verbindungen oder Requests neu. Session-Zustände, Wiederholungen und mögliche Doppelverarbeitung müssen von Anwendung und Client berücksichtigt werden.

Fazit

Loadbalancing Failover ist eine Betriebsentscheidung mit technischen, organisatorischen und wirtschaftlichen Folgen. Health Checks müssen die tatsächliche Verfügbarkeit eines Services bewerten, während Pools, Rückkehrregeln und Session-Verhalten das Ausfallrisiko begrenzen. Die ayedo Edge Cloud ordnet diese Mechanismen in ein Anycast-basiertes L4- und L7-Loadbalancing mit verteiltem Edge-Eingang ein. Hochverfügbarkeit entsteht jedoch erst durch das Zusammenspiel von Edge, Compute, Datenhaltung und belastbaren Betriebsprozessen.