Failure Domains in verteilten Edge-Architekturen

TL;DR

Eine Multi-PoP-Architektur reduziert Ausfälle nicht automatisch. Entscheidend ist, welche Komponenten, Leitungen, Routingpfade und Backends dieselbe Failure Domain teilen. Wer Fehlergrenzen statt Einzelkomponenten analysiert, erkennt gemeinsame Abhängigkeiten früher und kann Traffic, Schutzfunktionen und Failover gezielt entkoppeln.

Einleitung

Ein zusätzlicher Point of Presence erhöht die Verfügbarkeit nur dann, wenn ein Fehler nicht gleichzeitig mehrere Standorte oder zentrale Abhängigkeiten erreicht. Genau hier liegt ein häufiger Architekturfehler: Unternehmen zählen PoPs, Loadbalancer oder Backend-Instanzen, bewerten aber nicht, welche davon an dasselbe Netzwerk, dieselbe Routingentscheidung oder denselben Ursprung gekoppelt sind. Eine belastbare Ausfallanalyse beginnt deshalb nicht bei einzelnen Komponenten, sondern bei Failure Domains . Sie untersucht, welche Teile der Architektur gemeinsam ausfallen können, wie sich Fehler ausbreiten und welche Funktionsebene den Traffic noch übernehmen kann. Das betrifft die Edge selbst, die Netzwerkanbindung, DNS, Sicherheitsfunktionen und die Backends.

1. Failure Domains sind Fehlergrenzen, keine Komponentenlisten

Eine Failure Domain umfasst alle Ressourcen, die durch eine gemeinsame Ursache beeinträchtigt werden können. Das kann ein einzelner PoP sein, aber ebenso ein Provider, ein Transitpfad, eine Routingkonfiguration, eine DNS-Abhängigkeit oder ein gemeinsam genutztes Backend. Zwei Loadbalancer in getrennten Racks bilden daher nicht automatisch zwei unabhängige Fehlergrenzen, wenn sie dieselbe Stromversorgung, dasselbe Netzwerksegment oder denselben Upstream nutzen.

Für eine Multi-PoP-Architektur ist diese Unterscheidung zentral. Die relevante Frage lautet nicht: „Wie viele Standorte gibt es?“ Sondern: „Welche Fehler können mehrere Standorte gleichzeitig erreichen?“ Daraus entstehen Ebenen der Analyse: physischer Standort, Netzwerkpfad, Routing und DNS, Edge-Funktion sowie Backend. Jede Ebene benötigt eigene Annahmen über Ausfall, Erkennung und Wiederherstellung. Erst daraus lässt sich ableiten, ob Aktiv-Aktiv-Betrieb tatsächlich Fehler isoliert oder lediglich Kapazität verteilt.

2. Gemeinsame Abhängigkeiten zwischen Edge und Netzwerk

Die Edge kann Traffic nur verarbeiten, wenn sie erreichbar ist und Routingentscheidungen den Traffic zu funktionsfähigen Instanzen führen. Anycast reduziert dabei die Abhängigkeit von einem einzelnen Einstiegspunkt, beseitigt aber nicht jede gemeinsame Ursache. Routing, Upstream-Konnektivität, DNS und die Erreichbarkeit der einzelnen PoPs bleiben Teil derselben Ausfallanalyse.

Eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System schaffen in diesem Zusammenhang eine klarere technische Verantwortungsgrenze. Routing und Erreichbarkeit liegen stärker in einer zusammenhängenden Plattform, statt ausschließlich von der Netzwerktopologie eines einzelnen Infrastrukturproviders abzuhängen. Das ist keine vollständige Unabhängigkeit von externen Netzen: Transit- und Peering-Abhängigkeiten müssen weiterhin betrachtet werden. Der Beitrag liegt vielmehr in besserer Fehlerzuordnung, kontrollierbaren Routingpfaden und einer Architektur, in der Netzwerkredundanz bewusst gestaltet werden kann.

3. Edge-Funktionen und Backends bilden getrennte Domänen

Die Edge und die Compute-Infrastruktur erfüllen unterschiedliche Aufgaben. An der Edge werden öffentlicher Traffic angenommen, TLS terminiert, Anfragen geprüft, verteilt und bei Bedarf durch DDoS-Scrubbing geschützt. Die Anwendung läuft dagegen im Backend. Ein Ausfall der Edge ist deshalb ein anderer Fehler als ein Ausfall des Clusters oder der Datenbank. Beide können jedoch dieselbe Anwendung unzugänglich machen.

Backend Health Checks und Failover helfen nur, wenn tatsächlich alternative Backends verfügbar sind und deren Abhängigkeiten funktionieren. Ein zweiter Kubernetes-Cluster in einer anderen Fehlerzone isoliert beispielsweise nicht automatisch einen gemeinsamen Datenbankdienst oder eine zentrale Netzwerkverbindung. Backend Cloaking begrenzt zwar die direkte öffentliche Erreichbarkeit der Ursprünge und reduziert damit die Angriffs- und Kopplungsfläche. Es ersetzt jedoch keine Analyse der Rückwege, Kapazitäten und Zustandsabhängigkeiten zwischen Edge und Backend.

4. Fehlerisolierung muss Verhalten und Betrieb einbeziehen

Failure Domains sind nicht nur ein Infrastrukturthema. Entscheidend ist auch, wie die Plattform auf einen Fehler reagiert. Ein PoP-Ausfall kann durch Anycast und Aktiv-Aktiv-Verteilung abgefangen werden, sofern verbleibende PoPs ausreichend Kapazität besitzen und Routing sowie Health Checks den Fehler erkennen. Ein langsames oder teilweise gestörtes Backend stellt dagegen andere Anforderungen als ein harter Verbindungsabbruch. Falsche Schwellenwerte können Traffic zu einem überlasteten Ziel weiterleiten oder gesunde Backends unnötig aus dem Pool entfernen.

Deshalb sollte jede Fehlergrenze mit vier Fragen bewertet werden: Was fällt aus? Wie wird der Fehler erkannt? Welche Funktion bleibt verfügbar? Welche abhängigen Systeme werden dadurch belastet? Diese Sicht macht auch wirtschaftliche Folgen sichtbar. Eine größere Edge-Redundanz kann ihren Nutzen verlieren, wenn ein gemeinsamer Ursprung zum Engpass wird. Umgekehrt kann eine zentral betriebene Edge den Aufwand für Schutz, Routing und Failover über mehrere Backend-Umgebungen hinweg reduzieren.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine API in zwei Kubernetes-Clustern und veröffentlicht sie über mehrere Edge-PoPs. Fällt ein PoP vollständig aus, kann Anycast den Traffic zu anderen erreichbaren PoPs führen. Die Anwendung bleibt verfügbar, wenn die verbleibende Edge-Kapazität, die Backend-Anbindung und die Health Checks funktionieren.

Anders sieht es bei einer Störung des gemeinsamen Transitpfads zu beiden Clustern aus. Dann sind die PoPs zwar erreichbar, können aber keine erfolgreichen Backend-Verbindungen herstellen. Ein gutes Runbook behandelt deshalb beide Fälle getrennt: Beim PoP-Ausfall wird die Edge-Verteilung geprüft; beim Backend- oder Netzwerkausfall werden Ursprungserreichbarkeit, Failover-Ziele und deren Kapazität bewertet. Die Fehlergrenze liegt nicht dort, wo der erste Alarm erscheint.

FAQ

Ist jeder PoP eine eigene Failure Domain?

Nein. Ein PoP ist nur dann eine unabhängige Fehlergrenze, wenn gemeinsame Abhängigkeiten wie Netzwerk, Routing, Stromversorgung und zentrale Dienste ausreichend entkoppelt sind.

Welche Rolle spielt DNS bei der Ausfallanalyse?

DNS bestimmt, wie Clients den Einstiegspunkt auflösen. Anycast DNS und Multi-Provider-DNS können Abhängigkeiten verteilen, müssen aber gemeinsam mit Routing, Caching und Failover-Verhalten bewertet werden.

Verhindert Backend Cloaking Backend-Ausfälle?

Nein. Backend Cloaking schützt die Ursprünge vor direkter öffentlicher Erreichbarkeit. Verfügbarkeit erfordert zusätzlich redundante Backends, funktionierende Health Checks und belastbare Abhängigkeiten.

Fazit

Failure Domains liefern die belastbarere Perspektive auf Verfügbarkeit als eine reine Komponenten- oder PoP-Zählung. Sie zeigen, welche Fehler isoliert werden können und wo gemeinsame Abhängigkeiten weiterhin bestehen. Die ayedo Edge Cloud verbindet dafür eine verteilte Multi-PoP-Architektur, Aktiv-Aktiv-Prinzip, eigenes Autonomous System und eigene Netzwerk-Infrastruktur mit Funktionen für Routing, Schutz und Backend-Failover. Ihr technischer Wert zeigt sich vor allem dann, wenn diese Ebenen gemeinsam analysiert und betrieben werden.