× Install ThecoreGrid App
Tap below and select "Add to Home Screen" for full-screen experience.
B2B Engineering Insights & Architectural Teardowns

Multi-Region-HA und souveräne Fehlerdomänen

Die Multi-Region-Architektur verändert das Modell der Hochverfügbarkeit. Es geht nicht mehr um den Ausfall einer AZ, sondern um den Ausfall einer ganzen Region als einheitliche Domäne.

Bevor eine Region aufhört, eine verlässliche Ausfallgrenze zu sein, basiert das klassische High-Availability-Modell auf Multi-AZ: Ausfälle von Hardware, Netzwerk oder Rechenzentrum werden innerhalb der Region isoliert. Aber dieses Modell setzt voraus, dass eine Region nur aus technischen Gründen ausfällt und vom Anbieter verwaltet wird. Geopolitik bricht diese Annahme. Internetabschaltungen, Sanktionen, Datenübertragungsbeschränkungen oder physische Schäden an der Infrastruktur führen zu korrelierten Ausfällen (correlated failure), bei denen die gesamte Region sofort und ohne vorhersehbare Wiederherstellung nicht mehr verfügbar ist.

In diesem Kontext entsteht ein präziseres Modell — souveräne Fehlerdomäne (SFD). Dies ist eine Ausfallgrenze, die nicht durch Architektur, sondern durch Jurisdiktion, physische Infrastruktur und politischen Kontext definiert ist. Im Gegensatz zu AZ kann eine SFD nicht „entworfen“ oder kontrolliert werden. Sie existiert unabhängig vom System. Dies verändert die Fragestellung: Statt „Was passiert, wenn eine AZ ausfällt?“ stellt sich die Frage „Was passiert, wenn eine Region rechtlich oder physisch nicht mehr verfügbar ist?“. Für viele Systeme gibt es darauf einfach keine Antwort, da die Werkzeuge und Runbooks nicht darauf ausgelegt sind.

Die Lösung besteht im Übergang zu Multi-Region-Architektur als grundlegender Ebene der Fehlertoleranz für Systeme, die empfindlich auf solche Risiken reagieren. Hier gibt es die Wahl zwischen active-passive und active-active. Active-passive bietet ein einfacheres Modell und Kontrolle über die Konsistenz, erhöht jedoch die RTO aufgrund des Failovers (DNS, Gesundheitsprüfungen, Promotion von Replikaten). Active-active senkt die RTO nahezu auf null, erfordert jedoch den Umgang mit eventual consistency und kompliziert das Betriebsmodell. Dies ist ein klassischer Trade-off: Latenz und Einfachheit gegen Verfügbarkeit und Wiederherstellungsgeschwindigkeit.

Die Umsetzung stößt auf Details, die oft unterschätzt werden. Failover ist nicht eine einzige Aktion, sondern eine Kette von Verzögerungen. Zuerst die Erkennung durch Gesundheitsprüfungen, was Dutzende von Sekunden in Anspruch nehmen kann. Dann die DNS-Propagation, die von TTL und dem Verhalten der Resolver abhängt. Und schließlich die Promotion der Datenbank, bei der die Verzögerung vom Replikationsverzug abhängt. Unter realen Bedingungen wird genau die letzte Phase zur Quelle von Überraschungen. Tests mit null Verzögerung spiegeln selten das Verhalten unter Last wider.

Eine separate Schicht der Komplexität sind die Daten. Geo-verteilte Systeme machen den CAP-Trade-off auf regionaler Ebene offensichtlich. Starke Konsistenz erfordert synchrone Replikation, was die Latenz proportional zur Entfernung erhöht. Daher ist der typische Kompromiss — starke Konsistenz innerhalb der Region und eventual consistency zwischen den Regionen. Aber das funktioniert nur, wenn das System die Grenzen der Jurisdiktionen ausdrücklich berücksichtigt. Andernfalls wird die Replikation, die als Mechanismus der Zuverlässigkeit gedacht ist, zur Quelle von Compliance-Risiken.

Die praktische Umsetzung erfordert ein „Bewusstsein für Souveränität“ in der Datenebene. Dies kann durch die Möglichkeiten der DBMS (z. B. Platzierungsrichtlinien oder Lokalitätsbeschränkungen) oder auf Anwendungsebene durch die Routenführung von Datensätzen unter Berücksichtigung des Jurisdiktions-Tags erfolgen. Die Schlüsselidee ist — ein Datensatz muss innerhalb seiner Jurisdiktion bestätigt werden, nicht in einem abstrakten „globalen“ System. Systeme, die diese Ebenen nicht unterscheiden, haben in der Regel Probleme im Moment des Vorfalls und nicht in der Entwurfsphase.

Das Ergebnis eines solchen Wandels ist ein realistischeres Modell von Ausfällen. Multi-AZ ist nicht mehr die ausreichende Antwort auf die Frage nach Hochverfügbarkeit in globalen Systemen. Multi-Region wird notwendig, aber damit steigen die Kosten, die Komplexität und die Anforderungen an die Konsistenz. Die Gewinnmetriken hängen von der Umsetzung ab und sind im Ausgangsmaterial nicht angegeben, aber qualitativ ändert sich das Wesentliche: Das System beginnt, den Ausfall einer Region als normales Szenario zu betrachten und nicht als Ausnahme.

Lesen

×

🚀 Deploy the Blocks

Controls: ← → to move, ↑ to rotate, ↓ to drop.
Mobile: use buttons below.