Eine der Stärken der Cloudinfrastrukturen der Hyperscaler AWS, Microsoft und Google liegt eigentlich in deren Redundanz und damit ihrer Ausfallsicherheit. Hundertausende über geografische Regionen verteilte Server stehen bereit, um die Workloads rund um die Uhr abzuarbeiten und bei Störungen an Orte zu verschieben, die reibungslos laufen. Schon allein diese Features stellen allerdings eine große Herausforderung für die Cloudanbieter dar. Denn einerseits ist die Skalierung – etwas kontraintuitiv – eine umso schwierigere Aufgabe, je größer ein Rechenzentrum bereits ist. Dazu kommt die Dynamik einer siebenstelligen Anzahl von gleichzeitig laufenden, verteilten Anwendungen und deren Monitoring. Die Überwachung dieser Datenströme und deren Abhängigkeiten ist enorm komplex – und das im Übrigen nicht nur bei den Hyperscalern, sondern auch in großen lokalen Wolken.

Doch am 25. Januar zeigte sich am Beispiel Microsoft 365 und Azure, dass es selbst in einer Cloud mit rund 200 zugehörigen Rechenzentren und 200.000 Kilometer Microsoft-eigenen Kabeln einen Single Point of Failure gibt. Dieser manifestierte sich, als ein Techniker von Microsoft neue Router ins Azure-Netz bringen sollte. Bei dieser Skalierung ließ besagter Mitarbeiter alle internen Best Practices außen vor und seine erledigte Arbeit prüfte auch niemand mehr vor der Produktivschaltung. Der im Rahmen dieses Upgrades begangene Fehler zog schnell weite Kreise im Azure-Netzwerk. Zentrales Problem war ein katastrophaler Kommandozeilenbefehl, der alle anderen Router im Netz anwies, ihre IGP-Datenbanken zu löschen und die Routen neu zu berechnen. Ein solcher Befehl ist in Azure eigentlich einem System unterworfen, das ihn freizugeben hat. Nur bezieht Microsoft Router von drei Herstellern und bei den Geräten eines Anbieters wurde versäumt, diese Art von Anweisungen in die Block-Liste aufzunehmen. Kurze Zeit später standen erst Office 365 und schließlich auch Azure still.

Und dass die Redmonder Admins zudem noch empfahlen, Informationen zur Störung im nicht erreichbaren Azure Admin Center abzurufen und gleichzeitig die hauseigenen Statusseiten zu Azure alles in Grün anzeigten, setzte dem für Admins wie Microsoft gleichermaßen gebrauchten Tag noch die Krone auf. Somit dürfte das Vertrauen vieler IT-Verantwortlicher in die Cloud zumindest eingetrübt sein. Gleichzeitig gilt es aber auch, für die eigene Hybrid Cloud wertvolle Lehren zu ziehen und einen eigenen Blackout zu vermeiden. Etwa auf ein geeignetes Monitoring zu setzen, wie wir es mit ThousandEyes ab Seite 20 testen, oder wichtige Workloads lokal vorzuhalten. Dies erlaubt AppScale (Seite 24) auf eine AWS-kompatible Art und Weise.