Dipl.-Inform. Carsten Eilers

Vom Ausfall betroffen waren u.a. der News-Aggregator Reddit, die Frage&Antwort-Site Quora und der Geolocation-Anbieter Foursquare. Die Ausfallzeiten dieser prominenten Websites waren unterschiedlich lang: Reddit lief am Donnerstag in einem "emergency read only mode", bei Foursquare gab es Aussetzer. Und beim Webanalyse-Dienst chartbeat dauerten die Störungen vom 21. bis zum 27. April. Irgend jemand war so pfiffig, eine Website mit einer Aufstellung der betroffenen Angebote ins Netz zu stellen: EC2Disabled.com.

Ein Kunde nutzte Amazons EC2 angeblich zur Überwachung von Herzpatienten - oder auch nicht. Entweder wollte sich da jemand wichtig machen, oder jemand war wirklich so dumm, ein lebenswichtiges System auf virtuellen Servern in der Cloud zu hosten. Laut Albert Einstein ist die menschliche Dummheit zwar unendlich, aber ich persönlich denke, da wollte sich jemand wichtig machen.

Recovery dauert lange... und ist nicht völlig erfolgreich

Amazon brauchte einige Zeit, um die Probleme einzugrenzen, da blieb verständlicherweise wenig Zeit, die Vielzahl an Foren-Threads zum Thema ausführlich zu beantworten. Für einige Betroffene dauerte es deutlich länger als vermutet, um am Ende konnten nicht alle Daten restauriert werden. Beim schon oben erwähnten Chartbeat gingen ca. 11 Stunden protokollierter Daten verloren und sorgen für Lücken in den Analysen.

Inzwischen hat Amazon eine sehr ausführliche Erklärung des Vorfalls veröffentlicht. Primär betraf der Ausfall einen Teil der "Elastic Block Store" (EBS) Laufwerke in einer einzigen "Availability Zone" (AZ) im Osten der USA, die keine Schreib- und Leseoperationen mehr erlaubten. Instanzen, d.h. virtuelle Rechner, die auf diese Laufwerke zugreifen wollten, blieben daraufhin hängen. Auch der EBS nutzende "Relational Database Service" (RDS) war von den Ausfällen betroffen. Auslöser des Ausfalls war ein Fehler im Rahmen einer Konfigurationsänderung, der sich nach und nach aufschaukelte und auch auf andere Availability Zones übergriff.

Backup vergessen?!?!?

Und hier wird es interessant: Jeder weiß, dass man vor Änderungen am System ein Backup macht. Jeder? Nicht Amazon, denn dort gibt es kein Backup, so dass nun einige Kunden ihre Daten verloren haben, sofern sie keine eigenen Backups haben. Nun ist das mit dem "Backup machen" im Fall einer Cloud etwas aufwendiger als auf einem Einzelrechner, denn Amazon führte die Konfigurationsänderung ja im laufenden Betrieb durch, so dass sich die Daten auf den betroffenen EBS änderten, während man bei einem einzelnen Rechner normalerweise das Backup macht, die Konfigurationsänderung durchführt und danach weiterarbeitet. Aber wer eine Cloud betreibt, muss eben auch deren Eigenheiten berücksichtigen. Denn betrachten wir es mal aus Sicht der Benutzer: Die wissen nicht, wann Amazon am System rumschraubt, sie müssten also eigentlich laufend Backups machen, für den Fall, dass Amazon etwas ändert und es dabei ein Problem gibt. Das ist keinesfalls akzeptabel, also hätte Amazon für Backups sorgen müssen. Dass man das nicht getan hat, dürfte zum einen daran liegen, dass es ziemlich aufwändig wäre, zum anderen daran, dass ja nichts passieren sollte. Beides Argumente, die man auch bei normalen Rechnern öfter hört.

Wie geht es weiter?

Die Frage ist jetzt, welche Schlüsse man daraus zieht. Christine Drake weist im Cloud Security Blog von Trend Micro darauf hin, dass Unternehmen, die die Cloud nutzen, Ausfälle einplanen müssen. Service Level Agreements sind dabei nur ein Anhaltspunkt und keine Garantie. Sie stellen nur ein einkalkuliertes Geschäftsrisiko der Betreiber dar: Was können bzw. wollen sie leisten, und was können bzw. wollen sie zahlen, wenn sie diese Leistung nicht erbringen können. FathomDB-Gründer Justin Santa Barbara (der als Mitbewerber zu Amazons Cloud-Service im Bereich rationaler Datenbanken nicht neutral ist, sich aber mit der Materie auskennen sollte), erklärt, dass Amazon die eigenen Zusagen nicht eingehalten hat, da mehrere der Availability Zones von dem Ausfall betroffen waren, was eigentlich nicht hätte passieren dürfen.

Fast ein GAU, oder nur eine kleine Störung?

Betrachtet man das Ausmaß des Ausfalls, sieht man ein sehr gespaltenes Ergebnis: Es war der wohl bisher größte und längste Ausfall eines Cloud Services, betraf aber nur einen kleinen Teil der Kunden. Amazon betreibt für EC2 Standorte in vier Regionen: In den USA (an Ost- und Westküste), in Europa (Irland) und in Asien (Singapur), und nur der an der Ostküste der USA war von dem Ausfall betroffen. Und von Datenverlusten sind "nur" 0,07% der EBS-Laufwerke betroffen. Das klingt nach extrem wenig, aber es fehlen sämtliche Vergleichswerte. Bedenkt man Amazons Größe, können das schon etliche Kunden sein, die nun ihre Daten verloren haben, und je nachdem, was das für Unternehmen und Daten sind, kann das für ein Unternehmen schon kritisch sein. Um also zum ausgelutschten GAU-Vergleich zurück zu kommen: Für einige Amazon-Kunden kann das wirklich ein GAU sein, für Amazon ist es wahrscheinlich nur eine kleine Störung.

Kontrolle ist alles!

Und damit kommen wir zum entscheidenden Punkt: Kritische Anwendungen muss man unter eigener Kontrolle behalten. Aber wie hoch ist denn die Ausfallwahrscheinlichkeit bei einem selbst betriebenen System? Da gibt es schließlich etliche Variationsmöglichkeiten, vom Rootserver oder Managed Server bei einem Hosting-Provider über eigene Hardware in Colocation zum eigenen vollständigen Rechenzentrum - und alle können ausfallen. Also braucht man für alle Backup- und Fallback-Lösungen, ebenso wie bei der Nutzung der Cloud. Und wenn man alle Vorsichtsmaßnahmen ergriffen hat, spricht eigentlich einiges für die Cloud-Lösung, zumindest in diesen Fall. Denn wer kann sich schon selbst die Infrastruktur und Flexibilität leisten, die Amazon zur Verfügung stellt? Generell stehe ich der Cloud, schon aufgrund ihrer Schwammigkeit, skeptisch gegenüber. Aber in diesem Fall stehen Hardware-Server virtuellen Servern auf Amazons Servern gegenüber, und solange da keine sensitiven Daten drauf sind, besteht aus Sicherheitssicht kein großer Unterschied. Sensitive Daten würde ich allerdings nicht in der Cloud speichern - wer weiß schon, wer da im Zweifelsfall drauf zugreifen kann? Diesmal waren bei Amazon gar keine Zugriffe möglich, aber was wäre, wenn die Laufwerke falschen virtuellen Rechnern zugeordnet würden?

Eine Möglichkeit, wie man Cloud-Services relativ ausfallsicher nutzen kann, wird im Twilio Engineering Blog beschrieben. Theoretisch sind die gut, praktisch gibt es einen Kritikpunkt: Amazon teil die eigenen Dienste in Availability Zones ein, so dass beim Ausfall einer AZ alle anderen nicht betroffen sind. Wenn man nun Twilios Vorschlag folgt und seine Angebot auf mehrere AZs verteilt, sollte man auf der sicheren Seite sein - außer, es sind entgegen der Annahme doch mehr als eine AZ betroffen, wie im aktuellen Fall. Und nach Murphys Gesetz betrifft so ein Ausfall natürlich dann die AZs, bei denen die Kombination den größtmöglichen Schaden anrichtet. Wenn man also sein Angebot verteilt, dann richtig - es gibt ja mehr Möglichkeiten als nur Amazons EC2.

Carsten Eilers