TL;DR
Eine Aktiv-Aktiv-Architektur verteilt Edge-Funktionen über mehrere PoPs, statt einen Standort als passiven Ersatz vorzuhalten. Dadurch werden Failover und Wartung zu laufenden Betriebsprozessen. Für interne Plattformdienste bedeutet das: Der öffentliche Zugang, Schutzfunktionen und Routing müssen selbst ausfallsfähig sein – unabhängig davon, wo die Backends betrieben werden.
Einleitung
Hochverfügbarkeit endet nicht am Cluster- oder Rechenzentrumsrand. Ein Plattformdienst kann über mehrere Backends verfügen und trotzdem ausfallen, wenn sein zentraler Einstiegspunkt an einem einzelnen Standort, Loadbalancer oder DNS-System hängt. Genau dort entsteht ein häufig übersehener Single Point of Failure: die vorgelagerte Edge-Schicht.
Die Architekturentscheidung zwischen Aktiv-Passiv und Aktiv-Aktiv betrifft deshalb nicht nur Compute-Ressourcen. Sie bestimmt auch, wie Traffic angenommen, verteilt, geschützt und bei Störungen umgeleitet wird. Eine verteilte Multi-PoP-Architektur mit aktiv betriebenen Standorten behandelt die Edge als gemeinsamen Plattformbaustein – nicht als passiven Notfallstandort, der nur im Krisenfall relevant wird.
1. Aktiv-Aktiv beginnt vor dem Backend
Bei Aktiv-Passiv-Modellen verarbeitet normalerweise ein primärer Standort den Traffic. Ein zweiter Standort hält Ressourcen vor, übernimmt aber erst nach einer Störung. Dieses Modell kann funktionieren, wenn der Umschaltprozess zuverlässig, schnell und regelmäßig getestet ist. Es erzeugt jedoch eine zusätzliche Betriebsabhängigkeit: Der passive Pfad muss im Fehlerfall korrekt aktiviert, erreichbar und ausreichend dimensioniert sein.
Aktiv-Aktiv verteilt die Verarbeitung dagegen auf mehrere gleichzeitig genutzte PoPs. Jeder Standort ist Teil des regulären Betriebs. Fällt ein PoP oder ein Teil seines Pfads aus, kann Traffic über andere aktive Standorte verarbeitet werden. Das reduziert die Abhängigkeit von einem einzelnen Umschaltereignis.
Für Plattformdienste ist diese Unterscheidung relevant, weil der Edge-Einstieg häufig mehrere Funktionen bündelt: Anycast-L4- und L7-Loadbalancing, TLS-Terminierung, WAF, DDoS-Schutz und Routing zum Backend. Werden diese Funktionen an einem einzelnen Standort konzentriert, bleibt die Plattform trotz redundanter Backends ausfallsensibel.
2. Multi-PoP verändert das Failover-Modell
Failover ist nicht nur die Frage, wohin Traffic nach einem Ausfall geleitet wird. Entscheidend ist, wer den Ausfall erkennt, auf welcher Ebene er erkannt wird und wie der verbleibende Pfad bewertet wird. Ein DNS-Failover kann andere Fehlerbilder abdecken als ein Anycast-basiertes Routing oder ein Backend-Health-Check.
In einer Multi-PoP-Aktiv-Aktiv-Architektur greifen diese Ebenen zusammen. Die Edge nimmt Traffic verteilt an, prüft die Erreichbarkeit der Backends und kann fehlerhafte Ziele aus der Verteilung nehmen. Dadurch lässt sich zwischen einem Ausfall des PoPs, des Netzpfads und des eigentlichen Plattformdienstes unterscheiden.
Das verändert auch die Betriebsprozesse. Failover ist kein seltenes Notfallverfahren, sondern Bestandteil des Normalbetriebs. Wartungsarbeiten, Routingänderungen und Backend-Wechsel müssen so geplant werden, dass aktive Pfade kontrolliert verändert werden können. Regelmäßige Tests sind weiterhin notwendig, aber sie prüfen nicht nur einen ungenutzten Ersatzpfad, sondern das Verhalten eines kontinuierlich verteilten Systems.
3. Die Edge bleibt vom Compute getrennt
Aktiv-Aktiv auf der Edge bedeutet nicht automatisch, dass auch die Backends aktiv-aktiv betrieben werden. Ein Dienst kann hinter der Edge weiterhin in einem einzelnen Cluster, einer Region oder einem anderen Provider laufen. Die Edge erhöht in diesem Fall die Ausfallsicherheit des öffentlichen Zugangs, beseitigt aber keine Ausfälle im Backend.
Diese Trennung ist architektonisch wichtig. Edge-Funktionen übernehmen öffentlichen Traffic-Eingang, Schutz, Termination und Lastverteilung. Die Compute-Infrastruktur führt Anwendungen und Plattformkomponenten aus. Für ein belastbares Failover-Modell müssen beide Ebenen separat betrachtet werden: Was passiert bei einem PoP-Ausfall? Was bei einem nicht erreichbaren Cluster? Und welche Zustände darf ein Backend-Health-Check als funktionsfähig bewerten?
Die ayedo Edge Cloud ist für diese Trennung als verteilte Multi-PoP-Plattform ausgelegt. Ihr eigenes Autonomous System und die eigene Netzwerk-Infrastruktur bilden dabei den Rahmen für den Edge-Betrieb. Die Backends können in ayedo Managed Kubernetes, in eigenen Clustern oder bei anderen Providern betrieben werden. Damit bleibt die Edge-Architektur vom gewählten Compute-Standort entkoppelt.
4. Hochverfügbarkeit erzeugt betriebliche Pflichten
Eine Aktiv-Aktiv-Architektur reduziert einzelne Ausfallrisiken, macht den Betrieb aber nicht automatisch einfacher. Mehrere aktive Pfade bedeuten mehr Zustände, die beobachtet und bewertet werden müssen. Routing, Health Checks, TLS-Konfigurationen, WAF-Regeln und Backend-Zuordnungen müssen konsistent gepflegt werden.
Besonders kritisch ist die Definition von „gesund“. Ein erreichbarer Port beweist nicht, dass ein Plattformdienst nutzbar ist. Health Checks müssen zur jeweiligen Service-Semantik passen und dürfen bei kurzzeitigen Fehlern nicht zu instabilen Umschaltungen führen. Gleichzeitig muss ein tatsächlich fehlerhaftes Backend schnell aus dem Traffic genommen werden.
Für Unternehmen entstehen daraus organisatorische Konsequenzen: Netzwerk-, Plattform- und Anwendungsteams müssen gemeinsame Fehlerbilder definieren. Runbooks sollten nicht nur den Ausfall eines Clusters, sondern auch PoP-, DNS- und Routing-Szenarien abdecken. Die Aktiv-Aktiv-Architektur ist somit weniger ein einzelnes Feature als ein Betriebsmodell, das technische Zuständigkeiten und Tests über mehrere Ebenen hinweg verbindet.
Praxis- und Betriebsszenario
Ein Unternehmen betreibt eine interne Entwicklerplattform mit API-Zugang, Benutzeroberfläche und Automatisierungsdiensten. Die Workloads laufen in zwei Kubernetes Clustern bei unterschiedlichen Providern. In einem Aktiv-Passiv-Modell führt ein zentraler Standort den gesamten Edge-Traffic; der Ersatzpfad wird nur bei einem größeren Ausfall aktiviert.
Bei einer Aktiv-Aktiv-Architektur wird der Traffic über mehrere Edge-PoPs angenommen. Ein Backend-Health-Check erkennt, dass ein Cluster den Plattformdienst nicht mehr zuverlässig bereitstellt, und nimmt dieses Ziel aus der Verteilung. Fällt zusätzlich ein Edge-PoP aus, bleibt der Zugang über andere aktive PoPs bestehen. Die Anwendung muss dafür nicht am selben Ort wie die Edge betrieben werden. Das Failover verteilt sich auf mehrere Ebenen, statt an einer einzelnen Umschaltung zu hängen.
FAQ
Ist Aktiv-Aktiv dasselbe wie zwei aktive Kubernetes-Cluster?
Nein. Aktiv-Aktiv kann zunächst die Edge betreffen. Ob mehrere Backends gleichzeitig produktiv genutzt werden, hängt von Anwendung, Datenmodell und Betriebsstrategie ab.
Ersetzt Anycast jeden Failover-Mechanismus?
Nein. Anycast verteilt den Zugang, ersetzt aber weder Backend-Health-Checks noch anwendungsspezifische Fehlererkennung und geeignete Routingregeln.
Wann reicht Aktiv-Passiv aus?
Aktiv-Passiv kann genügen, wenn Umschaltung, Kapazität und Datenkonsistenz beherrscht sowie regelmäßig getestet werden. Die Edge bleibt dabei dennoch ein eigener Ausfallbereich.
Fazit
Hochverfügbarkeit ist unvollständig, wenn nur die Compute-Ebene redundant ausgelegt wird. Ein einzelner Edge-Standort kann trotz mehrerer Cluster zum gemeinsamen Ausfallpunkt werden. Die Aktiv-Aktiv- und Multi-PoP-Architektur der ayedo Edge Cloud ordnet den öffentlichen Zugang, Schutz und das Failover als eigenständige Plattformschicht ein. Entscheidend bleibt, Edge und Compute getrennt zu planen und ihre Fehler- und Betriebsmodelle bewusst miteinander zu verbinden.