TL;DR
Failover ist nur dann belastbar, wenn Ersatzpfade nicht von derselben Ausfallgrenze abhängen wie der Primärpfad. Backend, Cluster, Provider, Netzwerk und Edge müssen deshalb getrennt bewertet werden. Eine Multi-PoP-Architektur mit eigenem Autonomous System und Aktiv-Aktiv-Betrieb erweitert den Designraum für Hochverfügbarkeit, ersetzt aber keine saubere Abhängigkeitenanalyse.
Einleitung
Ein zweites Backend macht einen öffentlichen Dienst nicht automatisch hochverfügbar. Wenn beide Backends im selben Cluster, beim selben Provider oder hinter derselben Netzwerkabhängigkeit betrieben werden, bleibt die relevante Failure Domain unverändert. Genau deshalb muss Failover im Edge-Design von außen nach innen betrachtet werden: Welche Komponente fällt aus, welche Route bleibt erreichbar und welche Abhängigkeiten werden dabei nicht mitgerissen? Für öffentliche Services entscheidet sich Hochverfügbarkeit nicht erst in der Anwendung. DNS, Edge, Transitnetz, Provider, Cluster und Backend bilden eine Kette. Fällt ein gemeinsamer Abschnitt dieser Kette aus, versagen auch scheinbar redundante Systeme gemeinsam.
1. Failure Domains entlang des Request-Pfads
Ein Request durchläuft mehrere potenzielle Ausfallgrenzen. Auf Backend-Ebene können einzelne Instanzen, ein Service oder eine Datenbank betroffen sein. Auf Cluster-Ebene kommen Control-Plane-, Netzwerk- oder Storage-Probleme hinzu. Die Provider-Domain umfasst dagegen Infrastruktur, Stromversorgung, Routing und Betriebsprozesse eines einzelnen Cloud- oder Hosting-Anbieters.
Darüber liegt die Netzwerk-Domain: Transit, BGP-Erreichbarkeit, DNS-Auflösung oder ein zentraler Internet-Uplink können mehrere Providerpfade gleichzeitig beeinflussen. Die Edge selbst ist wiederum eine eigene Failure Domain. Ein einzelner Ingress, Loadbalancer oder PoP kann ausfallen, ohne dass Backend oder Provider gestört sind.
Diese Ebenen dürfen nicht nur als Liste dokumentiert werden. Entscheidend ist die Korrelation: Liegen mehrere Komponenten in derselben Failure Domain, ist ihre Redundanz im gemeinsamen Ausfallfall wirkungslos. Hochverfügbarkeitsdesign beginnt daher mit einer Abhängigkeitskarte, nicht mit der Anzahl bereitgestellter Backends.
2. Warum ein Ersatz-Backend oft nicht ausreicht
Ein klassischer Failover-Aufbau verteilt einen Dienst auf zwei Backends und aktiviert das zweite, wenn Health Checks beim ersten fehlschlagen. Das ist sinnvoll, deckt aber nur einen Teil des Fehlerbilds ab. Beide Backends können denselben Cluster, dieselbe Region, denselben Provider oder denselben Netzwerkpfad nutzen. Ein Ausfall oberhalb der Anwendung erreicht dann beide Ziele.
Auch die Umschaltung selbst benötigt eine funktionsfähige Steuerung. DNS-Caching, TTLs, BGP-Konvergenz, Session-Zustände und die Erreichbarkeit des Failover-Mechanismus bestimmen, wie schnell ein alternativer Pfad wirksam wird. Ein technisch vorhandenes Ersatz-Backend ist deshalb nicht gleichbedeutend mit einem nutzbaren Failover-Pfad.
Die Edge sollte Gesundheitszustände bewerten und Traffic gezielt verteilen, ohne den Fehler des Primärsystems zu vergrößern. Backend Health Checks, Failover und Backend Cloaking helfen dabei, den öffentlichen Zugang von den internen Zielsystemen zu entkoppeln. Die eigentliche Unabhängigkeit entsteht jedoch erst, wenn die Ziele und ihre vorgelagerten Abhängigkeiten bewusst über Failure Domains hinweg verteilt sind.
3. Multi-PoP, Autonomous System und Aktiv-Aktiv
Eine verteilte Multi-PoP-Architektur reduziert die Abhängigkeit von einem einzelnen Edge-Standort. Fällt ein PoP aus oder ist ein Teil des Netzes dort nicht erreichbar, können andere PoPs weiterhin Requests annehmen. Das ist architektonisch etwas anderes als ein zweiter Loadbalancer im selben Standort: Die Edge selbst wird über mehrere Betriebs- und Netzwerkbereiche verteilt.
Für die Bewertung der Netzwerk-Failure-Domain ist außerdem relevant, wer das Routing kontrolliert. Die ayedo Edge Cloud nutzt ein eigenes Autonomous System und eigene Netzwerk-Infrastruktur. Dadurch lässt sich die Edge als eigenständige Routing- und Schutzschicht betrachten, statt sie ausschließlich als Funktion eines einzelnen Compute-Providers zu modellieren. Das beseitigt keine externen Internetstörungen, reduziert aber die direkte Kopplung an eine einzelne Provider-Netzwerkarchitektur.
Das Aktiv-Aktiv-Prinzip verschiebt die Betriebslogik ebenfalls: Mehrere Edge-Pfade sind grundsätzlich gleichzeitig nutzbar, statt dass ein vollständig passiver Standby erst aktiviert werden muss. Failover wird damit zu einer Frage der Traffic-Verteilung und Gesundheitsbewertung, nicht nur zu einem manuellen Umschaltvorgang.
4. Failure Domains als Betriebs- und Kostenentscheidung
Die technische Trennung von Failure Domains hat betriebliche Konsequenzen. Werden Backends über Provider oder Cluster verteilt, steigen Integrations-, Monitoring- und Netzwerkaufwand. Werden sie dagegen nur innerhalb eines Systems repliziert, bleibt der Betrieb einfacher, aber die Resilienz gegen Provider- oder Cluster-Ausfälle begrenzt. Es gibt daher keinen universellen Redundanzgrad.
Eine belastbare Entscheidung braucht konkrete Ausfallannahmen: Soll ein einzelner Pod, ein kompletter Cluster, ein Provider oder auch die Edge selbst toleriert werden? Welche Daten dürfen zwischen Standorten verzögert synchronisiert werden? Welche Abhängigkeiten wie Identity, Datenbank oder DNS bleiben zentral? Erst daraus ergeben sich sinnvolle Failover-Pfade.
Die Edge Cloud kann zentrale Funktionen wie Anycast DNS, Layer-4- und Layer-7-Loadbalancing, TLS-Termination, DDoS-Schutz und Health-basierte Weiterleitung über eine verteilte Plattform bündeln. Für Kubernetes ist dabei nicht entscheidend, ob der Cluster von ayedo oder einem anderen Provider betrieben wird. Relevant ist, dass die öffentliche Eintrittsschicht unabhängig vom jeweiligen Compute-Betrieb geplant werden kann.
Praxisszenario: Drei Ebenen statt ein zweites Backend
Ein öffentlicher API-Dienst läuft zunächst in einem Kubernetes-Cluster bei einem Provider. Ein zweites Deployment im selben Cluster erhöht die Verfügbarkeit auf Workload-Ebene, schützt aber nicht vor einem Cluster- oder Provider-Ausfall. In einer erweiterten Architektur wird ein zweiter Cluster bei einem anderen Provider betrieben. Beide Cluster werden über die Edge veröffentlicht und durch Health Checks überwacht.
Die Edge verteilt den Traffic über mehrere PoPs und hält die Backends gegenüber dem Internet verborgen. Fällt eine Anwendung aus, wird der betroffene Pfad aus der Verteilung genommen. Bei einem Cluster- oder Provider-Ausfall bleiben Ziele in der anderen Umgebung verfügbar. Fällt ein einzelner Edge-PoP aus, übernehmen andere PoPs den Eingang. Der Mehrwert entsteht nicht durch eine einzelne Komponente, sondern durch die Trennung der Ausfallgrenzen.
FAQ
Ist Multi-Provider-Betrieb automatisch hochverfügbar?
Nein. Gemeinsame DNS-, Identity-, Datenbank- oder Netzwerkabhängigkeiten können weiterhin eine gemeinsame Failure Domain bilden. Multi-Provider-Betrieb ist nur dann wirksam, wenn diese Kopplungen ebenfalls bewertet werden.
Welche Rolle spielt das Autonomous System?
Es bildet eine eigenständige Routing-Domäne der Edge. Dadurch wird der öffentliche Zugang weniger eng an die Netzwerkinfrastruktur eines einzelnen Compute-Providers gekoppelt.
Muss jedes Backend aktiv genutzt werden?
Nicht zwingend. Ein passiver Standby kann betrieblich sinnvoll sein. Aktiv-Aktiv reduziert jedoch die Abhängigkeit von einem Umschaltvorgang und ermöglicht die gleichzeitige Nutzung mehrerer Edge-Pfade.
Fazit
Failure Domains sind die entscheidende Perspektive für belastbares Failover. Ein Ersatz-Backend genügt nicht, wenn Cluster, Provider, Netzwerk oder Edge dieselbe Ausfallgrenze teilen. Die Multi-PoP-Architektur, das eigene Autonomous System und der Aktiv-Aktiv-Betrieb der ayedo Edge Cloud schaffen eine eigenständige Edge-Schicht für diese Planung. Ihre Wirkung hängt jedoch davon ab, ob Unternehmen auch Compute-, Daten- und Betriebsabhängigkeiten konsequent entkoppeln.