Azure Wartungsprozesse und die Verfügbarkeit von Azure VMs

Was passiert eigentlich mit deinen Azure-VMs, wenn Microsoft die unterliegende Hardware-Plattform aktualisiert? Dass du für eine in Azure betriebene Einzel-VM schon allein aus Gründen der Hardwarewartung der physischen Infrastruktur keine Verfügbarkeit von 100 Prozent erwarten darfst, liegt auf der Hand. Doch wie hoch sind die Verfügbarkeiten für Azure-VMs, sichert Microsoft die Verfügbarkeit eigentlich per SLA zu und was kannst du tun, um die Verfügbarkeit zu verbessern? Diese grundlegenden Fragen beantwortet dieser Beitrag.

Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!

Azure ist eine Cloud Computing-Plattform zum Erstellen, Bereitstellen und Verwalten von Anwendungen und Diensten über einen Verbund von Rechenzentren, die von Microsoft verwaltet werden. Sobald du als Kunde im Rahmen von IaaS virtuelle Maschinen in Azure erstellst oder PaaS-Dienste nutzt, welche ihrerseits auf virtuellen Maschinen bestehen, werden diese VMs auf dem für die Verwendung in der Cloud optimierten Azure-Hypervisor ausgeführt. Dieser ist nicht öffentlich zugänglich. Zur Verbesserung der Zuverlässigkeit, Leistung und Sicherheit seiner Host-Infrastruktur für virtuelle Computer aktualisiert Microsoft seine Plattform regelmäßig. Diese Updates umfassen Patches für Softwarekomponenten in der Hostumgebung, aber auch Upgrades für Netzwerkkomponenten oder die Außerbetriebsetzung von Hardware.

Dabei gehört es zur Strategie von Microsoft, dass sich Updates möglichst wenig auf die von Kunden gehosteten virtuellen Computer auswirken. Das lässt sich aber nicht zu hundert Prozent verhindern. Sollten Updates Auswirkungen haben, verwendet Azure stets das Verfahren, das die geringsten Auswirkungen für Updates hat.  

Neben diesen „regulären“; also  …

1. geplanten Updates, gibt es noch zwei weitere Ereignisse, welche die Verfügbarkeit deiner VMs beeinträchtigen, nämlich das …
2. ungeplante Hardware-Wartungs-Ereignis und die …
3. unerwartete Downtime.
   

Geplante Hardware-Wartung

Schauen wir uns zuerst die reguläre Wartung an: Ist ein Update der Host-Hardware ohne Neustart der „betroffenen“ VM möglich, hält Azure die VM kurzzeitig (einige Sekunden) an, aktualisiert den Host und setze die VM fort. Derartige Wartungsvorgänge werden sequentiell auf die einzelnen Fehlerdomänen (siehe unten) angewendet und gelten als erfolgreich beendet, sobald ein Integritätswarnungssignal empfangen wird. Sollte das Aktualisieren des Host auf dieser Weise nicht möglich sein, verschiebt Azure die VM zur Laufzeit auf einen bereits aktualisierten Host (Live Migration). In beiden Fällen bekommst du davon als Kunde quasi nichts mit, da deine VM keine Downtime erfährt.

Sollte die Wartung des Hosts doch einen Neustart der VM nach sich ziehen, informiert dich Azure über die so genannte „geplante Wartung“ und richtet dir ein Zeitfenster von 35 Tagen ein, innerhalb dessen du die Wartung zu einem Zeitpunkt deiner Wahl durch Neustart der VM selbst veranlassen kannst, bevor Microsoft dies tut. Die VM kommt dann auf einem bereits aktualisierten Host wieder hoch. Ob eine Host-Wartung ansteht, siehst du entweder im Azure Monitor im Abschnitt „Service Health“ unter „Planned maintenace“ …

… oder bei ausgewählter VM im Menü „Updates“ um Abschnitt „Host OS updates“

Azure plant solche Wartungen, die einen Neustart erfordern, in „Wellen“, wobei jede Welle einen anderen Umfang (Regionen) hat. Startpunkt einer jeden Welle ist immer eine Kundenbenachrichtigung. Dieser wird per Default an den Administrator des Abonnements gesendet. Es ist aber problemlos möglich, weitere Empfänger und Nachrichtenoptionen wie E-Mail, SMS und Webhooks mithilfe einer benutzerdefinierten Warnung im Aktivitätsprotokoll einzurichten. Erst wenn die Benachrichtigung erfolgt ist, wird das oben erwähnte Self-Service-Zeitfenster bereitgestellt. Erst im Anschluss an das Self-Service-Zeitfenster von 35 Tagen beginnt das Zeitfenster für die geplante Wartung in dem Azure die erforderliche Wartung „irgendwann“ einplant und auf die betroffenen VMs anwendet. Die Self-Service-Wartung ist aber nicht in jedem Fall eine gute Idee, z. B. dann nicht, wenn du Verfügbarkeitsgruppen nutzt, um deine VM/Anwendungsverfügbarkeit zu erhöhen (s. u), denn bei Verfügbarkeitsgruppen wird ohnehin immer nur eine Update-Domäne nach der anderen aktualisiert.

Ungeplante Hardware-Wartung

Es kann auch zu einem so genannten „ungeplantes Hardware-Wartungsereignis“ kommen. Ein solches tritt auf, wenn die Azure-Plattform von sich aus vorhersagen kann – z. B. aufgrund problematischer Sensor- oder SMART-Daten der Hosts -, dass eine bestimmte Plattformkomponente, die einer physischen Maschine zugeordnet ist, kurz vor dem Ausfall steht. In diesem Fall wird so ein ungeplantes Hardware-Wartungsereignis ausgegeben und Azure verschiebt die betreffenden VMs via Live-Migration von der fehlerhaften Hardware auf eine fehlerfreie physische Maschine. Bei Live-Migrationen kann es allenfalls dazu kommen, dass die Leistung vor und / oder nach dem Ereignis kurz reduziert wird.

Unerwartete Ausfall

Zu einem unerwarteten Ausfall kommt es dann, wenn die Hardware oder die physische Infrastruktur für die virtuelle Maschine unerwartet ausfällt, z. B. aufgrund lokaler Netzwerkfehler, lokaler Festplattenfehler oder andere Fehler auf Rack-Ebene. Microsoft stellt die betreffenden VMs dann durch Neustart wieder her, wodurch bei den virtuellen Maschinen Ausfallzeiten auftreten. In einigen Fällen ist auch der Verlust des temporären Laufwerks möglich. Das Neustarten der VMs auf fehlerfreier Hardware ist möglich, weil OS- und Daten-Datenträger der VMs nicht von den physischen Hosts bereitgestellt werden auf denen die VMs laufen, sondern als so genannte verwaltete Datenträger aus einen Azure Speicherkonto stammen – dort werden die VHDs von der Plattform als Blobs verwaltet – und über das Netzwerk an die VMs angeschlossen sind, vergleichbar dem booten von einer SAN-LUN bei einem lokalen Storage Array.

Übrigens aktualisiert Microsoft das Betriebssystem oder die Software deiner VMs nicht automatisch, so dass du ggf. die vollständige Kontrolle und Verantwortung dafür hast, wann und ob OS-Patches eingespielt werden.

Verfügbarkeiten von Azure VMs

Beim Bereitstellen von Azure VMs z. B über das Portal hast du im ersten Schritt „Basics“ des Assistenten im Abschnitt „Instance details“ bei „Availability-Options“ die Möglichkeit, eine Verfügbarkeitsoption zu bestimmen. Standard ist „No infrastructure redundancy required“. In diesem Fall erhältst du stets eine Einzel-VM, deren Verfügbarkeit durch die Verfügbarkeit der Datenträger bestimmt wird. Bei Premium-Disks liegt diese bei 99,9 %. Wenn du z. B. im übernächsten Schritt „Disks“ des Bereitstellungsassistenten stattdessen „Standard SSD“ oder „Standard HDD“ wählst, weist Azure dich auch darauf hin, dass sich nur eine VM mit Premium Disk für den 99,9-%-SLA qualifiziert. Das gilt auch nur dann, wenn sämtliche Disks der VM (OS-Disk und alle Daten-Disks) Premium-SSDs sind. Bis vor wenigen Monaten war dies die einzige Möglichkeit, um in Azure einen SLA für die Verfügbarkeit eine Einzel-VM zu bekommen. Inzwischen gibt es auch SLAs für mit Standard-SSDs (99,5 %) und mit Standard-HDDs (99%) bestückte Einzel-VMs. Auch hier zählt das Service-Level-Agreement nur, wenn die VM über durchgängige gleiche Disk-Typen verfügt. Die drei „höherwertigen“ Verfügbarkeitsoptionen für Azure-VMs sind „Availability set“, „Availability zone“ und „Virtual Maschine Scale Set, wobei ein Scale Set eigentliche keine Verfügbarkeits-Option ist, sondern das Pendant zu einer Autoscaling-Gruppe in AWS. Die Verfügbarkeit ist hier die gleiche, wie bei Availability Zones.

Platzierst du zwei oder mehr Azure VMs in einem „Availability set“ sorgt die Azure-Plattform dafür, dass diese VMs nicht in der gleichen Fault-Domain (im gleichen Rack) und nicht in der gleichen Update-Domain platziert werden, also bei der oben erwähnten sequenziellen Host-Wartung nicht gleichzeitig betroffen sein können.  Eine Fehlerdomäne definiert eine Gruppe von virtuellen Computern, die eine Stromquelle und einen Netzwerkswitch gemeinsam nutzen. Die innerhalb der Verfügbarkeitsgruppe eingerichteten virtuellen Computer werden per Default auf bis zu drei Fehlerdomänen verteilt.

Dazu musst du das Availability Set – dieses kannst du im Zuge der VM-Erstellung oder vorab einrichten – mit genau diesen beiden Konfigurations-Optionen einrichten.

Microsoft garantiert dann eine Verfügbarkeit von 99,95 für die VM. Das ist natürlich nur statistisch korrekt, da ja Verfügbarkeit keine Frage des Deployments, sondern des Anwendungs-Designs ist. In der Praxis bedeutet das, dass du eine Anwendung benötigst, die mit horizontalem Clustering umgehen kann, wie z. B. eine Webserver-Farm und dass du dein Availability Set auch im Backend eines Azure Loadbalancers platzieren musst. Da das Availability Set einen Standard-Anwendungsfall für den Azure Load-Balancer darstellt, ist dieser in der Basic-Version kostenlos und akzeptiert in der Basic-Variante nur Availabilty-Sets oder Scale Sets im Backend-Pool. Der Load Balancer lässt sich unmittelbar bei der VM-Bereitstellung mit der VM im Availablity Set verbinden.

Würdest du eine Webserver Farm mit Hilfe eines Azure Load Balancers und Azure-VMs im Backend-Pool bereitstellen (ohne Availability Set) dann „wüsste“ die Azure-Pattform nicht, dass deine VMs im Backend Pool in Bezug auf Ihre Anwendung miteinander in Beziehung stehen. Theoretisch könnte es dann durchaus passieren, dass alle VMs deine Anwendung auf Servern im gleichen Rack (Fault Domain) oder auf Servern der gleichen Update-Domäne platziert würden, was die Wahrscheinlichkeit eines gleichzeitigen Ausfalls erhören würde.

Konstrukte wie das Availability Set gibt es z. B. bei AWS nicht, weil bei AWS durchweg jede AWS-Region über Verfügbarkeitszonen (Availability Zones) verfügt. Bei Azure ist das nicht so. Verwendest du allerdings auch in Azure eine Region mit Verfügbarkeitszonen (d. h. geografisch voneinander getrennten, autarken Rechenzentren, die durch Glasfaserleitungen mit niedriger Latenz miteinander verbunden sind), kannst du die VMs im Backend-Pool ihres Load Balancers auch in drei verschiedenen Zonen platzieren, was die Verfügbarkeit deiner Anwendung auf 99,99 % erhöht, auch wenn Microsoft diesen Wert statisch für die VM nennt.