Cloud Computing


Lehren für Anwender und Anbieter

Die 10 schlimmsten Cloud-Ausfälle

Werner Kurzlechner lebt als freier Journalist in Berlin und beschäftigt sich mit Rechtsurteilen, die Einfluss auf die tägliche Arbeit von Finanzentscheidern nehmen. Als Wirtschaftshistoriker ist er auch für Fachmagazine und Tageszeitungen jenseits der IT-Welt tätig.
Amazon, Googlemail, Hotmail: Das sind zwar klangvolle Namen, aber auch sie sind in der Liste der Ausfälle bei Cloud-Anbietern vertreten.
Vier Tage lang lief im April nichts bei Amazon Web Services. Schuld waren Turbulenzen im Rechenzentrum in Virginia.
Vier Tage lang lief im April nichts bei Amazon Web Services. Schuld waren Turbulenzen im Rechenzentrum in Virginia.
Foto: Amazon

Cloud Computing kann mit vielen Vorzügen aufwarten. Aber auch die Wolke ist kein IT-Paradies. „Die Cloud wurde als magisches Ding verkauft, das einfach funktioniert und total zuverlässig ist“, sagt dazu Lew Moorman, CSO beim Cloud-Provider Rackspace.

Aber in Wahrheit sei auch Cloud ComputingCloud Computing nur eine Möglichkeit, Computerleistung einzukaufen. Und diese sei immer anfällig für Störungen. „Wer sicherstellen will, dass solche Störungen keinen Schaden anrichten, braucht dafür einen Plan“, mahnt Moorman. In der Tat gab es in der kurzen Historie des Cloud Computing schon einige schlimme Ausfälle. Unsere amerikanische Schwesterpublikation InfoWorld hat die zehn heftigsten Fälle zusammengestellt und verrät, was Anwender daraus lernen können. Alles zu Cloud Computing auf CIO.de

1. Amazon Web Service: Im vergangenen April kam es im Amazon-Rechenzentrum im US-Bundesstaat Virginia zu einer Panne. Der Fehler begann mit einem schief gelaufenen Netzwerk-Upgrade, in dessen Folge sich Datenträger von Amazons Elastic Block Store (EBS) quasi verselbstständigten und nach Backup-Platz für sich selbst suchten. Hört sich lustig an, war es aus Sicht der Kunden von Amazon Web Services (AWS) aber überhaupt nicht. Vier Tage lang lief nichts mehr. Zumindest für die Mehrzahl der Kunden.

InfoWorld nennt als positive Ausnahme das Unternehmen Netflix, das auf seine Reise in die Wolke von vorne herein einen Rettungsring für derartige Turbulenzen an Bord hatte: ein System-Design nämlich, in dem die Möglichkeit solcher Pannen von Anfang an berücksichtigt ist. „Unsere Architektur verhindert, dass EBS als unser Hauptservice für Data StorageStorage genutzt wird“, berichtet Netflix. Genauso greife man nämlich auf die Services von SimpleDB, S3 und Cassandra zurück. Darüber hinaus werden die Daten laufend querbeet durch die Availability-Zonen kopiert, was einen Kollaps während des AWS-Ausfalls verhinderte. Auch beim IT-Dienstleister Twilio gab es keinen nennenswerten Schaden, obwohl das Unternehmen seine Infrastruktur bei AmazonAmazon EC2 gehostet hat. „Wir haben unsere Infrastruktur gemäß der Annahme aufgebaut, dass ein Host Pannen haben kann und wird“, sagt Twilio-CTO Evan Cooke. „Deshalb verlassen wir uns in unserer Kernarchitektur nicht auf eine einzelne Maschine oder Komponente.“ Alles zu Amazon auf CIO.de Alles zu Storage auf CIO.de

2. Sidekick: Es geschah im Herbst 2009. Ein Betriebsausfall bei der Microsoft-Tochter Sidekick sorgte dafür, dass die Nutzer fast eine Woche lang keinen Zugang zu E-Mails, Kalendernotizen und anderen persönlichen Daten hatten. Dann erst folgte das Ende mit Schrecken. MicrosoftMicrosoft musste zugeben, die in der Cloud gespeicherten Bits komplett verloren zu haben. Keine Restore-Chance also, denn es waren keine Backups angelegt worden. Auch wenn sich die Technologie seither weiterentwickelt hat, warnt InfoWorld vor blauäugiger Abgabe der Verantwortung für Daten an irgendeinen Provider. Also: Niemals glauben, dass ein Dritter automatisch die eigenen geschäftskritischen Daten schützt. Am besten selbst für Backups sorgen, mindestens aber das Disaster Recovery-Setup des Cloud-Providers genau unter die Lupe nehmen. Alles zu Microsoft auf CIO.de

Zur Startseite