Aktiv-Aktiv-Architektur für hochverfügbare Backends

TL;DR

Hochverfügbarkeit entsteht nicht allein durch redundante Backends. Auch die Eingangsschicht muss Ausfälle einzelner Standorte, Netzpfade oder Komponenten verkraften können. Eine verteilte Aktiv-Aktiv-Architektur kombiniert deshalb mehrere aktive Edge-Instanzen mit Backend Health Checks und kontrolliertem Failover. Entscheidend ist die gemeinsame Betrachtung von Edge und Compute .

Einleitung

Ein redundantes Backend ist nicht hochverfügbar, wenn der gesamte öffentliche Traffic über eine einzelne aktive Eingangsschicht läuft. Fällt dieser zentrale Einstiegspunkt aus, bleiben gesunde Anwendungen unerreichbar. Umgekehrt hilft auch eine verteilte Edge-Architektur nicht weiter, wenn sie weiterhin Traffic an nicht erreichbare oder fehlerhafte Backends verteilt. Hochverfügbarkeit ist daher eine Kette aus mindestens zwei Ebenen: der verteilten Annahme und Verarbeitung des Traffics sowie der kontrollierten Erreichbarkeit nachgelagerter Workloads. Eine Aktiv-Aktiv-Architektur muss beide Ebenen zusammenführen und Zustände kontinuierlich bewerten.

1. Aktiv-Aktiv beginnt am öffentlichen Eingang

Bei einer Aktiv-Aktiv-Architektur sind mehrere Edge-Instanzen gleichzeitig produktiv. Traffic wird nicht erst nach dem Ausfall einer primären Instanz auf eine passive Reserve umgeschaltet, sondern verteilt sich grundsätzlich über mehrere aktive Komponenten oder Standorte. Dadurch entfällt ein einzelner aktiver Einstiegspunkt als kritische Abhängigkeit.

Für die Edge Cloud bedeutet das eine verteilte Multi-PoP-Architektur mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System. Anycast kann dabei den öffentlichen Zugang über mehrere erreichbare Edge-Standorte abbilden. Der konkrete Traffic-Pfad hängt anschließend von Routing, Erreichbarkeit und den verfügbaren Edge-Funktionen ab.

Der betriebliche Vorteil liegt nicht nur in der Ausfalltoleranz. Wartungsarbeiten, Störungen einzelner Standorte oder Beeinträchtigungen bestimmter Netzpfade müssen nicht zwangsläufig den gesamten Dienst unterbrechen. Voraussetzung ist allerdings, dass die aktiven Edge-Komponenten denselben Dienst logisch repräsentieren und nicht jeweils einen isolierten Zustand bilden. Sonst entsteht trotz verteilter Infrastruktur ein versteckter Single Point of Failure.

2. Edge-Verfügbarkeit und Backend-Zustand sind getrennte Ebenen

Die Erreichbarkeit der Edge sagt nichts darüber aus, ob die Anwendung dahinter funktionsfähig ist. Ein Anycast-Endpunkt kann weiterhin Anfragen annehmen, während ein Backend wegen eines Ausfalls, einer Überlastung oder eines Netzproblems nicht mehr antwortet. Deshalb müssen Edge-Verfügbarkeit und Backend-Verfügbarkeit getrennt gemessen und anschließend zusammengeführt werden.

Backend Health Checks prüfen, ob definierte nachgelagerte Ziele erreichbar und für Traffic geeignet sind. Dabei ist die Wahl des Prüfpunktes relevant: Ein Netzwerk-Check bestätigt möglicherweise nur die Erreichbarkeit eines Ports, während ein HTTP- oder HTTPS-Check zusätzlich eine verwertbare Antwort des Dienstes prüfen kann. Welche Prüftiefe sinnvoll ist, hängt vom Protokoll und vom Fehlerbild ab.

Im Fehlerfall darf die Edge nicht weiter blind an ein ungesundes Ziel verteilen. Failover muss deshalb an einen definierten Zustand gekoppelt sein: etwa an das Ausbleiben erfolgreicher Health Checks oder an den Verlust einer Backend-Gruppe. So wird aus reiner Redundanz eine betriebsfähige Hochverfügbarkeitslogik. Die Edge Cloud verbindet dafür Loadbalancing, Health Checks und Failover, ohne die Compute Infrastruktur selbst zu ersetzen.

3. Failover braucht klare Zustände und kontrollierte Entscheidungen

Failover ist kein Synonym für „bei Fehlern einfach umschalten“. Eine belastbare Architektur muss festlegen, wann ein Backend als nicht verfügbar gilt, wie lange dieser Zustand beobachtet wird und welches alternative Ziel verwendet wird. Zu aggressive Umschaltungen können bei kurzen Netzstörungen unnötige Wechsel auslösen. Zu träge Entscheidungen verlängern dagegen die Zeit, in der Nutzer fehlerhafte Backends erreichen.

Besonders wichtig ist die Unterscheidung zwischen einem einzelnen fehlerhaften Backend und einem größeren Ausfall. Fällt nur eine Instanz aus, sollte Traffic möglichst auf gesunde Ziele derselben Gruppe verteilt werden. Ist eine gesamte Backend-Zone oder ein Cluster nicht erreichbar, braucht es ein Failover auf eine andere verfügbare Backend-Gruppe. Die Architektur muss dabei sicherstellen, dass das alternative Ziel tatsächlich Kapazität und die erforderlichen Daten oder Zustände besitzt.

Auch Protokoll und Anwendung beeinflussen die Entscheidung. Bei zustandslosen APIs ist ein Wechsel meist einfacher als bei lang laufenden Verbindungen oder Sitzungen mit lokalem Zustand. Health Checks und Failover lösen daher nicht automatisch jede Anwendungseigenschaft. Sie schaffen die technische Grundlage; Session-Handling, Replikation und Datenkonsistenz bleiben Aufgaben der Backend- und Compute Architektur.

4. Die gemeinsame Betriebsverantwortung darf nicht unsichtbar bleiben

Eine verteilte Edge reduziert das Ausfallrisiko am öffentlichen Eingang, verlagert die Betriebsaufmerksamkeit aber nicht vollständig von den Teams weg. Verantwortlichkeiten müssen zwischen Edge und Compute klar getrennt sein. Die Edge Cloud übernimmt Annahme, Routing, Schutz und Verteilung des Traffics. Die Compute-Infrastruktur verantwortet Anwendungen, Workloads, Daten und deren interne Redundanz.

Diese Trennung ist auch für die Fehleranalyse entscheidend. Ein Timeout kann durch einen nicht erreichbaren Edge-Pfad, ein fehlerhaftes Routing, einen ausgefallenen Backend-Service oder eine Überlastung im Cluster entstehen. Traffic- und Usage-Statistiken sowie der Status der Backend Health Checks liefern dafür unterschiedliche Perspektiven. Erst ihre gemeinsame Auswertung macht sichtbar, ob ein Problem am Eingang oder im nachgelagerten Dienst liegt.

Für Unternehmen hat das eine organisatorische und wirtschaftliche Konsequenz: Redundanz muss Ende zu Ende geplant werden. Mehrere Backend-Instanzen rechtfertigen keine Hochverfügbarkeitsaussage, wenn DNS, Edge oder Netzpfad zentralisiert bleiben. Umgekehrt kann eine aktive Edge keinen fehlenden Replikations- oder Failover-Mechanismus im Backend kompensieren.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine API in zwei Kubernetes Clustern bei unterschiedlichen Providern. Beide Cluster stellen denselben Dienst bereit, sind aber nicht identisch an den öffentlichen Traffic angebunden. Eine verteilte Edge nimmt Anfragen über Anycast entgegen und nutzt Health Checks für beide Backend-Gruppen.

Fällt eine Anwendungspod-Gruppe in Cluster A aus, verteilt die Edge den Traffic auf verbleibende gesunde Ziele. Wird der gesamte Cluster A unerreichbar, greift das Failover auf Cluster B. Fällt dagegen ein Edge-Standort aus, bleibt der Dienst über andere aktive Edge-Standorte erreichbar. Die Hochverfügbarkeit entsteht somit erst durch das Zusammenspiel aus verteilter Eingangsschicht, geprüften Backend-Zielen und einer tatsächlich nutzbaren zweiten Compute Umgebung.

FAQ

Ist eine Aktiv-Aktiv-Edge automatisch ein Aktiv-Aktiv-Backend?

Nein. Aktiv-Aktiv auf der Edge beschreibt die gleichzeitig betriebene Eingangsschicht. Die Backends müssen zusätzlich selbst redundant betrieben und über geeignete Routing- und Failover-Regeln eingebunden werden.

Was passiert, wenn alle Backends gesund, aber ein Edge-Standort nicht erreichbar ist?

Bei einer verteilten Aktiv-Aktiv-Architektur kann Traffic über andere aktive Edge-Standorte verarbeitet werden. Das setzt voraus, dass Routing und Erreichbarkeit den verbleibenden Pfad unterstützen.

Reichen Backend Health Checks für Hochverfügbarkeit aus?

Nein. Health Checks erkennen Zustände und ermöglichen Entscheidungen. Sie ersetzen weder redundante Backends noch Replikation, Kapazitätsplanung, Session-Handling oder einen getesteten Betriebsprozess.

Fazit

Hochverfügbarkeit ist eine Ende-zu-Ende-Eigenschaft und kein Merkmal einzelner Komponenten. Eine verteilte Aktiv-Aktiv-Architektur schützt den öffentlichen Eingang, während Backend Health Checks und Failover die Erreichbarkeit der nachgelagerten Dienste bewerten. Die ayedo Edge Cloud ordnet diese Ebenen in einer eigenen, verteilten Netzwerk-Infrastruktur ein und kann dabei auch mit Kubernetes Clustern außerhalb von ayedo Managed Kubernetes betrieben werden. Entscheidend bleibt die abgestimmte Architektur von Edge und Compute .