In diesem Beitrag wird unsere Reihe zum Thema Zuverlässigkeit fortgesetzt, die ich in meinem Blogbeitrag im Juli gestartet habe. Darin werden verschiedene aktuelle Initiativen zur weiteren Verbesserung der Plattformverfügbarkeit beschrieben, die unsere Verpflichtung widerspiegeln, vertrauenswürdige, sichere Clouddienste zu bieten. Heute möchte ich noch einmal auf unsere Investitionen in Updatetechnologien eingehen, die keine oder nur geringe Auswirkungen auf Benutzer haben, beispielsweise Hotpatching, speichererhaltende Wartung und Livemigration. Im letzten Jahr haben wir Dutzende Patches für die Sicherheit und Zuverlässigkeit der Hostinfrastruktur bereitgestellt. Viele davon wurden implementiert, ohne dass Kunden beeinträchtigt oder Downtimes verursacht wurden. Der nachfolgende Beitrag wurde von John Slack aus unserem zentralen Betriebssystemteam verfasst, der als Programm-Manager für mehrere der unten beschriebenen Updatetechnologien zuständig ist.“ – Mark Russinovich, CTO, Azure

---

Apurva Thanky, Cristina del Amo Casado und Shantanu Srivastava aus den für diese Technologien verantwortlichen Entwicklungsteams haben als Koautoren an diesem Beitrag mitgewirkt.

 

Die Azure-Hostinfrastruktur wird regelmäßig aktualisiert, um die Zuverlässigkeit, Leistung und Sicherheit der Plattform zu verbessern. Obwohl diese „Wartungsupdates“ unterschiedlichen Zwecken dienen, beinhalten sie in der Regel die Aktualisierung der Softwarekomponenten in der Hostumgebung oder die Außerbetriebsetzung von Hardware. Noch vor fünf Jahren bestand die einzige Möglichkeit, einige dieser Updates anzuwenden, darin, den gesamten Host vollständig neu zu starten. Bei diesem Ansatz wurden die virtuellen Computer (VMs) der Kunden jeweils mehrere Minuten heruntergefahren. Seitdem haben wir in eine Vielzahl von Technologien investiert, um die Auswirkungen bei der Aktualisierung der Kundenflotte zu minimieren. Heute werden die meisten Hostbetriebssystem-Updates per Hotpatching direkt bereitgestellt – mit absoluter Transparenz und ganz ohne Auswirkungen auf den Kunden. In seltenen Fällen, in denen kein Update per Hotpatching möglich ist, nutzen wir üblicherweise speichererhaltende Updatetechnologien mit geringen Auswirkungen, um das Update bereitzustellen.

Selbst bei diesen Technologien gibt es noch seltene Fälle, in denen die Wartung eine größere Beeinträchtigung verursacht (beispielsweise durch die Beseitigung fehlerhafter Hardware oder die Außerbetriebsetzung alter Hardware). In solchen Situationen verwenden wir eine Kombination aus Livemigration, Benachrichtigungen in VMs und geplanten Wartungsaktivitäten, die Kunden die Kontrolle geben.

Dank kontinuierlicher Investitionen in diesem Bereich haben wir einen Punkt erreicht, an dem die meisten Hostwartungsaktivitäten keine Auswirkungen auf die in der betroffenen Infrastruktur gehosteten VMs haben. Dieser Beitrag soll auf transparente Weise aufzeigen, mit welchen unterschiedlichen Verfahren wir gewährleisten möchten, dass Azure-Updates nur minimale Beeinträchtigungen verursachen.

Plan A: Hotpatching

Das „Hotpatching“ auf Funktionsebene bietet die Möglichkeit, gezielte Änderungen an ausgeführtem Code vorzunehmen, ohne dass Downtimes für Kunden-VMs entstehen. Dabei werden alle neuen Aufrufe einer Funktion auf dem Host an eine aktualisierte Version dieser Funktion umgeleitet. Daher wird diese Technologie als Update „ohne Auswirkungen“ angesehen. Nach Möglichkeit verwenden wir das Hotpatching für Hostupdates, wodurch eine Beeinträchtigung der auf dem Host ausgeführten VMs vollständig vermieden wird. Das Hotpatching wird seit 2017 in Azure verwendet. Seitdem wird die Anzahl der Komponenten, die das Hotpatching unterstützen, ständig erweitert. Beispielsweise wurde das Hostbetriebssystem im Jahr 2018 aktualisiert, damit Hotpatches für den Hypervisor ausgeführt werden können. Zukünftig befassen wir uns mit den Möglichkeiten von Firmware-Hotpatches. Dieses Thema wird von der Branche häufig vernachlässigt. Bei Firmware hieß es immer: „Update erforderlich? Dann starte den Server neu.“ Dass darunter die Kundenfreundlichkeit leidet, ist keine Frage. Wir arbeiten gemeinsam mit Hardwareherstellern an der Möglichkeit, Hotpatches und inkrementelle Updates für unsere eigene Firmware auszuführen.

Einige umfangreiche Hostupdates enthalten Änderungen, die nicht per Hotpatching auf Funktionsebene angewendet werden können. Bei diesen Updates versuchen wir, die speichererhaltende Wartung zu nutzen.

Plan B: Speichererhaltende Wartung

Bei der speichererhaltenden Wartung werden die Gast-VMs (unter Beibehaltung des Speicherinhalts im RAM) „angehalten“, der Hostserver aktualisiert und anschließend die VMs fortgesetzt und deren Uhren automatisch synchronisiert. Die speichererhaltende Wartung wurde erstmals im Jahr 2018 für Azure verwendet. Seitdem wurde die Technologie in drei wesentlichen Bereichen verbessert. Erstens haben wir für die speichererhaltende Wartung Varianten entwickelt, die geringere Auswirkungen haben und für Hostkomponenten konzipiert sind, die ohne Hostneustart gewartet werden können. Zweitens haben wir die Wartezeit für Kunden verkürzt. Drittens haben wir die Anzahl der VM-Typen erweitert, die mit der speichererhaltenden Wartung aktualisiert werden können. Obwohl wir in diesem Bereich Fortschritte machen, sind einige Varianten der speichererhaltenden Wartung mit einigen spezialisierten VM-Angeboten wie VMs der M-, N- oder H-Serie aus verschiedenen technischen Gründen weiterhin inkompatibel.

Im seltenen Fall, dass Wartungsaktivitäten größere Auswirkungen haben (beispielsweise durch Hostneustarts oder die erneute VM-Bereitstellung), werden Kunden im Voraus benachrichtigt und erhalten die Möglichkeit, die Wartung zu einem für ihre Workload(s) geeigneten Zeitpunkt durchzuführen.

Plan C: Self-Service-Wartung

Bei der Self-Service-Wartung können Kunden und Partner innerhalb eines Zeitfensters auswählen, wann Wartungsaktivitäten mit größeren Auswirkungen für ihre VM(s) initiiert werden sollen. Diese anfängliche Self-Service-Phase dauert in der Regel ungefähr einen Monat und ermöglicht es Organisationen, die Wartung nach ihrem eigenen Zeitplan auszuführen, sodass Benutzer nur eine minimale oder gar keine Unterbrechung wahrnehmen. Am Ende dieses Self-Service-Fensters beginnt eine Phase für geplante Wartungen – ab diesem Zeitpunkt wird die Wartung von Azure automatisch durchgeführt. In beiden Phasen können Kunden mithilfe von Azure Service Health oder durch eine Abfrage in PowerShell/CLI stets genau ermitteln, welche VMs aktualisiert wurden oder nicht. Die Self-Service-Wartung in Azure wurde erstmalig im Jahr 2018 angeboten. Normalerweise bevorzugen Administratoren die Self-Service-Phase, anstatt zu warten, bis ihre VMs in Azure automatisch gewartet werden.

Wenn sich der Hostcomputer darüber hinaus entweder durch die Verwendung von Azure Dedicated Hosts oder von isolierten VMs vollständig im Besitz des Kunden befindet, sind wir mittlerweile dazu übergegangen, für alle Plattformupdates, die Beeinträchtigungen beinhalten können, eine Wartungssteuerung anzubieten. Das schließt Updates ohne Neustart ein, die nur eine Unterbrechung von wenigen Sekunden verursachen. Dies ist bei VMs mit hochsensiblen Workloads hilfreich, die noch nicht einmal Unterbrechungen von wenigen Sekunden tolerieren. Kunden können in einem rollierenden Zeitfenster von 35 Tagen wählen, wann diese Updates mit Auswirkungen angewendet werden sollen. Die Funktion befindet sich in der öffentlichen Vorschau. Weitere Informationen finden Sie in diesem speziellen Blogbeitrag.

Manchmal sind Technologien für direkte Updates nicht praktikabel, z. B. wenn ein Host Anzeichen für eine Hardwarebeeinträchtigung aufweist. In solchen Fällen besteht die beste Möglichkeit darin, die VM auf einen anderen Host umzulagern. Dieser Vorgang kann entweder durch den Kunden über eine geplante Wartung gesteuert oder durch die Livemigration ausgeführt werden.

Plan D: Livemigration

Bei der Livemigration wird eine Kunden-VM bei laufendem Betrieb von einem „Quellhost“ auf einen „Zielhost" umgelagert. Zunächst wird während der Livemigration der lokale Zustand der VM (einschließlich RAM und lokalem Speicher) von der Quelle an das Ziel verschoben, während der virtuelle Computer weiterhin ausgeführt wird. Nachdem der größte Teil des lokalen Zustands verschoben wurde, wird die Gast-VM für fünf oder weniger Sekunden kurz angehalten. Nach dieser Pause wird die Ausführung der VM auf dem Zielhost fortgesetzt. Die Livemigration wurde in Azure erstmals im Jahr 2018 für die Wartung genutzt. Wenn von Azure Machine Learning-Algorithmen einen Hardwarefehler vorhergesagt wird, kann heute die Livemigration verwendet werden, um Gast-VMs präemptiv auf andere Hosts zu verschieben.

Die geplante Wartung und KI-Vorgänge waren u. a. Thema in dem kürzlich auf der Ignite 2019 gehaltenen Vortrag von Igal Figlin zur Entwicklung resilienter Anwendungen in Azure. Sehen Sie sich hier die Aufzeichnung an, um weitere Kontextinformationen zu erhalten und um mehr darüber zu erfahren, wie Sie die verschiedenen resilienten Dienste nutzen, die Azure zum Erstellen inhärent resilienter Anwendungen bietet.

Die Zukunft der Azure-Wartung 

Zusammenfassend lässt sich feststellen, dass die Wartungsaktivitäten in Azure abhängig von der Art der angewendeten Updates erheblich variieren. Unabhängig von den Besonderheiten besteht der Wartungsansatz in Azure immer darin, Kundenworkloads möglichst wenig zu beeinträchtigen. In diesem Beitrag wurden einige Technologien beschrieben, die wir zur Umsetzung dieses Ziels verwenden. Wir arbeiten intensiv daran, die Kundenerfahrung weiter zu verbessern. Mit Blick in die Zukunft investieren wir konsequent in Machine Learning-basierte Erkenntnisse und Automatisierung, um Verfügbarkeit und Zuverlässigkeit zu gewährleisten. Zuletzt wird das „KI-Vorgangsmodell“ in der Lage sein, vorbeugende Wartungsmaßnahmen auszuführen, Risiken automatisch zu mindern und beitragende Faktoren und Abhängigkeiten bei Vorfällen effektiver zu identifizieren als unsere technischen Mitarbeiter. Wir freuen uns, weitere Erkenntnisse zu diesen Themen zu teilen, während wir dazulernen und uns weiterentwickeln.