Freigeben über

Informationen zum Systemneustart für virtuelle Azure-Computer

  • Artikel

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

Virtuelle Azure-Computer (VMs) werden unter Umständen manchmal ohne erkennbaren Grund neu gestartet, ohne dass ein Nachweis dafür vorliegt, 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 Schützen einer in Azure ausgeführten Anwendung vor Neustarts von virtuellen Computern und damit Ausfallzeiten besteht in der Konfiguration der virtuellen Computer für Hochverfügbarkeit.

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. Durch diese Konfiguration wird sichergestellt, dass während eines geplanten oder ungeplanten Wartungsereignisses mindestens ein virtueller Computer verfügbar ist und die von der Azure-SLA zugesicherte Verfügbarkeit von 99,95 Prozent eingehalten wird.

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

Informationen zu Resource Health

Azure Resource Health ist ein Dienst, der die Integrität von einzelnen Azure-Ressourcen offenlegt und wertvolle Hinweise zur Behandlung von Problemen bietet. In einer Cloudumgebung, in der es nicht möglich ist, direkt auf Server oder Infrastrukturelemente zuzugreifen, besteht das Ziel der Ressourcenintegrität darin, den Zeitaufwand für die Problembehandlung zu verringern. Das vorrangigste Ziel ist die Reduzierung der Zeit, die Sie mit der Bestimmung verbringen, ob die Hauptursache des Problems die Anwendung oder ein Ereignis auf der Azure-Plattform ist. Weitere Informationen finden Sie unter Grundlegendes zu Resource Health.

Wenn Azure über weitere Informationen zur Grundursache einer von der Plattform ausgelösten Nichtverfügbarkeit einer virtuellen Maschine verfügt, können diese Informationen bis zu 72 Stunden nach der anfänglichen Nichtverfügbarkeit in Resource Health veröffentlicht werden.

Fehlende VM-Ausfallzeiten im Aktivitätsprotokoll

Warnmeldungen zur Ressourcenintegrität werden auf der Grundlage 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 für die Ausfallzeit keine Warnmeldungen zur Ressourcenintegrität gesendet. Die Ausfallzeit ist weiterhin in „Ressourcenintegrität“ sichtbar.

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

  • Wenn eine VM erstellt oder auf einen neuen Host migriert wird, zeigt die Azure-Plattform den VM-Status nicht ordnungsgemäß an, und der Status ä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 VM-Status von einem Status in „Unbekannt“ ändert und dann zum ursprünglichen Status zurückkehrt, wird der dazwischen liegende Status „Unbekannt“ (einschließlich dazugehöriger Übergänge) aus dem Aktivitätsprotokoll herausgefiltert.

Die VM-Ausfallzeiten, die nicht im Aktivitätsprotokoll angezeigt werden, werden auf der Azure-Plattform gefiltert, um zu verhindern, dass vorübergehende Fehler Kunden falsche Ausfallzeiten anzeigen. Mit fortlaufenden Investitionen in die Qualität der VM-Integrität sind die Filter möglicherweise nicht mehr erforderlich und können dazu führen, dass schnelle Änderungen des VM-Zustands nicht gemeldet werden. Microsoft arbeitet an einem Auslaufplan, um die beste Kundenerfahrung zu bieten.

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

Geplante Wartung

Microsoft Azure führt regelmäßig weltweit Updates aus, um die Zuverlässigkeit, Leistung und Sicherheit der Hostinfrastruktur zu verbessern, die virtuellen Computern 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.

Grundlagen zur geplanten Wartung in Azure – was sie ist und wie sie sich auf die Verfügbarkeit Ihrer virtuellen Linux-Computer auswirken kann – finden Sie in den hier aufgeführten Artikeln. Die Artikel bieten Hintergrundinformationen zu den Prozessen bei der geplanten Wartung in Azure und zum Erstellen eines Zeitplans für die geplante Wartung, um die Auswirkungen weiter zu verringern.

Speichererhaltende Updates

Für diese Klasse von Updates in Microsoft Azure kommt es für Benutzer nicht zu Auswirkungen auf ihre ausgeführten VMs. 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 Techniken durchgeführt, die eine direkte Livemigration ermöglichen. 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.

Notiz

Linux-Computer mit alten Kernelversionen werden während dieser Updatemethode durch eine Kernel Panic beeinträchtigt. Um dieses Problem zu vermeiden, aktualisieren Sie den Kernel auf die Version 3.10.0 - 327.10.1 oder höher. Weitere Informationen finden Sie unter An Azure Linux VM on a 3.10-based kernel panics after a host node upgrade (Kernel Panic auf einer Azure-VM unter Linux mit Kernelversion 3.10 nach einem Upgrade des Hostknotens).

Vom Benutzer eingeleitete Aktionen zum Neustarten oder Herunterfahren

Wenn Sie einen Neustart über das Azure-Portal, Azure PowerShell, die Befehlszeilenschnittstelle oder die REST-API durchführen, finden Sie das zugehörige 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 für Cloud und Windows Update

Microsoft Defender for Cloud überwacht täglich Windows- und Linux-VMs auf fehlende Betriebssystem-Updates. Defender for Cloud ruft eine Liste der verfügbaren Sicherheits- und kritischen Updates von Windows Update oder Windows Server Update Services (WSUS) ab, je nachdem, welcher Dienst auf einer Windows-VM konfiguriert ist. Darüber hinaus prüft Defender for Cloud auch die neuesten Updates für Linux-Systeme. Falls auf Ihrem virtuellen Computer ein Systemupdate fehlt, empfiehlt Defender for Cloud die Anwendung von Systemupdates. Die Anwendung dieser Systemupdates wird über den 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 Anwenden von Systemupdates in Defender for Cloud.

Wie bei lokalen Servern überträgt Azure Updates von Windows Update nicht per Push auf virtuelle Windows-Computer, da diese Computer durch ihre Benutzer verwaltet werden sollen. Es empfiehlt sich jedoch, die Einstellung für automatische Windows-Updates aktiviert zu lassen. Die automatische Installation von Updates über Windows Update kann auch dazu führen, dass Neustarts durchgeführt werden, 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 kann. 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 wird als Agent ausgeführt, der als Host-Agent bezeichnet und zusätzlich zu einigen anderen Azure-Komponenten ausgeführt wird. Wenn diese Azure-Softwarekomponenten auf dem physischen Server nicht mehr reagieren, löst das Überwachungssystem einen Neustart des Hostservers aus, um eine 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 fortlaufend diese Vorkommen, identifiziert die zugrunde liegenden Fehler und führt Updates durch, nachdem die Fehlerbehebung 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 Erneut bereitstellen auf der Detailseite des virtuellen Computers oder durch Anhalten und Neustarten des virtuellen Computers im Azure-Portal ausgelöst werden.

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 zunächst die am wenigsten störende Wiederherstellungsmethode, bei der der Host neu gestartet werden soll. Wenn ein Neustart des Hosts nicht möglich ist oder das ursprüngliche Problem hardwarebezogen ist, werden alle virtuellen Computer auf dem betroffenen Host vom Plattformdienst auf einem fehlerfreien Knoten geheilt. Während das Neustarten eines Hosts im Allgemeinen geringere Auswirkungen hat, können VMs für die Dienstheilung komplexer und zeitaufwändiger sein, je nach Anzahl der virtuellen Computer, deren Bereitstellungseinschränkungen und der lokalen Ressourcenverfügbarkeit. Die Dienstheilung wird in der Regel als letzte Möglichkeit für Hardwarefehler verwendet, da sichergestellt wird, dass VMs weiterhin ohne erhebliche Ausfallzeiten funktionieren.

Wenn ein Hostserver nicht neu gestartet werden kann, initiiert Azure eine automatische Wiederherstellungsaktion, um den fehlerhaften Host aus der Drehung für weitere Untersuchungen zu ergreifen. Während dieses automatischen Wiederherstellungsvorgangs werden alle virtuellen Computer auf dem Host automatisch auf einen anderen fehlerfreien Hostserver verschoben. Während dieser Vorgang in der Regel innerhalb von 15 Minuten abgeschlossen wird, kann die Wiederherstellungszeit je nach Faktoren wie der Arbeitsspeichergröße des Hosts und den verwendeten Wiederherstellungsmethoden variieren. Weitere Informationen dazu, wie Azure diese Szenarien behandelt, finden Sie unter Service Healing – Automatische Wiederherstellung virtueller Computer.

Ungeplante Wartung

In seltenen Fällen muss das Azure-Betriebsteam Wartungsaktivitäten durchführen, um die allgemeine Integrität 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 werden unter Umständen neu gestartet, falls Probleme in den virtuellen Computern selbst vorliegen. Die Workload oder Rolle, die auf dem virtuellen Computer ausgeführt wird, kann ggf. eine Fehlerüberprüfung innerhalb des Gastbetriebssystems auslösen. Hilfe beim Ermitteln der Ursache für den Absturz finden Sie bei virtuellen Windows-Computern in den System- und Anwendungsprotokollen und bei virtuellen Linux-Computern in den seriellen Protokollen.

Virtuelle Computer in Azure basieren auf virtuellen Datenträgern für das Betriebssystem und die Speicherung von Daten, die in der Azure Storage-Infrastruktur gehostet werden. Wenn Probleme mit der Verfügbarkeit oder Konnektivität zwischen dem virtuellen Computer und den zugehörigen virtuellen Datenträgern auftreten, die länger als 120 Sekunden anhalten, erzwingt die Azure-Plattform das Herunterfahren des virtuellen Computers, um Datenbeschädigungen zu vermeiden. Die virtuellen Computer werden automatisch wieder eingeschaltet, nachdem die Speicherkonnektivität wiederhergestellt wurde. Das Herunterfahren kann lediglich fünf Minuten dauern, aber auch deutlich länger.

Sonstige Vorfälle

In seltenen Fällen kann sich ein großflächig auftretendes Problem auf mehrere Server in einem Azure-Datencenter auswirken. In diesem Fall sendet das Azure-Team E-Mail-Benachrichtigungen an die betroffenen Abonnements. Im Dashboard zur Azure-Dienstintegrität und im Azure-Portal finden Sie Informationen zum Status aktueller Ausfälle und von Vorfällen in der Vergangenheit.

VM-Neustarts diagnostizieren

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

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.