Categories
Analysen

Amazon EBS: Wann beseitigen die Amazon Web Services ihren Single Point of Failure?

Innerhalb kürzester Zeit standen die Amazon Web Services in der Region US-EAST-1 in North Virginia wieder still. Zum einen am 19. August 2013, wobei anscheinend ebenfalls Amazon.com mit in die Tiefe gezogen wurde und zuletzt am 25. August 2013. Ursachen sollen wieder Unwetter gewesen sein. Dabei hat es dann natürlich auch wieder die üblichen Verdächtigen, allen voran Instagram und Reddit, erwischt. Instagram scheint vehement auf seine Cloud-Architektur zu vertrauen, die ihnen regelmäßig um die Ohren fliegt, wenn in North Virginia der Blitz einschlägt. Allerdings muss auch Amazon AWS scheinbar langsam etwas an seiner Infrastruktur verändern, denn so darf es nicht weitergehen.

US-EAST-1: Alt, günstig und brüchig

Die Amazon Region US-East-1 ist die älteste und meist genutzte Region in Amazons Cloud Computing Infrastruktur. Das hängt zu einem damit zusammen, das die Kosten im Vergleich zu anderen Regionen hier deutlich günstiger sind, wobei die Region Oregon mittlerweile preislich angepasst wurde. Zum anderen befinden sich hier auf Grund des Alters auch viele ältere Kunden mit vermutlich nicht für die Cloud optimierten Systemarchitekturen.

Alle Eier in einem Nest

Den Fehler, den die meisten Nutzer begehen ist, dass sie sich nur auf eine Region, in diesem Fall US-East-1, verlassen. Fällt diese aus, ist auch der eigene Service natürlich nicht mehr erreichbar. Das gilt für alle weltweiten Amazon Regionen. Um diese Situation zu umgehen, sollte ein Multi-Regionen Konzept gewählt werden, indem die Anwendung skalierbar und hochverfügbar über mehrere Regionen verteilt wird.

Amazon EBS: Single Point of Failure

Ich habe bereits im vergangenen Jahr die These aufgestellt, dass die Amazon Web Services über einen Single Point of Failure verfügen. Im Folgenden sind die Statusmeldungen vom 25. August 2013 zu sehen, die meine These unterstreichen. Das erste Mal bin ich durch einen Blogeintrag vom Amazon AWS Kunden awe.sm darauf aufmerksam geworden, die von ihren Erfahrungen in der Amazon Cloud berichten. Die fett markierten Stellen sind von entscheidender Bedeutung.

EC2 (N. Virginia)
[RESOLVED] Degraded performance for some EBS Volumes
1:22 PM PDT We are investigating degraded performance for some volumes in a single AZ in the US-EAST-1 Region
1:29 PM PDT We are investigating degraded performance for some EBS volumes and elevated EBS-related API and EBS-backed instance launch errors in a single AZ in the US-EAST-1 Region.
2:21 PM PDT We have identified and fixed the root cause of the performance issue. EBS backed instance launches are now operating normally. Most previously impacted volumes are now operating normally and we will continue to work on instances and volumes that are still experiencing degraded performance.
3:23 PM PDT From approximately 12:51 PM PDT to 1:42 PM PDT network packet loss caused elevated EBS-related API error rates in a single AZ, a small number of EBS volumes in that AZ to experience degraded performance, and a small number of EC2 instances to become unreachable due to packet loss in a single AZ in the US-EAST-1 Region. The root cause was a “grey” partial failure with a networking device that caused a portion of the AZ to experience packet loss. The network issue was resolved and most volumes, instances, and API calls returned to normal. The networking device was removed from service and we are performing a forensic investigation to understand how it failed. We are continuing to work on a small number of instances and volumes that require additional maintenance before they return to normal performance.
5:58 PM PDT Normal performance has been restored for the last stragglers of EC2 instances and EBS volumes that required additional maintenance.

ELB (N. Virginia)
[RESOLVED] Connectivity Issues
1:40 PM PDT We are investigating connectivity issues for load balancers in a single availability zone in the US-EAST-1 Region.
2:45 PM PDT We have identified and fixed the root cause of the connectivity issue affecting load balancers in a single availability zone. The connectivity impact has been mitigated for load balancers with back-end instances in multiple availability zones. We continue to work on load balancers that are still seeing connectivity issues.
6:08 PM PDT At 12:51 PM PDT, a small number of load balancers in a single availability zone in the US-EAST-1 Region experienced connectivity issues. The root cause of the issue was resolved and is described in the EC2 post. All affected load balancers have now been recovered and the service is operating normally.

RDS (N. Virginia)
[RESOLVED] RDS connectivity issues in a single availability zone
1:39 PM PDT We are currently investigating connectivity issues to a small number of RDS database instances in a single availability zone in the US-EAST-1 Region
2:07 PM PDT We continue to work to restore connectivity and reduce latencies to a small number of RDS database instances that are impacted in a single availability zone in the US-EAST-1 Region
2:43 PM PDT We have identified and resolved the root cause of the connectivity and latency issues in the single availability zone in the US-EAST-1 region. We are continuing to recover the small number of instances still impacted.
3:31 PM PDT The majority of RDS instances in the single availability zone in the US-EAST-1 Region that were impacted by the prior connectivity and latency issues have recovered. We are continuing to recover a small number of remaining instances experiencing connectivity issues.
6:01 PM PDT At 12:51 PM PDT, a small number of RDS instances in a single availability zone within the US-EAST-1 Region experienced connectivity and latency issues. The root cause of the issue was resolved and is described in the EC2 post. By 2:19 PM PDT, most RDS instances had recovered. All instances are now recovered and the service is operating normally.

Amazon EBS bildet die Basis vieler anderer Services

Die fett markierten Stellen sind aus diesem Grund von entscheidender Bedeutung, da alle diese Services gleichzeitig von einem einzigen Service abhängig sind: Amazon EBS. Zu dieser Erkenntnis ist awe.sm während seiner Analyse gekommen. Wie awe.sm festgestellt hat, ist EBS so gut wie immer das Hauptproblem größerer Ausfälle bei Amazon. So auch in dem obigen Ausfall. Mehr zum Amazon Elastic Block Store.

Zu den Services die von Amazon EBS abhängig sind gehören u.a. der Elastic Load Balancer (ELB), die Relational Database Service (RDS) oder Elastic Beanstalk.

Q: What is the hardware configuration for Amazon RDS Standard storage?
Amazon RDS uses EBS volumes for database and log storage. Depending on the size of storage requested, Amazon RDS automatically stripes across multiple EBS volumes to enhance IOPS performance.

Quelle: http://aws.amazon.com/rds/faqs/

EBS Backed
EC2: If you select an EBS backed AMI
ELB: You must select an EBS backed AMI for EC2 host
RDS
Elastic Beanstalk
Elastic MapReduce

Quelle: Which AWS features are EBS backed?

Load balancing across availability zones is excellent advice in principle, but still succumbs to the problem above in the instance of EBS unavailability: ELB instances are also backed by Amazon’s EBS infrastructure.

Quelle: Kommentar – How to work around Amazon EC2 outages

Wie man sieht hängen nicht wenige Services von Amazon EBS ab. Das bedeutet im Umkehrschluss, fällt EBS aus, sind diese Services ebenfalls nicht mehr verfügbar. Besonders tragisch verhält es sich mit dem Amazon Elastic Load Balancer (ELB), der dafür zuständig ist, im Fehlerfall oder bei großer Last den Datenverkehr zu leiten. Fällt also Amazon EBS aus und soll der Datenverkehr daraufhin in eine andere Region übertragen werden, funktioniert das nicht, da der Load Balancer ebenfalls von EBS abhängig ist.

Ich kann mich irren. Schaut man sich jedoch die vergangenen Ausfälle an, sprechen die Indizien dafür, dass Amazon EBS die zentrale Fehlerquelle innerhalb der Amazon Cloud ist.

Es darf daher die Frage erlaubt sein, ob einem Leader ständig dieselbe Komponente seiner Infrastruktur um die Ohren fliegen darf, die im Prinzip sogar als Single Point of Failure zu betrachten ist? Und ob ein Infrastructure-as-a-Service (IaaS) Anbieter, der die meisten Ausfälle von allen Anbietern am Markt zu verzeichnen hat, unter diesem Gesichtspunkt als Leader zu bezeichnen ist. Auch wenn ich immer wieder propagiere, dass man als Nutzer eines Public IaaS selbst für die Skalierbarkeit und Hochverfügbarkeit sorgen muss, hat der Anbieter selbst dennoch die Pflicht dafür zu sorgen, dass die Infrastruktur zuverlässig funktioniert.

Categories
News

Ein abgelaufenes SSL-Zertifikat zwingt Microsoft Windows Azure Storage weltweit(!) in die Knie

Seit Freitag, dem 22. Februar, 12:44 PM PST leidet Microsoft Windows Azure Storage weltweit(!) unter massiven Problemen. Grund hierfür ist ein abgelaufenes SSL-Zertifikat. Der Ausfall hat ebenfalls von Azure Storage abhängige Services in Mitleidenschaft gezogen (siehe Screenshot). Derzeit arbeitet Microsoft an der Wiederherstellung aller Services. Erste Test Deployments zeigen anscheinend Erfolg. Mehr unter dem Windows Azure Service Dashboard.

Ein abgelaufenes SSL-Zertifikat zwingt Microsoft Windows Azure Storage weltweit(!) in die Knie

Schade, wo Windows Azure Storage erst kürzlich einen Nasuni Performance Wettkampf gegen Amazon S3 gewonnen hat.

Humor an

Humor aus

Categories
Management @de

Amazon Web Services mit 20-stündigen Ausfall über Weihnachten

Nach einem eher holprigen Jahr 2012 mit einigen schweren Ausfällen, zeigten sich über Weihnachten erneut Probleme in der Cloud Infrastruktur der Amazon Web Services. Während eines 20-stündigen Ausfalls waren mehrere größere Kunden betroffen, darunter Netflix und Heroku. Das Hauptproblem bestand dieses Mal mit Amazons Elastic Load Balancer (ELB).

Region US-East-1 sehr großes Problemkind

Bei diesem Ausfall handelt es sich um den bisher letzten aus einer Reihe von schweren Ausfällen in Amazons Region US-East-1. Dabei handelt es sich um die älteste und meist genutzte Region in Amazons Cloud Computing Infrastruktur. Dieser erneute Ausfall eben in US-East-1 wirft neue Fragen bzgl. der Stabilität dieser Region auf und was Amazon aus den letzten Ausfällen tatsächlich gelernt und vor allem verbessert hat. Erst kürzlich hatte Amazon Kunde awe.sm Kritik an der Amazon Cloud und hier insbesondere an Amazon EBS (Amazon Elastic Block Store) und den Services die davon abhängig sind geäußert.

Amazon Elastic Load Balancer (ELB)

Von dem Ausfall war neben der Amazon Elastic Beanstalk API hauptsächlich der Amazon Elastic Load Balancer (ELB) betroffen. Dabei gehört Amazon ELB zu einem der wichtigen Services, wenn eine skalierbare und hochverfügbare Infrastruktur innerhalb der Amazon Cloud aufgebaut werden soll. Nutzer können mit dem ELB die Lasten zwischen verschiedenen Availability Zones (unabhängiges Amazon Rechenzentrum) verschieben und damit die Verfügbarkeit sicherstellen, wenn es in einem Rechenzentrum zu Problemen kommt.

Allerdings: Sowohl Amazon Elastic Beanstalk als auch Amazon ELB setzen auf Amazon EBS, welches als das “fehlerhafte Rückgrat der Amazon Web Services gilt“.

Categories
Analysen

Erfahrungen: Amazon EBS ist das fehlerhafte Rückgrat von AWS

In einem Blogartikel schreibt das Unternehmen awe.sm über die eigenen Erfahrungen mit der Nutzung der Amazon Web Services (AWS). Neben den Vorteilen, die sich für das Unternehmen und andere Startups durch die Cloud Infrastruktur ergeben, lässt sich aus dem Kontext aber auch ableiten, dass Amazon EBS der Single Point of Failure in Amazons Infrastruktur ist.

Die Probleme von Amazon EC2

awe.sm kritisiert Amazon EC2s Beschränkungen hinsichtlich der Geschwindigkeit und Zuverlässigkeit, auf die man als Kunde unbedingt achten und in die eigene Planung mit einfließen lassen sollte. Das größte Problem besteht in dem Zonen-Konzept von AWS. Die Amazon Web Services bestehen aus mehreren “Regionen” die weltweit verteilt sind. Innerhalb dieser Regionen unterteilt Amazon noch einmal in die sogenannten “Availability Zones“. Dabei handelt es sich um eigenständige Rechenzentren. awe.sm nennt drei Dinge, die sie aus diesem Konzept bisher gelernt haben.

Virtuelle Hardware hält nicht so lange wie echte Hardware

awe.sm nutzt AWS seit ca. 3 Jahren. Innerhalb dieses Zeitraums betrug die maximale Laufzeit einer virtuellen Maschine ungefähr 200 Tage. Die Wahrscheinlichkeit, dass sie nach dieser Zeit in den Zustand “retired” geht sei sehr hoch. Zudem sei Amazons “retirement process” unberechenbar. Manchmal wird man bereits zehn tage vorher informiert, dass eine virtuelle Maschine heruntergefahren wird. Es kam aber auch vor, dass eine Info zwei Stunden eintraf, nachdem die virtuelle Maschine bereits ausgefallen war. Zwar ist es relativ simple neue virtuelle Maschinen hochzufahren, aber man sollte sich bewusst machen, dass es auch notwendig ist frühzeitig eine automatisierte Deploymentlösung zu nutzen.

Man muss mehr als eine Availability Zone nutzen und die Redundanz zonenübergreifend planen

awe.sm hat die Erfahrungen gemacht, dass eher eine ganze Availability Zone ausfällt als eine einzige virtuelle Maschine. Das bedeutet für die Planung von Fehlerszenarios, dass es genauso nutzlos ist, einen Master und einen Slave in derselben Region zu haben wie gar keinen Slave einzusetzen. Sollte der Master ausfallen liegt es möglicherweise nämlich nur daran, weil die Availability Zone nicht verfügbar ist.

Man sollte mehrere Regionen verwenden

Die Region US-EAST ist die bekannteste und ebenfalls älteste und günstigste aller AWS Regionen weltweit. Allerdings ist auch gerade diese Region sehr fehleranfällig. Beispiele gab es im April 2011, März 2012 oder auch Juni 2012 [1][2]. awe.sm geht daher davon aus, das die häufige Regionen weite Instabilität auf die gleiche Ursache zurückzuführen ist: Amazon EBS.

Das Vertrauen in Amazon EBS ist verschwunden

Der Amazon Elastic Block Store (EBS) wird von AWS empfohlen, um darauf sämtliche Daten zu speichern. Das macht auch Sinn. Fällt eine virtuelle Maschine aus, kann das EBS Volume an eine neue virtuelle Maschine angebunden werden, ohne dabei Daten zu verlieren. EBS Volumes sollen ebenfalls dazu genutzt werden, um dort Snapshots, Backups der Datenbanken oder die Betriebssysteme darauf zu speichern. awe.sm sieht in EBS jedoch manche Herausforderungen.

Die I/O Raten von EBS Volumes sind schlecht

awe.sm hat die Erfahrungen gemacht, dass die I/O Raten von EBS-Volumes im Vergleich zu dem lokalen Speicher auf dem virtuellen Host (Ephemeral Storage) deutlich schlechter sind. Da es sich bei EBS Volumes im wesentlichen um Netzlaufwerke handelt, haben sie ebenfalls auch keine gute Performance. AWS stellt mit IOPS zwar mittlerweile EBS Volumes mit einer höheren Performance bereit. Für awe.sm sind diese auf Grund des Preises jedoch viel zu unattraktiv.

EBS versagt auf der Regionen-Ebene und nicht pro Volume

awe.sm hat an EBS zwei unterschiedliche Verhaltensarten festgestellt. Entweder funktionieren alle EBS Volumes oder keines! Zwei von den drei AWS Ausfällen sind auf Probleme mit Amazon EBS zurückzuführen. Sollte das eigene Disaster Recovery also darauf aufbauen, im Fehlerfall EBS Volumes zu transferieren, der Ausfall jedoch auf Grund eines EBS Fehlers auftritt, hat man ein Problem. awe.sm habe genau mit diesem Problem schon öfters zu kämpfen gehabt.

Der Fehlerzustand von EBS auf Ubuntu ist sehr schwerwiegend

Da EBS Volumes als Block-Devices getarnt werden, führt das zu Problemen im Linux Betriebssystem. Damit hat awe.sm sehr schlechte Erfahrungen machen müssten. So hat bspw. ein fehlerhaftes EBS Volume dazu geführt, dass eine virtuelle Maschine vollständig eingefroren ist und keine Möglichkeit mehr bestand auf die Maschine zuzugreifen oder weitere Aktionen durchzuführen.

Viele Services der Amazon Cloud setzen auf Amazon EBS

Da viele weitere AWS Services auf EBS aufsetzen, fallen diese ebenfalls aus, wenn EBS ausfällt. Dazu gehören u.a. der Elastic Load Balancer (ELB), die Relational Database Service (RDS) oder Elastic Beanstalk. Wie awe.sm festgestellt hat ist EBS so gut wie immer das Hauptproblem größerer Ausfälle bei Amazon. Fällt EBS also aus und soll der Datenverkehr daraufhin in eine andere Region übertragen werden, funktioniert das nicht, da der Load Balancer ebenfalls auf EBS läuft. Darüber hinaus kann keine neue virtuelle Maschine manuell gestartet werden, da die AWS Management Console ebenfalls auf EBS läuft.

Kommentar

Wenn man sich die Erfahrungen von awe.sm so durchliest erhält man den Eindruck, dass dieses so oft propagierte “Building Blocks” bei Amazon doch nicht so gelebt wird wie es eigentlich sollte. Auch wenn es dabei primär um das Angebot der einzelnen Cloud Services geht (diese unabhängig nutzen zu können), wieso macht man den Großteil dieser Services dann von einem einzigen Service (EBS) abhängig und schafft damit einen Single Point of Failure?

Categories
Management @de

Cloud Computing Ausfälle im Jahr 2012

Das Jahr neigt sich dem Ende und nicht alles ist 2012 in der Public Cloud so glatt gelaufen, wie es sich die meisten gewünscht haben. Ich denke bei dem einen oder anderen Cloud Admin und vor allem Nutzer werden sich in diesem Jahr wahrscheinlich ähnliche Gefühlsregungen gezeigt haben.

Public Cloud Ausfälle 2012

Ich habe mal eine kleine Auswahl aller Artikel zum Thema “Cloud Computing Ausfälle” zusammengestellt, die ich im Jahr 2012 hier auf CloudUser veröffentlicht habe.

  1. Microsoft Azure mit 12-stündigem Ausfall – War der Schalttag (29. Februar) das Problem?
  2. CloudStore der britischen Regierung ebenfalls vom Windows Azure Ausfall betroffen
  3. Microsoft bestätigt: Windows Azure Ausfall war ein Schaltjahr Problem
  4. Azure Nutzer erhalten für den Ausfall am 29. Februar eine Gutschrift über 33%
  5. Amazon Web Services mit kurzzeitigem Ausfall
  6. Erneute Probleme in der Amazon Cloud – Ausfall bei den Amazon Web Services in North Virginia
  7. Der Himmel weint. Nicht! Public Cloud Ausfälle sind nun einmal öffentlich.
  8. Armutszeugnis: Cloud Computing Ausfälle haben seit 2007 mehr als 71 Million US-Dollar an Kosten verursacht.
  9. Salesforce hatte mit Ausfall zu kämpfen
  10. Amazon Web Services (AWS) erneut mit Ausfall. Wieder ein Stromausfall. Wieder in North Virginia. Schwere Stürme sind die Ursache.
  11. Der Ausfall der Amazon Web Services (AWS) zeigt die schlechte Systemarchitektur von Instagram
  12. Amazon Web Services (AWS) Ausfall: Erklärungen | Erster Kunde geht | Netflix hält die Treue | Okta versteht die Cloud-Architektur
  13. Der Amazon Web Services (AWS) Ausfall: Letzte Chance – So etwas darf nicht noch einmal passieren!
  14. Ausfall: Salesforce erneut mit schwerwiegenden Problemen
  15. Ausfallprävention: Diese Fragen sollte man seinem Cloud Computing Anbieter stellen
  16. Microsoft Windows Azure Compute in der Region “West Europe” ausgefallen
  17. Fehlerhafte Netzwerkkonfiguration war Schuld am Windows Azure Ausfall für die Region “West Europe”
  18. Ausfall: Salesforce erneut mit Performance-Problemen
  19. Microsoft erklärt den Grund für den Ausfall von Windows Azure in der Region “West Europe”
  20. Schuldzuweisungen in Zeiten des Cloud Computing
  21. Erneuter Ausfall der Amazon Web Services zeigt, dass Cloud Nutzer nicht aus den eigenen Fehlern lernen
  22. Ausfall der Google App Engine – Load Balancer waren die Ursache
  23. Windows Azure Compute in “South Central US” und “West Europe” mit Problemen
  24. Ausfälle in der Cloud liegen in der Natur des Menschen

Da ist schon einiges zusammengekommen. Aber ich wette, tragen wir weltweit sämtliche Ausfälle in von Unternehmen selbst betriebenen Rechenzentren zusammen, schneidet die Public Cloud gut ab.

Hat jemand hierzu vielleicht Statistiken?

Categories
Kommentar

Ausfälle in der Cloud liegen in der Natur des Menschen

Wenn die Cloud fällt sind es wir Menschen, die dafür verantwortlich sind. Wie soll es auch anders sein. Schließlich programmieren und konfigurieren sich die Systeme nicht von alleine. Und auch wenn es heißt “No cloud without automation” muss man eigentlich sagen “(No cloud without automation) without human skills”. Insbesondere zeigen sich unsere menschlichen Schwächen in der Cloud dann, wenn es wieder mal zu einem Ausfall kommt. Vor allem in diesem Jahr haben wir ein paar davon gesehen.

Menschen machen Fehler

Und das ist ok. Solange aus diesen Fehlern auch gelernt wird. Was bei dem einen oder anderen Anbieter dieses Jahr nicht der Fall war. Ich will und werde hier keine Namen nennen, denn diejenigen Wissen bestimmt selbst, dass sie etwas deutlich besser machen müssen. Aber wenn ein Notstromaggregat innerhalb kürzester Zeit zweimal nicht funktioniert und ebenfalls sämtliche Notfallpläne scheitern, läuft etwas falsch!
Zwar war dieser Ausfall, von dem ich hier spreche, in erster Linie kein menschliches Versagen. Denn gegen einen Wirbelsturm und Gewitter sind wir machtlos. Aber die Kaskade von Fehlern die während des Unwetters passiert war, ist unerklärlich.

Andere Fehler die in diesem Jahr passiert sind, lassen sich dem Menschen direkt zuordnen. Zum einen waren da bspw. falsch konfigurierte Netzwerkschnittstellen die dafür gesorgt haben, dass die Netze der Anbieter mit Daten überflutet wurden und sich somit selbst Schachmatt gesetzt haben. Oder es wurden erst kürzlich bei einem Anbieter Änderungen an der Konfiguration der Load-Balancer vorgenommen, die zu einem längeren Ausfall führten.

Wie gesagt, Menschen machen Fehler. Und daher sollte man nicht immer “der großen bösen Cloud” die Schuld geben, sondern hinter die Fassade schauen und bedenken, dass dort auch nur Menschen wie Du und ich sitzen.

In diesem Sinne, auf in ein besseres 2013. 🙂

Categories
News

Entwarnung: Windows Azure Compute rollt wieder rund

Kurz nachdem ich den Post zu Windows Azure Compute Problemen in den Regionen “South Central US” und “West Europe” veröffentlicht hatte, zeigte das Azure Statusboard wieder alle Status ohne Probleme an (Häckchen ganz links).

Windows Azure Compute rollt wieder rund

Categories
News

Windows Azure Compute in "South Central US" und "West Europe" mit Problemen

Zwar ist davon bisher nichts auf Twitter oder sonstigen Medien zu lesen, aber Windows Azure Compute zeigt aktuell Auffälligkeiten bei der Verfügbarkeit in “South Central US” und “West Europe”. Zudem weiß ich aus einer sehr sicheren Quelle das mindestens ein Unternehmen, dass seinen Service auf Azure Compute betreibt, Probleme hat. Die Webseiten sind nicht erreichbar. Es verwundert hier allerdings ein wenig, dass das Unternehmen hierzu keine Statusmeldung im Social Web geschrieben hat.

Windows Azure Compute in

Das Statusboard berichtet bereits seit dem “20-Nov-12, 9:00 PM UTC” von Problemen mit der Verfügbarkeit von Windows Azure Compute in den Regionen “South Central US” und “West Europe”. Im Detail schreibt Microsoft über das “Partial impact to Service management” für beide Regionen:

20-Nov-12, 9:00 PM UTC

We are experiencing an issue with Compute Service Management in West US, South Central US, North Europe and West Europe sub-regions. 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.

20-Nov-12, 10:00 PM UTC

We are gathering all the data required to identify the root cause and resolve the issue 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.

20-Nov-12, 11:00 PM UTC

Service Management is still partially impacted for existing and new hosted service deployments in West US, South Central US, North Europe and West Europe sub-regions. Customers may experience failures with Create, Delete and Update operations. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

21-Nov-12, 12:00 AM UTC

The incident has been mitigated for new hosted service deployments in the sub-regions. Customers with hosted services already deployed in these sub-regions may still experience service management failures or timeouts. Further updates will be published to keep you apprised of the situation. We apologize for any inconvenience this causes our customers.

21-Nov-12, 1:00 AM UTC

We identified the root cause and are executing the repair steps. The steps will be executed on multiple nodes of the impacted clusters and this will take several hours. Further updates will be published after the recovery is complete. We apologize for any inconvenience this causes our customers.

Categories
News

Ausfall der Google App Engine – Load Balancer waren die Ursache

Keine schöne Woche für Anbieter von Cloud Services. Nachdem die Amazon Web Services in dieser Woche ihren fünften signifikanten Ausfall in den letzten 18 Monaten in Virginia zu verzeichnen hatten, war gestern die Google App Engine an der Reihe. Auf Twitter mehrten sich die Meldungen, dass es Probleme gab, den PaaS zu nutzen. Ähnliche Meldungen gab es über Tumblr und Dropbox.

Ausfall der Google App Engine

Probleme zunächst unbekannt

Um 10:52 pm PDT (Pacific Daylight Time) meldete Google Probleme mit dem eigenen Platform-as-a-Service Google App Engine. Zwar war ein Team bereits dabei diese zu beheben, dennoch gab es noch langsame Antwortzeiten und erhöhte Fehlerraten.

“The malfunction appears to be limited to a single component which routes requests from users to the application instance they are using, and does not affect the application instances themselves.”

Um 9:33 a.m. PDT folgte folgende Statusmeldung:

“At approximately 7:30am Pacific time this morning, Google began experiencing slow performance and dropped connections from one of the components of App Engine. The symptoms that service users would experience include slow response and an inability to connect to services. We currently show that a majority of App Engine users and services are affected. Google engineering teams are investigating a number of options for restoring service as quickly as possible, and we will provide another update as information changes, or within 60 minutes.”

Die Fehler machten sich ebenfalls bei Cedexis, Anbieter von Performance und Monitoring Tools für Cloud Services, bemerkbar:

Ausfall der Google App Engine

Zudem mehrten sich die Meldungen auf Twitter zu dem Ausfall.

Weiterhin war zu hören, dass ebenfalls Dropbox, Tumblr und iMessage Probleme hätten:

Probleme mit den Load Balancern

In einer Stellungnahme gab Google bekannt, dass der Ausfall durch Probleme an den Load Balancern verursacht wurde. Um den Fehler zu beheben, wurden sämtliche Verbindung zunächst getrennt, um den Service anschließen langsam wieder hochzufahren. Weitere Informationen zu dem Ausfall stellt Google hier zur Verfügung.

Neben Google hatten auch andere Anbieter darunter Tumblr und Dropbox mit Ausfällen zu kämpfen. Wie The Next Web berichtet, soll es in Nordamerika und Asien zu größeren Problemen mit Paketverlusten gekommen sein. Wie es dazu und zu den Ausfällen kam, ist jedoch weiterhin ungeklärt.

Categories
Kommentar

Erneuter Ausfall der Amazon Web Services zeigt, dass Cloud Nutzer nicht aus den eigenen Fehlern lernen

Gestern war es dann wieder einmal soweit. Amazon hatte erneut mit einem schweren Ausfall in seiner Region US-East-1 zu kämpfen und zog direkt die üblichen Verdächtigen Reddit, Foursquare, Heroku und Co. mit. Dabei handelt es sich bereits um den fünften signifikanten Ausfall in den letzten 18 Monaten in dieser Region. Nach April 2011, März 2012 sowie dem 15. und 30. Juni 2012 plus vier weitere Ausfälle innerhalb nur einer Woche im Jahr 2010, nun der nächste Ausfall.

Die Hintergründe des AWS Ausfall

Die Region US-East-1 ist die älteste aller AWS Regionen. Dabei handelt es sich um das Rechenzentrum in Virginia, das erst vor kurzer Zeit wegen schwerer Gewitter in die Schlagzeilen geraten war. Letzte Woche hatte ich noch geschrieben, dass neue Public Cloud Anbieter zwar mittlerweile über aktuellere Technologien verfügen, es für Amazon auf Grund der losen Kopplung sämtlicher Services aber leicht fallen sollte, einen Austausch vorzunehmen. Es scheint, dass der Zeitpunkt mehr als überschritten ist. Das Grab US-East-1 ist größer als vermutet.

Was ist passiert?

Was genau passiert ist, kann der AWS Statusseite zu Beginn verständlicherweise nicht immer direkt entnommen werden. In der Regel wird ein paar Tage nach dem Ausfall ein ausführlicher Blogpost mit ein paar Details veröffentlicht.

Aus den Statusmeldungen lässt sich nur entnehmen, dass es wieder Performanceprobleme “mit einer kleinen Anzahl von EBS Volumes (Elastic Block Store)” gibt.

10:38 AM PDT We are currently investigating degraded performance for a small number of EBS volumes in a single Availability Zone in the US-EAST-1 Region.
11:11 AM PDT We can confirm degraded performance for a small number of EBS volumes in a single Availability Zone in the US-EAST-1 Region. Instances using affected EBS volumes will also experience degraded performance.
11:26 AM PDT We are currently experiencing degraded performance for EBS volumes in a single Availability Zone in the US-EAST-1 Region. New launches for EBS backed instances are failing and instances using affected EBS volumes will experience degraded performance.

12:32 PM PDT We are working on recovering the impacted EBS volumes in a single Availability Zone in the US-EAST-1 Region.
1:02 PM PDT We continue to work to resolve the issue affecting EBS volumes in a single availability zone in the US-EAST-1 region. The AWS Management Console for EC2 indicates which availability zone is impaired.EC2 instances and EBS volumes outside of this availability zone are operating normally. Customers can launch replacement instances in the unaffected availability zones but may experience elevated launch latencies or receive ResourceLimitExceeded errors on their API calls, which are being issued to manage load on the system during recovery. Customers receiving this error can retry failed requests.

2:20 PM PDT We’ve now restored performance for about half of the volumes that experienced issues. Instances that were attached to these recovered volumes are recovering. We’re continuing to work on restoring availability and performance for the volumes that are still degraded.

Zudem waren auch “eine kleine Anzahl von RDS Instanzen (Relational Database Service)” betroffen. Hier kam es zu Problemen bei der Verbindung und ebenfalls bei der Performance.

11:03 AM PDT We are currently experiencing connectivity issues and degraded performance for a small number of RDS DB Instances in a single Availability Zone in the US-EAST-1 Region.
11:45 AM PDT A number of Amazon RDS DB Instances in a single Availability Zone in the US-EAST-1 Region are experiencing connectivity issues or degraded performance. New instance create requests in the affected Availability Zone are experiencing elevated latencies. We are investigating the root cause.

Die üblichen Verdächtigen: Reddit, Foursquare, Heroku und Co.

Interessant ist, dass immer die üblichen Verdächtigen u.a. Reddit, Heroku und Foursquare von einem Ausfall der US-East-1 Region betroffen sind. Das bedeutet im Umkehrschluss, dass alle Beteiligten nicht aus den eigenen Fehlern vorheriger Ausfälle gelernt haben und genau so weitermachen wie zuvor. Das “Schöne” an solchen Ausfällen ist, dass man einen schönen öffentlichen Rundumblick auf die Robustheit der jeweiligen Angebote der Anbieter erhält, die ihre Anwendungen auf den Amazon Web Services laufen lassen. Auch Instagram, dass bekannterweise für 1 Milliarde Dollar an Facebook verkaufte wurde, war bei einem der letzten Ausfälle schwer getroffen. Da scheint die technische Due Diligence Prüfung nicht funktioniert zu haben.

Es stellt sich die Frage, wie lange die Verantwortlichen von Reddit, Foursquare, Heroku (gehört übrigens zu Salesforce) und Co. noch warten, bis etwas an der Architektur geändert wird. Die Systemarchitekten sollten langsam damit beginnen etwas zu ändern. Gute Vorbilder sind Netflix und Okta.

Was ist zu tun?

Das ist im Einzelfall zu entscheiden. Jedoch reicht es zunächst einmal nicht aus, nur eine Region oder eine Availability Zone zu nutzen. Man muss einfach verstehen, dass Cloud Computing viel mehr bedeutet, als nur ein paar Server zu nutzen und miteinander zu verbinden. Es geht um die gesamte Architektur des eigenen Systems bzw. der eigenen Anwendung, die auf der virtuellen Infrastruktur (IaaS) aufgebaut wird. Wie ich schon in einem Artikel für die Computerwoche geschrieben habe:

Viele Unternehmen entwickeln ihre Cloud-Applikation “daheim” in den eigenen vier Wänden. Erst nach der Fertigstellung soll der Rollout auf eine Cloud-Infrastruktur oder Cloud-Plattform erfolgen. Das ist ein Fehler.

Inbesondere IaaS-Umgebungen (Infrastructur as a Service) wie die Amazon Web Services oder Microsoft Windows Azure vermitteln den Eindruck, nur eine Vielzahl von virtuellen Maschine bereitzustellen. Den Rest übernehme die “Cloud automatisch”. Das ist fatalerweise auch der Tenor, der von vielen Medien verbreitet wird und damit ein völlig falscher Eindruck von einer Cloud entsteht.

Eine Cloud-Anwendung ist nur so viel wert wie die Architektur, auf der sie basiert. Eine Anwendung muss direkt für die Cloudentwickelt werden – Skalierbarkeit und Hochverfügbarkeit sind von Beginn an mit zu bedenken. Eine Anwendung sollte eigenständig weitere virtuelle Maschinen hochfahren können, wenn mehr Leistung benötigt wird (Skalierbarkeit) bzw. die nicht mehr benötigten virtuellen Maschinen auch selbstständig wieder herunterfahren. Genauso verhält es sich, wenn eine virtuelle Maschine in einen fehlerhaften Zustand gerät. Auch hier muss die Anwendung selbst dafür sorgen, dass entsprechend eine virtuelle Maschine als Ersatz hochgefahren wird und die defekte Maschine aus dem System verschwindet (Hochverfügbarkeit).

Die Anwendung muss daher in der Lage sein, auf jeder beliebigen virtuellen Maschine (VM) einer Cloud-Infrastruktur zu funktionieren. Das liegt unter anderem daran, dass jederzeit eine VM ausfallen kann und eine andere neu hochgefahren werden muss. Und auch die Daten, auf die eine Anwendung operiert, befinden sich zwangsläufig nicht mehr an einem einzigen Ort, sondern sind über die Cloud verteilt gespeichert.

Mehr…

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 das Problemkind zu sein. 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.

Das gilt für die gesamte Cloud!

Alle genannten Bereiche gelten nicht nur für die Amazon Web Services, sondern ebenfalls für Windows Azure, Rackspace usw. Bevor man in die IaaS-Cloud eines Anbieter geht, sollte man sich vorher damit auseinandersetzen und verstehen, wie die Infrastruktur funktioniert und wie das eigene Systeme daraufhin entwickelt werden muss.