Aktiv-Aktiv statt Cold Standby: Edge-HA erklärt

TL;DR

Beim Aktiv-Aktiv-Betrieb verarbeiten mehrere Edge-Instanzen dauerhaft produktiven Traffic. Fällt ein Standort oder Verarbeitungspfad aus, wird der Traffic auf verbleibende Ressourcen verteilt. Cold Standby aktiviert eine Reserve erst im Fehlerfall und muss deshalb Umschaltung, Kapazität und Betriebszustand zusätzlich beherrschen.

Ein Cold-Standby-Modell wirkt auf den ersten Blick effizient: Eine Reserve-Infrastruktur steht bereit, verursacht aber im Normalbetrieb möglichst wenig Aufwand. Für die Hochverfügbarkeit am öffentlichen Anwendungseingang entsteht dadurch ein zusätzlicher Betriebsprozess. Die Reserve muss im Fehlerfall erreichbar, ausreichend dimensioniert, korrekt konfiguriert und schnell aktivierbar sein. Gleichzeitig muss das Routing den Ausfall erkennen und den Traffic umleiten.

Aktiv-Aktiv verfolgt einen anderen Ansatz. Mehrere Edge-Ressourcen sind gleichzeitig produktiv und teilen sich den eingehenden Traffic. Hochverfügbarkeit entsteht nicht durch eine ungenutzte Ersatzumgebung, sondern durch verteilte Verarbeitungskapazität und die Fähigkeit, den Traffic bei Ausfällen neu zu verteilen.

Aktiv-Aktiv und Cold Standby im Architekturvergleich

Bei Cold Standby verarbeitet eine primäre Umgebung den Traffic. Die Reserve ist während des Normalbetriebs entweder abgeschaltet oder nicht in den aktiven Datenpfad eingebunden. Ein Failover muss daher mehrere Schritte koordinieren: Fehlererkennung, Aktivierung der Reserve, Aktualisierung des Routings und gegebenenfalls das Bereitstellen aktueller Konfigurationen.

Im Aktiv-Aktiv-Betrieb sind mehrere Edge-Ressourcen bereits Teil der produktiven Architektur. Anycast kann Anfragen an verfügbare Edge-Standorte lenken, während Loadbalancing die Verteilung innerhalb der Plattform übernimmt. Die einzelnen Ressourcen sind nicht lediglich Ersatz, sondern tragen kontinuierlich zur Verarbeitung bei.

Der Unterschied liegt damit nicht nur in der Umschaltlogik. Cold Standby verschiebt einen Teil des Risikos in den Fehlerfall. Aktiv-Aktiv verteilt den Betriebsaufwand über den Normalbetrieb und reduziert die Abhängigkeit von einer einzelnen Aktivierungsprozedur. Dafür müssen Zustände, Konfigurationen und Kapazitätsgrenzen über die aktiven Pfade hinweg konsistent betrieben werden.

Traffic-Verteilung und Failover an der Edge

Edge-Hochverfügbarkeit beginnt mit der Frage, wie ein Ausfall erkannt wird. Backend Health Checks prüfen, ob nachgelagerte Anwendungen erreichbar und funktionsfähig sind. Für die Edge selbst sind verfügbare Verarbeitungspfade, Routing-Informationen und die Erreichbarkeit der jeweiligen Ressourcen entscheidend. Fällt ein Pfad aus, darf der Traffic nicht weiter dorthin verteilt werden.

In einer Anycast-Architektur kündigen mehrere Edge-Standorte dieselbe öffentliche Erreichbarkeit an. Das Routing kann Anfragen dadurch zu einem anderen verfügbaren Standort führen, wenn ein Standort oder ein Netzwerkpfad nicht mehr erreichbar ist. Innerhalb der Edge übernehmen Layer-4- und Layer-7-Loadbalancing die weitere Verteilung.

Cold Standby benötigt dagegen eine explizite Aktivierung oder Umschaltung. Je nach Mechanismus können DNS-TTLs, Routing-Konvergenz oder die Initialisierung der Reserve die Wiederherstellungszeit beeinflussen. Failover ist dann ein Ablauf mit mehreren Abhängigkeiten. Aktiv-Aktiv beseitigt nicht jeden Fehler, verkürzt aber die Strecke zwischen Fehlererkennung und Weiterverarbeitung, weil die Zielressourcen bereits aktiv sind.

Auslastung, Kapazität und Betriebskosten

Der wichtigste wirtschaftliche Unterschied betrifft die Nutzung der bereitgestellten Ressourcen. Im Cold-Standby-Modell bleibt ein Teil der Infrastruktur im Normalbetrieb ungenutzt. Das kann sinnvoll sein, wenn die Reserve nur für seltene Ausfälle benötigt wird. Gleichzeitig bezahlt das Unternehmen für Redundanz, ohne aus ihr laufenden Durchsatz zu gewinnen.

Aktiv-Aktiv verteilt den produktiven Traffic auf mehrere Ressourcen. Dadurch wird vorhandene Kapazität besser genutzt, und Lastspitzen können sich auf mehrere Verarbeitungspfade verteilen. Die Dimensionierung muss jedoch nicht nur den Normalbetrieb abdecken. Fällt ein Standort aus, müssen die verbleibenden Ressourcen den zusätzlichen Traffic zumindest innerhalb der geplanten Grenzen verarbeiten können.

Das verändert auch die Betriebsaufgaben. Statt eine Reserve regelmäßig auf Funktionsfähigkeit zu testen, muss ein Aktiv-Aktiv-System vor allem Verteilung, Kapazitätsreserven, Health Checks und Fehlerszenarien überwachen. Traffic- und Usage-Statistiken unterstützen dabei, reale Lastverteilungen zu bewerten. Der Betriebsaufwand verschwindet nicht; er verlagert sich von der Aktivierung einer Reserve zur kontinuierlichen Kontrolle eines verteilten Systems.

Sicherheits- und Architekturfolgen des Aktiv-Aktiv-Betriebs

Die Edge ist der öffentliche Eingang vor Anwendungen und APIs. Deshalb müssen Sicherheitsfunktionen während eines Failovers nicht erst nachgeladen oder neu aktiviert werden. TLS Termination, Web Application Firewall und DDoS Protection sollten an den aktiven Edge-Pfaden konsistent verfügbar sein. Andernfalls kann die Umschaltung zwar technisch funktionieren, aber Sicherheits- oder Routing-Eigenschaften verändern.

Backend Cloaking begrenzt zusätzlich die direkte Sichtbarkeit der eigentlichen Backends. Der Traffic wird an der Edge verarbeitet und anschließend über definierte Pfade weitergeleitet. Für Kubernetes kann die Edge Cloud dabei mit ayedo Managed Kubernetes oder mit eigenen Clustern und Clustern anderer Provider verbunden werden. Die Hochverfügbarkeit der Edge bleibt somit vom konkreten Compute-Provider getrennt.

Die ayedo Edge Cloud verbindet dafür Anycast, eine eigene Netzwerk-Infrastruktur, ein eigenes Autonomous System und eine verteilte Multi-PoP-Architektur mit einem Aktiv-Aktiv-Prinzip. Das ist kein Synonym für eine bestimmte Kubernetes -Bereitstellung. Die Edge übernimmt öffentlichen Traffic-Eingang, Schutz, Termination und Verteilung; die Compute-Infrastruktur führt die Workloads aus. Diese Trennung verhindert, dass ein einzelner Cluster oder Provider automatisch zum Maßstab für die Edge-Hochverfügbarkeit wird.

Praxisszenario: Ausfall eines Edge-Standorts

Ein Unternehmen betreibt eine API auf Kubernetes , wobei die Cluster bei einem externen Provider laufen. Der öffentliche Endpunkt liegt an der Edge. Im Cold-Standby-Modell würde ein primärer Edge-Pfad den Traffic verarbeiten. Bei dessen Ausfall müsste eine Reserve aktiviert und anschließend über DNS oder Routing erreichbar gemacht werden. Die Wiederherstellung hängt damit von mehreren zeitlich aufeinanderfolgenden Schritten ab.

Im Aktiv-Aktiv-Modell verarbeiten mehrere Edge-Standorte bereits produktive Anfragen. Fällt einer aus, wird der Traffic auf verfügbare Standorte verteilt. Die Backends bleiben dabei unverändert erreichbar; nur der öffentliche Verarbeitungspfad ändert sich. Entscheidend ist, dass die verbleibenden Ressourcen ausreichend Kapazität besitzen und die Sicherheits- sowie Routing-Konfigurationen konsistent sind.

FAQ

Ist Aktiv-Aktiv automatisch ausfallsicher?

Nein. Aktiv-Aktiv reduziert die Abhängigkeit von einer einzelnen Ressource. Es benötigt weiterhin korrekte Health Checks, ausreichende Restkapazität, konsistente Konfigurationen und getestete Fehlerannahmen.

Was ist der zentrale Nachteil von Cold Standby?

Die Reserve muss im Fehlerfall erst aktiviert und erreichbar gemacht werden. Dadurch entstehen zusätzliche Abhängigkeiten bei Routing, Initialisierung, Konfigurationsstand und Wiederanlauf.

Muss Aktiv-Aktiv auf demselben Provider betrieben werden?

Nein. Die Edge kann unabhängig von der Compute-Plattform betrieben werden. Kubernetes -Cluster können bei ayedo, im eigenen Rechenzentrum oder bei anderen Providern laufen.

Fazit

Aktiv-Aktiv ist kein reines Verteilungsmodell, sondern eine Betriebsentscheidung: Redundante Edge-Ressourcen werden dauerhaft genutzt, überwacht und in die Kapazitätsplanung einbezogen. Cold Standby kann Ressourcen im Normalbetrieb schonen, verlagert aber wesentliche Risiken in den Fehlerfall. Für Unternehmen mit verteilten Anwendungen und APIs ist deshalb entscheidend, Edge und Compute getrennt zu betrachten. Die ayedo Edge Cloud setzt diese Trennung mit einer verteilten Aktiv-Aktiv-Architektur, Anycast und eigenem Netzwerkbetrieb um.