Gedanken zum Cloud-Ausfall bei Amazon – Teil I
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
Comments (2)
Nun ja, Datenverlust ist zwar bitter, aber in diesem Fall waren es ja „nur“ ein paar Bits und Bytes…..
Auf Anhieb fallen mir da zwei weitere Beispiele hochkomplexer Automatismen ein, die schon viel mehr Schaden angerichtet haben:
1) Vollautomatische Stopp-Loss-Orders haben schon so manchen Kursverfall einzelner Aktien bis hin zum Börsencrash ausgelöst oder zumindest stark beschleunigt.
2) Vor 25 Jahren flog in der Ukraine ein Atomkraftwerk in die Luft, weil Sicherheitsautomatismen während einer Übung genau das Gegenteil von dem bewirkt hatten, wofür sie gedacht waren.
Heutige Systeme werden nun mal immer komplexer und die Zeiten, in denen man sämtliche Abläufe im Voraus durchdenken und berücksichtigen konnte, sind lange vorbei.
Wichtig ist imho die vollautomatische Überwachung der Systeme. Und die Möglichkeit, die Automatismen durch ein „Not-Aus“ unterbrechen zu können….
Nach meinen bisherigen Erfahrungen seid ihr da bei WorNet auf einem guten Mittelweg. Damit’s für euch spannend und für mich beruhigend bleibt ;-).
Hoch interessanter Blog-Post, Glückwunsch! Da muss ich natürlich als Froschungsheini mit Interessensschwerpunkt „Troubleshooting of Operational Networks“ auch noch ein bisschen Senf loswerden. 🙂
Vielen von Christians Beobachtungen und Schlussfolgerungen stimme ich voll zu. Allerdings darf man bei der Frage „wieviel Automatisierung ist gut“ auch nicht die Größenverhältnisse außer acht lassen. Amazon AWS ist auf „web scale“ ausgelegt, mithin also darauf, dass man als Kunde sich eine Lastspitze durch das kurzfristige, automatisierte Deployen von 1000 VMs abfangen kann. 50 Server lassen sich semi-manuell managen. 50.000 Server eher nicht, insofern hat Amazon keine Wahl. Das gilt auch für Amazon-Kunden, die Top-200-Webseiten betreiben und von dem Ausfall betroffen waren, wie Reddit, Quora und Foursquare.
Interessanterweise war der Auslöser des Amazon-Ausfalls übrigens ein klassischer manueller Operator Mistake (Überlastung des Kontroll-Netzwerkes durch versehentliche Umleitung des Produktions-Netzes). Die gravierenden Auswirkungen wurden dann jedoch durch eine klassische Feedback-Loop und einen zu aggressiven Recovery-Mechanismus verursacht. Exakt das gleiche Problem hat übrigens vor Weihnachten auch den 3-tätigen Ausfall von Skype verursacht.
Was ist also daraus zu lernen?
* Automatismen in verteilten Systemen sind schwierig und fehleranfällig. Vor allem Interaktionen zwischen Einzelkomponenten können schwer vorherzusehende Feeback-Loops erzeugen. Es lohnt sich, besonders die Recovery- und FailOver-Strategien genau anzuschauen, und zu überlegen, ob diese auch für einen großflächigen Ausfall funktionieren, oder ob dann aggresive Optimierungen das gesamte System destabilisieren können. Auf der anderen Seite sind weltweit skalierende Anwendungen ohne Automatisierung der Infrastruktur auch nicht machbar.
* Es lohnt sich, Versprechungen von Infrastruktur-Anbietern mit einer gewissen Portion Skepsis zu betrachten. AWS hat Verfügbarkeitszonen die laut Marketing „fail-independent“ angelegt sind. Das heißt, sie werden in separaten Datacentern betrieben, mit unterschiedlichen Internet-Anbindungen, Routing, redundanter Control- und Managementplane. Alles schön und gut, aber während des Ausfalls führte der Rebuild-Storm dazu, dass die *gesamte* Control Plane überlastet war und damit auch teilweise die gesamte Region unmanagebar war, und Kunden betroffen waren, die sich eben durch redundante Auslegung in mehreren Availability Zones abgesichert hatten.
* Kundenservice ist wichtig. In den 3 Tagen waren die einschlägigen Foren voll von Technikern von globalen Webseiten, die bei Amazon niemand erreichten, obwohl Millionen User bei Ihnen vor verschlossenen Türen standen. Bei WorNet wüsste ich wo ich anrufe 🙂
Ergo: „Cloud“ im großen Stil ist für globale Websites unvermeidbar. Also, dann wenn man als weborientiertes Startup tatsächlich befürchten muss, in kurzer Zeit 100, 500, 1000 Server zu brauchen. Oder als etablierter Dienst das tatsächlich tut. Für die meisten von uns gilt das eher nicht.
Übrigens: Ein großer Kunde von AWS hat die Cloud-calypse ohne für die Kunden sichtbaren Ausfall überstanden: Netflix. Das dortige OPs-Team hat sich das „Always-Fail“-Prinzip zu Herzen genommen und den Chaos-Monkey programmiert. Ein Dienst, der andauernd nach dem Zufallsprinzip *in* *der* *Produktionsumgebung* Dienste abschießt, um die Fail-Over-Mechanismen zu prüfen. Mal sehen ob wir das auch können: $ killall lerncu. Ne, lieber doch nicht. 🙂