Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03397.jsonl.gz/2186

Der Tag, an dem Azure still stand: Ein Bug, schlecht durchdachte Sicherheitsmechanismen, ein schneller Fix, ein vergessener Test und ein paar Server, denen alles zu viel wurde.
Eine kleine Horrorstory für Cloud-Provider und deren Kunden. Und alles begann, wie sich das für eine Horrorstory gehört, um Punkt Mitternacht: Microsoft-Mann Bill Laing hat in einem ausführlichen und aufschlussreichen Blog-Eintrag
geschildert, wie es dazu kam, dass Microsofts Cloud-Platfform Azure, und damit die darauf laufenden Applikationen zahlreicher Kunden, am 29. Februar fast einen Tag lang nicht richtig funktionierte.
In Azure tickte eine Zeitbombe in Form eines Logikfehlers in der Zeitberechnung eines kleinen, aber essentiellen Softwaremoduls. Um zu erklären, wie der Fehler die ganze Plattform beeinträchtigen konnte, muss Laing etwas ausholen. Dabei verrät er auch viele interessante Details zur Funktionsweise der Azure-Plattform.
Die Plattform
Die Plattform ist in Cluster von je rund 1000 physischen Servern unterteilt, so Laing, auf denen eine wechselnde Zahl von virtuellen Maschinen läuft. Die physischen und virtuellen Server eines Clusters werden über eine gemeinsame Management-Software, den sogenannten "Fabric Controller" (FC) verwaltet. Ein FC führt dabei auch selbstständig automatische Funktionen aus. Dazu gehört es beispielsweise, virtuelle Maschinen auf "gesunde" Server zu verschieben, wenn der FC glaubt, dass ein Server Probleme hat.
Mit den virtuellen Maschinen kommuniziert der FC über zwei Softwaremodule, einen in jeder virtuellen Maschine vorhandenen "Guest Agent" (GA) sowie einen "Host Agent" (HA). Wenn eine virtuelle Maschine neu aufgesetzt wird, ist die erste Aufgabe der beiden Agenten, die verschlüsselte Kommunikation sicherzustellen, so dass "Geheimnisse" wie beispielsweise SSL-Zertifikate ausgetauscht werden können. Dazu muss zuerst der GA ein "Transferzertifikat" erstellen.
Der Schalttagbug
An dieser Stelle war die Zeitbombe eingebaut. Das vom GA erstellte Transferzertifikat hat eine Gültigkeit von einem Jahr. Startdatum ist das aktuelle Datum, das Ende derselbe Tag ein Jahr später. Bei der Programmierung war aber der Schalttag vergessen gegangen. Am 29. Februar 2012 versuchten die Guest Agents von neu aufgesetzten virtuellen Maschinen, Zertifikate mit Gültigkeit bis 29. Februar 2013 auszustellen. Da das letztere Datum gleichzeitig als ungültig erkannt wurde, ging die Zertifikatserzeugung schief. Wenn sie nicht klappt, sind die GAs darauf programmiert, sich abzuschalten.
Wenn ein Host Agent 25 Minuten nichts von einem neuen GA hört, versucht er, die virtuelle Maschine neu zu starten. Erst nach zwei Versuchen gibt er seinerseits auf, und meldet das Problem nach 75 Minuten dem FC. Dieses glaubt, weil in der virtuellen Maschine noch kein weiterer Code ausgeführt wurde, dass ein Hardware-Problem vorliegt. Darauf ruft er um menschliche Hilfe – beziehungsweise er setzt den Server auf "Human Intervention" (HI) Status. Gleichzeitig beginnt er selbsttätig, alle auf dem betroffenen Server laufenden virtuellen Maschinen, auch die, welche problemlos laufen, auf anderen Servern zu replizieren. Dort sollte dann aber wiederum der GA als erstes ein Transferzertifikat generieren. Das lief am 29. Februar, da der GA ja immer noch der gleiche war, natürlich wieder schief, und 75 Minuten später galten auch der nächste Server als "krank" – so konnte der Bug eine Art Kettenreaktion auslösen.
Wenn in einem Cluster ein bestimmter Anteil der Server auf HI-Status gesetzt wurde, schlägt der FC Generalalarm an die menschlichen Administratoren. Zusätzlich stoppt er alle internen Updates und das selbstständige "Heilen" von virtuellen Maschinen.
Eines langen Tages Reise in die Nacht...
Ab Punkt Null Uhr Standardzeit am 29. Februar, 16 Uhr Nachmittags am Microsoft-Hauptsitz in Redmond, versuchten die GAs neu aufgesetzter virtueller Maschinen in Azure also Transferzertifikate mit Gültigkeit bis 29. Februar 2013 zu generieren, und hörten deshalb auf, zu funktionieren. In manchen Clustern verlief die Fortpflanzung des Bugs schleichend. In vielen Clustern waren aber sofort sehr viele GAs betroffen. Da dort zufälligerweise gerade ein geplanter Update der FCs, HAs und GAs stattfand, wurden gerade sehr viele virtuelle Maschinen neu aufgesetzt. Diese Cluster erreichten so präzise 75 Minuten später, um 17 Uhr 15, alle gleichzeitig die HI-Alarmschwelle, was die Administratoren wohl ziemlich verschreckte. Diese informierten darauf sofort das FC-Entwicklerteam.
Dieses identifizierte um 18 Uhr 38 Redmond-Zeit den Schalttagbug. Um 18 Uhr 55 deaktivierte das Team weltweit das kundenseitige Servicemanagement, so dass Kunden ihre Applikationen nicht mehr ändern oder updaten konnten. Der Gedanke war es, zu verhindern, dass Kunden durch eigene Aktivitäten und das Aufsetzen neuer virtueller Maschinen die Situation verschlimmern konnten.
...in den Morgen...
Um 22 Uhr war ein Test- und Rollout-Plan für neue GAs parat, um 23 Uhr 20 dann auch die gepatchten GAs selbst. Danach testete man die neuen GAs bis um 2 Uhr 11 und begann darauf, die gepatchten GAs auf die meisten produktiven Cluster zu verteilen. Um 5 Uhr 23 meldete Microsoft, dass die meisten Cluster wieder funktionierten.
Bei sieben Clustern entschieden sich die Verantwortlichen aber für ein anderes Vorgehen – was einen zweiten Ausfall verursachte. Bei diesen Clustern war der eingangs erwähnte geplante Update noch nicht abgeschlossen. Auf ihnen liefen Server mit alten Agenten zusammen mit Servern mit bereits erneuerten HAs und GAs. Die Verantwortlichen entschieden sich nun dazu, auf diesen Servern ein Software-Paket mit alten HAs und ebenfalls alten (aber gepatchten) GAs auszurollen, um die Server auf den gleichen Stand zu bringen. Dummerweise übersah man dabei, dass man in die Patch-Pakete versehentlich Network-Plugins eingeschlossen hatte, die für die neuen HAs gedacht und nicht kompatibel mit den alten HAs waren. Die virtuellen Maschinen konnten dadurch nicht aufs Netzwerk zugreifen. Fatalerweise hatte man zudem auch genau diese Funktion nicht getestet – das fehlerhafte Paket wurde ab 2 Uhr 47 auf die genannten sieben Produktivcluster "gespitzt".
Der neue Fehler wurde zwar schnell bemerkt und ein weiteres Paket zusammengestellt. Dieses musste aber erneut getestet werden, so dass man erst ab 5 Uhr 40 mit den erneuten Updates beginnen konnte. Um 8 Uhr morgens liefen dann die Cluster eigentlich wieder normal.
...und in den Nachmittag
Leider konnte man das nicht von allen virtuellen Servern behaupten. Aufgrund der verschiedenen Transitionen, so Laing, seien sie beschädigt worden. Entwickler und Adminstratoren mussten daraufhin noch Stunden daran arbeiten, auch diese Server noch manuell wieder herzustellen und zu prüfen. Erst um 14 Uhr 15 am Nachmittag konnte Microsoft endgültig Entwarnung geben.
Die Lehren
Aus dem ganzen Vorfall will Microsoft gemäss Laing diverse Konsequenzen für den Betrieb von Azure ziehen. So sollen beispielsweise Softwaretests verbessert werden, so dass auch zeitbedingte Fehler wie der Schalttag-Bug entdeckt werden sollten. Die Management-Software soll besser zwischen Hard- und Softwarefehlern unterscheiden können. Zudem sollem Mechanismen eingeführt werden, die verhindern, dass sich Fehler innerhalb eines Clusters oder der Plattform "vermehren" können.
Auch bei der Kundeninformation sieht Microsoft Verbesserungsbedarf. Das Status-"Dashboard" war während der Krise wegen Überlastung zeitweise schlecht erreichbar. Die Infrastruktur für das Dasboard soll nun stabiler gemacht werden. Zudem sollen die Informationen in Zukunft öfter nachgeführt, und die zum Teil unübersichtlichen Detailinformationen durch einfacher fassbare Zusammenfassungen ergänzt werden. (Hans Jörg Maron)