Cloud-Computing: Amazons Speichersystem ging der Platz aus
Amazon hat eine Analyse der Ursachen des Ausfalls von Teilen seines europäischen Cloud-Computing-Dienstes AWS(öffnet im neuen Fenster) veröffentlicht und Maßnahmen vorgestellt, mit denen ähnliche Probleme in Zukunft verhindert werden sollen. Zahlreiche EC2-, EBS- und RDS-Instanzen waren wegen Amazons Problemen zum Teil tagelang nicht verfügbar.
Wie schon in der Vergangenheit führte eine Verkettung von Problemen zu den Ausfällen. Ausgangspunkt war der Ausfall eines Transformators mit 110 kV und 10 Megawatt am 7. August 2011 um 10:41 Uhr (Pacific Time), über den die Stromversorgung des Rechenzentrums lief. Dadurch kam es zu einen Stromausfall, der alle an diesen Transformator angeschlossenen Kunden betraf, darunter auch ein großer Teil der Systeme der danach ausgefallenen AWS-Verfügbarkeitszone. Zunächst war ein Blitzeinschlag als Ursache ausgemacht worden, mittlerweile hat der Stromanbieter dies dementiert und sucht weiter nach der Ursache.
Ein Stromausfall sollte kein Problem sein
Nun sollte solch ein Stromausfall eigentlich kein größeres Problem sein, denn genau für diesen Fall sollten Rechenzentren vorsorgen, mit Strom von mehr als einem Anbieter auf unterschiedlichen Anschlussleitungen und einer Notstromversorgung über Akkus und Notstromaggregate. So auch in diesem Rechenzentrum. Bevor aber ein Notstromaggregat die Stromversorgung übernehmen kann, muss seine Phase mit den übrigen Systemen synchronisiert werden. Einer der dafür verantwortlichen Programmable Logic Controller (PLCs) funktionierte nicht korrekt, so dass ein Teil der Notstromaggregate nicht ans Netz ging. Dadurch stand letztendlich nicht genügend Strom für alle Systeme in der Verfügbarkeitszone zur Verfügung.
Laut Amazon fielen deshalb 58 Prozent der EC2-Instanzen und 58 Prozent der EBS-Volumen (Elastic Block Storage) in der Verfügbarkeitszone aus. Auch das EC2-Netzwerk, über das die Systeme ans Internet angebunden sind, war ohne Strom. Die Folge waren Verbindungsprobleme, die zu API-Fehlern führten, wenn Nutzer versuchten, Systeme in der Zone zu starten und zu erstellen.
Probleme wirken sich auf andere Zonen aus
Dann breiteten sich die Probleme weiter aus. Ab 11:05 Uhr verzeichnete Amazon API-Fehler in allen Verfügbarkeitszonen in der westlichen EU. Das EC2-Verwaltungssystem nutzt Server in allen Verfügbarkeitszonen und routete auch Aufgaben an Verwaltungsserver in den ausgefallen Zonen, die nicht erreichbar waren. Zudem nahm das Verwaltungssystem weiterhin Aufträge zur Ausführung von EC2-Instanzen in der ausgefallenen Verfügbarkeitszone an, die in eine Warteschlange gestellt und nicht abgelehnt wurden. Dadurch verlängerte sich die Startzeit für EC2-Instanzen. Erst nachdem Amazon den Start von EC2-Instanzen in der ausgefallenen Zone gegen 12:00 Uhr deaktiviert hatte, normalisierte sich die Startzeit für EC2-Instanzen in den anderen Zonen wieder.
Zwar konnte Amazon die Stromversorgung vieler EC2- und EBS-Systeme gegen 11:54 Uhr wiederherstellen, doch erst um 1:49 Uhr war auch das Netzwerk ausreichend mit Strom versorgt, so dass die Zone wieder ans Internet angebunden werden konnte. Dadurch waren viele Systeme in der Zone wieder verfügbar. Doch die Probleme waren damit nicht gelöst.
Amazons Elastic Block Storage ging der Speicher aus
Amazons EC2 nutzt Amazons EBS, um Daten zu speichern, und das Speichersystem Elastic Block Storage bereitete größere Probleme. Sie waren in der Art und Weise begründet, wie EBS funktioniert: Die einzelnen Nodes spiegeln ihre Daten auf andere Nodes, um einem Datenverlust bei Ausfällen vorzubeugen. Verliert eine EBS-Node die Verbindung zu einem anderen EBS-Server, auf den er Daten repliziert, sucht sich dieser Server einen anderen, um seine Daten dort zu spiegeln. Bis ein neuer Partner gefunden ist, werden aber keine Daten geschrieben.
Da zahlreiche EBS-Nodes in der betroffenen Zone ausgefallen waren, ging Amazon der Speicherplatz aus, bevor alle Speicher-Volumes neu gespiegelt werden konnten.
Für eine EC2-Instanz ist der Ausfall seines EBS-Nodes ein Problem, denn es kann dann keine Daten mehr schreiben und bleibt stehen. Im Normalfall sucht sich eine EC2-Instanz einen neuen EBS-Server, doch in diesem Fall blieb die Suche zum Teil ohne Erfolg; die betroffenen EC2-Server blieben stehen. Und da viele EBS-Nodes mangels Speicherplatz ihre Daten nicht spiegeln konnten, blockierten sie die Schreibzugriffe.
Um die EC-Systeme wieder zum Laufen zu bringen, musste Amazon für zusätzliche Speicherkapazität sorgen. Das aber brauchte Zeit, da in der Nacht zunächst zusätzliche Systeme aus einem anderen Rechenzentrum herangeschafft werden mussten. Sobald der zusätzliche Speicher online war, beruhigte sich die Situation.
Datenverlust nicht ausgeschlossen
Amazon kann aber nicht ausschließen, dass es in einigen Fällen Datenverluste gegeben hat. Falls eine EC2-Instanz und sämtliche EBS-Nodes, auf denen ihre Daten lagen, ausgefallen sind, kann Amazon nicht sicherstellen, dass alle Daten auf allen Nodes konsistent sind. Wird ein inkonsistentes Volume wieder hochgefahren, könnte es zu größeren Problemen durch unentdeckte, latent vorhandene Datenfehler kommen, erklärte Amazon. Kann Amazon nicht sicherstellen, dass die Daten auf den EBS-Servern konsistent sind, wird ein Recovery-Snapshot erstellt, aus dem Kunden eine neue Instanz erzeugen und auf Konsistenz prüfen können.
Diese Snapshot-Erstellung aber dauerte eine Weile, da zunächst die Daten aller Nodes auf Amazons Cloud-Speicher S3 kopiert, dann ins Recovery-Snapshot-Format umgewandelt und erneut kopiert werden mussten, damit die Kunden Zugriff auf die Snapshots hatten. Um 6:04 Uhr am 9. August 2011, also knapp zwei Tage nach dem Beginn des Ausfalls, standen erst 38 Prozent der Recovery-Snapshots bereit, am 10. August um 2:37 Uhr waren es 85 Prozent und um 20:25 Uhr am selben Tag 98 Prozent.
Auch Datenbanken fielen aus
Auch Amazons Cloud-Datenbank RDS (Relational Database Service) war von dem Ausfall der EBS-Nodes betroffen. RDS-Instanzen, die nur in einer Verfügbarkeitszone liefen, fielen fast alle schlagartig aus. Sobald die EBS-Server wieder verfügbar waren, liefen auch die RDS-Systeme weitgehend wieder. Waren die EBS-Volumes aber nicht konsistent, mussten die Kunden auf Backups zurückgreifen, die Amazon automatisch erstellt, wenn die Kunden dies nicht abschalten.
Allerdings waren die Probleme bei RDS nicht auf die eine Zone beschränkt: Auch einige Datenbanken, die auf mehrere Verfügbarkeitszonen verteilt wurden, hatten Probleme, wenige davon auch länger anhaltende. Eigentlich sollte beim Ausfall eines primären Datenbanksystems automatisch auf das Backup umgeschaltet werden. Bevor dies aber passiert, wird eine "Gesundheistprüfung" des anderen Systems vorgenommen, um zu vermeiden, dass sich beide Instanzen für die primäre halten. Diese Abfrage aber schlug aufgrund eine DNS-Problems, ausgelöst durch den Stromausfall, in einigen Fällen fehl, so dass nicht automatisch umgeschaltet wurde.
Die DNS-Probleme waren zwar in vier Minuten behoben und nach spätestens 14 Minuten waren die Backups aller betroffenen Systeme eingesprungen, bei einigen Kunden führte ein Softwarebug aber zu weiteren Verzögerungen.
Amazon will Systeme verbessern
Damit ein solches Problem in Zukunft nicht mehr auftritt, will Amazon verschiedene Maßnahmen ergreifen: So sollen die PLCs zur Synchronisation der Phasen redundant ausgelegt und stärker isoliert werden.
Das EC2-Verwaltungssystem soll verbessert werden, damit es durch einzelne Ausfälle nicht mehr zu Verzögerungen in andern Zonen kommt. Bis alle geplanten Änderungen umgesetzt sind, könne es aber einige Monate dauern, erklärte Amazon.
Bei EBS soll die Zeit zur Wiederherstellung stehengebliebener Systeme erheblich reduziert werden. Künftig soll es nicht mehr notwendig sein, Daten auf S3 zu kopieren, um einen Recovery-Snapshot zu installieren.
Nutzern, deren Systeme in der betroffenen Zone liefen, gewährt Amazon zehn Tage kostenlose Nutzung, ganz gleich, ob es zu Problemen kam oder nicht.