TL;DR
Aktiv-Aktiv-Failover verteilt produktiven Traffic gleichzeitig auf mehrere Backends. Dadurch bleiben einzelne Ausfälle für Nutzer und Clients oft transparent. Der Preis ist zusätzlicher Aufwand: Sitzungen, Datenänderungen und Nebenwirkungen müssen über die beteiligten Instanzen hinweg konsistent oder bewusst fehlertolerant gestaltet werden.
Einleitung
Aktiv-Aktiv ist keine reine Redundanzentscheidung, sondern eine Architekturentscheidung für den gesamten Request- und Datenpfad. Mehrere Backends gleichzeitig produktiv zu nutzen, reduziert die Abhängigkeit von einer einzelnen Failure Domain. Es beseitigt jedoch nicht automatisch Ausfallrisiken: Ein Backend kann erreichbar sein, aber veraltete Daten liefern, Sitzungen verlieren oder widersprüchliche Änderungen erzeugen. Die zentrale Frage lautet deshalb nicht nur, wie Traffic verteilt wird, sondern welche Zustände verteilt werden müssen. Für öffentlich erreichbare Anwendungen und APIs entscheidet diese Trennung darüber, ob Aktiv-Aktiv-Failover tatsächlich kontinuierliche Nutzung ermöglicht oder lediglich einen komplexeren Betriebsmodus schafft.
1. Traffic-Verteilung über mehrere Failure Domains
In einer Aktiv-Aktiv-Architektur verarbeiten mehrere Backends gleichzeitig produktive Anfragen. Ein Ausfall führt nicht zwingend zu einem vollständigen Wechsel auf ein passives System; die Traffic-Verteilung kann den Anteil eines betroffenen Backends reduzieren oder es vollständig aus dem Pool entfernen. Dadurch werden Failure Domains entkoppelt, etwa einzelne Cluster, Rechenzonen, Provider oder Netzwerkpfade.
Technisch benötigt dieser Ansatz einen öffentlichen Eingang, der Erreichbarkeit und Backend-Zustand laufend bewertet. Anycast-basiertes Layer-4- und Layer-7-Loadbalancing kann Anfragen über eine verteilte Edge-Infrastruktur an verfügbare Backends leiten. Health Checks sind dabei keine Konsistenzprüfung: Sie zeigen, ob ein Dienst erreichbar und funktionsfähig genug ist, nicht ob seine Daten aktuell sind.
Die ayedo Edge Cloud übernimmt genau diese Edge-Aufgaben mit Anycast, Backend Health Checks und Failover. Sie kann damit mehrere eigene oder providerübergreifend betriebene Backends anbinden. Die eigentliche Anwendungskonsistenz bleibt jedoch Aufgabe der Backend- und Datenarchitektur.
2. Sitzungen und Zustände im Request-Pfad
Der einfachste Aktiv-Aktiv-Fall ist eine zustandslose Anwendung. Jeder Request enthält alle Informationen, die das Backend benötigt, oder greift auf einen gemeinsam verfügbaren Zustand zu. Dann kann Traffic ohne feste Bindung an eine Instanz verteilt werden. Das verbessert die Ausfalltoleranz und erleichtert Skalierung, setzt aber eine konsequente Trennung von Request-Verarbeitung und Sitzungszustand voraus.
Problematisch wird es, wenn Sessions im lokalen Speicher eines Backends liegen. Wird der nächste Request an eine andere Instanz verteilt, fehlen Authentifizierungs-, Warenkorb- oder Workflow-Daten. Sticky Sessions können dieses Problem begrenzen, verschlechtern aber die Lastverteilung und machen einen Backend-Ausfall spürbarer. Außerdem lösen sie keine Datenkonsistenz zwischen Instanzen.
Für öffentlich erreichbare APIs sind kurzlebige Tokens, idempotente Operationen und ein klar definierter gemeinsamer Zustand häufig robuster. TLS Termination an der Edge, Proxy Protocol oder Backend Cloaking können den Netzwerkpfad strukturieren und die Backends schützen. Sie ersetzen jedoch keine Entscheidung darüber, wo Sitzungsdaten liegen und wie deren Ausfall behandelt wird.
3. Datenkonsistenz als eigentliche Komplexitätsgrenze
Bei mehreren aktiven Backends ist die Datenhaltung meist der anspruchsvollste Teil. Lesen zwei Instanzen unterschiedliche Replikationsstände, entstehen sichtbare Abweichungen: Ein gerade angelegtes Objekt erscheint noch nicht, ein Statuswechsel wird überschrieben oder eine API liefert widersprüchliche Antworten. Je nach Geschäftsprozess kann das tolerierbar, fachlich kritisch oder unzulässig sein.
Vor einer Aktiv-Aktiv-Entscheidung müssen daher Konsistenzmodell und Fehlerverhalten festgelegt werden. Denkbare Anforderungen reichen von eventual consistency bis zu stärker koordinierter Verarbeitung. Schreibzugriffe können partitioniert, über definierte Leader geführt oder durch Idempotency Keys gegen Wiederholung abgesichert werden. Konfliktauflösung darf nicht implizit dem Loadbalancer überlassen werden.
Das erzeugt organisatorische und wirtschaftliche Folgen. Entwicklungsteams müssen Zustandsübergänge, Retries und Nebenläufigkeit spezifizieren; Betriebsteams benötigen Metriken für Replikationsverzug und fehlgeschlagene Synchronisation. Aktiv-Aktiv reduziert zwar die Abhängigkeit von einzelnen Infrastrukturkomponenten, kann aber den Aufwand für Datenbetrieb und Tests deutlich erhöhen.
4. Failover braucht Anwendungswissen
Ein Backend gilt nicht automatisch als gesund, nur weil ein Port antwortet. Ein oberflächlicher Health Check kann einen Prozess als verfügbar melden, obwohl Datenbankzugriffe fehlschlagen, Abhängigkeiten nicht erreichbar sind oder das Backend keine neuen Schreibvorgänge sicher verarbeiten kann. Zu aggressive Checks erzeugen dagegen unnötige Umschaltungen und zusätzliche Last.
Sinnvoll sind abgestufte Zustände: Ein Backend kann weiterhin lesen, aber keine Schreibvorgänge annehmen; es kann aus dem Traffic-Pool entfernt werden, während laufende Verbindungen auslaufen. Layer-7-Checks können anwendungsnahe Verfügbarkeit prüfen, müssen aber fachlich sorgfältig definiert sein. Failover sollte außerdem mit Retries, Timeouts und Idempotenz abgestimmt werden, damit ein erneut gesendeter Request keine doppelten Nebenwirkungen erzeugt.
Die ayedo Edge Cloud kann verfügbare Backends über Health Checks bewerten und Traffic entsprechend verteilen oder umleiten. Das schafft eine technische Grundlage für Aktiv-Aktiv-Failover, entscheidet aber nicht, ob ein Dienst fachlich sicher weiterbetrieben werden kann. Diese Verantwortung liegt bei Anwendung, Datenhaltung und Betriebsprozessen.
Praxis- und Betriebsszenario
Eine API läuft in zwei unabhängigen Kubernetes Clustern bei unterschiedlichen Providern. Beide Cluster sind aktiv und werden über die ayedo Edge Cloud veröffentlicht. Leseanfragen können auf beide Backends verteilt werden. Für Schreibvorgänge verwendet die Anwendung Idempotency Keys und ein Datenmodell, das Replikationsverzug berücksichtigt. Ein Health Check entfernt ein Backend aus dem Pool, wenn die API zwar erreichbar ist, aber keine gültigen Datenbankoperationen ausführen kann.
Ohne diese Maßnahmen würde ein reines Traffic-Failover lediglich Requests umleiten. Nutzer könnten dann zwischen unterschiedlichen Zuständen wechseln oder Schreibvorgänge mehrfach auslösen. Die Aktiv-Aktiv-Architektur reduziert also die Auswirkung eines Cluster- oder Provider-Ausfalls, verlangt aber bewusst modellierte Zustände und überprüfbare Betriebsabläufe.
FAQ
Ist Aktiv-Aktiv-Failover für jede Anwendung geeignet?
Nein. Anwendungen mit strikt zentraler, nicht replizierbarer Zustandslogik profitieren möglicherweise stärker von einem kontrollierten Aktiv-Passiv-Modell.
Sind Sticky Sessions eine ausreichende Lösung?
Nein. Sie stabilisieren Sitzungszuordnung, lösen aber weder Datenreplikation noch den Ausfall des gebundenen Backends.
Welche Rolle spielt Anycast dabei?
Anycast stellt einen verteilten öffentlichen Eingang bereit. Die konkrete Backend-Auswahl und deren Konsistenz bleiben davon getrennte Architekturaufgaben.
Fazit
Aktiv-Aktiv-Failover ist dann sinnvoll, wenn mehrere Backends kontinuierlich produktiv arbeiten sollen und Failure Domains bewusst entkoppelt werden müssen. Die entscheidende Grenze verläuft nicht beim Loadbalancing, sondern bei Sessions, Schreibvorgängen und Datenkonsistenz. Eine Edge-Plattform wie die ayedo Edge Cloud kann öffentlichen Traffic über Anycast verteilen, Backends prüfen und Failover auslösen. Ob dieser Mechanismus fachlich sicher ist, bestimmt jedoch die Architektur hinter der Edge.