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?