Microsofts Cloud-Ausfall (Okt. 2019) – Hintergründe und Verlauf

Was waren die Ursachen für den Ausfall der Microsoft Cloud ab dem 18. bis zum 22. Oktober 2019, die vor allem Nordamerika, aber auch Teile Europas betraf? Inzwischen läuft es wieder und Microsoft legt partiell die Gründe für die Störungen offen. Dabei gab es für mich 'überraschende' Einblicke, wie Microsoft Störungen beseitigt, die inzwischen wieder aus den offiziellen Analen getilgt wurden.


Anzeige

Rückblick: Cloud-Ausfall ab 18. Oktober 2019

Ab dem 18. Oktober 2019 kam es bei Azure, Microsoft 365 und Office 365 zu Problemen, die bis zum 22. Oktober 2019 anhielten. Nutzer konnten sich nicht mehr anmelden und die Dienste nutzen, weil die Multifaktor-Authentifizierung (MFA) streikte.

Office365-Status

Ich hatte bereits am 18. Oktober 2019 über diese Störung berichtet (siehe Multifaktor-Authentifizierung für Azure u. Office 365 gestört?). Dem Artikel nach betraf es vor allem Kunden in Nordamerika. Erstaunlich war aber der lange Zeitraum der Störungen, die über das Wochenende anhielten.

Erklärungsversuche Microsofts

Ich hatte das Thema bereits aus den Augen verloren, als ich die Nacht auf den nachfolgenden Tweet von Tero Alhonen stieß.

Er hatte sich die Statusseite mit dem Störungsverlauf anzeigen lassen. Und jetzt wird es interessant. Die Nacht stand dort für den 18. Oktober 2019 der in obigem Screenshot gezeigte Text:

Root cause: At 13:30 UTC, severe packet loss was experienced on an external network route between Microsoft and the Apple Push Notification Service (APNS). The packet loss was greater in severity and duration than previously encountered. It also coincided with morning peak traffic in North America. This combination of events caused a build-up of unprocessed requests in the MFA service, leading to service degradation and failures in MFA requests.

Mitigation: Service monitors detected the build-up of unprocessed requests in the MFA service at 13:38 UTC and engineers were fully engaged by 13:48 UTC. Engineering confirmed the issue was a loss of network connectivity and began troubleshooting within the Microsoft datacenter networks. Engineering determined that the datacenter networks did not experience loss of connectivity and pinpointed the issue as external to the Microsoft datacenter networks. While further troubleshooting was underway to identify the most impacted network routes, engineering prepared a hotfix to bypass the impacted external service altogether, and to restore MFA functionality. The hotfix was rolled out to one region to validate the effectiveness of the fix. In the meantime Saty called Tim, the external network recoverd, and packet loss was reduced to normal reates. Engineering paused further rollout of the hotfix …

Einer der Gründe für die Störung bei der Multifaktor-Anmeldung (MFA) war, dass in einer externen Netzwerk-Routing-Verbindung zwischen Microsoft und dem Apple Push Notification Service (APNS) Pakete verloren gingen. Die Techniker begannen mit der Störungssuche und –behebung und rollten einen Hotfix zur Umgehung dieser fehlerhaften Netzwerkroute aus.

Während die Techniker noch darauf warteten, ob der Hotfix das Problem beseitigen würde, hat das 'rote Telefon' geklingelt. Herr Satya (Nadella) von Microsoft hat so mir nichts, dir nichts, den Tim (Cook) bei Apple angerufen. Der Tim ist dann während des Gesprächs bei Apple in den Server-Raum gegangen und hat den Rat von Satya 'have you switched it of and on again' bei einem Router probiert. Und plötzlich war die Störung weg – so stelle ich mir als klein Lieschen die in obigem Text gelb hinterlegte Passage einfach mal vor. Müßig zu erwähnen, dass der Text inzwischen verschwunden ist (als ich die Nacht nachgeschaut habe, stand der noch so in der Statusseite – dann hat wohl ein Scherzkeks etwas auf die Mütze bekommen und musste den Text ändern). Jetzt heißt es:


Anzeige

Mitigation: Service monitors detected the build-up of unprocessed requests in the MFA service at 13:38 UTC and engineers were fully engaged by 13:48 UTC. Engineering confirmed the issue was a loss of network connectivity and began troubleshooting within the Microsoft datacenter networks. Engineering determined that the datacenter networks did not experience loss of connectivity and pinpointed the issue as external to the Microsoft datacenter networks. While further troubleshooting was underway to identify the most impacted network routes, engineering prepared a hotfix to bypass the impacted external service altogether, and to restore MFA functionality. The hotfix was rolled out to one region to validate the effectiveness of the fix. In the meantime, the external network recovered, and packet loss was reduced to normal rates. Engineering paused further rollout of the hotfix. The network issue was confirmed to be mitigated at 15:57 UTC, and the MFA service functionality recovered. The hotfix, which was then redundant, was rolled back.

Also weder Satya noch Tim waren beteiligt oder hatten schuld. Aber die MFA funktionierte plötzlich wieder. Interessant sind allerdings die Statuseinträge vom 21. und 22. Oktober 2019 für Europa.

RCA – Storage – West Europe

Summary
Between 23:20 UTC on 21 Oct 2019 and 04:32 UTC on 22 Oct 2019, a subset of customers using Storage in West Europe may have experienced service availability issues. In addition, resources with dependencies on the impacted storage unit may have experienced downstream impact in the form of availability issues or high latency.

Root Cause and Mitigation
Root Cause: The Azure Storage service uses an automatic load balancing system to partition and balance customer workloads across different servers within a storage scale unit. A partition master role maintains the map of how the partitions are distributed across the different partition servers. A routine maintenance operation on one of the partitions caused an inconsistency in the partition map due to a bug. This caused the servers handling the inconsistent state to crash and resulted in a single storage scale unit in West Europe becoming unhealthy. Downstream availability impact was then seen to several dependent services in the region.
Mitigation: Engineers developed a tool to correct the inconsistency in the partition map on the impacted scale unit. The time taken to develop and test this tool resulted in a higher than expected recovery time. Engineers also blocked the backend operation that triggered the inconsistent state until the underlying bug is fixed. Once service health was restored to the backend Storage scale unit, all dependent services automatically recovered.

Einige Benutzer, die in West Europa Speicher in der Microsoft Cloud auf Azure gebucht hatten, stellten plötzlich fest, dass der nicht mehr verfügbar war. Schuld war das automatische Load-Balancing im Azure Storage Service, welches wohl die Partitionsaufteilung über die verschiedenen Speicher-Server verteilte. Auf Grund eines Bugs gab es Inkonsistenzen in den Partitionstabellen und damit Abstürze der Server. Eine Speichereinheit in Europa war dadurch gestört. Am 22. Oktober gab es dann noch diverse Anmeldeprobleme in West Europa, die aber nicht der Rede wert waren. Genau so wenig wie die später am Tag festgestellten Probleme beim Dienstzugriff. Die Details könnt ihr hier nachlesen.

Es ist doch immer wieder schön zu lesen, wie man die Cloud im Griff hat. Und wenn alle Stricke reißen, ruft der Satya den Tim an – oder umgekehrt – und der Angerufene geht in den Keller, um den Router aus- und wieder einzuschalten. Das haben die Cloud-Spezialisten sich bestimmt bei deutschen Internet-Providern abgeguckt, die das Prozedere allen Kunden bei Störungsbehebungen empfehlen, selbst wenn der Bagger das Kabel vorm Haus durchtrennt hat. Und ja, wenn es einen Cyber-Angriff (DDoS) auf Amazon AWS gibt, stellt sich Jeff Bezos mit einem Stopp-Schild vor den Eingang des Server-Raums. Das klappt dann schon. Wenn ich aber lese, dass ein Routerausfall bei Vodafon in Deutschland 80.000 Telefonanschlüsse lahm gelegt hat, dürften die Störungen bei Cloud-Diensten mit steigender Verbreitung zunehmen. Und wenn genügend IoT-Geräte zu einem Botnet zusammen gekommen sind, könnten DDoS-Angriffe auch größere Cloud-Anbieter erden. 

Ähnliche Artikel:
Cyber-Angriff (DDoS) auf Amazon AWS
Multifaktor-Authentifizierung für Azure u. Office 365 gestört?
TeamViewer-Hack: Hatte APT41-Gruppe Zugriff auf Millionen Geräte?


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Azure, Cloud, Office, Outlook.com abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

7 Antworten zu Microsofts Cloud-Ausfall (Okt. 2019) – Hintergründe und Verlauf

  1. H.V. sagt:

    … klingt schon interessant, dass aber die beiden sich im Serverraum herumtreiben und Hardwareprobleme lösen ist was für die Geschichtensammlung des Weihnachtsmannes…

  2. 1ST1 sagt:

    Siehste mal… Bei Microsoft und Apple machen die Chefs die wirklich wichtigen Sachen noch selber! Fatal finde ich aber, dass bei Microsoft so heftige Ausfälle statt finden können, weil bei Apple was verbockt ist.

    • Günter Born sagt:

      Oha, erinnert mich an 'Chefarzt-Behandlung' und Meister in meiner Zeit als Lehrling.

      Zum Meister-Cheffe: Der war zwar Starkstrom-Klempner, schaute aber auch in die damaligen Röhrenfernseher. Als Stift schaust Du halt zu, damit Du vom Meister und Cheffe was lernen kannst … Kein Duspol oder Hochspannungsprüfer dabei, tippte er mit einem 220 Volt-Spannungsprüfer auf den Hochspannungsteil. Der Spannungsprüfer flog dann quer durch den Raum und blieb in der Couch-Garnitur stecken. War dann lernen durch praktische Anschauung ;-)

      Und zum Chefarzt: Nach meinem schweren Sportunfall lag ich 4 Wochen geerdet auf einem Bett in einem Klinikum. Hab dann beobachtet, wenn Chefarzt-Visite war. Die Chirurgen haben den beiden Cheffes erklärt, was sie da operiert hatten. Die nickten dann leicht und die 'Blase der Visiteure' verschwand wieder aus dem Zimmer. Cheffe hatte sein Chefarzt-Honorar verdient. Da habe ich mehrfach drei Kreuze gemacht, keine Chefarzt-Behandlung gehabt zu haben. Oberarzt und Stellvertreterin, die waren als Neurochirurgen Spitze (haben mir den Arsch gerettet und am Rückenmark herum operiert) – darunter und darüber war ich dann vorsichtig, was die praktischen Fähigkeiten betraf (obwohl die Leute motiviert und nicht schlecht waren). So viel zu 'der Chef macht's noch selber'. Obwohl: Ausnahmen bestätigen die Regel – und ein gerade ernannter Chefarzt wird wohl Spitze sein – aber nach mehreren Jahren Verwaltungstätigkeit könnten die praktischen Fähigkeiten deutlich abnehmen.

    • ThBock sagt:

      Wenn unser Chef (Technischer Service) bei uns im Betrieb etwas selber machen würde, fingen sogar die Atheisten an zu beten…

  3. Dani sagt:

    Bei uns in der Schweiz empfehlen die grossen ISPs öfters mal auch einen Router-Reset wenn der Neustart nicht gefruchtet hat. Scheiss drauf was der Kunde da vielleicht konfiguriert hat / hat konfigurieren lassen.
    Das schöne daran ist, das die ISPs mit ihrem schlechten Service ihren eigenen Ruf herunterwirtschaften, und wir dank denen mehr Arbeit haben (und unseren Ruf einfach aufbessern können).

  4. Tom sagt:

    …und, was wurde gecloud? – Entschuldigung für den (schlechten)Wortwitz – mir war aber gerade danach…

  5. Anonymous sagt:

    Aktuell vermeldet der Spiegel: "Pentagon vergibt Jedi-Milliardenauftrag an Microsoft".
    Alle anderen großen Anbieter haben das Nachsehen. Google sei nicht sicher "ob das Jedi-Projekt den eigenen Grundsätzen zum Umgang mit künstlicher Intelligenz entspreche".

    Haben Chinesen auch an dem Verfahren teilgenommen? Kleiner Scherz…

Schreibe einen Kommentar zu 1ST1 Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.