Offline? Nicht mit mir. Ein Cloud-Ausfall ist jederzeit möglich

Viele tausende Websites und mobile Apps vertrauen auf „Amazon S3“ und andere Cloud-basierte Dienste. Wie sich aber im Fall von Amazon Anfang des Jahres gezeigt hat, kann ein Ausfall selbst eines der größten und am besten etablierten Unternehmen treffen. Smarte Unternehmen sollten daher auf eine Multi-Cloud-Strategie setzen, empfiehlt Chip Childers, CTO der Cloud Foundry Foundation.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

VMware Global Inc Zweigndl. Deutschland

DataCore Software GmbH

Cloud Foundry Foundation

Als Anfang des Jahres ein Teil des „Amazon Simple Storage Service“ (S3) offline war, hatte dies gravierende Folgen für die internet-basierte Wirtschaft. Der Ausfall war dermaßen schwerwiegend, dass Amazon noch nicht einmal auf sein eigenes Dashboard zugreifen konnte, um die Nutzer über die Störung zu informieren. Weltweit waren Apps und Websites nicht mehr erreichbar, als der S3-Speicherdienst plötzlich seinen Dienst versagte. Von dem Ausfall waren nicht nur Apps betroffen, die S3 als Datenspeicher nutzen, sondern auch tausende Websites und mobile Apps, die auf den S3-Service für die Bereitstellung ihrer Inhalte vertrauen.

Das Unheil nahm seinen Anfang, als ein Techniker des S3-Teams in der Region „US-East-1“ im Bundesstaat Nord-Virgina einige Server vom Netz nahm, um Fehler in einem Performance-schwachen Abrechnungssystem auszubessern. Wegen einer fehlerhaften Eingabe musste ein systemweiter Neustart durchgeführt werden, was eine Kettenreaktion auslöste. Vier Stunden später war die Störung behoben und der S3-Dienst arbeitete wieder normal.

Vier Stunden sind vielleicht keine Ewigkeit, aber nahezu ein Fünftel des gesamten World Wide Web war von dem Ausfall betroffen und die in Mitleidenschaft gezogenen Unternehmen hatten Kosten in dreistelliger Millionenhöhe zu beklagen. Und alles nur wegen eines vierstündigen Ausfalls.

Keine Vorkehrungen getroffen? Dafür gibt es keine Entschuldigung

Größen wie Apple, Adobe, Medium, Slack, Splitwise, Trello und US Securities and Exchange Commission, sie alle waren von dem Ausfall betroffen wie tausende kleinere Unternehmen auch. Eine Downtime ist eine ernstzunehmende Angelegenheit. In diesem Fall scheint das Problem größtenteils darauf zurückzuführen zu sein, dass Amazon Web Services seine eigenen Services oft nutzt, um übergeordnete Dienste zu entwickeln.

Der Ausfall von S3 hatte also zur Folge, dass andere übergeordnete AWS-Dienste, die auf S3 in dieser Region vertrauen, auch ausfielen. Dazu gehörte die S3-Konsole, ein Dashboard, das Nutzer informiert, wenn ein Problem auftritt. So zog der Ausfall immer weitere Kreise.

Wenn man sich vor Augen führt, dass es den Teams der Amazon Web Services in relativ kurzer Zeit gelang, die Sache wieder in den Griff zu bekommen, überrascht es vielleicht nicht so sehr, dass Amazon von einem Ausfall betroffen war (Ausfälle hat es schon immer gegeben und wird es auch in Zukunft geben), als vielmehr die Tatsache, dass die auf Amazon vertrauenden Unternehmen schlichtweg keine Vorkehrungen für den Ernstfall getroffen hatten.

Cloud-Services können ausfallen – Treffen Sie Vorkehrungen

Als die Cloud noch ein fieberhafter Traum vorausdenkender Technologiestrategen war, hatten IT-Abteilungen bei der Konzeption ihrer Systeme stets eine 24h-Verfügbarkeit im Hinterkopf. Früher dachten wir viel über die Verfügbarkeit und Wiederherstellbarkeit unserer IT-Systeme nach.

Doch nach und nach wurde die Cloud Realität, entwickelte sich weiter und Provider investierten viel Zeit und Energie in die Entwicklung widerstandsfähiger Systeme. Deshalb sind sie auch so gefragt.

Aufgrund der Skaleneffekte haben die Provider in puncto operative Erfahrung viel mehr zu bieten, als die meisten Unternehmen intern leisten können. Nur wenige Unternehmen in der Welt sind in der Lage, es mit der Größenordnung von Amazon Web Services aufzunehmen, geschweige denn den Grad an Verfügbarkeit und Resilienz zu erreichen.

Doch wenn Sie Apps in der Cloud bereitstellen, führt kein Weg an der Tatsache vorbei, dass die Unternehmen noch immer selbst für die Verfügbarkeit Ihrer Business-Systeme verantwortlich sind. Und wie Hardware auch sind Cloud-Dienste nicht immun gegen Ausfälle.

Warum eine Multi-Cloud-Strategie sinnvoll ist

Wenn man über "Design for Failure" (Ausfall bereits in der Design-Phase berücksichtigen) spricht, richtet sich der Fokus in der Regel auf die Verfügbarkeit von EC2-Instanzen und mehrere „Availability Zones“ für Apps. Doch im Falle des Ausfalls von S3 liegen die Dinge etwas anders.

Erstens geht es bei S3 mehr um die dauerhafte Speicherung von Daten als um die Ausführung des Codes von Benutzerapplikationen. Zahlreiche AWS-Nutzer sind davon ausgegangen, dass Dauerhaftigkeit mit Verfügbarkeit gleichzusetzen ist.

Das sind jedoch zwei Paar Schuhe. Zweitens konzentrieren sich die meisten Informationen zu AWS auf die Nutzung von Availability Zones, um das Eingrenzen von Fehlern zu gewährleisten, doch der Ausfall erstreckte sich über eine ganze Region.

In diesem Zusammenhang wird deutlich, warum eine Multi-Cloud-Strategie durchaus nützlich sein kann. Das Designen einer App für eine Multi-Cloud-Umgebung bedeutet, dass Sie als Anwender auf mehrere Cloud-Provider oder zumindest auf mehrere Regionen eines einzelnen Cloud-Providers vertrauen können. Sie haben die Möglichkeit, die Speicherdienste von Google und Amazon oder Microsoft und Amazon oder mehrere AWS-Regionen zu nutzen.

Das Risiko, dass mehrere Systeme ausfallen, nimmt ab, je weiter die Systeme voneinander entfernt sind, unabhängig davon, ob sie sich in verschiedenen Teilen der Welt befinden oder ob sie von verschiedenen Unternehmen angeboten werden. Die Entscheidung für Multi-Cloud-Provider ist eine Entscheidung für eine verlässliche Verfügbarkeitsstrategie.

Erste Schritte

Zunächst einmal sollten Anwendungsarchitekten sich Gedanken darüber machen, wie sie sowohl Schreib- als auch Leseoperationen multi-cloud-gerecht handhaben wollen.

Bei Schreiboperationen haben Sie die Wahl: Entweder Echtzeitspiegelung der Schreiboperationen auf mehrere Speicherdienste oder Konsistenztechniken, mit denen die Daten zum sekundären Dienst repliziert werden. Ihren Anforderungen entsprechend wählen Sie eine der beiden Vorgehensweisen oder beide.

Bei Leseoperationen betrachten Sie den Zugriff auf Cloud-Speicherdienste genauso wie Sie es bei anderen Microservices, auf die Ihre App vertraut, tun würden. Sie können einfach das "Circuit Breaker Pattern" anwenden, um Leseoperationen für den Failover von Ihrem primären zum sekundären Cloud-Speicherdienst durchzuführen.

Sie sollten also grundsätzlich in Erwägung ziehen, Ihre Daten in mindestens zwei Speicherdiensten zu haben und Ihre App so designen, dass sie automatisch auf einen Ausfall reagieren kann.

Es steht außer Frage, dass die zusätzlichen Speicherdienste und der Support für das Design Geld kosten. Doch vergleichen Sie einmal diese zusätzlichen Kosten mit den Kosten eines schwerwiegenden Ausfalls, falls es dazu kommt, und was wahrscheinlicher ist, wenn es dazu kommt. Wenn Sie jetzt in eine Multi-Cloud-Strategie investieren, wird sich das als eine Ihrer besten Investitionen erweisen.

*Chip Childers ist CTO der Cloud Foundry Foundation.

Hinweis: Am 11. und 12. Oktober 2017 findet in Basel der „Cloud Foundry Summit Europe“ statt.

(ID:44921850)