TL;DR
Aktiv-Aktiv-Failover entsteht nicht durch einen einzelnen Mechanismus, sondern durch das Zusammenspiel von Anycast, verteilten Edge-PoPs, belastbaren Health Checks und dynamischer Backend-Auswahl. Fällt ein Backend aus, muss die Edge den Zustand erkennen und neue Verbindungen gezielt an verfügbare Backends verteilen, ohne einen zentralen Primärpfad vorauszusetzen.
Einleitung
Ein häufiger Architekturfehler besteht darin, Anycast mit Hochverfügbarkeit gleichzusetzen. Eine global erreichbare IP-Adresse reduziert zwar die Abhängigkeit von einem einzelnen Einstiegspunkt, verhindert aber keinen Ausfall der Anwendung. Erst wenn die Edge den Zustand der Backends kontinuierlich bewertet und Routingentscheidungen daran ausrichtet, entsteht ein belastbarer Aktiv-Aktiv-Betrieb. Dabei wirken zwei Ebenen zusammen: Anycast und verteilte Edge-PoPs halten den öffentlichen Zugang verfügbar, während Backend-Failover den Datenverkehr innerhalb der verfügbaren Anwendungsinfrastruktur steuert. Die Qualität dieser Architektur hängt deshalb weniger von einem einzelnen Failover-Schalter ab als von der Fehlererkennung, der Auswahl geeigneter Ziele und dem Umgang mit bestehenden Verbindungen.
1. Anycast verteilt den Eingang, nicht automatisch die Anwendung
Bei Anycast wird dieselbe IP-Adresse von mehreren geografisch verteilten Netzwerkknoten angekündigt. Das Routing im Internet führt Pakete typischerweise zu einem aus Netzwerksicht geeigneten erreichbaren PoP. Dadurch existiert kein einzelner öffentlicher Einstiegspunkt, dessen Ausfall den gesamten Traffic blockieren muss. Eine verteilte Edge kann den Zugang damit robuster gegen Ausfälle einzelner Standorte oder Netzwerkpfade gestalten.
Anycast löst jedoch nicht die Frage, ob das dahinterliegende Backend verfügbar ist. Ein Edge-PoP kann erreichbar sein, während eine Anwendung, ein Cluster oder ein einzelner Service Fehler liefert. Ebenso kann ein Backend nur für bestimmte Protokolle oder Pfade gestört sein. Hochverfügbarkeit erfordert deshalb eine zweite Entscheidungsebene: Die Edge muss für neue Verbindungen ein gesundes Backend auswählen. Bei ayedo bildet die Anycast-basierte Edge mit mehreren verteilten PoPs und Aktiv-Aktiv-Prinzip die Eingangsebene; das Backend-Failover entscheidet anschließend über die erreichbaren Anwendungsziele.
2. Health Checks sind die Grundlage für Backend-Failover
Backend-Failover beginnt mit der Frage, wann ein Ziel als nicht verfügbar gilt. Ein einfacher TCP-Check bestätigt lediglich, dass ein Port erreichbar ist. Für HTTP- oder HTTPS-Anwendungen kann zusätzlich relevant sein, ob ein definierter Endpunkt den erwarteten Status liefert. Ein zu oberflächlicher Check lässt fehlerhafte Backends im Pool; ein zu strenger Check entfernt funktionierende Ziele unnötig aus dem Routing.
Entscheidend ist außerdem die zeitliche Bewertung. Einzelne Paketverluste oder kurze Antwortverzögerungen dürfen nicht sofort zu einer instabilen Umschaltung führen. Umgekehrt darf die Erkennung eines tatsächlichen Ausfalls nicht so lange dauern, dass weitere Requests auf ein defektes Ziel treffen. Health Checks sollten daher zur Anwendung, zum Protokoll und zur Fehlerdomäne passen. Sie müssen außerdem zwischen Erreichbarkeit und Dienstfähigkeit unterscheiden. Für die ayedo Edge Cloud sind Backend Health Checks und Failover zentrale Bausteine, um Traffic dynamisch an verfügbare Ziele weiterzuleiten.
3. Aktiv-Aktiv verändert die Failover-Logik
Im Aktiv-Aktiv-Betrieb sind mehrere Backends gleichzeitig für Traffic vorgesehen. Failover bedeutet dann nicht primär, von einem aktiven auf einen passiven Server umzuschalten. Stattdessen wird die Menge der verfügbaren Ziele dynamisch angepasst: Ein gesundes Backend bleibt im Pool, ein fehlerhaftes wird für neue Verbindungen nicht mehr berücksichtigt. Der Traffic verteilt sich auf die verbleibenden Ziele, sofern diese die Last aufnehmen können.
Das reduziert die Abhängigkeit von einem definierten Primärpfad, stellt aber höhere Anforderungen an die Anwendung. Zustände müssen entweder repliziert, extern gehalten oder so behandelt werden, dass Requests zwischen Backends wechseln können. Auch Datenbankverbindungen, Sessions und lang laufende Streams benötigen eine eigene Betrachtung. Health Checks beeinflussen meist vor allem neue Verbindungen; bereits bestehende Sessions können bei einem Backend-Ausfall trotzdem abbrechen. Aktiv-Aktiv ist daher keine automatische Reparatur für zustandsbehaftete Workloads, sondern eine Architekturentscheidung mit Konsequenzen für Datenhaltung, Kapazitätsplanung und Fehlerbehandlung.
4. Fehlerdomänen und Betriebsgrenzen müssen getrennt betrachtet werden
Ein Backend-Ausfall, ein Edge-PoP-Ausfall und ein Fehler im Upstream-Routing sind unterschiedliche Ereignisse. Backend-Failover kann ein nicht erreichbares Anwendungsziel aus dem Pool entfernen. Es kann aber nicht jede Störung kompensieren, etwa wenn alle Backends betroffen sind oder eine gemeinsame Datenabhängigkeit ausfällt. Umgekehrt kann Anycast den Traffic zu einem anderen Edge-PoP führen, ohne dass das Backend selbst gewechselt wird.
Für den Betrieb ist diese Trennung wichtig. Monitoring und Incident Response müssen erkennen lassen, ob der Fehler am öffentlichen Eingang, an der Verbindung zur Anwendung oder im Backend selbst liegt. Eine verteilte Aktiv-Aktiv-Architektur braucht deshalb Kapazitätsreserven, konsistente Konfigurationen und nachvollziehbare Health-Check-Signale. Die eigene Netzwerk-Infrastruktur und das eigene Autonomous System der ayedo Edge Cloud sind in diesem Zusammenhang relevant, weil die Edge als zusammenhängende, verteilte Eingangsschicht betrieben wird. Sie ersetzen jedoch keine resiliente Backend-Architektur.
Praxis- und Betriebsszenario
Ein Unternehmen betreibt eine API in zwei Kubernetes-Clustern bei unterschiedlichen Providern. Beide Cluster sind aktiv und über die Edge erreichbar. Ein Health Check erkennt, dass der API-Service in einem Cluster zwar TCP-Verbindungen annimmt, aber den definierten HTTP-Endpunkt nicht mehr erfolgreich beantwortet. Die Edge berücksichtigt dieses Ziel für neue Verbindungen nicht weiter und verteilt den Traffic auf das verbleibende Backend. Der öffentliche DNS- oder Anycast-Einstieg bleibt unverändert. Gleichzeitig müssen Betreiber prüfen, ob das verbleibende Cluster ausreichend Kapazität besitzt und ob laufende Verbindungen kontrolliert beendet werden. Nach der Wiederherstellung darf das Backend nicht allein aufgrund eines einzelnen erfolgreichen Checks sofort wieder vollständig belastet werden.
FAQ
Ist Anycast allein ein Aktiv-Aktiv-Failover?
Nein. Anycast verteilt den öffentlichen Zugang auf erreichbare Edge-PoPs. Aktiv-Aktiv-Failover benötigt zusätzlich Health Checks und eine dynamische Auswahl gesunder Backends.
Was passiert mit bestehenden Verbindungen?
Das hängt vom Protokoll und vom Fehler ab. Backend-Failover wirkt typischerweise auf neue Verbindungen. Bestehende Sessions können bei einem Backend-Ausfall abbrechen und müssen gegebenenfalls durch die Anwendung wiederaufgebaut werden.
Kann Backend-Failover Datenbankausfälle kompensieren?
Nein. Es kann Traffic von fehlerhaften Anwendungszielen fernhalten. Gemeinsame Datenbanken, Replikation und Zustandskonsistenz bleiben separate Anforderungen der Anwendung und ihrer Infrastruktur.
Fazit
Hochverfügbarkeit entsteht zwischen Edge und Compute, nicht ausschließlich an einer dieser Ebenen. Anycast und verteilte PoPs halten den öffentlichen Zugang belastbarer; Health Checks und Backend-Failover sorgen dafür, dass neue Verbindungen verfügbare Anwendungsziele erreichen. Das Aktiv-Aktiv-Prinzip vermeidet einen einzelnen Primärpfad, verlangt aber konsistente Backends und ausreichende Reserven. Die ayedo Edge Cloud ordnet diese Funktionen in einer eigenen, verteilten Edge-Infrastruktur ein – unabhängig davon, wo die Kubernetes- oder sonstigen Backends betrieben werden.