Aktiv-Aktiv und Backend-Failover im Zusammenspiel

TL;DR

Aktiv-Aktiv an der Edge beseitigt keinen Backend-Ausfall. Hochverfügbarkeit entsteht erst, wenn beide Ebenen getrennt geplant und technisch gekoppelt werden: Die Edge verteilt eingehenden Traffic redundant, während Backend Health Checks die Erreichbarkeit einzelner Ziele bewerten. Erst daraus entsteht belastbares Backend-Failover .

Einleitung

Ein redundanter Zugang ist keine hochverfügbare Anwendung. Fällt ein Backend aus, kann auch eine aktiv-aktive Edge den Traffic weiterhin zuverlässig an ein nicht funktionsfähiges Ziel verteilen. Umgekehrt hilft ein redundanter Compute-Cluster wenig, wenn der öffentliche Eingang, das Routing oder die Lastverteilung selbst eine zentrale Fehlerdomäne bildet. Hochverfügbarkeit muss deshalb entlang der gesamten Anforderungskette betrachtet werden: vom Anycast-Eingang über die Edge-Verarbeitung bis zu den Backends. Entscheidend ist dabei die klare Trennung von Edge und Compute. Die Edge Cloud übernimmt Annahme, Schutz, Routing und Verteilung des Traffics. Die Compute-Infrastruktur betreibt die Anwendung. Backend-Failover verbindet beide Verantwortungsbereiche, ohne sie zu vermischen.

1. Aktiv-Aktiv an der Edge reduziert die Fehlerdomäne

Bei einer Aktiv-Aktiv-Architektur sind mehrere Edge-Standorte gleichzeitig in der Lage, eingehenden Traffic zu verarbeiten. Anycast sorgt dafür, dass eine IP-Adresse aus verschiedenen Netzwerkpositionen erreichbar ist und der Traffic über die verfügbare Edge-Infrastruktur aufgenommen werden kann. Fällt ein einzelner Edge-Pfad oder eine einzelne Instanz aus, muss nicht der gesamte öffentliche Eingang umgeschaltet werden.

Das ist architektonisch etwas anderes als ein einzelner Loadbalancer mit einem Standby-System. Dort existiert häufig ein zentraler Umschaltpunkt, dessen Zustand, Routing und Erreichbarkeit selbst kritisch sind. Eine verteilte Aktiv-Aktiv-Edge mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System reduziert diese Abhängigkeit auf der Zugangsebene.

Damit ist jedoch nur eine Fehlerdomäne adressiert. Die Edge kann Anfragen weiterhin annehmen, TLS an der Edge terminieren, Regeln der Web Application Firewall anwenden und Traffic verteilen. Ob ein Backend die Anfrage noch sinnvoll verarbeiten kann, ist eine separate Frage. Aktiv-Aktiv beschreibt daher zunächst die Betriebsbereitschaft der Edge, nicht automatisch die Redundanz der Anwendung.

2. Backend-Failover braucht belastbare Health Checks

Backend-Failover basiert auf einer Zustandsentscheidung: Ein Ziel wird verwendet, solange es die definierten Erreichbarkeits- und Funktionskriterien erfüllt. Backend Health Checks liefern dafür die technische Grundlage. Sie prüfen nicht nur, ob ein Port erreichbar ist, sondern sollten möglichst einen für den Dienst aussagekräftigen Zustand abbilden. Ein Prozess kann Verbindungen akzeptieren, obwohl abhängige Datenbanken, Queues oder interne Services bereits nicht verfügbar sind.

Die Qualität des Failovers hängt deshalb von mehreren Parametern ab: Prüfintervall, Timeout, Anzahl notwendiger Fehlversuche und Zeit bis zur Wiederaufnahme eines Backends. Zu aggressive Werte können bei kurzen Störungen unnötige Umschaltungen auslösen. Zu konservative Werte halten Traffic dagegen zu lange an einem defekten Ziel. Beides erzeugt betriebliche Risiken: instabile Lastverteilung im ersten Fall, verlängerte Fehlerzeiten im zweiten.

Health Checks sind außerdem kein Ersatz für Anwendungsdesign. Sie erkennen Verfügbarkeit aus Sicht der Edge, aber nicht automatisch fachliche Korrektheit, Datenkonsistenz oder sichere Wiederholbarkeit. Für mutierende Requests müssen Idempotenz, Session-Verhalten und mögliche Nebenwirkungen separat bewertet werden.

3. Edge und Compute müssen als getrennte Ebenen geplant werden

Die Edge Cloud ist der öffentliche Eingang vor Anwendungen und APIs. Sie schützt und verarbeitet eingehenden Traffic, übernimmt Lastverteilung und kann Backends durch Backend Cloaking aus dem öffentlichen Netz herausnehmen. Die Compute-Infrastruktur führt dagegen die Workloads aus und entscheidet über Replikation, Datenhaltung, Clusterbetrieb und Wiederanlauf. Diese Trennung verhindert, dass die Verfügbarkeit eines einzelnen Compute-Providers automatisch mit der Verfügbarkeit des öffentlichen Eingangs gleichgesetzt wird.

Für die Architektur bedeutet das: Backends können bei ayedo Managed Kubernetes , in eigenen Kubernetes-Clustern oder bei anderen Providern betrieben werden. Die Edge-Funktionen bleiben dabei eine eigenständige Schicht. Ein Wechsel oder Failover auf ein anderes Backend muss nicht den öffentlichen DNS-Namen oder die externe IP-Struktur der Anwendung verändern.

Diese Entkopplung erleichtert auch organisatorische Entscheidungen. Ein Plattformteam kann die Edge zentral betreiben und Policies, Zertifikate, Schutzmechanismen sowie Statistiken standardisieren, während Anwendungsteams ihre Compute-Umgebung unabhängig verantworten. Voraussetzung ist eine klare Zuständigkeit dafür, welche Signale einen Failover auslösen und wer deren Auswirkungen bewertet.

4. Redundanz braucht abgestimmte Betriebslogik

Ein aktiv-aktiver Edge-Eingang und mehrere Backends ergeben nicht automatisch eine aktiv-aktive Anwendung. Backends können parallel produktiv sein, als Primär- und Sekundärsystem betrieben werden oder nur für einen definierten Wiederanlauffall bereitstehen. Die Edge kann anhand von Health Checks verfügbare Ziele berücksichtigen, aber sie kann keine fehlende Datenreplikation oder widersprüchliche Zustände zwischen Anwendungssystemen kompensieren.

Besonders relevant ist das bei Sessions, Schreibzugriffen und regional verteilten Daten. Werden Anfragen nach einem Ausfall an ein anderes Backend geleitet, muss dieses den erforderlichen Zustand kennen oder die Anwendung muss stateless arbeiten. Andernfalls führt korrektes technisches Failover zu fachlichen Fehlern. Auch Connection Draining und kontrollierte Wiederaufnahme sind wichtig, damit laufende Verbindungen nicht unnötig abgebrochen werden und ein wiederhergestelltes Backend nicht sofort überlastet wird.

Betrieblich sollten Edge-Metriken und Backend-Signale gemeinsam ausgewertet werden. Traffic- und Usage-Statistiken zeigen, wie sich die Verteilung verändert; Health Checks erklären, warum Ziele aus dem Pool entfernt oder wieder aufgenommen wurden. Erst diese Kombination macht Failover nachvollziehbar und testbar.

Praxisszenario: Zwei Backends, ein gemeinsamer Edge-Eingang

Eine API läuft in zwei getrennten Kubernetes -Umgebungen. Beide sind über die ayedo Edge Cloud erreichbar; der öffentliche Einstieg bleibt durch Anycast und die verteilte Edge-Struktur unabhängig von einem einzelnen Compute-Standort. Backend Health Checks prüfen einen anwendungsnahen Endpunkt. Solange beide Ziele gesund sind, verteilt die Edge den Traffic entsprechend der konfigurierten Lastverteilung.

Fällt die abhängige Datenbank eines Backends aus, bleibt der Containerprozess möglicherweise erreichbar. Ein einfacher TCP-Check würde das Ziel weiter berücksichtigen. Ein geeigneter Health Check erkennt dagegen den nicht funktionsfähigen Dienst und nimmt das Backend aus der Verteilung. Der Traffic geht auf das verbleibende Ziel. Bei nicht idempotenten Requests müssen Wiederholungen und bereits gestartete Transaktionen trotzdem auf Anwendungsebene behandelt werden.

FAQ

Ist Aktiv-Aktiv an der Edge dasselbe wie Aktiv-Aktiv im Backend?

Nein. Aktiv-Aktiv an der Edge beschreibt die parallele Verarbeitung des öffentlichen Traffics. Backend-Aktivität, Datenreplikation und fachliche Konsistenz müssen in der Compute- und Anwendungsschicht umgesetzt werden.

Wann ist ein TCP-Health-Check ausreichend?

Für einfache Erreichbarkeitsprüfungen kann TCP genügen. Für APIs und Anwendungen sollte der Check möglichst einen Dienstzustand prüfen, der auch kritische Abhängigkeiten berücksichtigt.

Verhindert Backend-Failover Datenverlust?

Nein. Failover verteilt Traffic auf ein verfügbares Ziel. Datenhaltbarkeit, Replikation, Transaktionssicherheit und Wiederholbarkeit bleiben Aufgaben der Anwendung und ihrer Compute-Infrastruktur.

Fazit

Mehrschichtige Hochverfügbarkeit entsteht nicht durch eine einzelne redundante Komponente. Die Edge muss den öffentlichen Eingang aktiv-aktiv und providerunabhängig bereitstellen, während Backends ihre eigene Verfügbarkeit und Datenkonsistenz sicherstellen. Backend Health Checks bilden die Verbindung zwischen beiden Ebenen, ersetzen aber kein robustes Anwendungsdesign. Die ayedo Edge Cloud ist in diesem Modell eine eigenständige Edge-Plattform vor unterschiedlichen Compute-Umgebungen – nicht lediglich ein Loadbalancer vor einem einzelnen Cluster.