Am 1. März wurde eine Availability Zone in der AWS-Region me-central-1, mec1-az2, von dem getroffen, was AWS als "objects that struck the data center, creating sparks and fire" beschrieb. Rund achtzehn Stunden später verlor eine zweite Zone, mec1-az3, ebenfalls Strom. Die dritte, mec1-az1, blieb durchgehend oben. Mit zwei von drei beeinträchtigten Zonen begannen S3 und DynamoDB regionsweit auszufallen, und der Rat von AWS an die Kunden lautete, in eigenen Worten auf dem Health Dashboard, sie sollten "enact their disaster recovery plans and recover from remote backups into alternate AWS Regions, ideally in Europe". Die Unabhängigkeit von Availability Zones ist gegen Stromfehler, Kühlungsfehler und Netzwerkfehler ausgelegt. Im März traf sie auf eine Ursache, gegen die sie nie ausgelegt war, und die Ursache scherte sich nicht um die Technik.

Dies ist Teil 2 von Nothing Fails Alone. Teil 1 untersuchte den us-east-1 Incident im Mai und argumentierte, dass die Zonengrenze hielt, und das tat sie: Ein Kühlungsausfall in einem Datensaal blieb innerhalb einer Zone, genau wie entworfen, und der darauf folgende Ausfall wurde vom Kunden gebaut. Dieses Argument war korrekt, und es beantwortete eine bestimmte Frage: Fängt AZ-Isolation die Failure Modes ab, gegen die sie ausgelegt ist? Das März-Ereignis in me-central-1 stellt eine andere Frage. Es geschah, bevor Teil 1 geschrieben wurde, und zu dieser Zeit war es leicht, es als Kriegs-Sonderfall abzulegen, eine Kriegsakt-Fußnote ohne Lehren für normale Architektur. Der Mai-Incident machte die allgemeine Form sichtbar: In Teil 1 ging es darum, was die Zonengrenze schützt, und in diesem Teil geht es darum, was sie nicht schützen kann, nämlich jede Ursache, die mehr als eine Zone erreicht. Diese Ursachen existieren auch in Friedenszeiten. Der Krieg hat die Demonstration nur auf zwei Tage komprimiert.

Was in me-central-1 tatsächlich geschah

Das Ereignis öffnete auf dem AWS Health Dashboard um 4:51 AM PST am 1. März als Untersuchung von "issues with AWS services in the ME-CENTRAL-1 Region", schnell eingegrenzt auf ein "localized power issue" in einer einzelnen Availability Zone, mec1-az2. Das Dashboard-Log ist ungewöhnlich offen, und um 9:41 AM PST erklärte es, warum der Strom weg war: "At around 4:30 AM PST, one of our Availability Zones (mec1-az2) was impacted by objects that struck the data center, creating sparks and fire. The fire department shut off power to the facility and generators as they worked to put out the fire." Am nächsten Tag benannte AWS die Ursache, in einem Update, das The Register am selben Tag behandelte: Drohnenangriffe, Teil des Konflikts im Nahen Osten. "In the UAE, two of our facilities were directly struck", und die Angriffe "caused structural damage, disrupted power delivery to our infrastructure, and in some cases required fire suppression activities that resulted in additional water damage".

Den ersten Tag über sah der Incident wie ein Lehrbuch-Einzelzonen-Ereignis aus, und AWS sagte das im selben 9:41 AM Update: "Customers who were running their applications redundantly across the AZs are not impacted by this event." Multi-AZ war zu dieser Stunde die richtige und ausreichende Antwort, und ein Update weniger als eine Stunde zuvor hatte eine Einschränkung getragen, die du schon gelesen hast, wenn du Teil 1 gelesen hast: aufgrund erhöhter Nachfrage in den nicht betroffenen Zonen "customers may experience longer than usual provisioning times". Dieselbe Formulierung, die AWS während des us-east-1 Ereignisses im Mai veröffentlichen würde, dem Incident, den Teil 1 vor zwei Wochen behandelte, obwohl im Kalender der März zuerst kam. Massen-Failover in überlebende Zonen ist überall ein Thundering Herd, in jeder Region, in jedem Incident.

Dann, um 10:46 PM PST, rund achtzehn Stunden nach dem ersten Angriff: "a localized power issue has affected another Availability Zone in the ME-CENTRAL-1 Region (mec1-az3) ... At this point it is not possible to launch new instances in the region ... Other AWS Services, such as DynamoDB and S3 are also experiencing significant error rates and latencies." Zwei von drei Zonen unten, und der Ausfall war vollständig aus der Zonenschicht herausgeklettert.

Achtzehn Stunden sind nicht gleichzeitig, und das ist der Punkt

Die beiden Zonen fielen nicht gemeinsam. Sie fielen rund achtzehn Stunden auseinander, durch dieselbe Ursache. Diese Unterscheidung ist das ganze Argument dieses Posts, also lohnt es sich, dabei präzise zu sein. Zonenunabhängigkeit ist eine Wahrscheinlichkeitsbehauptung: AWS legt Zonen auf getrennten Strom, getrennte Kühlung, getrennte Überschwemmungsgebiete und getrennte Netzwerkpfade, sodass die internen Fehler einer Einrichtung, ein ausgefallener Chiller, ein ausgefallener Transformator, ein defektes Switch-Fabric, innerhalb dieser bleiben und nicht mit den internen Fehlern einer anderen zusammenfallen. Nach den eigenen Maßstäben dieser Behauptung änderte der März nichts. Keine Zone riss die andere mit. Es gab keinen gemeinsamen Transformator, keine kaskadierende Abhängigkeit. Die Isolationstechnik funktionierte durchgehend.

Was versagte, war die Annahme unter der Wahrscheinlichkeitsmathematik: dass Zonenausfälle unabhängige Ereignisse sind. Sie sind nur dann unabhängig, wenn die Ursache innerhalb einer Einrichtung entsteht. Eine Ursache, die außerhalb der Einrichtungen entsteht, ein Sturm, ein Netzzusammenbruch, ein Flächenbrand, ein bewaffneter Konflikt, wird einmal gezogen und auf jede Zone in ihrer Reichweite angewendet. Die Zonen teilten sich einen Ballungsraum, ein Stromnetz, einen Luftraum und einen Krieg. Korrelierter Ausfall bedeutet nicht, dass zwei Zonen im selben Moment sterben; er bedeutet, dass eine Ursache beide nach ihrem eigenen Zeitplan erreicht. Die Lücke von achtzehn Stunden ist, wie Korrelation auf einem Dashboard tatsächlich aussieht: kein synchronisierter Crash, sondern dieselbe Hand, die zweimal klopft.

Deshalb scheitert das Framing als Kriegs-Sonderfall. Drohnen sind exotisch; gemeinsam genutzte Metro-Infrastruktur ist es nicht. Jede Multi-AZ-Region konzentriert ihre Zonen innerhalb einstelliger Millisekunden voneinander, was in der Praxis denselben stadtweiten Blast Radius für Wetter, Versorger und Politik bedeutet. Das März-Ereignis ist das extreme Ende einer Familie von Ursachen, die jedes Ereignis umfasst, das groß genug ist, um nach der Stadt benannt zu werden, in der es geschah. Als InfoQ den Incident später im selben Monat unter dem Titel "War in Iran Damages Multiple AWS Data Centers, Challenging Multi-AZ Assumptions" analysierte, war die Community-Diskussion, die er zusammenfasste, bereits über die Drohnen hinaus zum allgemeinen Fall gelangt: Zonen sind ein Cluster von Gebäuden in derselben Stadt, und die Annahmen, die es zu hinterfragen lohnt, betreffen alles, was eine Stadt erreichen kann.

Wenn die Region selbst die Failure Domain ist

Das lehrreichste Update im ganzen Log kam um 2:53 AM PST am 2. März, als AWS erklärte, was zwei verlorene Zonen mit S3 machen: "Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone ... As the second AZ became impaired, S3 error rates increased. With two Availability Zones significantly impacted, customers are seeing high failure rates for data ingest and egress."

Lies diesen Satz als Architekturdokument, denn er ist eines. S3 und DynamoDB sind die Services, die du nicht auf Zonenausfall auslegst, weil AWS es für dich tut, indem es über Zonen hinweg repliziert, sodass der Verlust einer Zone unsichtbar ist. Dieses Design hat eine angegebene Toleranz: eine Zone. Die zweite Zone überschritt sie, und die Services, auf die sich jede "resiliente" Architektur in der Region stützte, für State, für Backups, für die Koordinationsdaten des Failovers selbst, begannen, Reads und Writes regionsweit zu verweigern. Deine Multi-AZ-Anwendung verlor nicht nur ihre Instances; sie verlor das regionale Substrat, auf das sie sich wiederherstellen wollte. mec1-az1 war gesund, und es spielte keine Rolle, denn eine gesunde Zone, die an eine beeinträchtigte regionale Control Plane hängt, ist ein Raum mit brennendem Licht in einem Gebäude ohne Sanitäranlagen. Das ist der Teil, den Multi-AZ nicht beantworten kann. Die regionalen Services sind auf denselben drei Zonen aufgebaut wie du, und ihre Toleranz für korrelierten Zonenverlust ist eine Zahl, die AWS gewählt hat, nicht eine Zahl, die du gewählt hast.

"Ideally in Europe"

Bis 6:22 AM PST am 2. März war die Anleitung von AWS bei ihrem unverblümtesten Satz angekommen: "We recommend customers enact their disaster recovery plans and recover from remote backups into alternate AWS Regions, ideally in Europe."

Dieser Satz verdient eine langsamere Lesart, als er im März bekam. Erstens: Der Provider, dessen Region es ist, sagte den Kunden, sie sollten sie verlassen. Das ist die Obergrenze der In-Region-Redundanz, ausgesprochen vom Anbieter: Es gibt eine Klasse von Ereignissen, für die die richtige Menge an me-central-1 in deinem Recovery-Plan gleich null ist, und du findest mitten im Incident heraus, in welcher Klasse du bist, von einem Dashboard. Zweitens leistet "ideally in Europe" stille, sorgfältige Arbeit. Die nächstgelegene Alternative, me-south-1 in Bahrain, ist einen kurzen Sprung entfernt und wäre aus Latenzgründen die reflexartige DR-Wahl, und eine Einrichtung dort war von einem nahegelegenen Angriff in derselben Kampagne betroffen gewesen. AWS sagte den Kunden, ohne es auszubuchstabieren, dass die korrelierte Ursache eine Geografie hatte, und dass eine brauchbare Recovery-Region eine ist, die außerhalb dieser Geografie liegt, nicht bloß außerhalb der Region-ARN. Distanz von deiner Primärregion ist kein Compliance-Häkchen; sie ist eine Wette darüber, wie weit deine korrelierten Ursachen reisen. Wähle deine DR-Region, indem du fragst, was plausibel beide treffen könnte, nicht, was die Replikationslatenz hübsch hält.

Drittens funktioniert der Rat nur für Kunden, die ihm folgen konnten. "Recover from remote backups" setzt voraus, dass die Remote-Backups existieren, erstellt vor dem 1. März, denn dasselbe Update-Log zeigt, wie S3 "data ingest and egress" während des Ereignisses regionsweit ausfällt. Deine Daten aus einer Region herauszukopieren ist eine Friedenszeit-Aktivität. Wenn der Provider dazu rät, hat sich das Fenster zum Anfangen bereits geschlossen.

Mehrere Monate

Das letzte Update des Ereignisses, datiert auf den 30. April, ist einen Absatz lang und beendet die Geschichte, ohne sie zu beenden: Die Region "has suffered damage as a result of the conflict in the Middle East and is currently unable to reliably support customer applications", Kunden sollten "migrate all accessible resources to other Regions and restore inaccessible resources from remote backups as soon as possible", der Abrechnungsbetrieb ist ausgesetzt, und die Wiederherstellung "is expected to take several months".

Stell das einem Standard-DR-Dokument gegenüber. Ein RTO wird als Dauer geschrieben, und fast jedes RTO, das ich geprüft habe, nimmt stillschweigend an, dass das Wiederherstellungsziel der Ort ist, an dem du ohnehin bist: den Snapshot wiederherstellen, die Flotte neu starten, dieselbe Region, im schlimmsten Fall Stunden. "Several months" belastet diese Zahl nicht, es löscht die Achse, auf der sie geschrieben wurde. Wenn die Region in diesem Quartal nicht zurückkommt, ist deine tatsächliche Wiederherstellungszeit so lange, wie ein kalter regionsübergreifender Neuaufbau dauert, einschließlich der Teile, die niemand geprobt hat: IAM und Networking neu erstellt aus Code, den du hoffentlich hast, Daten wiederhergestellt aus Replikas, die du hoffentlich gemacht hast, DNS umgeschaltet, Kapazität gefunden in einer Zielregion, die den Exodus aller anderen auf einmal aufnimmt. Für Teams, bei denen die regionsübergreifende Replikation bereits floss, war der März eine schlechte Woche. Für Teams, deren DR-Plan aus In-Region-Snapshots bestand, war er ein Migrationsprojekt, angekündigt durch Artillerie.

Das Lab: in welchen physischen Zonen bist du tatsächlich?

Teil 1 schloss seinen Lab-Abschnitt mit der Bemerkung, dass AWS-Incident-Reports Zonen per ID benennen, use1-az4, und dass du ohne das ID-zu-Name-Mapping nicht sagen kannst, ob das dein us-east-1a war. Der März ist der Incident, bei dem das aufhört, eine Nebensächlichkeit zu sein. Das Dashboard sagte mec1-az2, dann mec1-az3. Um zu wissen, ob deine Workloads in den getroffenen Zonen oder in der überlebenden saßen, musstest du diese IDs gegen deinen Account auflösen, mitten im Incident, denn ein Zonenname wie me-central-1a ist ein account-bezogener Alias: AWS weist Buchstaben pro Account unabhängig zu physischen Zonen zu, sodass das me-central-1a zweier Accounts meist verschiedene physische Zonen sind. "Wir sind über a, b und c verteilt" ist eine Aussage über die Benennung in deinem Account, nicht über die physische Platzierung.

Das Lab für diesen Teil, 02-az-id-truth, ist bewusst das kleinste der Serie: ein einzelnes read-only Skript, dessen einzige API-Aufrufe DescribeAvailabilityZones und GetCallerIdentity sind, letzteres nur, um die Ausgabe zu beschriften. Es druckt das Name-zu-ID-Mapping für den aktuellen Account und die aktuelle Region. Dies ist die tatsächliche Ausgabe für einen meiner Accounts:

$ python3 az_ids.py --region us-east-1
Region: us-east-1

ZONE NAME  | ZONE ID  | STATE
---------------------------------
us-east-1a | use1-az1 | available
us-east-1b | use1-az2 | available
us-east-1c | use1-az4 | available
us-east-1d | use1-az6 | available
us-east-1e | use1-az3 | available
us-east-1f | use1-az5 | available
...

In diesem Account ist use1-az4, die Zone im Mai-Incident-Report, us-east-1c. Ein Engineer hier, der im Mai "use1-az4" las und auf ein mit "us-east-1a" beschriftetes Diagramm blickte, hätte sich bei der falschen Zone entspannt und sich um eine gesunde gesorgt. Das Skript nimmt außerdem --compare <profile>, das das Mapping eines zweiten Accounts in derselben Region liest und die beiden nebeneinander druckt, mit einem Urteil pro Name, ob sie auf dieselbe physische Zone auflösen, und dann die Nichtübereinstimmungen zählt; dass derselbe Name über Accounts hinweg auf verschiedene IDs auflöst, ist der Normalfall, nicht die Ausnahme. Ein geteiltes Runbook, das sagt "evakuiere us-east-1a", tut in verschiedenen Accounts verschiedene Dinge. Runbooks, Platzierungsentscheidungen und Incident-Lookups gehören in Zonen-IDs. Es gibt ein --json Flag, um das Mapping in Inventar-Tooling einzuspeisen, und der Exit-Code ist 0, wann immer der Lauf durchläuft, wobei 2 für Läufe reserviert ist, die überhaupt nicht stattfinden können: kein boto3, keine Credentials, keine Region, ein unbekanntes Profil oder das Fehlschlagen des Describe-Aufrufs selbst.

Failure Modes und worauf zu achten ist

Sei zuerst ehrlich über die Grenzen: Ein Kunde kann me-central-1 nicht aus einem Krieg herausarchitekten. Nichts in deinem Terraform verhindert die korrelierte Ursache; was du kontrollierst, ist, ob sie dich findet, während deine Daten bereits anderswo liegen. Die Watchlist, die aus dem März folgt, ist kurz. Zähle die Ursachen auf, die alle deine Zonen auf einmal erreichen: die gemeinsame Metro, das gemeinsame Netz, das gemeinsame Wetter, die gemeinsame Jurisdiktion, und behandle die Antwort als deine echte Wahrscheinlichkeit für Regionsverlust, die niedrig ist, aber nicht die Null, die die Zonenmathematik stillschweigend annahm. Halte regionsübergreifende Backups für alles, was du nicht neu erzeugen kannst, in einer Region, die dafür gewählt wurde, außerhalb der korrelierten Geografie zu liegen, und teste den Restore, denn die März-Version dieses Tests hatte eine Feuerwehr darin. Schreibe RTOs zweimal, einmal für In-Region-Recovery und einmal unter der Annahme, dass die Region ein Quartal lang weg ist, und lege die zweite Zahl demjenigen vor, dem das Risiko gehört. Und führe ein Inventar deiner physischen Zonen-IDs pro Account, denn wenn der nächste Report eine Zonen-ID nennt, ist die Zeit, dein Mapping zu lernen, nicht während des Ereignisses. Die Zonengrenze ist real, und Teil 1 zeigte sie standhalten. Der März zeigte das, was darüber liegt: Zonen können perfekt voneinander isoliert sein und trotzdem nicht von der Welt isoliert sein.

Lies das als Nächstes

Für Consulting zu AWS, Cloud-Architektur, Resilience Reviews und Plattform-Arbeit, starte auf ercanermis.com.

Referenzen