Grundlegendes zu einem Systemneustart für Azure VM

Gilt für: ✔️ Linux-VMs Windows VMs ✔️

Zusammenfassung

Azure virtuelle Computer (Virtual Machines, VMs) können manchmal ohne ersichtlichen Grund neu gestartet werden, ohne dass der Neustartvorgang von Ihnen initiiert wurde. In diesem Artikel sind die Aktionen und Ereignisse aufgeführt, die dazu führen können, dass virtuelle Computer neu gestartet werden. Außerdem erfahren Sie, wie Sie unerwartete Neustartprobleme vermeiden oder die Auswirkungen dieser Probleme reduzieren können.

Konfigurieren von virtuellen Computern für Hochverfügbarkeit

Die beste Möglichkeit zum Schutz einer Anwendung, die auf Azure ausgeführt wird, vor VM-Neustarts und Ausfallzeiten besteht darin, die virtuellen Computer für hohe Verfügbarkeit zu konfigurieren.

Um eine solche Redundanzebene für Ihre Anwendung zu gewährleisten, empfehlen wir die Gruppierung von zwei oder mehr virtuellen Computern in einer Verfügbarkeitsgruppe. Diese Konfiguration stellt sicher, dass während eines geplanten oder ungeplanten Wartungsereignisses mindestens eine VM verfügbar ist und die 99,95 Prozent Azure SLA erfüllt.

Weitere Informationen zu Verfügbarkeitsgruppen finden Sie unter Verwalten der Verfügbarkeit von VMs.

Ressourcen-Gesundheitsinformationen

Azure Resource Health ist ein Dienst, der den Status einzelner Azure Ressourcen verfügbar macht und umsetzbare Anleitungen zur Problembehandlung bereitstellt. In einer Cloudumgebung, in der es nicht möglich ist, direkt auf Server oder Infrastrukturelemente zuzugreifen, besteht das Ziel von Resource Health darin, den Zeitaufwand für die Problembehandlung zu reduzieren. Das Ziel ist insbesondere, die Zeit zu reduzieren, die Sie aufwenden, um festzustellen, ob die Ursache des Problems in der Anwendung oder in einem Ereignis innerhalb der Azure Plattform liegt. Weitere Informationen finden Sie unter Understand und Verwenden von Resource Health.

Wenn Azure weitere Informationen über die Ursache einer plattforminitiierte Nichtverfügbarkeit für einen virtuellen Computer hat, können diese Informationen in der Ressourcenintegrität bis zu 72 Stunden nach der anfänglichen Nichtverfügbarkeit bereitgestellt werden.

Fehlende VM-Ausfallzeiten im Aktivitätsprotokoll

Resource Health Warnungen werden basierend auf den Informationen des Aktivitätsprotokolls gesendet. In bestimmten Fällen werden VM-Ausfallzeiten möglicherweise nicht im Aktivitätsprotokoll angezeigt. Wenn die Ausfallzeit nicht im Aktivitätsprotokoll angezeigt wird, werden Resource Health Warnungen nicht für die Ausfallzeit gesendet. Die Ausfallzeiten sind in Resource Health noch sichtbar.

In den folgenden Fällen werden VM-Ausfallzeiten nicht im Aktivitätsprotokoll angezeigt:

• Wenn ein virtueller Computer erstellt oder zu einem neuen Host migriert wird, zeigt Azure Plattform den VM-Zustand nicht ordnungsgemäß an, und der Zustand ändert sich in Unbekannt. Erst wenn alle Netzwerkkonnektivitäts- und Knotenprozesse eingerichtet sind, ändert sich der VM-Status in „Verfügbar“. Der verlängerte Zeitraum des Status „Unbekannt“ wird aus dem Aktivitätsprotokoll herausgefiltert.
• Wenn sich der VM-Verfügbarkeitsstatus beispielsweise von „Verfügbar“ in „Nicht verfügbar“ ändert und dann innerhalb von 35 Sekunden wieder zu „Verfügbar“ wechselt, wird die Ausfallzeit nicht im Aktivitätsprotokoll angezeigt. Dieser Fall tritt nicht auf, wenn eine korrelierte Ausfallzeit innerhalb von 15 Minuten vor dem Auftreten des ersten Übergangs gesendet wird.
• Wenn sich der Status einer VM von einem Status in „Unbekannt“ ändert und dann zum ursprünglichen Status zurückkehrt, wird der zwischengeschaltete Status „Unbekannt“ und die zugehörigen Übergänge aus dem Aktivitätsprotokoll herausgefiltert.

Die VM-Ausfallzeiten, die nicht im Aktivitätsprotokoll angezeigt werden, werden auf der Azure-Plattformseite gefiltert, um vorübergehende Fehler daran zu hindern, fehlerhafte Ausfallzeiten für Kunden anzuzeigen. Mit fortlaufenden Investitionen in die VM-Gesundheitsqualität sind die Filter möglicherweise nicht mehr erforderlich und können dazu führen, dass schnelle Änderungen der VM-Gesundheit nicht gemeldet werden. Microsoft arbeitet an einem Phase-Out-Plan, um das beste Kundenerlebnis zu erzielen.

Aktionen und Ereignisse, die zu einem Neustart virtueller Computer führen können

Geplante Wartung

Microsoft Azure führt regelmäßig weltweit Updates durch, um die Zuverlässigkeit, Leistung und Sicherheit der Hostinfrastruktur zu verbessern, die den VMs zugrunde liegt. Viele dieser Updates, einschließlich speichererhaltender Updates, werden ohne Beeinträchtigung Ihrer virtuellen Computer oder Clouddienste ausgeführt.

Allerdings erfordern einige Updates einen Neustart. In diesen Fällen werden die VMs heruntergefahren, während wir die Infrastruktur aktualisieren, und anschließend neu gestartet.

Informationen dazu, was Azure geplante Wartung ist und wie sich dies auf die Verfügbarkeit Ihrer Linux-VMs auswirken kann, finden Sie in den hier aufgeführten Artikeln. Die Artikel enthalten Hintergrundinformationen zum Azure geplanten Wartungsvorgangs und zur Planung der geplanten Wartung, um die Auswirkungen weiter zu reduzieren.

• Geplante Wartung für VMs in Azure
• Wie planen Sie geplante Wartung auf Azure Windows virtuellen Computern
• Wie planen Sie geplante Wartung auf Azure Linux-VMs

Speichererhaltende Updates

Für diese Klasse von Updates in Microsoft Azure haben Benutzer keine Auswirkungen auf ihre ausgeführten virtuellen Computer. Viele dieser Updates betreffen Komponenten oder Dienste, die ohne Beeinträchtigung der ausgeführten Instanz aktualisiert werden können. Bei einigen handelt es sich um Plattforminfrastrukturupdates für das Hostbetriebssystem, die ohne Neustart der virtuellen Computer angewendet werden können.

Diese speichererhaltenden Updates werden mit einer Technologie durchgeführt, die eine Live-Migration vor Ort ermöglicht. Bei der Aktualisierung wird die VM in den Zustand Angehalten versetzt. In diesem Zustand wird der Speicherinhalt im RAM beibehalten, während das zugrunde liegende Hostbetriebssystem die erforderlichen Updates und Patches erhält. Die virtuelle Maschine wird normalerweise innerhalb von 30 Sekunden nach der Unterbrechung wieder gestartet. Nachdem der Betrieb des virtuellen Computers fortgesetzt wird, wird seine Uhr automatisch synchronisiert.

Aufgrund des kurzen Pausenzeitraums werden die Auswirkungen auf die virtuellen Computer durch die Bereitstellung von Updates über diesen Mechanismus stark reduziert. Aber nicht alle Updates können auf diese Weise bereitgestellt werden.

Updates für mehrere Instanzen (VMs in einer Verfügbarkeitsgruppe) werden nacheinander auf die einzelnen Updatedomänen angewendet.

Vom Benutzer initiierte Aktionen zum Neustart oder Herunterfahren

Wenn Sie einen Neustart über das Azure Portal, Azure PowerShell, die Befehlszeilenschnittstelle oder die REST-API durchführen, finden Sie das Ereignis im Azure Aktivitätsprotokoll.

Falls Sie die Aktion über das Betriebssystem des virtuellen Computers durchführen, finden Sie das Ereignis in den Systemprotokollen.

Zu weiteren Szenarien, in denen in der Regel der virtuelle Computer neu gestartet wird, gehören verschiedene Änderungen an der Konfiguration. Meist werden Sie in einer Warnmeldung darüber informiert, dass die Ausführung einer bestimmten Aktion zu einem Neustart des virtuellen Computers führt. Beispiele sind Änderungen an der Größe virtueller Computer, das Ändern des Kennworts für das Administratorkonto und das Festlegen einer statischen IP-Adresse.

Microsoft Defender for Cloud und Windows Update

Microsoft Defender for Cloud überwacht täglich Windows und Linux-VMs auf fehlende Betriebssystemupdates. Defender for Cloud ruft eine Liste der verfügbaren Sicherheits- und kritischen Updates aus Windows Update oder Windows Server Update Services (WSUS) ab, je nachdem, welcher Dienst auf einer Windows VM konfiguriert ist. Defender for Cloud sucht auch nach den neuesten Updates für Linux-Systeme. Wenn auf Ihrem virtuellen Computer ein Systemupdate fehlt, empfiehlt Defender for Cloud, Systemupdates anzuwenden. Die Anwendung dieser Systemupdates wird über die Defender for Cloud im Azure Portal gesteuert. Nachdem Sie einige Updates angewendet haben, sind unter Umständen Neustarts der virtuellen Computer erforderlich. Weitere Informationen finden Sie unter Systemupdates anwenden in Microsoft Defender for Cloud.

Wie lokale Server pusht Azure keine Updates von Windows Update an Windows VMs, da diese Computer von ihren Benutzern verwaltet werden sollen. Sie werden jedoch ermutigt, die Einstellung für den automatischen Windows Update aktiv zu lassen. Die automatische Installation von Updates von Windows Update kann auch dazu führen, dass Neustarts auftreten, nachdem die Updates angewendet wurden. Weitere Informationen finden Sie unter Windows Update FAQ.

Andere Situationen mit Einfluss auf die Verfügbarkeit von virtuellen Computern

Es gibt andere Fälle, in denen Azure die Verwendung eines virtuellen Computers aktiv anhalten können. Sie erhalten E-Mail-Benachrichtigungen, bevor eine solche Aktion durchgeführt wird, damit Sie die zugrunde liegenden Probleme lösen können. Beispiele für Probleme, die sich auf die Verfügbarkeit von virtuellen Computern auswirken, sind Sicherheitsverstöße und der Ablauf von Zahlungsmethoden.

Hostserverfehler

Der virtuelle Computer wird auf einem physischen Server gehostet, der in einem Azure Rechenzentrum ausgeführt wird. Der physische Server führt zusätzlich zu einigen anderen Azure Komponenten einen Agent aus, der als Host-Agent bezeichnet wird. Wenn diese Azure Softwarekomponenten auf dem physischen Server nicht mehr reagieren, löst das Überwachungssystem einen Neustart des Hostservers aus, um die Wiederherstellung zu versuchen. In vielen Fällen ist die VM innerhalb von 10-15 Minuten wieder verfügbar und läuft auf demselben Host weiter wie zuvor.

Serverfehler werden normalerweise durch einen Hardwarefehler, z.B. den Ausfall einer Festplatte oder eines Solid State Drives, verursacht. Azure überwacht diese Vorkommen kontinuierlich, identifiziert die zugrunde liegenden Fehler und führt Updates aus, nachdem die Abschwächung implementiert und getestet wurde.

Da einige Hostserverfehler spezifisch für den jeweiligen Server sein können, kann bei wiederholten Neustarts des virtuellen Computers eine manuelle neue Bereitstellung des virtuellen Computers auf einem anderen Hostserver die Situation verbessern. Dieser Vorgang kann mithilfe der Option redeploy auf der Detailseite des virtuellen Computers ausgelöst werden, oder indem Sie den virtuellen Computer im Azure-Portal beenden und neu starten.

Automatische Wiederherstellung

Die Azure-Plattform wurde entwickelt, um Hostknotenprobleme mit minimalen Auswirkungen auf die VM-Leistung zu behandeln. Wenn bei einem Hostknoten ein Problem auftritt, versucht Azure zuerst die am wenigsten störende Wiederherstellungsmethode, die den Host neu starten soll. Wenn ein Neustart des Hosts nicht möglich ist oder das Problem hardwarebezogen ist, initiiert Azure eine automatische Wiederherstellungsmaßnahme, um den fehlerhaften Host aus dem Betrieb herauszunehmen, um weitere Untersuchungen durchzuführen. Im Rahmen dieser automatischen Wiederherstellung verschiebt ein Prozess, der als Dienstheilung bezeichnet wird, automatisch alle virtuellen Computer auf dem fehlerhaften Host in einen anderen fehlerfreien Host um. Dieser Vorgang wird in der Regel innerhalb von 15 Minuten abgeschlossen, obwohl die Wiederherstellungszeit je nach Faktoren wie der verwendeten Arbeitsspeichergröße und den wiederherstellungsmethoden des Hosts variieren kann. Die Dienstheilung wird in der Regel als letzte Möglichkeit für Hardwarefehler verwendet, um sicherzustellen, dass VMs weiterhin ohne erhebliche Ausfallzeiten funktionieren.

Weitere Informationen dazu, wie Azure diese Szenarien behandelt, finden Sie unter Service Healing – Automatische Wiederherstellung von Virtual Machines.

Nicht geplante Wartung

In seltenen Fällen muss das Azure Betriebsteam Wartungsaktivitäten durchführen, um den Gesamtzustand der Azure Plattform sicherzustellen. Dieses Verhalten wirkt sich unter Umständen auf die VM-Verfügbarkeit aus. Das Ergebnis ist in der Regel die oben beschriebene automatische Wiederherstellungsaktion.

Zur nicht geplanten Wartung gehört Folgendes:

• Dringende Knotendefragmentierungen
• Dringende Updates für Netzwerkswitches

VM-Abstürze

Virtuelle Computer können aufgrund interner VM-Probleme oder Hardwareprobleme neu gestartet werden, z. B. aufgrund eines Betriebssystemdatenträgerproblems, wie zuvor beschrieben. Die Workload oder Rolle, die auf dem virtuellen Computer ausgeführt wird, löst eventuell eine Fehlerüberprüfung im Gastsystem aus. Um den Grund für den Absturz zu finden, überprüfen Sie das System und die Anwendungsprotokolle auf Windows VMs und die seriellen Protokolle für Linux-VMs. Das Sammeln eines Speicherabbilds ist in der Regel die beste Methode, um die Ursache zu identifizieren.

Weitere Informationen finden Sie in den folgenden Artikeln:

• Windows Absturzabbildinformationen
• Linux-Absturzabbildinformationen

Gezwungenes Herunterfahren aufgrund von Speicher

VMs in Azure basieren auf virtuellen Datenträgern für Betriebssystem und Datenspeicher, die in der Azure Storage-Infrastruktur gehostet werden. Wenn die Verfügbarkeit oder Konnektivität zwischen dem virtuellen Computer und den zugehörigen virtuellen Datenträgern länger als 180 Sekunden betroffen ist, führt die Azure-Plattform ein erzwungenes Herunterfahren der virtuellen Computer durch, um Datenbeschädigungen zu vermeiden. Die virtuellen Computer werden automatisch wieder eingeschaltet, nachdem die Speicherkonnektivität wiederhergestellt wurde. Die Dauer des Herunterfahrens kann so kurz wie fünf Minuten sein, aber es kann auch deutlich länger sein.

Sonstige Vorfälle

In seltenen Fällen kann sich ein weit verbreitetes Problem auf mehrere Server in einem Azure Rechenzentrum auswirken. Wenn dieses Problem auftritt, sendet das Azure Team E-Mail-Benachrichtigungen an die betroffenen Abonnements. Sie können das dashboard Azure Service Health und das Azure Portal auf den Status von laufenden Ausfällen und früheren Vorfällen überprüfen.

Diagnostizieren von VM-Neustarts

Sie können das Blatt "Diagnose" und "Solve " auf dem Blatt "VM" verwenden, um zusätzliche Diagnosen auszuführen. Dadurch lassen sich möglicherweise genauere Gründe für den letzten Neustart der VM ermitteln. Wenn ein Gastbetriebssystemproblem aufgetreten ist, sammeln Sie ein Speicherabbild, und wenden Sie sich an den Support.