Zusammenfassung

  • Laut Azure lief eine vorübergehende Beschränkung für Betriebssystemupdates aus; zahlreiche Gateway-Updates wurden daraufhin in kurzer Zeit fortgesetzt. Eine zuvor ausgerollte Änderung hatte außerdem die Verarbeitung von Konfigurationsvorgängen verlangsamt.
  • Die kombinierte Last beeinträchtigte Verwaltungsoperationen mehrerer Netzwerkdienste in verschiedenen Regionen. Bei einigen ExpressRoute-Gateways begann das Update der nächsten redundanten Instanz, bevor Konfiguration und Routing vollständig wiederhergestellt waren.

Die bequemste Erklärung für einen Cloud-Ausfall lautet oft: Ein Update hat ihn ausgelöst. Azure beschreibt in seinem Rückblick auf den Vorfall vom 30. September bis 1. Oktober jedoch ein wichtigeres Zusammenspiel. Eine temporäre Beschränkung hatte Betriebssystemupdates für eine Gruppe von Gateways angehalten. Nach ihrem Ablauf wurden viele Updates innerhalb kurzer Zeit fortgesetzt. Gleichzeitig erhöhte eine bereits ausgerollte Änderung die Bearbeitungszeit für Konfigurationsvorgänge in einer gemeinsam genutzten regionalen Netzwerk-Steuerungsebene. Es trafen mehr Anfragen ein, während jede einzelne länger dauerte.

Das ist eine andere Kausalerzählung als der Fehler eines einzelnen Updates. Microsoft beschreibt einen Anstieg von Neustarts und Konfigurationsabrufen, der auf einen langsameren Dienst traf; vorhandene Begrenzungs- und Lastschutzmechanismen schützten kritische Verarbeitung nicht ausreichend. Die Update-Welle bewegte sich rollierend durch die Regionen, daher unterschieden sich die Zeitpunkte der Auswirkungen. Azure nennt unter anderem ExpressRoute Gateway, Application Gateway, Azure Firewall, Bastion, Virtual WAN und VPN Gateway in Regionen Amerikas, Europas, Asien-Pazifiks, Afrikas und des Nahen Ostens.

Der öffentliche Bericht enthält keine vollständige Auswirkungsaufstellung für jeden Kunden.

Ein Verwaltungsproblem unterbrach auch einige Verbindungen

Viele betroffene Vorgänge waren Verwaltungsoperationen. Bei einigen ExpressRoute-Gateways kam es jedoch zu einem konkreteren Effekt: Die Verbindung zu angeschlossenen lokalen Netzen fiel vorübergehend aus. Laut Azure konnte eine während des Updates neu startende Instanz als gesund markiert werden, bevor Konfiguration und Routingstatus wiederhergestellt waren. Das Update wechselte dann zur nächsten redundanten Instanz. Wenn beide Instanzen die benötigte Routingkonfiguration nicht abrufen konnten, brach die Verbindung ab.

Nach etwa 30 Minuten erfolgloser Konfigurationsabrufe wandten die betroffenen Gateways ihre lokal gespeicherte letzte funktionierende Konfiguration an. Diese Zeit beschreibt Microsofts Wiederholungsversuche, nicht die Ausfalldauer jedes Kunden. Der Gesamtvorfall begann am 30. September um 20:30 UTC; die letzte Auswirkungswelle wurde am 1. Oktober um 02:15 UTC entschärft. Azure weist ausdrücklich darauf hin, dass die Gesamtdauer nicht der Dauer für jeden Kunden und jede Ressource entspricht.

Der Zeitablauf zeigt auch, warum zusätzliche Kapazität allein das Problem nicht löste. Die ExpressRoute-Verschlechterung wurde um 20:43 erkannt, die breitere Steuerungsebenenstörung um 20:58. Das Anhalten weiterer Updates um 21:45 und Verkehrsverschiebungen brachten vorübergehende Entlastung; auch Versuche, Ressourcen hinzuzufügen, reichten nicht aus. Um 23:55 wurde eine Performance-Regression als Ursache der längeren Konfigurationsverarbeitung identifiziert. Der Rollback begann am 1. Oktober um 01:15 zunächst in einer Region, wurde geprüft und anschließend ausgeweitet.

Als er in den betroffenen Regionen um 02:15 abgeschlossen war, endeten die Kundenauswirkungen.

Ein Wartungsfenster gestaltet nicht, wie sich die Warteschlange leert

Laut Azure-Dokumentation können Gateway-Wartungen Softwarepatches, Netzwerkkomponenten-Upgrades und die Ausmusterung von Hardware umfassen. Kunden können für bestimmte Gateways Wartungsfenster festlegen. Das steuert den Zeitpunkt, belegt aber nicht, wie ein aufgeschobener Update-Bestand nach einer Pause abgearbeitet wird. Microsoft nennt Verbesserungen für eine gestufte Fortsetzung, Prüfungen zur Wiederherstellung von Konfiguration und Routen vor dem nächsten redundanten Update, Korrekturen an Skalierungsbeschränkungen sowie besseres Throttling und Load Shedding.

Dies sind im Bericht genannte Maßnahmen und Schätzungen, kein unabhängiger Nachweis ihres vollständigen Abschlusses.

Microsofts Leitfaden für sichere Bereitstellungen empfiehlt eine schrittweise Ausweitung, Gesundheitsprüfungen vor jeder Phase und den Stopp eines Rollouts bei Problemen. Die konkrete Betriebsfrage lautet: Bedeutet „gesund“, dass der Prozess neu gestartet wurde, oder dass die für den Dienst nötige Konfiguration und das Routing wiederhergestellt und überprüft wurden? Redundanz schützt nicht, wenn die nächste Instanz von derselben noch nicht verfügbaren Steuerungsebene abhängt.

Microsoft zufolge konnten Kunden die Auswirkungen dieses konkreten Dienstvorfalls nicht verhindern oder mindern. Sie können dennoch erfassen, welche Workloads von welchem Gateway abhängen, ihren eigenen Datenpfad getrennt von Verwaltungsoperationen beobachten und Service-Health-Warnungen konfigurieren. Das verbessert Erkennung und Reaktion; es macht den Wiederherstellungsplan des Anbieters aber nicht zu einer vom Kunden kontrollierten Garantie.

Quellen: Azure-Vorfallsbericht 7Q30-010; ExpressRoute-Virtual-Network-Gateways; Kundengesteuerte Gateway-Wartung; Sichere Bereitstellungspraktiken. Nur als redaktioneller Rahmen: Heng Lu, Notiz 20.