Editorial

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

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.