Kategorien
News

AWS Elastic Beanstalk unterstützt nun Python und eine nathlose Datenbankintegration

AWS Elastic Beanstalk unterstützt nun auch Python Applikationen. Das hat Amazon auf seinem Blog angekündigt. Elastic Beanstalk ist eine Art Platform-as-a-Service (PaaS) von Amazon über den PHP, Java, .NET und nun auch Python Anwendungen ausgerollt und verwaltet werden können. Dazu wird der jeweilige Anwendungscode in die Amazon Cloud hochgeladen und Elastic Beanstalk sorgt für das hochfahren entsprechender Amazon EC2 Instanzen, Load Balancer, das Auto Scaling und Monitoring.

AWS Elastic Beanstalk unterstützt nun Python und eine nathlose Datenbankintegration

Python in der Amazon Cloud

Elastic Beanstalk ist in der Lage Python Applikationen auszuführen, die für den Apache HTTP Server und WSGI bestimmt sind. Das bedeutet, dass Beanstalk ebenfalls Django und Flask Applikationen unterstützt. Neben der AWS Management Console lassen sich Anwendungen zusätzlich über eb und Git mit der Kommandozeilen ausrollen.

Integration mit Amazon RDS

Sollte eine Anwendung eine relationale Datenbank benötigen, ist Elastic Beanstalk in der Lage, eine Amazon RDS Datenbank Instanz für die Anwendung zu starten. Die RDS Datenbank Instanz wird dazu automatisch so konfiguriert, dass sie mit der Amazon EC2 Instanz kommuniziert, auf welcher sich die eigentliche Anwendung befindet.

Anpassen der Python Umgebung

Die eigene Python Laufzeitumgebung für Elastic Beanstalk kann mit einer Reihe von deklarativen Textdateien innerhalb der Anwendung angepasst werden. Sollte die Anwendung bspw. eine requirements.txt in der oberen Verzeichnisebene benötigen, sorgt Elastic Beanstalk mittels pip automatisch dafür, dass die entsprechenden Abhängigkeiten installiert werden.

Darüber bietet Elastic Beanstalk nun einen neuen Konfigurations-Mechanismus, mit dem Pakete über yum installiert, Skripte eingerichtet und Umgebungsvariablen gesetzt werden können. Dazu muss lediglich ein „.ebextensions“ Verzeichnis innerhalb der Python Anwendung erstellt und dieses in die „python.config“ eingetragen werden. Elastic Beanstalk lädt diese Konfigurationsdatei und installiert anschließend die yum Pakete, führt die Skripte aus und setzt die Umgebungsvariablen.

Snapshot der Logdateien erstellen

Um Probleme zu debuggen können ab sofort Snapshots aus der AWS Management Console erstellt werden. Elastic Beanstalk fasst die ersten 100 Zeilen aus verschiedenen Logdateien zusammen. Darunter die Apache Error Log. Die Snapshots werden in Amazon S3 gespeichert und automatisch nach 15 Minuten gelöscht.

Kategorien
News

Die Amazon Web Services erweitern Amazon RDS um weitere Funktionen für Oracle Datenbanken

Die Amazon Web Services haben vier neue Funktionen für Amazon RDS for Oracle präsentiert. Darunter die Möglichkeit, die Datenbank in einer Private Cloud zu betreiben. Dazu können Unternehmen nun RDS (Relational Database Service) Instanzen mit einer Oracle Datenbank innerhalb einer VPC (Virtual Private Cloud) nutzen. Administratoren erhalten, im Vergleich zu einer Standard Instanz oder einer virtuellen Maschine, damit mehr Kontrolle.

Die Amazon Web Services erweiterten Amazon RDS um weitere Funktionen für Oracle Datenbanken

Erweiterter Oracle Support

Weitere neue Funktionen sind die Unterstüzung für Oracle APEX (Application Express), XML DB und Time Zone. Mit Time Zone können Administratoren Informationen zu Timestamps persistent speichern, wenn Benutzer die Amazon Web Services über mehrere Zeitzonen hinweg verteilt einsetzen.

Bei APEX handelt es sich um eine freies Web-basiertes Entwicklungstool für Oracle Datenbanken. Mit dem Tool sollen ebenfalls Entwickler mit geringen Programmierkenntnissen Anwendungen entwickeln und ausrollen können. Das Entwicklungs-Framework für APEX bietet Wizards und Eigenschaftsfenster für die jeweiligen Objekte, mit denen Anwendungen geschrieben und gewartet werden sollen. Amazon RDS unterstützt die APEX Version 4.1.1.

XML DB ist eine Funktion von Oracle Datenbanken und bietet native XML Speicher- und Abfrage-Möglichkeiten.

Amazon RDS for Oracle

Mit Amazon RDS lassen sich Oracle Database 11g auf der Amazon Cloud bereitstellen. Der Service bietet Datenbank-Administrationsaufgaben wie das Provisioning, Backups, Software-Patches, Monitoring und Hardware-Skalierung.

Unternehmen können entweder ihre eigenen Datenbanken-Lizenzen nutzen oder lassen Amazon sich um die Lizenzierung kümmern. Die Preise betragen dann 0,11 Dollar pro Stunde bzw. 0,16 Dollar pro Stunde.

Erst kürzlich hatte Amazon eine Reihe von Verbesserungen für seinen Cloud-basierten Datenbank-Service Dynamo vorgestellt. Darunter die Aktualisierung der DynamoDB Management-Konsole.

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

Amazon Web Services (AWS) präsentieren neuen EC2 High I/O Instanz-Typ mit 2 TB SSD Speicher. Netflix mit erstem Benchmark.

Immer mehr moderne Web- und mobile Applikationen sind von einem hohen I/O Durchsatz abhängig. Für das Darstellen umfangreicher Informationen und Graphiken sowie der Reaktion auf Interaktionen in Echtzeit, sind die Anwendungen darauf angewiesen eine Menge an Daten zu speichern und auf diese zuzugreifen. Die Amazon Web Services (AWS) haben nun darauf reagiert und gestern einen neuen EC2 Instanz-Typ für Anwendungen mit einem hohen I/O Durchsatz und einer geringen Latenz präsentiert. Nach Angaben von Amazon ist die Instanz ideal für den Einsatz von NoSQL Datenbanken wie Cassandra und MongoDB.

Amazon Web Services (AWS) präsentieren neuen EC2 High-Performance Instanz-Typ mit 2 TB SSD Speicher. Netflix mit erstem Benchmark.

Eigenschaften der High I/O EC2 Instanz

Die erste Instanz aus der neuen High I/O Reihe nennt sich High I/O Quadruple Extra Large (hi1.4xlarge) und verfügt über die folgende Spezifikation:

  • 8 virtuelle Kerne, insgesamt 35 ECU (EC2 Compute Units)
  • HVM und PV Virtualisierung
  • 60,5 GB RAM
  • 10 Gigabit Ethernet
  • 2TB lokaler SSD Speicher, ein Paar von jeweils 1TB

Die High I/O Quadruple Extra Large Instanzen stehen aktuell in den Regionen US East (Northern Virginia) und EU West (Ireland) bereit. Die Kosten betragen 3,10 Dollar bzw. 3,41 Dollar pro Stunde.

Netflix präsentiert ersten Benchmark

Netflix Cloud Architekt Adrian Cockcroft hatte bereits im März 2012 während eines Interviews darüber philosophiert, dass es in Zukunft schnellere I/O Mechanismen in der Cloud geben muss und hatte sich den Einsatz von SSDs (Solid-State-Drives) als Speichertechnologie für die Amazon Cloud gewünscht.

Nach Ankündigung der neuen Technologie, lies es sich Cockcroft natürlich nicht nehmen, eigene Test durchzuführen und hat dazu einen umfangreichen Benchmark veröffentlicht, der hier zu finden ist.

Neue EC2 Instance Status Metriken

Neben dem neuen High I/O Instanz-Typ hat AWS ebenfalls weitere Status Metriken für EC2 eingeführt. Es existieren zwei unterschiedliche Tests, die System Status Checks und Instanz Status Checks. Die Ergebnisse der Tests werden auf der AWS Management Console veröffentlicht und können ebenfalls über die Kommandozeile und den EC2 APIs abgerufen werden.

Zudem können die Metriken nun auch über Amazon CloudWatch abgefragt werden. Zu jeder Instanz gehören drei Metriken, die alle 5 Minuten aktualisiert werden:

  • StatusCheckFailed_Instance = „0“ wenn der Instanz-Check positiv ist, ansonsten „1“.
  • StatusCheckFailed_System = „0“ wenn der System-Check positiv ist, ansonsten „1“.
  • StatusCheckFailed = „0“ wenn keiner der beiden oben genannten Wert „0“ ist, sonst „1“.
Kategorien
Analysen

Microsoft attackiert die Amazon Web Services über die Private Cloud

Microsoft portiert seine Cloud Lösungen Windows Azure Web Sites, Virtual Machines und das Service Management Portal auf den Windows Server und ermöglicht es damit Hosting Anbieter ihren Kunden hochverfügbare Webseiten und Infrastructure-as-a-Service Lösungen auf Basis von Microsoft Cloud Technologien anzubieten. Anders als die Google Compute Engine, lassen sich die neuen Microsoft Cloud Lösungen prinzipiell auch in einer Private Cloud aufbauen. Die Cloud Implementierung, die sich bei etablierten Unternehmen tendenziell als die Bevorzugte herausstellt.

Microsoft Hosting Services

Die Microsoft Hosting Services setzten sich im Kern aus der „Windows Server Hosting Platform“, „Infrastructure-as-a-Service“, „Windows Azure“ und den „Business Productivity Hosting Solutions“ zusammen. Dabei bietet die Hosting Plattform ein Framework, Web Server, Datenbanken und weitere Tools, mit denen Web Seiten auf Windows gehostet werden können. Mit dem „Dynamic Data Center Toolkit“ können Web-Hoster on-Demand virtuelle Server, Cluster, Netzwerkinfrastrukturen und Speicherplatz bereitstellen. Über Windows Azure stehen Möglichkeiten zur Verfügung, neue Anwendungen auszurollen sowie neue Cloud Services zu erstellen. Die „Business Productivity Hosting Solutions“ ermöglichen das Anbieten von Business Anwendungen auf Basis von Microsoft Exchange 2010 und SharePoint 2010.

Granularer wird zwischen „Web Sites“, „Virtual Machines“, dem „Service Management Portal“ und einer „API“ unterschieden.

Web Sites

Mit „Web Sites“ können hochverfügbare und skalierbare Webseiten-Infrastrukturen aufgebaut werden, mit denen man über 10.000 Seiten in einer einzigen Web Farm verwalten kann. Zudem werden unterschiedliche Frameworks und Sprachen wie ASP.NET, ASP, PHP und Node.js mit einer vollständigen Git Integration unterstützt.

Virtual Machines

Zusammen mit bekannten Microsoft Technologien wie System Center und Windows Server lassen sich Infrastructure-as-a-Service Angebote aufbauen, mit denen virtuelle Machinen mit Windows Server und Linux bereitgestellt werden.

Service Management Portal und API

Anhand einer Metro-basierten Oberfläche und einem Self-Service Portal lassen sich „Web Sites“ und „Virtual Machines“ verwalten. Mit einer REST-basierten API lässt sich das Portal anpassen und erweitern, um damit bspw. andere Portal anzubinden.

Amazon ist ein reiner Service Anbieter

Auch wenn sich das neue Microsoft Angebot in erster Linie an Hosting-Anbieter richtet, sollte man nicht vergessen, wie einfach es ist, die Lösungen für die Private Cloud verfügbar zu machen.

Die Amazon Web Services verstehen es zwar hochwertige Public Cloud IaaS auszuliefern. Wenn es um die on-Premise Anforderungen von Unternehmen geht, hat Microsoft hier allerdings die Nase vorn. Wo AWS in der Cloud geboren ist und langsam damit anfangen muss, etablierte Kunden von der Basis abzuholen, um das große Geschäft zu machen, kommt Microsoft aus dem on-Premise Bereich und ist hier mit Abstand Marktführer.

Zudem weiß Microsoft, was es bedeutet, Software anzubieten, diese zu warten, Updates auszuliefern usw. Amazon ist ein reiner Service Anbieter und ist in kurzer Zeit nicht in der Lage diese Expertise und vor allem die notwendigen Vertriebskanäle aufzubauen.

Private Cloud wird bevorzugt

Und genau darin besteht auch Microsofts großer Vorteil. Das Unternehmen befindet sich bereits dort, wo die meisten Unternehmen gerne bleiben möchte, in den eigenen vier Wänden ihres Rechenzentrums, in der Private Cloud. Laut einer KPMG-Studie haben fast 60% (400 Befragte) der IT-Entscheider gute Erfahrung mit Private Cloud Lösungen gemacht. 21% wollen in Zukunft hier gezielter investieren. Dabei fließen bereits 19% des IT-Budgets in die Private Cloud, bevorzugt in Infrastructure-as-a-Services.

Für das Jahr 2013 wollen ein Drittel der befragten Unternehmen 26% – 50% ihres IT-Budget in die Private Cloud stecken. Darüber hinaus interessieren sich ca. 90% der Unternehmen nicht(!) für die Public Cloud, wobei 6% diese nutzen und 7% darüber nachdenken.

Amazons einziger Private Cloud Anker heißt Eucalyptus

Man kann sich nun die Frage stellen, ob AWS überhaupt daran interessiert ist, mit Microsoft in der Private Cloud in den Wettbewerb zu ziehen. Egal wird es ihnen allerdings nicht sein, das haben Maßnahmen zu Beginn des Jahres gezeigt.

Genauer geht es um den Deal der Amazon Web Services mit Eucalyptus Inc., die einen Fork der Amazon Web Services für die Private Cloud anbieten. Die Kooperation ist so aufgebaut, das Entwickler aus beiden Unternehmen Lösungen schaffen werden, um Private Cloud Lösungen auf Basis von Eucalyptus mit der Amazon Infrastruktur nahtlos zu verbinden. Zudem sollen die Kunden für die Nutzung von AWS als auch Eucalyptus dieselben Management Tools verwenden können. Darüber hinaus soll die Kompatibilität beider APIs verbessert werden.

Eucalyptus ist derzeit also der einzige Weg für die Amazon Web Services in die Rechenzentren der Unternehmen, wo Microsoft bereits wartet.

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

Kategorien
News

Amazon Web Services (AWS) erneut mit Ausfall. Wieder ein Stromausfall. Wieder in North Virginia. Schwere Stürme sind die Ursache.

Es scheint sich langsam zu einer never ending story zu entwicklen. Die Amazon Web Services (AWS) haben erneut mit einem Ausfall in der Region US-EAST-1 in North Virginia zu kämpfen. Dabei handelt es sich, wie erst kürzlich, um einen Stromausfall. Dieses Mal auf Grund schwerer Stürme.

Schwere Stürme sind für den Ausfall verantwortlich

Grund für den Stromausfall sind laut dem Stromversorger Dominion Virginia Power schwere Stürme mit 80 Meilen pro Stunde, welche die Netzteile zerstört haben die zu massiven Schäden geführt haben. Dominion Virginia Power versorgt mehrere Rechenzentren in der Region Virginia.

A line of severe storms packing winds of up to 80 mph has caused extensive damage and power outages in Virginia. Dominion Virginia Power crews are assessing damages and will be restoring power where safe to do so. We appreciate your patience during this restoration process. Additional details will be provided as they become available.

Viele Amazon Services betroffen

Von dem Ausfall sind dieses Mal deutlich mehr Services betroffen, als noch bei dem Ausfall vor zwei Wochen. Darunter Amazon CloudSearch, Amazon CloudWatch, Amazon Elastic Compute Cloud, Amazon Elastic MapReduce, Amazon ElastiCache, Amazon Relational Database Service und AWS Elastic Beanstalk.

Hier das Protokoll des Ausfalls.

Amazon CloudSearch (N. Virginia)

10:16 PM PDT We are investigating elevated error rates impacting a limited number customers. The high error rates appear related to a recent loss of power in a single US-EAST-1 Availability Zone. We are working to recover the impacted search domains and reduce the error rates which they are experiencing.

Amazon CloudWatch (N. Virginia)

8:48 PM PDT CloudWatch metrics for EC2, ELB, RDS, and EBS are delayed due to lost power due to electrical storms in the area. CloudWatch alarms set on delayed metrics may transition into INSUFFICIENT DATA state. Please see EC2 status for the latest information.
10:19 PM PDT CloudWatch metrics and alarms are now operating normally.

Amazon Elastic Compute Cloud (N. Virginia)

8:21 PM PDT We are investigating connectivity issues for a number of instances in the US-EAST-1 Region.
8:31 PM PDT We are investigating elevated errors rates for APIs in the US-EAST-1 (Northern Virginia) region, as well as connectivity issues to instances in a single availability zone.
8:40 PM PDT We can confirm that a large number of instances in a single Availability Zone have lost power due to electrical storms in the area. We are actively working to restore power.
8:49 PM PDT Power has been restored to the impacted Availability Zone and we are working to bring impacted instances and volumes back online.
9:20 PM PDT We are continuing to work to bring the instances and volumes back online. In addition, EC2 and EBS APIs are currently experiencing elevated error rates.
9:54 PM PDT EC2 and EBS APIs are once again operating normally. We are continuing to recover impacted instances and volumes.
10:36 PM PDT We continue to bring impacted instances and volumes back online. As a result of the power outage, some EBS volumes may have inconsistent data. As we bring volumes back online, any affected volumes will have their status in the „Status Checks“ column in the Volume list in the AWS console listed as „Impaired.“ If your instances or volumes are not available, please login to the AWS Management Console and perform the following steps: 1) Navigate to your EBS volumes. If your volume was affected and has been brought back online, the „Status Checks“ column in the Volume list in the console will be listed as „Impaired.“ 2) You can use the console to re-enable IO by clicking on „Enable Volume IO“ in the volume detail section. 3) We recommend you verify the consistency of your data by using a tool such as fsck or chkdsk. 4) If your instance is unresponsive, depending on your operating system, resuming IO may return the instance to service. 5) If your instance still remains unresponsive after resuming IO, we recommend you reboot the instance from within the Management Console. More information is available at: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html

Amazon ElastiCache (N. Virginia)

8:43 PM PDT This service is currently affected by a power event. Please see the EC2 status for further information.
9:25 PM PDT We can confirm that a large number of cache clusters are impaired. We are actively working on recovering them.
10:21 PM PDT We are continuing to recover impacted Cache Nodes. Our APIs are operating normally.

Amazon Relational Database Service (N. Virginia)

8:33 PM PDT We are investigating connectivity issues for a number of RDS Database Instances in the US-EAST-1 region.
9:24 PM PDT We can confirm that a large number of RDS instances are impaired. We are actively working on recovering them.
10:43 PM PDT RDS APIs are operating normally. We are continuing to recover impacted RDS instances and volumes.

AWS Elastic Beanstalk (N. Virginia)

9:00 PM PDT This service is currently affected by a power event. Please see the EC2 status for further information.

Erneut bekannte Webseiten und Services betroffen

Der Ausfall hat mit Instagram, Pinterest und Netflix wieder viele bekannte Webseiten und Services betroffen. Ebenfalls der PaaS Anbieter Heroku, der viele Startups und mobile Anwendungen zu seinen Kunden zählt ist betroffen. Wohingegen Pinterest und Netflix erreichbar sind, ist Instagram vollständig down. Erst am 14. Juni 2012 gab es in North Virginia einen Stromausfall im Amazon Rechenzentrum.