Der Amazon Web Services (AWS) Ausfall: Letzte Chance – So etwas darf nicht noch einmal passieren!

[ 13 ] Juli 8, 2012 |

Nach dem letzten Ausfall der Amazon Web Services (AWS) am 29.06/30.06 habe ich – zurecht – die schlechte Systemarchitektur von Instagram kritisiert. Man sollte niemals alle seine Eier in ein Nest legen. Allerdings habe ich mir noch einmal in Ruhe die Fehler innerhalb der Amazon Cloud während des Ausfalls angeschaut. Amazon muss unbedingt seine Hausaufgaben erledigen, es geht hier schließlich um knallhartes Business und die Kunden zählen auf die Verfügbarkeit der Cloud Infastruktur.

Der Geduldsfaden wird immer dünner

Eines ist klar und das predige ich in jeder Situation. Amazon bzw. jeder IaaS Anbieter stellt “nur” die nötigen Infrastrukturressourcen in Form von virtuellen Instanzen inkl. Konfigurationstools bereit, um damit sein eigenes virtuelles Rechenzentrum aufzubauen. Die Verfügbarkeit des auf der Cloud betriebenen Systems muss selbst sichergestellt werden. Aber wie, wenn das “Werkzeug” dafür nicht funktioniert?

David Linthicum schreibt, dass er in der Nähe der Cloud Rechenzentren an der Ost Küste der USA wohnt. Und er bestätigt, dass die Gewitter wirklich sehr stark gewesen sind und die Stromversorgung und das Mobilfunknetz flächendecken lahmgelegt haben. Er schreibt zudem, dass solche Unwetter in dieser Region nicht ungewöhnlich sind und die meisten Cloud Anbieter keine Probleme damit hatten.

Komplexität kann man nicht beherrschen

Amazon ist mit Abstand Marktführer im Cloud Infrastruktur Markt und dieser Ausfall zeigt deutlich, wie schwierig es für Cloud Computing Anbieter (uneingeschränkt) ist, diese massiven Systeme zu betreiben und robust gegen Fehler auszulegen. Immerhin besteht alleine die Amazon Cloud in der Region US-EAST, nach eigenen Angaben, aus 10 Rechenzentren, die in vier Availability Zones aufgeteilt ist.

Die Probleme im Detail

Es handelte sich mal wieder um eine Kaskade von unerwarteten Fehlern, die zu diesem langen Ausfall führten. So konnte in einem Rechenzentrum die Notstromversorgung nicht aktiviert werden. Die USVs konnte die Systeme nicht lange genug mit Strom versorgen, wodurch diese in der Region heruntergefahren werden mussten. Dadurch standen keine virtuellen Instanzen mehr zur Verfügung. Was die Situation jedoch verschlimmerte, waren Probleme mit den Konfigurationstools, Software mit denen Kunden die Ressourcen innerhalb der Region erstellen, verschieben und anpassen können. Dadurch waren die Kunden nicht in der Lage auf den Ausfall zu reagieren.

Engpass

Ein weiteres Problem war ein Engpass während des Bootvorgangs der Amazon Server. Das führte dazu, dass es länger dauerte als erwartet, um wichtige AWS Services wie EC2 und EBS wieder hochzufahren. Das sorgte für ein Folgeproblem, als EBS wieder online war, da hier technische Eingriffe notwendig waren, um sicherzustellen, dass alle auf EBS gespeicherten Daten weiterhin vorhanden sind. Laut Amazon hat es mehrere Stunden benötigt, um diesen Fehler zu beheben.

Ein unbekanntes Problem

Das aber vielleicht schwerwiegendste Problem bestand in einem unvorhergesehen Fehler im Elastic Load Balancer (ELB), der dafür zuständig ist, den Traffic zu den Servern mit ausreichend Kapazität zu leiten. Als EC2 plötzlich nicht mehr verfügbar war, versuchte der ELB weiterhin Workloads auf die Server zu verteilen. Als die Amazon Cloud dann neu gestartet wurde, fuhren ebenfalls eine große Anzahl an ELBs in einem Status hoch der zu einem Fehler führte, den Amazon zuvor noch nicht gesehen hatte. Dieser überflutete die Amazon Cloud mit Anfragen, was wiederum zu einer Verzögerung führte. Dieser Fehler, in Kombination mit einer großen Anzahl neuer Server, die in von dem Ausfall nicht betroffenen Availability Zones durch Kunden ausgerollt wurden, erzeugte weitere Anfragen, die in der Summe die Fehlerbehebung verzögerte.

Gewitter + Viele eigene Fehler

Zwar war die eigentliche Ursache für den Ausfall der Amazon Cloud ein Gewitter. Die Wahrheit ist jedoch, dass sich die Cloud Infrastruktur durch eigene versteckte Fehler wieder selbst außer Gefecht gesetzt hat.

Kunden verlieren Daten

Neben Anbietern wie Instagram, Pinterest und Heroku waren ebenfalls Foursquare, Quran, Moby und Reddit von dem Ausfall betroffen. Dabei sollen mehrere große EC2 Kunden wertvolle Daten verloren haben. Darunter Chartbeat, die von einem Verlust von 11 Stunden an historischen Datenmaterial sprechen. Diese seien laut dem Unternehmen nicht wiederherstellbar.

Alternativen evaluieren

Ich habe mich bisher immer schützend vor die Amazon Web Services gestellt, da sie wirklich einen sehr guten Job machen und für das Cloud Computing stehen. Allerdings muss ich gestehen, dass ich langsam ein wenig irritiert bin was die Vorsichtsmaßnahmen gegenüber “unvorhersagbare” Ereignisse wie Gewitter und Stromausfälle sind. Das erneut die Notstromversorgung nicht funktioniert, die schlussendlich zu dem Ausfall geführt hat, ist doch sehr merkwürdig und muss hinterfragt werden. Zumal es sich dabei schon um das zweite Mal handelt, wo “ein Schalter” defekt war. Bis vor einer Woche habe ich meine Hand dafür ins Feuer gelegt, dass Amazon regelmäßig Fail-Over Szenarien durchführt, um sicherzustellen, dass Stromausfälle oder Unwetter routinemäßig “abgearbeitet” werden und “ein Schalter” im richtigen Moment mal nicht klemmt. Wo gerade der Strom doch als das analoge Paradebeispiel für das Pay-as-you-go Modell des Cloud Computing steht. Mittlerweile muss ich meine Hand – für die Amazon Web Services – für diesen Fall leider erst einmal zurückziehen.

Die Amazon Web Services haben dem Cloud Computing mit dieser Ausfallserie zwar nicht stark geschadet, aber erneut Diskussionen ausgelöst, die vor Monaten Ad acta gelegt wurden. Es kann einfach nicht sein, dass ein Stromausfall solche Probleme verursacht und schon gar nicht ein zweites Mal.

Es ist daher an der Zeit seine Eier nicht mehr nur in eine Availability Zone oder Region zu legen, sondern sich ebenfalls Gedanken über Alternativen und andere Clouds zu machen, um das eigene Risiko zu minimieren. Ein gutes Beispiel ist die Web TV Agentur Schnee von Morgen von Nikolai Longolius. Das Unternehmen setzt primär auf die Amazon Web Services und hat parallel eine Version für die Google App Engine entwickelt. Risikomanagement halt!

Ich sehe hier für Amazon allerdings noch ein zweites Problem. Nachdem sich das Unternehmen anfangs verstärkt auf die Startups dieser Welt konzentriert hat und weiterhin konzentrieren wird, versuchen sie auch vehement in den Bereich für etablierte Unternehmen einzusteigen. In einem Markt, wo sich bereits erfahrene Anbieter wie HP, IBM und Microsoft tummeln, die Wissen wie man auf die Bedürfnisse von großen Kunden eingeht. Diese Ausfälle werden es Amazon erschweren, Argumente für den Weg in die AWS Cloud zu finden.


Bildquelle: http://thearmadagroup.com

Tags: , , , , , ,

Category: Analysen

About the Author ()

Rene Buest is Senior Analyst and Cloud Practice Lead at Crisp Research, covering cloud computing and IT infrastructure. He is member of the worldwide Gigaom Research Analyst Network, top cloud computing blogger in Germany and one of the worldwide top 50 bloggers in this area. In addition, he is one of the world’s top cloud computing influencers and belongs to the top 100 cloud computing experts on Twitter. For more than 16 years he is focused on the strategic use of information technology in businesses and the IT impact on our society as well as disruptive technologies. Rene Buest is the author of numerous professional cloud computing and technology articles, speaker and participant of experts rounds. On CloudUser.de he writes about topics from the fields of cloud computing, it-infrastructures, technologies, management and strategies. He holds a diploma in computer engineering from the Hochschule Bremen (Dipl.-Informatiker (FH)) as well as a M.Sc. in IT-Management and Information Systems from the FHDW Paderborn.

Leave a Reply

You must be logged in to post a comment.