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.