Hallo, zusammen

Was lernen wir aus dem Ausfall der Amazon Cloud an Ostern?

Am Osterwochenende 2011 gab es einen großen Ausfall in einem der Amazon-Rechenzentren, das virtuelle Rechner als „elastic Cloud“ (EC2) bereitstellt (http://aws.amazon.com/message/65648/). Dabei waren viele Server für mehr als 24 Stunden nicht verfügbar. Bei einem sehr kleinen Teil davon gingen auch Daten unwiederbringlich verloren (http://www.heise.de/newsticker/meldung/Wolkenbruch-bei-Amazon-Datenverlust-in-der-Cloud-1234444.html).

Die technischen Ursachen dieses Ausfalls sind mittlerweile untersucht und Amazon wird sicher Maßnahmen ergreifen. Darüber ist schon hinreichend viel geschrieben worden. Kurz gesagt hat der Ausfall von Netzinfrastruktur die Verbindung zwischen den Datenspeichern gestört, worauf diese riesige Datenmengen auf Ausfallsysteme kopiert haben, was das Netz weiter lahmgelegt hat. Daneben war die Datenmenge wohl auch zu groß für die zur Verfügung stehenden Reservesysteme.

In der Diskussion fehlt mir aber eine allgemeinere Betrachtung der Konsequenzen für die IT-Landschaft und was der einzelne Unternehmer tun kann um sich abzusichern.

Cloud-Rechenzentren sind hochkomplex und nicht unfehlbar

Die veröffentlichte Forensik des Ausfalls ergibt ein Bild der hochkomplexen Redundanzen und Automatismen mit denen Amazon seine Cloud-Dienste ausgestattet hat. Ein Fehler führte zu automatischen Korrekturmaßnahmen, die für den Ausfall einzelner Systeme gedacht waren, aber beim Ausfall größerer Strukturen eine unsinnige Flut von Datentransfers zur Folge hatte.

Ein menschlicher Operator hätte wohl niemals eine solche Masse an Replikations-Aufträgen gleichzeitig gestartet!

Komplexität und Verfügbarkeit sind schwer unter einen Hut zu bringen

Bei WorNet gilt das „KISS-Prinzip“ (Keep it simple and stupid) nachdem insbesondere alles so auszulegen ist, dass der diensthabende Mitarbeiter, der nachts um 2 Uhr aus dem Bett geklingelt wird, die Fehlersuche auch unter Schlafmangel und Stress sicher ausführen kann.

Automatisch dürfen nur triviale Dinge passieren, und dieser Automatismus muss sicher abgeschaltet werden können. Das bedeutet zwar häufigere kleine Ausfälle, die ein Automatismus wohl abgefangen hätte. Aber die großen Ausfälle sind seltener und dauern weniger lange an, da ein Amok-laufender Automatismus die Lage nicht zusätzlich verschlimmert.
Ein Problem am DECIX in Frankfurt hatte zum Beispiel letztes Jahr Auswirkungen auf einen unserer Router in München. Der Operator konnte diesen Router einfach durch Unterbrechung der Stromzufuhr deaktivieren und in Ruhe die Logfiles durchsuchen. Der Betrieb hat sich unmittelbar stabilisiert und die Zahl der betroffenen Systeme wurde so sehr klein gehalten. Erst nachdem der Vorfall verstanden war wurde das System wieder in Betrieb genommen.

Dank „KISS-Prinzip“ mussten wir noch nie mehr als 4 Stunden Ausfall verkraften.

Im zweiten Teil geht es darum welche Bedeutung einzelne Rechenzentren erlangen können und wie man sich als Kunde gegen Ausfälle schützen kann.

IT bleibt spannend,

Euer Christian Eich