Suchen

Multi-Cloud-Ansatz verhindert Totalausfälle Die größten Cloud-Pannen der Corona-Krise

| Autor / Redakteur: Anna Kobylinska und Filipe Pereira Martins * / Elke Witmer-Goßner

COVID-19 hat Cloud-Dienste an die vorderste Front im Kampf um die wirtschaftliche Relevanz digitalisierter Unternehmen katapultiert. Inmitten des Lockdowns wurde die Cloud von einer Krücke zum Ausgleich fehlender Kapazitäten zum wichtigsten Schrittmacher von Versorgungsketten, dem universellen Konnektivitäts- und Produktivitätshub für Tele-Arbeit und einer Unterhaltungsmaschine.

Firmen zum Thema

Während des COVID-19-Lockdowns kämpften viele Cloud-Provider und andere Dienste-Anbieter mit massiven Ausfällen ihrer Umgebungen.
Während des COVID-19-Lockdowns kämpften viele Cloud-Provider und andere Dienste-Anbieter mit massiven Ausfällen ihrer Umgebungen.
(Bild: © trendobjects - stock.adobe.com)

Unerwartete Bedarfsspitzen durch die plötzliche Umstellung der globalen Wirtschaft auf Cloud-Dienste wie Unified Communications stellten die Betriebsbereitschaft von IT-Infrastrukturen ganz plötzlich auf die Probe. Denn der Wind pfeift darauf, ob der Baum müde ist, wie es die Japaner so zu sagen pflegen. Vielerorts ging es drüber und drunter. „Momentan ist da draußen alles im Untergang und düsterer Finsternis“, kommentierte im März Jeff Aden, Executive Vizepräsident von 2nd Watch. In der Ruhe liegt die Kraft, könnten die Deutschen einwenden.

Kalt erwischt im Corona-Fieber

Cloud-Anbieter und ihre Nutzer mussten im Lockdown die eine oder andere Lektion auf die harte Tour lernen. Naja, besser auf neuen Wegen etwas stolpern als auf alten Pfaden auf der Stelle zu trampeln, würden vielleicht die Chinesen sagen. Viele Mittelständler stolperten in die Krise jedenfalls völlig unvorbereitet hinein und mussten auf einmal sensibles Krisenmanagement praktizieren. Dienste wie Zoom oder Slack konnten die Wirtschaft auffangen und über Wasser halten während Plattformen wie Netflix für Abwechslung (oder Ablenkung) im Home-Office sorgten.

Visualisierung von Cloud-Ausfällen von ThousandEyes: Die Verzahnung von Cloud-Diensten unterschiedlicher Anbieter wird manchem Unternehmen zum Verhängnis.
Visualisierung von Cloud-Ausfällen von ThousandEyes: Die Verzahnung von Cloud-Diensten unterschiedlicher Anbieter wird manchem Unternehmen zum Verhängnis.
(Bild: ThousandEyes)

Auch viele Cloud-Anbieter hat die plötzliche Explosion der Nachfrage mehr oder weniger kalt erwischt. Die Bedarfsspitzen setzten den Cloud-Anbietern schwer zu. Microsoft musste zwischendurch seinen Azure-Kunden in Kalifornien und anderswo die Nutzungskontingente zwangsweise herunterschrauben, um die SLAs eigener Cloud-Dienste wie Office365 erfüllen zu können. Dienst-Ausfälle waren vorprogrammiert und kurzfristig unausweichlich. „Wer hätte das gedacht“, war so die Devise. „Die meisten Unternehmen konnten [überhaupt nur] dank der Cloud weiterarbeiten,“ beobachtet Aden.

Auf der Achterbahn unvorhersehbarer Dienstausfälle

Mitte 2020 hatte die Coronavirus-Pandemie Europa bereits voll im Griff. Am 16. des Monats stellte ein plötzlicher Zufluss neuer Benutzer von Microsoft Teams die Dienstverfügbarkeit in Europa auf eine harte Probe. Für zwei Stunden ging der Dienst dann europaweit ganz in die Knie. Für die plötzlichen Bedarfsspitzen hatte das Unternehmen anscheinend nicht vorgesorgt. Gut eine Woche brach auch die Azure Cloud vom 24. bis 26. März global zusammen.

Während der ersten fünf Stunden des Ausfalls hatte Microsoft laut Angaben des Engineering Directors Chad Kimes den Vorfall noch nicht einmal zugestanden. Normalerweise dauern Azure-Cloud-Outages laut Microsofts eigenen Angaben durchschnittlich maximal 10 Minuten und so versuchten die Verantwortlichen den Vorfall offenbar leise auszusitzen. Denn wer den Schaden hat, braucht für den Spott nicht zu sorgen. Nachträglich hat sich Microsoft für die halbherzige und nur sehr zögerliche Behebung der Azure-Cloud-Outage aber dann doch entschuldigt.

Es „brannte“ bei Microsoft an vielen Stellen, wie auch der Vorfall vom 3. März 2020 zeigt. An diesem Tag fiel pünktlich um 09:30 der US-Ostküstenzeit ein ganzes Azure-Datencenter aus. Die Panne hatte diesmal nordamerikanische Nutzer der Cloud auf dem falschen Fuß erwischt. Im Nachhinein stellte sich heraus, ein Versagen der automatischen Gebäude-Kontrollmechanismen sei die Ursache gewesen. Eine Fehlfunktion habe die Kühlung des Datencenters stellenweise außer Betrieb gesetzt. Als Resultat daraus kam das Netzwerk ins Stottern, sodass Compute- und Storage-Instanzen plötzlich nicht mehr verfügbar waren.

Die Lösung war genauso einfach wie die Ursache offensichtlich war: „den Reset-Knopf drücken“. Nach einem Neustart der Controller des Kühlsystems fiel die Temperatur in den Räumlichkeiten wieder auf tolerable Werte. Dann ließen sich auch die Server per Reset schrittweise aus der Hängepartie befreien. Doch erst nach dem Einspielen von Backups kehrte wieder Normalität ein. Das ganze Drama hielt sechs Stunden an.

Eine Panne nach der anderen bei GitHub

Der anfängliche Schrecken des Lockdowns war längst vorbei als die DevOps-Plattform GitHub, der führende Cloud-Hoster von Git-Repositories, mindestens zum vierten Mal in der COVID-Krise zusammenbrach. Der Dienst erlitt einen globalen Ausfall seiner Cloud-Dienste in der Nacht vom 13. Juli und war weltweit über nahezu zwei Stunden lang nicht erreichbar. GitHub gehört übrigens zu Microsoft. Über 50 Millionen Entwickler auf der ganzen Welt vertrauen auf diesen Dienst. Der Cloud-Überwachungsdienst ThousandEyes urteilte „selber schuld“, konnte aber nichts Näheres dazu berichten.

GitHub selbst wollte sich zu den möglichen Ursachen des Juli-Ausfalls nicht äußern. Die drei Dienstausfälle im April 2020 hatten den guten Ruf des Cloud-Hosters schwer angeschlagen, zumal sie sich auf scheinbar ganz triviale Ursachen zurückführen ließen. Beim ersten Ausfall hatte GitHub eine Fehlkonfiguration seiner Lastverteiler beschuldigt, die in Software implementiert waren. Diese Fehlkonfiguration soll das interne Routing zwischen GitHubs eigenen Anwendungen und nicht näher bezeichneten Cloud-Diensten durcheinandergebracht haben, weswegen die Plattform einen Betriebsausfall erlitten habe.

Die zweite April-Panne schob GitHub seinen Datenbankadministratoren in die Schuhe. Eine laufende Datenpartitionierung habe es „unerwartet in die Produktion geschafft“ und eine Fehlkonfiguration der Datenbankverbindungen ausgelöst. Die wahre Lektion hat das Management aus dem zweiten Vorfall offenbar nicht gelernt, denn bald war der Service wieder außer Betrieb. Diesmal sei eine Netzwerkfehlkonfiguration „versehentlich auf das Produktionsnetzwerk angewendet“ worden. Einen Sündenbock zu finden ist um Einiges einfacher, als der wahren Ursache auf die Spur zu kommen.

Bei jedem der Ausfälle mussten Millionen von Entwicklern eine Kaffeepause einlegen. Die betroffenen Unternehmen konnten ihren Code nicht aktualisieren. Bugs in kritischer Software waren für alle Endbenutzer eingefroren. Noch im selben Monat hat GitHub offenbar beschlossen, die blamablen Erkenntnisse über seine Pannen nicht mehr an die große Glocke zu hängen, denn danach hieß es nur, man habe „Probleme mit der Staging-Labs-Umgebung“. Für all die Betroffenen, die auf ihren Anwendungscode in der Cloud auf einmal nicht zugreifen konnten, war das nur ein schwacher Trost.

Ein kleines Update „mal eben einspielen“

Doch jetzt zu meinen, dass sich Cloud-Pannen nur auf Microsoft und seine Cloud-Dienste beschränken, reflektiert keinesfalls die Realitäten. Es braucht nicht erst eine Pandemie, damit respektable Cloud-Dienste einen Aussetzer haben. Am 7. Februar 2020 punktgenau um 17 Uhr der US-Ostküstenzeit ging Twitter in die Knie. Patrick Traughber, Product Manager bei Twitter, kommentierte kurz angebunden „Tweeten ist kaputt. Wir arbeiten an einem Fix“. Sieben Minuten später war alles wieder beim Alten. Die Downtime habe ein fehlerhaftes Update ausgelöst (Schöne Grüße an GitHub vielleicht? Oder auch nur wieder „selber schuld“?).

Auch Google und AWS sind gegen Ausfälle nicht wirklich immun. Bei AWS sind von den Ausfällen gemäß Angaben der Überwachungsdienstleisters DownDetecor am meisten die Konsole und EC2 betroffen. Google hatte laut DownDetector unter anderem am 26. März an der US-Ostküste im Großraum Washington D.C. massive Betriebsstörungen verzeichnet. Die Google Cloud Platform fiel an jenem Tag ganz spektakulär mit Error 500 und Error 502 (Bad Gateway Error) aus und zog alle Google-Cloud-Dienste mit in den Abgrund. Offiziell hat Google die Probleme mit Hardware-Ausfällen bei seinen Infrastruktur-Komponenten begründet.

Mit dem Multi-Cloud-Ansatz zu mehr Robustheit

Wie dem auch sei. Warum auf eine Cloud setzen, wenn es so viele gibt? Die reellen Bedrohungen des informationstechnischen wie auch wirtschaftlichen Fortbestands digitalisierter Unternehmen im COVID-Lockdown wurden mancher Chefetage erst im Nachhinein bewusst. Doch wo ein Wille ist, ist auch ein Weg. Seither machen Multi-Clouds noch mehr von sich reden.

Schematische Darstellung der Architektur der Multi-Cloud-Plattform von Jelastic .
Schematische Darstellung der Architektur der Multi-Cloud-Plattform von Jelastic .
(Bild: Jelastic)

Der Begriff Multi-Cloud bezeichnet neuerdings das Zusammenführen mehrerer SaaS- und/oder PaaS-Dienste zu einer einzigen Laufzeitumgebung für cloud-nativen Softwarecode, sei es in Form von Microservices oder Funktionscode. Der Multi-Cloud-Ansatz erlaubt es, den katastrophalen Ausfall eines Cloud-Anbieters durch die Verschiebung laufender Workloads in andere Clouds auszugleichen. Diese Umstellung muss allerdings in Beinahe-Echtzeit stattfinden. Manuelle Eingriffe zur Provisionierung von Infrastrukturbauteilen, zur Umsetzung von Konfigurationsänderungen oder gar Anpassungen des Anwendungscode an eine andere Betriebssystemplattform kommen in diesem Szenario erst gar nicht in Frage. Die erfolgreiche Ausführung erfordert einen cloud-agnostischen Ansatz der Anwendungsentwicklung und -Bereitstellung.

Schematische Darstellung der Architektur der HashiCorp Cloud Platform auf dem Unterbau von AWS, Azure und GCP.
Schematische Darstellung der Architektur der HashiCorp Cloud Platform auf dem Unterbau von AWS, Azure und GCP.
(Bild: HashiCorp)

Schematische Darstellung der Funktionsweise der Multi-Cloud-Lösung VMware Tanzu.
Schematische Darstellung der Funktionsweise der Multi-Cloud-Lösung VMware Tanzu.
(Bild: VMware)

Lösungen wie die quelloffene Cloud Foundry versprechen zwar Abhilfe, aber nur die wenigsten Unternehmen haben hierzu die nötige Expertise entwickelt, um Multi-Cloud-Umgebungen im Selbstbedienungsverfahren aufzusetzen und ohne externe Hilfe zu betreiben. Jene Nutzer adressieren Anbieter wie VMware mit Tanzu sowie Anbieter von Cloud-Anwendungsplattformen wie Jelastic (Jelastic.com) oder HashiCorp mit der HashiCorp Cloud Platform mit AWS, Microsoft Azure und GCP als Unterbau.

Fazit

„Cloudifizierte“ Unternehmen gehen aus der Corona-Krise nicht alle angeschlagen hervor. Die einen oder anderen sind gestärkt durch die Erkenntnis, dass sie mit ausgereiften Multi-Cloud-Ansätzen ungeachtet möglicher Dienstausfälle einzelner Cloud-Anbieter ihr Schicksal selbst in die Hand nehmen und ihre Betriebskontinuität gewährleisten können.

* Das Autorenduo Anna Kobylinska und Filipe Pereira Martins arbeiten für McKinley Denali Inc. (USA).

(ID:46752245)