Diese Kettenreaktion legte Windows Azure lahm
Kommentare

Einige unter Ihnen erinnern sich vielleicht, sofern der Vorfall nicht zwischen Weihnachtsbaum und Silvesterknallern untergegangen ist: Am 28. Dezember war Windows Azure für rund zwei Tage ausgefallen.

Einige unter Ihnen erinnern sich vielleicht, sofern der Vorfall nicht zwischen Weihnachtsbaum und Silvesterknallern untergegangen ist: Am 28. Dezember war Windows Azure für rund zwei Tage ausgefallen. Der Fehler betraf einige Kunden der Public Cloud im Datencenter der Region US South.

Wo die Cloud doch angeblich so ausfallsicher sein soll, fragen wir uns nun natürlich, wie Windows Azure derart langfristig lahm gelegt werden konnte. Dieser Frage ist auch Microsoft selbst nachgegangen. Die gewonnenen Erkenntnisse wurden im Windows Azure Blog veröffentlicht.

In jedem Datencenter befinden sich mehrere Speichereinheiten, genannt Stamps. Ein Stamp wiederum enthält mehrere Speicherknoten. Gleichzeitig gibt es da auch noch den Fabric Controller, der die Hardware überwacht und verhindert, dass Fehler von einem Stamp auf andere übergreifen. Tritt ein Fehler im Fabric Controller auf, wird er durch die sogenannte Node Protection davon abgehalten, unangebrachte Aktionen auf die einzelnen Knoten anzuwenden.

Einige Zeit vor dem Datum des Azure-Ausfalls kamen mehrere Knoten aus der Reparatur zurück. In diesem Falle wird die Node Protection ausgeschaltet, damit die Knoten neu eingerichtet werden können. Aufgrund menschlichen Versagens wurde der Schutz jedoch nach der Einrichtung nicht wieder aktiviert und so waren zehn Prozent der in diesem Stamp enthaltenen Knoten ohne Schutz.

Gleichzeitig war auch in dem Überwachungssystem, das normalerweise Konfigurationsfehler von Knoten aufspürt, ein Fehler aufgetreten. Aus diesem Grund erfuhr niemand von dem fehlenden Schutz der neu eingerichteten Knoten.

Und so kam es, wie es kommen musste. Am 28. Dezember um 7.09 Uhr Ortszeit wurde der Übergang auf einen neuen Hauptknoten durchgeführt – das geschieht hin und wieder zur Instandhaltung und Einrichtung von Updates. Während dieses Vorgangs wurde fälschlicherweise eine Aktion des Fabric Controllers gegen die ungeschützten Knoten ausgelöst. Diese Aktion formatierte die Treiber auf den besagten Knoten neu und so wurden alle drei Kopien der betroffenen Knoten praktisch unbrauchbar.

Glücklicherweise fanden die Verantwortlichen relativ schnell eine Möglichkeit, die verlorenen Daten im Storage Stamp ohne Verlust wiederherzustellen und am 30. Dezember um 9.32 Uhr waren alle Daten wieder da.

Doch natürlich wurden auch Konsequenzen aus dem Ausfall gezogen. Das Knoten-Überwachungssystem wurde repariert, der Bug im Fabric Controller, welcher die Neukonfigurationen auslöste, gefixt. Die Mitarbeiter des Datencenters möchte man in Zukunft besser schulen, sodass Leichtsinnsfehler wie der besagte künftig nicht mehr auftreten können. Durch den Vorfall geschädigte Kunden werden natürlich angemessen entschädigt – so das Versprechen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -