Schlagwort: Amazon

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
Analysen

Der Ausfall der Amazon Web Services (AWS) zeigt die schlechte Systemarchitektur von Instagram

Auf Grund eines erneuten Ausfalls der Amazon Web Services (AWS) vom 29.06.12 bis 30.06.12 hatten viele Services, darunter populäre Seiten wie Pinterest, Netflix, Instagram und Heroku mit Problemen zu kämpfen. Wohingegen auf Netflix und Pinterest, zumindest hier aus Europa, zugegriffen werden konnte, war Instagram vollständig down. Auf Twitter begann währenddessen eine Wut-Welle gegen die Amazon Web Services, weil das geliebte Instagram nicht genutzt werden konnte. Von Cloud Computing und Marketing Bullshit war die Rede. Was die Nutzer natürlich nicht wissen konnten, es war die schlechte Systemarchitektur von Instagram selbst, die dafür gesorgt hat, dass der Bilderservice nicht erreichbar war.

Schwere Stürme führten zu dem Ausfall

Grund für den Stromausfall waren laut dem Stromversorger Dominion Virginia Power schwere Stürme mit 80 Meilen pro Stunde, die zu massiven Schäden geführt haben. Dominion Virginia Power versorgt mehrere Rechenzentren in der Region Virginia. In­fol­ge­des­sen viel die Stromversorgung für das Amazon Rechenzentrum aus, was erneut zu einer Kaskade von Problemen innerhalb der einzelnen Services der Amazon Cloud führte.

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.

Zahlreiche Amazon Services betroffen

Der Ausfall betraf dieses Mal deutlich mehr Services, 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.

Instagram nutzt nur eine Region

Von dem Ausfall war nur die Availability Zone US-EAST-1 betroffen, die sich in North Virginia befindet. Alle anderen weltweit verteilten Amazon Regionen zeigten keine Fehler und liefen weiterhin stabil. Anders als von dem Ausfall betroffene Anbieter wie Netflix oder Pinterest, war Instagram weltweit überhaupt nicht erreichbar. Das führt eindeutig zu dem Ergebnis, dass Instagram seine Systeme ausschließlich in dieser einen Amazon Region, der US-EAST-1, laufen lässt. Die Entscheider und Systemarchitekten müssen sich daher die Frage gefallen lassen, warum ein mittlerweile so populärer Dienst, der für 1 Milliarde US-Dollar an Facebook verkauft wurde, nicht hochverfügbar ausgelegt ist, indem die Systeme über mehrere Regionen bzw. Availability Zones in der Amazon Cloud verteilt sind. Scheinbar hat Instagram aus den Fehlern anderer Amazon Kunden nicht gelernt, die von den bisherigen Ausfällen betroffen waren.

Für den Fehlerfall vorbereitet sein

Selbstverständlich darf man Amazon von diesem erneuten Ausfall auf keinen Fall freisprechen. Die Region US-EAST-1 in North Virginia scheint zum Problemkind zu werden. Dennoch weißt Amazon regelmäßig und vehement darauf hin: „Design for failure!“

Hierfür hat das Unternehmen eine Webseite geschaffen, auf der Whitepapers zum Download bereitstehen, die dabei helfen, fehlertolerante Anwendungen zu entwickeln und Cloud Architekturen zu verstehen. Dazu gehören u.a. die Folgenden.

AWS Cloud Architecture Best Practices Whitepaper

Dieses Whitepaper gibt einen technischen Überblick aller AWS Services und verschiedener Best Practice Ansätze für die architektonische Gestaltung, um damit effiziente und skalierbare Architekturen zu entwerfen.
Link

Building Fault-Tolerant Applications on AWS Whitepaper

In diesem Whitepaper werden Funktionen für die Erhöhung der Fehlertoleranz vorgestellt, die dazu dienen, um hoch zuverlässige und hochverfügbare Anwendungen innerhalb der AWS Cloud zu entwickeln.
Link

Web Hosting Best Practices Whitepaper

Dieses Whitepaper überprüft detailliert Lösungen für das Web Application Hosting. Dazu gehört unter anderem, wie jeder AWS Service genutzt werden kann, um eine hochverfügbare und skalierbare Webanwendung zu entwerfen.
Link

Leveraging Different Storage Options in the AWS Cloud Whitepaper

Dieses Whitepaper dient dazu, einen Überblick über die Speichermöglichkeiten in der AWS Cloud zu geben und darüber hinaus Szenarien vorzustellen, um eine effektive Nutzung zu erzielen.
Link

AWS Security Best Practices Whitepaper

In diesem Whitepaper werden bestimmte Tools, Funktionen und Richtlinien beschrieben, um zu verstehen, wie Cloud Anwendungen innerhalb der AWS Infrastruktur von Grund auf geschützt werden können.
Link

Netflix und sein Chaos Monkey

Ein Grund warum Netflix ein so robustes und hochverfügbares System auf der Amazon Cloud betreibt, ist der selbst entwickelte und sogenannte Chaos Monkey. Der Chaos Monkey hilft Netflix dabei sicherzustellen, dass alle einzelnen Komponenten unabhängig voneinander arbeiten. Dazu zerstört der Chaos Monkey wahllos Instanzen und Services innerhalb der Netflix AWS Infrastruktur, um seinen Entwicklern dabei zu helfen, zu gewährleisten, dass jede einzelne Komponente antwortet, auch wenn die System-Abhängigkeiten nicht einwandfrei funktionieren.

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.

Kategorien
Analysen

Google Cloud Platform vs. Amazon Web Services – Ein erster Vergleich

Nachdem Google sein Cloud Portfolio mit der Compute Engine erweitert hat, fangen erste Medien an darin den Killer der Amazon Web Services zu sehen. Ein Grund mal die Cloud Services von Google und Amazon gegenüberzustellen. Wer sich für einen direkten Vergleich von Microsoft Windows Azure mit den Amazon Web Services interessiert, sollte hier weiterlesen.

Der Vergleich: Google Cloud vs. Amazon Cloud

Die folgende Tabelle stellt das Cloud Services Portfolio 1:1 gegenüber und schafft Klarheit, wer in welchem Bereich was anbietet, wie der Name des jeweiligen Service lautet und unter welcher URL weitere Informationen zu diesem zu finden sind.

Funktion

Amazon Web Services

Google Cloud Platform

Rechenleistung
Virtuelle Maschinen Elastic Compute Cloud Full Virtual Machines (Google Compute Engine)
High Performance Computing Cluster Compute Instances
–
MapReduce Elastic Map Reduce Google App Engine
Dynamische Skalierung Auto Scaling Google Compute Engine

Speicher
Unstrukturierter Speicher Simple Storage Service Google Cloud Storage
Flexible Entities SimpleDB
–
Block Level Storage Elastic Block Store Persistent disk (Google Compute Engine)

Datenbanken
RDBMS Relational Database Service Google Cloud SQL, BigQuery
NoSQL DynamoDB „Google F1“

Caching
CDN CloudFront
–
In-Memory ElastiCache
–

Netzwerk
Load Balancer Elastic Load Balancer
–
Hybrid Cloud Virtual Private Cloud
–
Peering Direct Connect
–
DNS Route 53 Public DNS

Messaging
Async Messaging Simple Queue Service
–
Push Notifications Simple Notification Service
–
Bulk Email Simple Email Service
–

Monitoring
Ressourcen Monitoring CloudWatch
–

Sicherheit
Identitätsmanagement Identity Access Management
–

Deployment
Ressourcenerstellung CloudFormation
–
Web Application Container Elastic Beanstalk Google App Engine

Wie man sieht, ist das Google Cloud Portfolio im Vergleich zum Service Angebot der Amazon Web Services noch sehr dünn. Falls ich etwas bei Google übersehen habe, macht mich darauf bitte aufmerksam. Ich werde das dann umgehend nachtragen.

Kategorien
News

Google präsentiert sein eigenes Infrastructure-as-a-Service Angebot offenbar während der Google I/O

Nachdem bereits Mitte Mai erste Gerüchte um ein Infrastructure-as-a-Service (IaaS) Angebot aus dem Hause Google aufkamen, spekuliert GigaOm weiter, dass der Suchmachinengigant den Service in dieser Woche während seiner jährlichen Entwicklerkonferenz Google I/O in San Francisco präsentieren wird.

Google präsentiert sein eigenes Infrastructure-as-a-Service Angebot offenbar während der Google I/O

Google steht im Markt zwei festen Größen gegenüber. Zum einen die Amazon Web Services, zum anderen Microsoft Windows Azure. Da auch Microsoft sein ursprüngliches Platform-as-a-Service Angebot mittlerweile zu einem vollständigen Cloud Stack mit IaaS ausgebaut hat, sieht es danach aus, dass sich ein Dreikampf um die Vorherrschaft in der Cloud entwickeln wird.

Wie Googles Strategie in der Cloud aussehen wird ist schwierig vorherzusagen. Auf der einen Seite gehört die Entwicklergemeinde zu Googles Zielgruppe, die wiederum auch zu Microsoft Schwerpunkt zählt und in dem die Redmonder wirklich sehr stark aufgestellt sind. Zum anderen wird sich Amazon als der größte Mitbewerber im IaaS Bereich herausstellen, die ebenfalls die Entwickler Communities beackern und sich zudem um Microsoft Entwickler bemühen.

Während Amazon derzeit noch verstärkt um die Startups dieser Welt bemüht ist und langsam versucht in die Unternehmen zu gelangen, bleibt der Markt für etablierte Unternehmenskunden den Public Cloud Playern dennoch weitestgehend verschlossen. Ob Google daran etwas ändern kann wird sich zeigen. Allerdings kristallisiert sich langsam der Trend heraus, dass Unternehmen sich vermehrt auf die Private Cloud konzentrieren und Entwickler sowie Startups sich zunächst die Public Cloud zu nutze machen. Letztendlich geht es immer um den Use Case.

Kategorien
News

Wenn der Kuchen spricht, haben die Krümel Pause: So sieht Amazon CTO Werner Vogels die Cloud in 5 Jahren

Er ist der weltweit einflussreichste Manager, wenn es um das Thema Cloud Computing geht und wird vereinzelnd schon als Cloud Rockstar bezeichnet, Amazon CTO Werner Vogels. Werner ist die treibende Kraft hinter den Amazon Web Services und hatte mit seiner damaligen Dissertation „Scalable Cluster Technologies for Mission-Critical Enterprise Computing“ zumindest im Geiste bereits die Amazon Cloud geschaffen. Auf der diesjährigen GigaOM Structure 2012 warf er einen Blick in sein Orakel und erzählte wie sich die Cloud seiner Meinung nach von heute bis ins Jahr 2017 verändern wird.

Die Amazon Web Services werden noch günstiger

Werner verspricht, das Amazon in Zukunft sein Preismodell weiterhin verbessern wird. „Wenn man zurück schaut, sieht man, dass wir unsere Preise bereits 20 mal verringert haben. Das Beste ist, dieses auch weiterhin zu tun. Das ist unser Ziel.“

Die Startup Szene wird sich weiter vergrößern

Das Amazon Startups liebt, wissen wir ja bereits. Mit Socialcam, Pinterest und Instagram nennt er nur ein paar Beispiele von jungen Unternehmen, die sich die Cloud zu nutze gemacht haben, um auf ihr schnell skalieren zu können und freut sich schon auf weitere neue Startups. Werner nennt dieselben Argumente, die auch ich immer gerne wieder nutze. „Wären sie in der Lage gewesen ihre Unternehmen in einer traditionellen Welt von Hardware und Infrastruktur aufzubauen? Ich denke nicht! Wir werden viele junge Unternehmen sehen, die völlig neue Dinge bauen werden.“

CIOs werden auf junge Unternehmen hören

Wenn es um IT-Lösungen geht, die erst durch die Cloud entstanden sind, „werden CIOs bereit sein, auf junge Unternehmen zu hören.“ „Vor fünf Jahren hätten sie nur mit den großen Jungs gesprochen.“ Dies wird sich weiter verändern.

Alte Hardware Unternehmen werden gegen das Aussterben kämpfen

HP und die anderen klassischen Hardware Unternehmen müssen sich anpassen um zu überleben. „Ich glaube wenn Unternehmen wirklich eine neue Cloud-Mentalität verinnerlichen – nicht nur eine Cloud im Angebot haben, sondern ein echter Partner für ihre Kunden sind statt nur ein Verkäufer zu sein – und Ihnen helfen Kosten einzusparen, werden CIOs sich auch junge Unternehmen anschauen, die überall auftauchen.“ „Ich sehe CIOs die mittlerweile bereit sind mehr Risiko einzugehen“, so Werner. „Wenn sich Dinosaurier nicht verändern, nun ja wir wissen was mit den Dinosaurier passiert ist.“

Werner Vogels Video auf der GigaOM Structure 2012

Watch live streaming video from gigaomstructure at livestream.com

Bildquelle: http://www.allthingsdistributed.com

Kategorien
News

Armutszeugnis: Cloud Computing Ausfälle haben seit 2007 mehr als 71 Million US-Dollar an Kosten verursacht.

Seit 2007 haben 568 Stunden Ausfallzeit von 13 namhaften Cloud Services mehr als 71.700,000 US-Dollar an Kosten verursacht, das sagt zumindest die 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. Ein Armutszeugnis für die Public Cloud Anbieter?

Mit „Availability Ranking of World Cloud Computing (ARWC)“ handelt es sich um die erste Publikation der im März 2012 von ParisTech und 13 pariser Universitäten gegründeten Gruppe. Grundlage ihrer Forschung sind Presseberichte von Cloud Computing Ausfällen von Services wie Twitter, Facebook, Amazon, Microsoft, Google, Yahoo, Paypal und Weiteren.

Public Cloud Anbieter stehen unter Druck

Seit die Cloud Anbieter damit begonnen haben, immer mehr staatliche Einrichtungen und weltweit agierende Unternehmen anzusprechen wird es zunehmend wichtiger, dass die bereitsgestellten Services zuverlässig arbeiten, insbesondere dann, wenn es sich um geschäftskritische Systeme handelt. Das scheinen die Cloud Anbieter aber scheinbar nicht zu 100% verinnerlicht zu haben.

Die Kosten pro Ausfall sind nicht zu vernachlässigen

Die Forscher fanden heraus, dass die Kosten für einen einstündigen Ausfall variieren. Der Reiseanbieter Amadeus hätte demnach mit 89.000 US-Dollar zu rechnen, Paypal hingegen mit 225.000 US-Dollar pro Stunde. Die Zahlen basieren auf den stündlichen Kosten, mit der die jeweilige Industrie in ihrem Markt rechnet. Ausfälle bei Unternehmen wie Google, Microsoft und Amazon belaufen sich, laut den Forschern, auf schätzungsweise 200.000 US-Dollar pro Stunde.

Neben den wirtschaftlichen Auswirkungen für den Service Anbieter, sollte hier aber nicht der Kunde aus den Augen verloren werden. Der ist viel wichtiger! Manche Ausfälle haben sich schließlich schon über mehrere Tage hingezogen.

Der Zustand ist wahrscheinlich noch viel schlimmer

Die Forscher merken an, dass ihre Vorgehensweise nicht perfekt sei, da die vorliegenden Informationen bei weitem nicht vollständig seien. Sie gehen daher davon aus, das sie die vorliegenden Zahlen wahrscheinlich unterschätzen. Viele Ausfälle wurden von der Presse nicht publiziert, was viel Platz für weitere bietet. Darüber hinaus standen den Forschern ebenfalls nicht die exakten Werte für die wirtschaftlichen Kosten pro Ausfall oder die durchschnittlichen Kosten pro Stunde von jedem Cloud Anbieter zur Verfügung.

Liebe Anbieter entschädigt richtig!

Wie ich erst vorgestern geschrieben habe, sind Public Cloud Ausfälle nun einmal öffentlich. Probleme in einem privaten Rechenzentrum interessieren niemanden. Kein Journalist würde darüber berichten, da es einfach langweilig ist und keine Leser anziehen würde.

Aber der „Witz“ an der ganzen Cloud Ausfall Geschichte ist, dass die Cloud Anbieter lediglich die Kosten für den Zeitraum, in welchem der Service nicht verfügbar war, erlassen. So haben Azure Nutzer für den Ausfall am 29. Februar eine Gutschrift über 33% erhalten. Amazon ist hier nicht besser.

Es ist ja schön und gut und vor allem zwingend erforderlich, dass man als Nutzer zumindest nicht einen Service berechnet bekommt, der nicht funktioniert. Wo kommen wir denn dahin: Pay as you go! Aber die Cloud Anbieter müssen hier etwas ändern, sonst werden sie von Seiten der Kunden früher oder später ihr blaues Wunder erleben. Sie müssen sich an dieser Stelle mit mehr Transparenz und Glaubwürdigkeit durch eine strengere Selbstkontrolle und Verpflichtung gegenüber ihren Kunden abheben.

Die Erstattung der Kosten für einen nicht verfügbaren Service ist das eine. Aber wie schaut es mit Vertragsstrafen aus, wenn ich als Unternehmen auf Grund des Ausfalls meinen Kunden wiederum nicht die erwartete Serviceleistung erbringen kann und von diesem wiederum in Regress genommen werde bzw. wenn ich dadurch Umsatzeinbußen habe. Hier halten sich die Cloud Anbieter derzeit (noch) schön raus. Ich denke hier gibt es eine Menge Stoff für Diskussionen. Rechtsanwälte bitte zuerst. 😛

Bildquelle: http://www.deerns.nl