Google legt die Ursache für den Cloud-Ausfall am 2. Juni 2019 offen

Google hat jetzt die Ergebnisse seiner Analysen veröffentlicht, warum es zu einem Cloud-Ausfall kam. Hier einige Informationen, um was es geht und warum es zu dem Ausfall kam.

Worum geht es genau?

Anfang Juni 2019 kam es zu einem vierstündigen Ausfall einiger Cloud-Dienste von Google. Glücklicherweise fand der Ausfall en einem Sonntag statt, so dass kaum Firmennutzer auf Leistungen wie die G Suite zugriffen. Trotzdem hatte der Ausfall einige gravierende Konsequenzen.

(Google Cloud down – downdetector.com)

Die Ausfälle von YouTube oder Snapchat sowie der G Suite waren Google-Leistungen, die die Benutzer wegen fehlender Anmeldung oder Bandbreite nicht mehr nutzen konnten. Der Ausfall hatte weltweit für betroffene Benutzer wohl breitere Auswirkungen als nur ein gestörtes Gmail oder YouTube. Der folgende Tweet verdeutlicht, dass das who is who der US-Digital-Branche betroffen war.

Affected companies include some of the biggest names around, such as Snapchat, Vimeo, Shopify, Discord, Pokemon GO; but also most of Google's own services, like YouTube, Gmail, Google Search, G Suite, Hangouts, Google Drive, Google Docs, Google Nest, and others. pic.twitter.com/T1PTvQ4jGI

— Catalin Cimpanu (@campuscodi) 2. Juni 2019

Stichwort Nest: Deren Thermostate steuern Heizungen und Klimaanlagen in US-Haushalten. Das Zeugs ließ sich nicht bedienen, weil die App ausgefallen war. Elektronische Schlösser versperrten Hausbesitzern den Zugang, Online-Games waren nicht spielbar und der Taxi-Vermittlungsdienst UBER war wohl mangels App auch nicht vermittlungsfähig. Ich hatte über den Ausfall hier im Blog im Beitrag Google Cloud-Dienste waren down sowie bei heise im Artikel Googles Cloud-Dienste am Sonntag ausgefallen berichtet.

Google legt die Gründe für den Ausfall offen

Ich hatte die Information bereits kurz bei Golem gesehen – bin aber auch über einen Tweet auf eine weitere Darstellung bei Wired auf die Post Mortem-Analyse von Google aufmerksam geworden.

The author of this did a great job of translating the post Mortem in a way people would understand what happened with the cascading failures https://t.co/H2T5fBG9TR

— jessie frazelle ‍ (@jessfraz) 8. Juni 2019

Die Statusinformationen von Google sind im Original hier einsehbar. Die Probleme wurden durch eine Fehlkonfiguration im Netzwerk hervorgerufen. Mit beteiligt war die automatisierte Pflege des Netzwerks.

Hintergrundinformationen zur Cloud-Struktur

Innerhalb eines einzelnen physischen Rechenzentrums sind die Maschinen von Google in mehrere logische Cluster unterteilt, die über eine eigene, dedizierte Cluster-Management-Software verfügen, die die Ausfallsicherheit jedes einzelnen Cluster-Managers gewährleistet. Die Netzwerkkontrollebene von Google läuft unter der Kontrolle verschiedener Instanzen derselben Cluster-Management-Software; an jedem einzelnen Standort werden wiederum mehrere Instanzen dieser Cluster-Management-Software verwendet, so dass der Ausfall einer einzelnen Instanz keinen Einfluss auf die Netzwerkkapazität hat.

Die Cluster-Management-Software von Google spielt eine wichtige Rolle bei der Automatisierung von Wartungsereignissen im Rechenzentrum, wie Änderungen an der Strominfrastruktur oder der Erweiterung des Netzwerks. Die Größe von Google bedeutet, dass Wartungsereignisse weltweit verbreitet sind, wenn auch selten an einem einzigen Ort. Aufträge, die von der Clustermanagementsoftware ausgeführt werden, sind mit einem Hinweis darauf gekennzeichnet, wie sie sich bei einem solchen Ereignis verhalten sollen: Typischerweise werden Aufträge entweder auf eine Maschine verschoben, die sich nicht in der Wartung befindet, oder sie werden nach dem Ereignis gestoppt und neu eingeplant.

Es ist schief gegangen, was schief gehen konnte

Am Anfang des Problems waren zwei normalerweise fehlerhafte Konfigurationen. Und dann kam noch ein spezifischer Softwarefehler hinzu, der dann zum Ausfall der Cloud geführt hat:

• Erstens wurden die Aufträge für die Netzwerkkontrollebene und ihre unterstützende Infrastruktur in den betroffenen Regionen so konfiguriert, dass sie bei einem Wartungsereignis gestoppt werden.
• Zweitens wurden die mehreren Instanzen von Cluster-Management-Software, die auf der Netzwerkkontrollebene laufen, als für die Aufnahme in einen bestimmten, relativ seltenen Wartungsereignistyp geeignet markiert.
• Drittens hatte die Software, die Wartungsereignisse auslöst, einen spezifischen Fehler. Die Software kann ein Wartungsereignis für mehrere unabhängige Software-Cluster einplanen und selbst entscheiden, selbst wenn sich diese an verschiedenen physischen Standorten befinden.

Idee war, eine Wartung an einigen wenigen Servern vorzunehmen. Auf Grund des Bugs in der Automatisierungssoftware wurden mehrere der unabhängigen Cluster gleichzeitig angewiesen, ihre Dienste zu stoppen. Es betraf dabei auch Cluster an verschiedenen Standorten. Am Ende waren alle Server von der automatisierten Netzwerkverwaltung über die Wartungsroutine in den betreffenden Bereichen offline.

Google hat zwar sein Netzwerk so geplant, dass es sogar solche Ausfälle überstehen kann. Klappte auch für einige Minuten, bis das BGP-Routing zwischen den Standorten zurückgezogen wurden. Damit brach die Netzkapazität plötzlich massiv ein – es kam zu den beobachteten Cloud-Ausfällen.

Techniker müssen vor Ort ran

Die Google-Techniker haben das zwar sofort bemerkt. Aber die Überlastung des Netzwerks verhinderte, dass die Korrektur der Störung zügig erfolgen konnte. Automatisierte Werkzeuge zur Fehlerbehebung über das Netzwerk waren nicht mehr einsetzbar, die Techniker musste raus und die Korrekturen in den einzelnen Rechenzentren durchführen. Das kostete halt Zeit, was den Ausfall über vier Stunden erklärt. McMurphy hat wieder zugeschlagen: Was schief gehen kann, geht schief.