Aktiv-Aktiv-Architektur für souveränen Edge-Betrieb

TL;DR

Eine Aktiv-Aktiv-Architektur verteilt den öffentlichen Traffic-Eintritt auf mehrere gleichzeitig aktive Standorte. Dadurch entfällt der einzelne aktive Eintrittspunkt als zentrale Ausfallannahme. Der Ansatz erhöht jedoch die Anforderungen an Anycast-Routing, Health Checks, Failover und Betriebsprozesse. Souveränität bedeutet dabei vor allem: Unternehmen kontrollieren Netzwerk, Routinglogik und Ausfallverhalten selbst.

Einleitung

Ein einzelner aktiver Edge-Standort ist kein neutraler Architekturbaustein. Fällt seine Anbindung, seine Routing-Instanz oder ein zentraler Dienst aus, kann der öffentliche Zugang zu ansonsten verfügbaren Backends unterbrochen werden. Ein redundanter Standby-Standort reduziert dieses Risiko, bleibt aber auf einen kontrollierten Umschaltvorgang angewiesen. Die Aktiv-Aktiv-Architektur verfolgt einen anderen Ansatz: Mehrere Standorte nehmen Traffic gleichzeitig an und teilen sich die Verantwortung für den Eintritt in die Plattform . Damit steigt die Hochverfügbarkeit, aber auch die technische Verantwortung für Routing, Zustandsbewertung und Failover. Wer den öffentlichen Traffic-Eintritt selbst kontrollieren will, muss diese Mechanismen als zusammenhängenden Betriebsprozess betrachten.

1. Aktiv-Aktiv reduziert zentrale Eintrittspunkte

Bei einer Aktiv-Passiv-Architektur verarbeitet ein primärer Standort den Traffic. Ein zweiter Standort wartet auf eine Aktivierung oder übernimmt erst nach einer manuellen beziehungsweise automatisierten Umschaltung. Dieses Modell kann funktionieren, erzeugt aber eine klare Abhängigkeit: Der primäre Standort ist bis zum Failover der zentrale Eintrittspunkt.

Eine Aktiv-Aktiv-Architektur verteilt diese Rolle auf mehrere gleichzeitig aktive Edge-Standorte. Anycast-Routing kann Anfragen an den aus Netzwerksicht geeigneten Standort führen, ohne dass Clients einen einzelnen festen Endpoint kennen müssen. Fällt ein Standort aus, kann der Traffic über die verbleibenden aktiven Standorte verarbeitet werden.

Der Vorteil ist nicht nur technische Redundanz. Mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System liegt die Kontrolle über den öffentlichen Eintritt, die Routing-Entscheidungen und die Rücknahme nicht verfügbarer Pfade beim Plattformbetreiber. Das ist ein konkretes Merkmal digitaler Souveränität. Es bedeutet jedoch nicht, dass Ausfälle verschwinden: Die Architektur verlagert die Verantwortung von einem zentralen Standort auf verteilte Routing- und Betriebsprozesse.

2. Routing muss Verfügbarkeit tatsächlich abbilden

Anycast allein erzeugt keine Hochverfügbarkeit. Es verteilt Traffic zunächst anhand netzwerktechnischer Kriterien wie BGP-Pfaden und Erreichbarkeit. Ob ein Standort auch in der Lage ist, eine Anwendung sinnvoll zu bedienen, muss durch zusätzliche Zustandsinformationen bewertet werden.

Dafür müssen Routing und Health Checks zusammenwirken. Ein Health Check kann beispielsweise prüfen, ob ein Edge-Dienst erreichbar ist, ob ein Backend antwortet oder ob eine definierte Anwendungskomponente einen funktionsfähigen Zustand meldet. Entscheidend ist die Wahl der Prüfebene: Ein erreichbarer Proxy bedeutet nicht automatisch, dass die dahinterliegende Anwendung gesund ist.

Zu aggressive Prüfungen können funktionierende Standorte aus dem Routing nehmen und dadurch unnötige Umschaltungen auslösen. Zu großzügige Prüfungen lassen dagegen fehlerhafte Pfade aktiv. Für die Betriebsstabilität brauchen Unternehmen deshalb klare Kriterien für Fehlererkennung, Zeitverhalten und Wiederaufnahme. Ein Aktiv-Aktiv-Design ist nur dann belastbar, wenn Routingentscheidungen den tatsächlichen Servicezustand möglichst präzise abbilden.

3. Failover ist ein verteiltes Betriebsproblem

Failover wird häufig als einzelne Umschaltaktion verstanden. In einer verteilten Aktiv-Aktiv-Architektur ist es jedoch eine Kette voneinander abhängiger Entscheidungen. Ein Standort kann ausfallen, während seine Netzwerkverbindung noch aktiv ist. Ein Backend kann nur teilweise erreichbar sein. Oder ein Fehler betrifft ausschließlich eine Anwendungsschicht, während Layer 4 weiterhin antwortet.

Daraus entstehen unterschiedliche Failover-Szenarien für Layer 4 und Layer 7. Die Edge muss entscheiden, ob sie neue Verbindungen an einen anderen Standort lenkt, bestehende Sessions auslaufen lässt oder Anfragen auf ein anderes Backend verteilt. Bei zustandsbehafteten Anwendungen können Session-Bindings, Wiederholungen und Timeout-Verhalten die Umschaltung zusätzlich beeinflussen.

Health Checks und Failover-Regeln müssen deshalb gemeinsam getestet werden. Relevant sind nicht nur vollständige Standortausfälle, sondern auch fehlerhafte Routen, degradierte Backends und verzögerte Wiederherstellung. Die Aktiv-Aktiv-Architektur reduziert die Abhängigkeit von einem Standort, erhöht aber die Anforderungen an Runbooks, Monitoring, Änderungsprozesse und regelmäßige Ausfalltests.

4. Souveränität umfasst auch den Betrieb

Eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System schaffen die Grundlage, um den öffentlichen Traffic-Eintritt unabhängig von einem einzelnen Infrastrukturprovider zu steuern. Diese Unabhängigkeit ist architektonisch wertvoll, wenn Routing, Schutzfunktionen und Failover nicht vollständig an die Infrastruktur eines einzelnen Anbieters gekoppelt sein sollen.

Sie bringt aber zusätzliche Betriebsverantwortung mit sich. Routingänderungen müssen nachvollziehbar sein. Health-Check-Fehler brauchen eine eindeutige Interpretation. Failover darf nicht durch widersprüchliche Zustände zwischen mehreren Standorten instabil werden. Auch die Rückkehr eines Standorts in den aktiven Betrieb muss kontrolliert erfolgen, damit kein sogenanntes Flapping entsteht.

Eine Plattform wie die ayedo Edge Cloud verbindet dafür verteilte Multi-PoP-Infrastruktur, eigenes Netzwerk und Aktiv-Aktiv-Betrieb mit Funktionen für Anycast-Loadbalancing , Health Checks und Failover. Der relevante Punkt ist nicht die einzelne Funktion, sondern deren Zusammenspiel am öffentlichen Eingang vor Anwendungen und APIs. Die Backends können dabei in ayedo Managed Kubernetes, in eigenen Clustern oder bei anderen Providern betrieben werden.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine API in zwei Rechenzentren und möchte keinen Standort als primären öffentlichen Eingang festlegen. Beide Standorte sind über eine Aktiv-Aktiv-Edge erreichbar. Anycast-Routing verteilt neue Verbindungen, während Health Checks die Erreichbarkeit der Edge- und Backend-Komponenten bewerten.

Fällt die Backend-Anbindung eines Standorts aus, bleibt dessen Netzwerkpfad möglicherweise weiterhin sichtbar. Ohne anwendungsnahe Health Checks würde der Standort deshalb weiterhin Traffic erhalten. Mit abgestimmten Prüfungen kann die Edge den fehlerhaften Pfad aus der Verteilung nehmen. Nach der Reparatur darf die Wiederaufnahme nicht allein durch das Wiedererscheinen einer Route erfolgen, sondern sollte den geprüften Servicezustand berücksichtigen. Der Mehraufwand liegt damit weniger in der zweiten Leitung als in der kontrollierten Zustands- und Änderungslogik.

FAQ

Ist Aktiv-Aktiv immer verfügbarer als Aktiv-Passiv?

Nein. Aktiv-Aktiv reduziert zentrale Eintrittspunkte, erfordert aber präzise Zustandsbewertung und getestetes Failover. Fehlkonfigurierte Health Checks oder instabiles Routing können die Verfügbarkeit sogar verschlechtern.

Welche Rolle spielt Anycast im Failover?

Anycast ermöglicht, dass mehrere Standorte dieselbe öffentliche Erreichbarkeit anbieten. Die eigentliche Ausfallsteuerung entsteht erst durch die Kombination aus Routing, Health Checks und Regeln zur Entfernung fehlerhafter Standorte.

Macht eigene Netzwerkinfrastruktur automatisch souverän?

Nein. Sie schafft technische Kontrollmöglichkeiten über Routing und Traffic-Eintritt. Souveränität hängt zusätzlich von Betriebsprozessen, Abhängigkeiten, Zuständigkeiten und der Fähigkeit ab, Ausfälle kontrolliert zu behandeln.

Fazit

Eine Aktiv-Aktiv-Architektur für den Edge-Betrieb ist vor allem eine Entscheidung über Kontrolle und Betriebsverantwortung. Sie reduziert die Abhängigkeit von einem einzelnen aktiven Standort, verlangt dafür aber belastbare Verfahren für Routing, Health Checks und Failover. Für Unternehmen mit hohen Anforderungen an öffentlichen Traffic-Eintritt und digitale Souveränität ist die ayedo Edge Cloud relevant, wenn diese Funktionen über eigene Netzwerk-Infrastruktur und verteilte, gleichzeitig aktive Standorte zusammengeführt werden.