Über Hostereignisse

Sie können auswählen, wie die Instanzen Ihrer virtuellen Maschinen (VMs) während oder nach einem Hostereignis reagieren, indem Sie Folgendes festlegen: Hostwartungsrichtlinie während der VM-Erstellung. Ein Hostereignis kann die reguläre Wartung der Compute Engine-Infrastruktur oder einen Hostfehler auf einer VM umfassen. Standardmäßig sind VMs bei Hostsystemereignissen auf Live-Migration eingestellt. Sie können sie jedoch so einstellen, dass sie beendet und optional neu gestartet werden. Z3-VMs sind die Ausnahme von der Live-Migration, da sie standardmäßig neu gestartet werden.

Die folgenden Hostereignisse führen je nach den festgelegten Hostwartungsrichtlinien entweder zur Live-Migration oder zur Beendigung der VM:

Wartungsereignisse

Ein Wartungsereignis ist ein Zeitpunkt, zu dem Compute Engine eine VM beendet, um eine Hardware- oder Softwareaktualisierung durchzuführen. Wenn Sie die Hostwartungsrichtlinie für Live-Migration aktivieren, verschiebt Compute Engine die VM auf einen neuen Host und es kommt zu keiner Unterbrechung Ihrer Anwendung.

Das VM-Verhalten während eines Wartungsereignisses kann je nach Mandantenfähigkeit der VM variieren. Die folgende Tabelle zeigt einige Unterschiede zwischen dem Verhalten von Mehrmandanten- und VMs für einzelne Mandanten während Wartungsereignissen.

Host-Mandantenfähigkeit Ungefähre Häufigkeit* Live-Migration zum neuen Host Hostauswahl
Mandantenfähig Alle 2 Wochen Ja Compute Engine
Einzelner Mandant Alle 4 bis 6 Wochen Abhängig von der Hostwartungsrichtlinie Abhängig von der Hostwartungsrichtlinie
* Diese Angaben sind Näherungswerte. Compute Engine kann gelegentlich Wartungen häufiger ausführen.

Compute Engine wendet auch einfache Hypervisor- und Netzwerkupgrades im Hintergrund unterbrechungsfrei an.

Hostwartungsrichtlinie

Die Hostwartungsrichtlinie einer VM bestimmt, wie sie sich bei den folgenden Ereignissen verhält:

  • Bei einem Wartungsereignis, bei dem Google eine VM auf einen anderen Hostcomputer verschieben muss
  • Bei einem Hostfehler, bei dem Google eine VM beenden oder neu starten muss

Sie können VMs so konfigurieren, dass sie während der Hostwartung weiterhin ausgeführt werden, während sie von Compute Engine live zu einem anderen Host migriert werden, oder Sie können stattdessen Ihre VMs beenden. Die Hostwartungsrichtlinie einer VM kann jederzeit aktualisiert werden, um zu steuern, wie sich Ihre VMs verhalten sollen.

Für die Hostwartungsrichtlinie einer VM lassen sich die beiden folgenden Einstellungen ändern:

  • Wartungsverhalten: Gibt an, ob die VM live migriert oder beendet wird, wenn ein Wartungsereignis auftritt.
  • Neuverhalten: Gibt an, ob Compute Engine die VM neu startet oder beendet, wenn die VM abstürzt oder ein Hostfehler auftritt.
  • Erkennungszeit für Hostfehler: Die maximale Zeit, die Compute Engine auf den Neustart oder die Beendigung einer VM wartet, nachdem erkannt wurde, dass die VM nicht mehr reagiert.
  • Lokale SSD-Wiederherstellungszeit: Die maximale Zeit, die Compute Engine für die Wiederherstellung der Daten auf lokalen SSD-Laufwerken benötigt, nachdem ein Hostfehler erkannt wurde. Die lokalen SSD-Daten gehen verloren, wenn die angegebene Zeit ohne erfolgreiche Wiederherstellung verstrichen ist.

Wartungsplanung

Google Cloud bietet Features, die eine bessere Kontrolle über die Wartung ermöglichen. Durch die Verwendung bestimmter VM-Familien können Sie Wartungseinstellungen angeben, um mehrtägige Benachrichtigungen über Cloud Logging zu erhalten. Nach Erhalt einer Benachrichtigung können Sie die Wartung jederzeit bis zum geplanten Ereignis auslösen.

Sie können diese Features in Kombination mit Ihrer Hostwartungsrichtlinie verwenden, um einen Zeitplan anzupassen, der zu Ihrer Arbeitslast passt.

Live-Migration

Standardmäßig sind alle VMs außer Z3-VMs auf Live-Migration eingestellt, wobei Compute Engine Ihre VM automatisch von einem Wartungsereignis der Infrastruktur migriert, und Ihre VM wird während der Migration weiterhin ausgeführt. Auf der VM wird möglicherweise ein vorübergehender Leistungsabfall verzeichnet, aber im Allgemeinen sollten die meisten VMs keine nennenswerten Unterschiede aufweisen. Dies ist ideal für VMs, die eine konstante Betriebszeit erfordern und eine kurzfristig verminderte Leistung tolerieren.

Mit der Migration Ihrer VM von Compute Engine wird ein Systemereignis gemeldet und in der Liste der Zonenvorgänge angezeigt. Sie können dieses Ereignis durch Aufruf der Compute Engine-Vorgänge für eine bestimmte Zone prüfen. Für Live-Migrationsereignisse gilt folgender Vorgangstyp:

    compute.instances.migrateOnHostMaintenance

Beenden und (optional) neu starten

Wenn für Ihre VM keine Live-Migration ausgeführt werden soll, können Sie Ihre VM auch beenden und wahlweise neu starten. Wenn VMs so eingestellt werden, dass sie beendet und optional neu gestartet werden, sendet Compute Engine ein "Soft-Power-Off"-Signal zum Herunterfahren der VM. Anschließend wird 60 Sekunden gewartet, bis die VM ordnungsgemäß heruntergefahren ist, die VM wird beendet und in zeitlichem Abstand zum Wartungsereignis neu gestartet. Wenn die VM nicht innerhalb von 60 Sekunden ordnungsgemäß heruntergefahren wurde, wird sie beendet.

Diese Option ist ideal, wenn Ihre VMs eine konstante, maximale Leistung benötigen und die gesamte Anwendung auf die Bewältigung von VM-Fehlern oder Neustarts ausgelegt ist.

Wenn Ihre VMs in Compute Engine beendet und neu gestartet werden, wird ein Systemereignis gemeldet, das in der Liste der Zonenvorgänge angezeigt wird. Sie können dieses Ereignis durch Aufruf der Compute Engine-Vorgänge für eine bestimmte Zone prüfen. Für beendete Ereignisse gilt folgender Vorgangstyp:

compute.instances.terminateOnHostMaintenance

Beim Neustart der VM wird das gleiche nichtflüchtige Bootlaufwerk verwendet und alle konfigurierten sekundären, nichtflüchtigen Speicher werden wieder angehängt. Die Daten auf diesen Laufwerken bleiben über die Migration und den Neustart der VM hinweg erhalten.

Lokale SSD-Daten gehen verloren, wenn eine VM aufgrund eines Wartungsereignisses beendet wird. Beim Neustart der VM wird eine neue lokale SSD erstellt, die Sie formatieren und bereitstellen müssen.

Lokale SSD-Daten bleiben auf speicheroptimierten Z3-VMs (Vorschau) erhalten. Bei einem Wartungsereignis wird die Z3-VM direkt neu gestartet, anstatt zu einem neuen Host zu migrieren. Am Ende der routinemäßigen Wartung wird Ihre VM neu gestartet. Google Cloud unternimmt alles, um zu gewährleisten, dass Ihre lokalen SSD-Daten intakt bleiben. Es gibt jedoch Fälle, in denen Daten nicht wiederhergestellt werden können, z. B. eine Zeitüberschreitung.

Automatischer Neustart

Wenn Ihre VM so eingestellt ist, dass sie bei Wartungsarbeiten beendet wird, oder Ihre VM wegen eines zugrundeliegenden Hardwarefehlers abstürzt, können Sie Google Compute Engine so einstellen, dass die VM automatisch neu startet. Setzen Sie dazu das Feld automaticRestart auf true. Diese Einstellung gilt nicht, wenn die VM durch eine Nutzeraktion offline genommen wurde, zum Beispiel durch das Aufrufen von sudo shutdown, oder während eines Zonenausfalls.

Beim automatischen Neustart der VM in Compute Engine wird ein Systemereignis gemeldet, das in der Liste der Zonenvorgänge angezeigt wird. Sie können dieses Ereignis durch Aufrufen der Compute Engine-Vorgänge für eine bestimmte Zone überprüfen. Für automatische Neustartereignisse gilt folgender Vorgangstyp:

compute.instances.automaticRestart

Hostfehler

Ein Hostfehler (compute.instances.hostError) bedeutet, dass auf der physischen Maschine, die Ihre VM hostet, ein Problem mit der Hardware oder Software aufgetreten ist, das zum Absturz der VM führte. Ein Hostfehler, der einen völligen Hardwareausfall oder andere Hardwareprobleme nach sich zieht, kann eine Live-Migration Ihrer VM verhindern. Wenn Ihre VM so eingestellt ist, dass sie automatisch neu startet (dies ist die Standardeinstellung), startet Google Ihre VM in der Regel innerhalb von drei Minuten ab dem Fehler. Je nach Problem kann der Neustart bis zu 5,5 Minuten dauern.

VMs mit lokalen SSD-Laufwerken

Wenn ein Hostfehler auf einer VM auftritt, an die ein oder mehrere lokale SSDs angehängt sind, versucht Compute Engine, die Verbindung zur VM wiederherzustellen und die lokalen SSD-Daten beizubehalten. Während Compute Engine Ihre VM und das lokale SSD-Laufwerk wiederherstellt, reagieren das Hostsystem und das zugrunde liegende Laufwerk nicht.

Sie können festlegen, wie lange Compute Engine versuchen soll, lokale SSD-Daten wiederherzustellen, indem Sie das Zeitlimit für die lokale SSD-Wiederherstellung bestimmen.

Weitere Informationen zum Verhalten lokaler SSD-Laufwerke bei einem Hostfehler finden Sie unter Datenpersistenz auf lokalen SSDs.

Nicht reagierende VMs

Manchmal reagiert eine VM möglicherweise nicht mehr, bevor ein Hostfehler erkannt wird. Sie können die Zeit verkürzen, die Compute Engine auf den Neustart oder die Beendigung der VM wartet. Legen Sie dazu das Zeitlimit für die Fehlerbehebung des Hosts fest (Vorschau). Weitere Informationen finden Sie unter Verfügbarkeitsrichtlinien festlegen.

Physische Hardware- und Softwarefehler können von Zeit zu Zeit auftreten, sind jedoch eher selten. Um Ihre Anwendungen und Dienste solchen potenziell störenden Systemereignissen zu schützen, sollten Sie folgende Ressourcen prüfen:

Google bietet auch verwaltete Dienste wie App Engine und die flexible App Engine-Umgebung.

Zeitlimit für Wiederherstellung lokaler SSDs

Wenn ein Hostfehler auftritt, versucht Compute Engine, alle lokalen SSD-Laufwerke wiederherzustellen, die mit der VM verbunden sind. Mit dem Zeitlimit für die lokale SSD-Wiederherstellung können Sie steuern, wie viel Zeit Compute Engine mit dem Versuch verbringt, die Daten wiederherzustellen. Standardmäßig verbringt Compute Engine 1 Stunde für die Wiederherstellung der Daten. Gültige Werte liegen jedoch zwischen 0 und 168, in Schritten von 1 Stunde. Die einzige Ausnahme hiervon ist Z3, das eine Standardwiederherstellungszeit von bis zu 6 Stunden hat.

Wenn das Zeitlimit abläuft und die Daten immer noch nicht wiederhergestellt werden können, startet Compute Engine die VM ohne das lokale SSD-Laufwerk neu. Compute Engine hängt der neu gestarteten VM ein neues, leeres lokales SSD-Laufwerk an.

Wenn das Zeitlimit eine Stunde oder länger ist, befindet sich die VM im Zustand REPAIRING, während Compute Engine alle angehängten lokalen SSD-Laufwerke wiederherstellt. Die VM- und lokalen SSD-Laufwerke reagieren während der Wiederherstellung nicht.

Wenn das Zeitlimit 0 ist, versucht Compute Engine nicht, die lokalen SSD-Laufwerke wiederherzustellen und die Daten können nicht wiederhergestellt werden. Sie können für das Zeitlimit für die Wiederherstellung den Wert 0 festlegen, wenn die Fortsetzung der Arbeitslast wichtiger ist als die Wiederherstellung der lokalen SSD-Daten.

Wiederherstellung des lokalen SSD-Laufwerks beenden

Sie können den Wiederherstellungsprozess unterbrechen, bevor das Zeitlimit für die Wiederherstellung der lokalen SSD abläuft. Führen Sie dazu den Befehl gcloud compute instances stop mit dem Flag --discard-local-ssd=True aus.

Dadurch wird der Wiederherstellungsprozess beendet und die VM beendet und die lokalen SSD-Daten werden verworfen. Sie können die VM anschließend neu starten. Weitere Informationen finden Sie unter VM mit lokaler SSD beenden.

Informationen zum Festlegen des Zeitlimits für die Wiederherstellung der lokalen SSD finden Sie unter VM-Hostwartungsrichtlinie festlegen.

Nächste Schritte