Schlagwort: Ausfall

Kategorien
News

Microsoft erklärt den Grund für den Ausfall von Windows Azure in der Region "West Europe"

Microsoft hat gestern weitere Informationen zu dem 2-stündigen Ausfall von Windows Azure in Europa in der letzten Woche bekanntgegeben. In einer ersten Stellungnahme am Tag nach dem Ausfall berichtete Microsoft von einer fehlerhaften Netzwerkkonfiguration, die zu den Problemen geführt haben soll.

Fehlkonfiguration und Nachrichtenflut

In einem weiteren Blogbeitrag erklärt Windows Azure General Manager Mike Neil, dass Microsoft weitere Rechenkapazitäten hinzufügen wollte, um die steigende Nachfrage in der Sub-Region „West Europa“ zu befriedigen. Allerdings wurde das Limit der für die neuen Kapazitäten benötigten „Devices“ nicht angepasst. Da die Last auf diesen Cluster plötzlich stark Anstieg, wurde der Grenzwert schnell überschritten, was zu einer großen Anzahl von Netzwerkmanagement-Nachrichten führte. Die erhöhten Managementdaten lösten wiederum Fehler in der Hardware des Clusters aus, wodurch die CPU-Auslastung auf 100% anstieg.

Cloud Computing ist eine Frage des Vertrauens und der Transparenz

Mit dem Stand heute haben wir für das Jahr 2012 zwei Spitzenreiter bei den Public Cloud Ausfällen. Platz eins teilen sich Amazon (3) und Salesforce (3), gefolgt von Microsoft (2). Das Ausfälle immer mal wieder vorkommen werden, daran sollte man sich höchstwahrscheinlich gewöhnen. Denn eine 100% Verfügbarkeit gibt es nun einmal nicht. Und jeder Anbieter, der eine 100% Verfügbarkeit verkauft, DER LÜGT! Warum? Ganz einfach, wie bei einigen Amazon Ausfällen, als auch dem letzten Microsoft Ausfall ist u.a. menschliches Versagen Schuld an dem Ausfall. Menschen machen Fehler.

Cloud Computing Anbieter müssen daher dafür sorgen, dass ihre Dienstleistungen und vor allem die Art wie sie arbeiten transparent ist. Das schließt die zeitnahe und umfangreiche Analyse aber vor allem die uneingeschränkte öffentliche Kommunikation während eines Ausfalls ein. Transparenz ist im Cloud Computing enorm wichtig für ein Unternehmen, dass seine Daten einem Anbieter anvertraut und bei dem die Daten vermeintlich auf dem selben physikalischen System gespeichert sind wie die eines Mitbewerbers. Denn Transparenz schafft Vertrauen!

Bildquelle: http://haymarket.net.au

Kategorien
News

Ausfall: Salesforce erneut mit Performance-Problemen

Nach den beiden Ausfällen im Juni und Juli, startet der CRM Anbieter Salesforce erneut mit Problemen in den August. Dieses Mal traf es weltweit den eigenen E-Mail Service, der – laut der Statusseite – mit einem Leistungsabfall („performance degradation“) zu kämpfen hatte.

Leistungsabfall und keine konkreten Informationen

Die Probleme begannen um 2:18 AM PDT, wo die Statusseite einen Leistungsabfall des E-Mail Service anzeigte. Halbstündlich fügte Salesforce ein Update zu der Seite hinzu, allerdings ohne nennenswerten Informationswert. Es wurde lediglich immer von

The salesforce.com Technology Team is actively working on resolving the performance degradation issue affecting the Email services. At this point, customers may experience slowness with Email services. Please check the status of trust.salesforce.com frequently for updates regarding this issue.

berichtet. Weitere Informationen wurden nicht bekanntgegeben.

Das führte Salesforce bis 6:30 am PDT weiter fort und berichtete dann:

The salesforce.com Technology Team has resolved the performance degradation issue affecting the Email Services. The problem began at 6:45am and was resolved as of 1:30pm UTC.

Um 11:46 am PDT folgte ein weiteres Problem mit der Instanz CS6, bei der ebenfalls von einem Leistungsabfall berichtet wurde.

The salesforce.com Technology Team is working to isolate a performance degradation issue on the CS6 instance. Some customers might be experiencing intermittent errors.

Um 12:01 pm PDT wurde das Problem dann scheinbar gelöst:

The salesforce.com Technology Team has resolved the performance degradation issue on the CS6 instance. The problem began at 17:47 UTC and was resolved as of 18:36 UTC.

Salesforce wird zum Problemfall

Der Ausfall des E-Mail Systems ist nun nicht so gravierend wie die letzten Ausfälle. Hier zeigten die Salesforce Systeme ebenfalls Leistungsabfälle. Insbesondere der Ausfall im Juli offenbarte schwerwiegende Probleme, bei dem mehrere Instanzen nicht erreichbar waren und von dem ebenfalls die sogenannten “Sandbox” Instanzen betroffen waren, welche die Salesforce Kunden für die Entwicklung und Test neuer Funktionen nutzen. Den Ausfall im Juni begründete Salesforce mit einer Fehlfunktion zwischen dem Storage und der Datenbank.

Kategorien
News

Netflix veröffentlicht seinen Chaos Monkey

Netflix hat den Quellcode für seinen Chaos Monkey veröffentlicht. Das schreiben Cory Bennett und Ariel Tseitlin auf dem Netflix-Blog. Unternehmen die ernsthaft Systemarchitekturen in der Cloud der Amazon Web Services (AWS) betreiben wollen und sich auf Ausfälle von AWS vorbereiten möchten, sollten auf den Chaos Monkey zurückgreifen, um das eigene System zu stabilisieren.

Der Chaos Monkey

Der Chaos Monkey ist ein Service der auf den Amazon Web Services läuft, nach Auto Scaling Groups (ASGs) sucht Instanzen (virtuelle Maschinen) pro Guppe wahllos beendet. Dabei ist die Software flexibel genug entwickelt worden, dass sie ebenfalls auf den Plattformen anderer Cloud Anbieter funktioniert. Der Service ist voll konfigurierbar, läuft standardmäßig aber an gewöhnlichen Werktagen von 09.00 Uhr bis 15.00 Uhr. In den meisten Fällen hat Netflix seine Anwendungen so geschrieben, dass diese weiterhin funktionieren, wenn eine Instanz plötzlich Probleme hat. In speziellen Fällen passiert das bewusst nicht, damit die eigenen Leute das Problem beheben müssen, um daraus zu lernen. Der Chaos Monkey läuft also nur ein paar Stunden am Tag, damit sich die Entwickler nicht zu 100% auf ihn verlassen.

Weitere Informationen zum Chaos Monkey und der Simian Army gibt es unter „Netflix: Der Chaos Monkey und die Simian Army – Das Vorbild für eine gute Cloud Systemarchitektur„.

Chaos Monkey Quellen

Kategorien
News

Fehlerhafte Netzwerkkonfiguration war Schuld am Windows Azure Ausfall für die Region "West Europe"

Grund für den ca. 2,5-stündigen Ausfall von Microsoft Cloud Service Windows Azure Compute am vergangenen Donnerstag (26.07.12) war offenbar eine fehlerhafte Netzwerkkonfiguration. Das schreibt Windows Azure General Manager Mike Neil in einem Blogbeitrag.

Fehlerhafte Netzwerkkonfiguration war Schuld an Windows Azure Ausfall für die Region

Fehlerhaft konfiguriertes Netzwerk-Device

Wie Neil schreibt, war nur Azure Compute in der Region „West Europe“ von dem Ausfall betroffen. Das Problem sei auf ein falsch konfiguriertes Netzwerk-Device zurückzuführen, was dafür gesorgt hat, dass der Datenverkehr nicht mehr zu einem zuständigen Cluster in dieser Region übertragen wurde. Als die Grenze für ausgehende Verbindungen erreicht wurde, führte dies zu weiteren Problemen in einem anderen Netzwerk-Device innerhalb dieses Clusters, was das Netzwerkmanagement und die Wiederherstellung erschwerte.

Microsoft will in der kommenden Woche weitere detaillierte Informationen zu dem Ausfall veröffentlichen.

Microsoft holt gegenüber Amazon auf – Salesforce spielt auch mit

Es handelt sich bereits um den zweiten schweren Ausfall von Windows Azure in den letzten Monaten. Erst am 29. Februar 2012 wurde die Microsoft Azure Cloud Opfer des diesjährigen Schaltjahres und war damit für 12 Stunden nicht erreichbar.

Ausfall-Könige bleiben in diesem Jahr jedoch (noch) die Amazon Web Services, die das negative Duell mit einem Vorsprung von einem Ausfall anführen. Zwischenstand 3 (AWS) zu 2 (Microsoft). Aber auch Salesforce spielt langsam in der Liga mit und bietet bereits zwei Ausfälle.

Kategorien
News

Microsoft Windows Azure Compute in der Region "West Europe" ausgefallen

Microsoft kämpft laut dem offiziellen Statusboard aktuell mit einem Ausfall seiner Cloud Computing Plattform Azure in der Region „West Europe“ und hier speziell mit dem Bereich Azure Compute. Microsoft liefert seine Cloud Services für Westeuropa aus Rechenzentren in Amsterdam und Dublin aus.

Windows Azure Compute in der Region

Ursachen für den Ausfall sind nicht genauer bekannt

Die Ursache für den Ausfall wurde bisher noch nicht veröffentlicht. Es wird lediglich von Problemen mit der Verfügbarkeit der Services gesprochen. Allerdings sollen die Accounts für den Cloud Storage davon nicht betroffen sein.

26-Jul-12 · 11:09 AM UTC
We are experiencing an availability issue in the West Europe sub-region, which impacts access to hosted services in this region. We are actively investigating this issue and working to resolve it as soon as possible. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers

26-Jul-12 · 12:09 PM UTC
We are still troubleshooting this issue, and capturing all the data that will allow us to resolve it. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers

26-Jul-12 · 1:09 PM UTC
We are still troubleshooting this issue, and verifying the most probable cause. Storage accounts in this region are not affected. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

Update

26-Jul-12 · 1:33 PM UTC
The issue has been addressed. Full service functionality has been restored in the region. Storage accounts and running applications were not impacted throughout the duration of the incident. We apologize for any inconvenience this caused our customers.

Ausfälle häufen sich

Nachdem die Amazon Web Services erst kürzlich innerhalb von 14 Tagen mit zwei schweren Ausfällen zu kämpfen hatten, wurde Microsofts Cloud Infrastruktur Opfer des diesjährigen Schaltjahres am 29. Februar. Bisher steht es in diesem Jahr allerdings noch 3:2 für die Amazon Web Services.

Kategorien
Analysen

Ausfallprävention: Diese Fragen sollte man seinem Cloud Computing Anbieter stellen

Ausfälle, wie der kürzlich bei den Amazon Web Services, in der Cloud, sind für alle Beteiligten sehr ärgerlich. Der Kunde verliert im schlimmsten Fall seine Daten und Kunden, hat aber in der Regel mit der Nichtverfügbarkeit seiner Systeme zu kämpfen. Der Anbieter, auf der anderen Seite, muss sich erklären und erleidet einen Imageverlust.

Vor Ausfällen ist niemand geschützt

Seit 2007 haben 568 Stunden Ausfallzeit von 13 namhaften Cloud Services mehr als 71.700,000 US-Dollar an Kosten verursacht, das zeigt eine Studie der International Working Group on Cloud Computing Resiliency (IWGCR). Dabei liegt die durchschnittliche Nichtverfügbarkeit von Cloud Services bei 7,5 Stunden pro Jahr. Das entspricht einer garantierten Verfügbarkeit von 99,9 Prozent, die weit weg von dem liegt, was von geschäftskritischen Systemen (99,999 Prozent) erwartet wird. Im Vergleich dazu beträgt die durchschnittliche Nichtverfügbarkeit von Strom in einer modernen Großstadt weniger als 15 Minuten pro Jahr.

Zwar vergüten die Cloud Anbieter die Ausfallzeiten, indem für den Zeitraum des Ausfalls keine Gebühren berechnet oder Rabatte erstattet werden, allerdings bezieht sich das lediglich auf die genutzte Infrastruktur. Die weiteren Kosten, die dem Kunden durch den Ausfall entstanden sind – Ersatzansprüche seiner Kunden, Datenverluste, usw. – erstattet der Cloud Anbieter nicht.

Fragen an den Cloud Computing Anbieter

Der Kunde wird also nicht geschützt und sollte sich vorab selbst darum kümmern den Anbieter auf Herz und Nieren zu prüfen.

Entspricht das SLA den eigenen Ansprüchen?

Cloud Anbieter werben in der Regel mit einer Verfügbarkeit von 99,9%. Wen das die eigenen Ansprüche nicht befriedigt oder das Unternehmen eine deutlich höhere Verfügbarkeit benötigt, der muss nachverhandeln. Zudem sollte man darauf achten, dass im Vertrag für jeden Service gut definierte Wiederherstellungspunkte beschrieben sind und welche Objekte das betrifft. Erwartet man eine Verfügbarkeit von 99,999% ist allerdings davon auszugehen, dass man hier monatlich deutlich draufzahlen muss.

Wie wird Verfügbarkeit und Ausfallzeit bestimmt?

Was genau bezeichnet der Anbieter selbst als Ausfall? Ist es die nicht Verfügbarkeit der gesamten Infrastruktur oder wenn 10%, 20% oder 60% der Nutzer von dem Problem betroffen sind? Wie sieht es aus, wenn das System zwar technisch einwandfrei funktioniert, aber sehr langsam arbeitet? Die meisten Anbieter schließen eine Reihe von Themen in ihren AGBs aus, die nicht als Ausfall bezeichnet werden, darunter Notsituationen oder Ausfälle von 15 Minuten oder weniger.

Wie schaut es mit höherer Gewalt aus?

Die meisten Cloud Anbieter schließen Ereignisse durch höhere Gewalt aus. Dazu gehören Naturkatastrophen, Kriege und Streiks. Hier muss man allerdings genauer hinschauen. Wenn bspw. die Notstromaggregate auf Grund eines Defektes an der eigenen Infrastruktur ausfallen, ist es wiederum keine höhere Gewalt, selbst dann wenn der Stromausfall z.B. durch ein Unwetter ausgelöst wurde. (eigene Meinung)

Wie robust ist die Cloud Umgebung?

Hier sollte man genau hinschauen. Befindet sich das Rechenzentrum z.B. in einem Erdbeben gefährdeten Gebiet, ist das ein enormes Risiko. Man sollte die Cloud Umgebung daher immer einer genauen technischen Prüfung unterziehen, wenn man die Cloud Services ernsthaft nutzen will.

Wie sehen die Notfallpläne aus?

Hier sollte man besonders drauf achten, das haben die letzten Ausfälle gezeigt! Es gilt daher, sich einen Blick auf die Notfallpläne zu verschaffen und ggf. einen Besuch vor Ort vorzunehmen und einen Audit durchzuführen. Das gilt für den gesamten Prozess inkl. der eigenen Anwendung, die auf der Cloud Infrastruktur betrieben wird, falls es zu einem Ausfall kommt.

Wie oft werden die Notfallpläne gestestet?

Nur weil der Anbieter über einen Notfallplan verfügt, bedeutet das nicht, dass dieser auch funktioniert. Fakten sind hier gefragt. Hier ist es angebracht sich die Ergebnisse der letzten Tests zu zeigen und dieses ebenfalls vertraglich festzuhalten.

Wie nutze ich die Infrastruktur am besten?

Beim letzten Ausfall der Amazon Web Services waren viele Services nicht verfügbar, da sich diese nur auf eine AWS Region konzentriert haben. Andere hingegen waren dennoch erreichbar, da sie ihre Systeme intelligent über die Amazon Cloud verteilt haben. 1. Ermöglicht ein Anbieter diese Vorgehensweise? 2. Wie nutze ich diese (gibt es eine Dokumentation dafür)?

Kann ich bevorzugt behandelt werden?

Sollte es zu einem Ausfall kommen, sind in der Regel mehrere Kunden davon betroffen. Der Anbieter wird also dafür sorgen müssen tausende von Kunden wieder online zu bringen. Hier kann es sich lohnen, für eine bevorzugte Behandlung zu zahlen, wenn die eigene Anwendung geschäftskritisch ist.

Due Diligence?

Neben den technischen Prüfungen ist es ebenfalls interessant zu wissen, wie der Anbieter z.B. auf der finanziellen Seite aufgestellt ist, um seine eigenen Rechnungen zu bezahlen. Was nützt also eine sehr robuste Infrastruktur, wenn der Anbieter auf Grund einer Insolvenz plötzlich nicht mehr erreichbar ist.

Bildquelle: http://www.mobileappz.tv, http://blog.cloudbees.com

Kategorien
News

Ausfall: Salesforce erneut mit schwerwiegenden Problemen

Salesforce.com musste am letzten Dienstag erneut mit Problemen kämpfen. Zwei Wochen nach dem letzten Ausfall, waren die Systeme des CRM Anbieters erneut nicht verfügbar. Die Infrastruktur ist in mehrere unterschiedliche Instanzen weltweit aufgeteilt, um damit die Kunden in verschiedenen Regionen zu erreichen.

Ausfall: Salesforce erneut mit Problemen

Mehrere Instanzen betroffen

Laut dem offiziellen Statusboard zeigten sieben Instanzen am vergangenen Dienstag Probleme, darunter zunächst NA1, NA5 und NA6 in Nordamerika. Kurze Zeit später folgten Ausfälle in den Regionen CS0, CS1, CS3 und CS12, die zu den sogenannten „Sandbox“ Instanzen gehören, welche die Salesforce Kunden für die Entwicklung und Test neuer Funktionen nutzen.

Ursache: Stromausfall

Der Salesforce Application Store war ebenfalls nicht verfügbar, da dieser Infrastruktur aus der Instanz NA6 nutzt. Was die Ursache für den Ausfall war, wurde zunächst nicht bekannt. Später gab Salesforce die Information bekannt, dass es Probleme mit der Stromversorgung gab. Das kennen wir doch irgendwoher, oder?

Kategorien
Management

Netflix: Der Chaos Monkey und die Simian Army – Das Vorbild für eine gute Cloud Systemarchitektur

Die letzten Ausfälle bei den Amazon Web Services (AWS) hier und hier haben gezeigt, dass bei manchen Kunden wie bspw. Instagram, die Systemarchitektur nicht auf das Cloud Computing ausgelegt ist. Und auch wenn AWS so etwas nicht (mehr) passieren darf, sollte man selbst darauf achtgeben, präventiv auf den möglichen Ernstfall vorbereitet zu sein. Eine Möglichkeit ist der von Netflix entwickelte Chaos Monkey und weitere Tools, die ich in diesem Artikel vorstellen möchte.

Üben, Lernen, Testen

Bevor sich Netflix für den Einsatz seines Systems auf den Amazon Web Services entschieden hat (Migration von einer eigenen Infrastruktur), verbrachte das Unternehmen viel Zeit damit, um die AWS Plattform zu verstehen und ein Test-System innerhalb der Infrastruktur aufzubauen. Dabei wurde insbesondere darauf geachtet, soviel realistischen Traffic bzw. Traffic Szenarien wie möglich zu erzeugen, um damit das Test-System auf seine Stabilität hin zu prüfen.

Anfangs entwickelte Netflix dazu einen einfachen Repeater, der die echten und vollständigen Kundenanfragen auf das System innerhalb der AWS Infrastruktur kopierte. Damit identifizierte Netflix die möglichen Engpässe seiner Systemarchitektur und optimierte im Zuge dessen die Skalierbarkeit.

Netflix Rambo Architektur

Netflix selbst bezeichnet seine Software Architektur gerne auch als Rambo Architektur. Das hat den Hintergrund, dass jedes System unabhängig von den anderen Systemen einwandfrei funktionieren muss. Dazu wurde jedes System innerhalb der verteilten Architektur so entwickelt, dass es darauf vorbereitet ist, dass andere Systeme zu denen eine Abhängigkeit besteht, ausfallen können und das dieses toleriert wird.

Sollte das Bewertungssystem ausfallen, verschlechtert sich zwar die Qualität der Antworten, aber es wird dennoch eine Antwort geben. Statt personalisierten Angeboten werden dann nur bekannte Titel angezeigt. Sollte das System, dass für die Suchfunktion zuständig ist, unerträglich langsam sein, muss das Streaming der Filme trotzdem einwandfrei funktionieren.

Der Chaos Monkey

Eines der ersten Systeme die Netflix auf bzw. für AWS entwickelt hat, nennt sich Chaos Monkey. Sein Job ist es zufällig Instanzen und Services innerhalb der Architektur zu zerstören. Damit stellt Netflix sicher, dass alle Komponenten unabhängig voneinander funktionieren, selbst dann wenn Teil-Komponenten ein Problem haben.

Neben dem Chaos Monkey hat Netflix viele weitere Monitoring und Test-Tools für den Betrieb seines Systems auf den Amazon Web Services entwickelt, die das Unternehmen als The Netflix Simian Army bezeichnet.

Latency Monkey

Der Latency Monkey induziert künstliche Verzögerungen im Netflix eigenem REST-Client-Server Communication-Layer, um einen Leistungsabfall zu simulieren und rechtzeitig Maßnahmen zu ergreifen bzw. im Vorwege angemessen zu reagieren. Indem sehr große Verzögerungen erzeugt werden, kann damit zudem der Ausfall eines Nodes oder eines vollständigen Service simuliert werden, ohne diese Instanzen tatsächlich zu zerstören. Damit wird die Fehlertoleranz eines neuen Service überprüft, indem der Ausfall seiner Abhängigkeiten simuliert wird. Der Ausfall dieser Abhängigkeiten wirkt sich dabei jedoch nicht auf den Rest des Systems aus.

Conformity Monkey

Der Conformity Monkey findet Instanzen, die nicht den Best-Practices Anforderungen entsprechen und fährt diese herunter. Wenn z.B. Instanzen gefunden werden, die nicht zu einer Auto-Scaling Group gehören, weiß der Conformity Monkey, dass dieses zu Problemen führen wird. Diese werden also heruntergefahren, um dem Service-Owner die Gelegenheit zu geben, neue Instanzen mit den erwarteten Eigenschaften hochzufahren.

Doctor Monkey

Der Doctor Monkey überprüft die Health Checks, die sich auf jeder Instanz befinden und überwacht zudem weitere Eigenschaften, wie bspw. die CPU-Auslastung, um mögliche Fehlerquellen innerhalb der Instanzen selbst zu erkennen. Werden fehlerbehaftete Instanzen entdeckt, werden diese zunächst automatisch vom Service entfernt. Anschließend erhält der Service-Owner die Gelegenheit die Ursache für den Fehler zu finden und beendet diese Möglicherweise um stattdessen neue Instanzen zu starten.

Janitor Monkey

Der Janitor Monkey sorgt dafür, dass die Netflix Cloud Umgebung effizient betrieben wird und sich kein Müll oder überschüssige Instanzen anhäufen. Dazu sucht er nach ungenutzten Ressourcen und sorgt dafür, dass diese verschwinden.

Security Monkey

Der Security Monkey ist eine Erweiterung des Conformity Monkey. Er findet Sicherheitslücken oder Schwachstellen wie falsch konfigurierte AWS Security Groups und beendet die beanstandeten Instanzen. Er stellt zudem sicher, dass alle SSL-und DRM-Zertifikate gültig sind.

10-18 Monkey

Der 10-18 Monkey (steht auch für Lokalisierung-Internationalisierung bzw. l10n-i18n) erkennt Konfigurations- und Laufzeit Probleme innerhalb von Instanzen, die Kunden in verschiedenen geografischen Regionen, mit unterschiedlichen Sprachen und Zeichensätze bedienen.

Chaos Gorilla

Der Chaos Gorilla ist vergleichbar mit dem Chaos Monkey, simuliert allerdings einen vollständigen Ausfall einer Amazon Availability Zone. Damit wird sichergestellt, dass die Funktionalität des Systems automatisch in andere Availability Zones verschoben wird, ohne das ein manueller Eingriff von Netflix erforderlich ist und das der Nutzer davon etwas bemerkt.

Fazit

Die Simian Army von Netflix ist ein Extrembeispiel wie eine Cloud Architektur auszusehen hat. Das Unternehmen hat viel Zeit, Anstrengungen und Kapital in die Entwicklung seiner Systemarchitektur investiert, die auf der Cloud Infrastruktur der Amazon Web Services läuft. Aber es lohnt sich und jedes Unternehmen, das die Cloud ernsthaft nutzen möchte und ein hochverfügbares Angebot präsentieren will, sollte sich Netflix unbedingt zum Vorbild nehmen.

Kategorien
Analysen

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

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

Kategorien
Analysen

Amazon Web Services (AWS) Ausfall: Erklärungen | Erster Kunde geht | Netflix hält die Treue | Okta versteht die Cloud-Architektur

Nach dem erneuten Ausfall von Teilen der Amazon Web Services (AWS) am vergangenen Freitag und Samstag, von denen große Webseiten und Services wie Netflix und Instagram betroffen waren, gab es in dieser Woche neben einer Stellungnahme von Amazon, ebenfalls Reaktionen von Kunden, die zeigen, dass der Geduldsfaden langsam reißt. Allerdings sind auch selbstkritische Töne zu hören.

Amazon erläutert das Problem

Während einer Stellungnahme am Montag erklärte Amazon, dass seine Rechenzentren an der Ostküste der USA von einem Gewitter am Freitag (29.06.12) betroffen waren. Während die Notstromversorgung bei den meisten wie erwartet funktionierte, kam es bei einem einzigen erneut zu einer Fehlfunktion bei der redundanten Stromversorgung. Der daraus resultierte Stromausfall beeinflusste „eine einstellige Prozentzahl an Kunden“. Darunter Instagram, Netflix, Pinterest, Quora, Heroku und Hootsuite.

Erster Kunde verlässt die Amazon Cloud

Wie die InformationWeek berichtet, hat mit Whatsyourprice.com, einem Online Dating Service, der erste AWS Kunde die Konsequenzen aus dem Ausfall am 29.06/ 30.06 gezogen und seine 10 virtuellen Server in eine Co-Location in Las Vegas umgezogen. Neben dem kürzlichen Ausfall war Whatsyourprice.com bereits vom zwei Stündigen Ausfall am 14.06.12 betroffen. Hinzu kam, dass der letzte Ausfall gerade zu einer Zeit eintrat, während nach Angaben des Unternehmens typischerweise viele Singles online sind.

Laut Whatsyourprice.com basierte die Systemarchitektur auf zwei Availability Zones. Dennoch war das Unternehmen nicht in der Lage neue Instanzen in der nicht von dem Ausfall betroffenen Availability Zone zu starten. Whatsyourprice.com kann sich diesen Umstand nicht erklären, da sie ihrer Meinung nach alles richtig gemacht haben und werden auf Grund dieser Situation nicht mehr auf Amazon EC2 setzen.

Netflix hält die Treue

Netflix, die auch von dem Ausfall betroffen waren, werden der Amazon Cloud hingegen nicht den Rücken kehren. Wie das Unternehmen auf seinem Blog schreibt, hat der Ausfall ein paar Schwächen in seiner Architektur aufgezeigt, die ebenfalls den Chaos Monkey überlistet haben. So habe die eigene Load-Balancing Architektur das gesamte Problem während des Ausfalls noch verstärkt.

Dennoch wird Netflix weiterhin auf die (Amazon) Cloud setzen, da der Service seit dem Wechsel in die Cloud eine bessere Uptime hat als zuvor. Zudem sei die eigene Architektur so ausgelegt, dass ein Ausfall von AWS davon nicht beeinflusst wird. Dafür achtet Netflix darauf, die Services weltweit zu verteilen. Während des Ausfalls in der Region US-EAST, konnten europäische Kunden den Services trotzdem nutzen. Darüber hinaus setzt Netflix auf Cassandra, einem Distributed Cloud Storage, der über alle AWS Zonen und Regionen verteilt ist. Cassandra sorgt dafür, dass der Verlust von einem Drittel aller Nodes innerhalb einer Region aufgefangen wird, ohne Daten zu verlieren oder die Verfügbarkeit zu beeinflussen.

Bitte: Nicht den Fehler von Instagram machen

Netflix selbstkritische Analyse sollte sich auch Instagram oder besser Facebook zu Herzen nehmen. Mich wundert, warum die schlechte Systemarchitektur von Instagram während der Due-Diligence-Prüfung durch Facebook bei der 1,5 Milliarden Dollar hohen Übernahme nicht aufgefallen ist.

Okta, ein Cloud basierter Identity Management Service, setzt ebenfalls auf die Cloud Infrastruktur der Amazon Web Services und war für seine Kunden weltweit zu 100% verfügbar. Das schreibt Okta VP Eric Berg auf dem Unternehmensblog. Demnach sei die Systemarchitektur so konzipiert, dass einzelne Komponenten ohne Weiteres zu jeder Zeit ausfallen können. In diesem Fall werden die Anfrage zu einem funktionsfähigen System „irgendwo auf der Welt“ weitergeleitet. An dieser Stelle sehen wir wieder einmal, dass Cloud Computing nicht bedeutet, einfach nur einen virtuellen Server hochzufahren!

Bildquelle: http://apod.nasa.gov