Über Hostereignisse

Während der Lebensdauer einer VM-Instanz oder Bare-Metal-Instanz kann es auf dem Hostcomputer, auf dem die Instanz ausgeführt wird, zu mehreren Hostereignissen kommen. Ein Hostereignis kann die regelmäßige Wartung der Compute Engine-Infrastruktur oder in seltenen Fällen einen Hostfehler umfassen. Sie können auswählen, wie Ihre VM- und Bare-Metal-Instanzen während oder nach einem Hostereignis reagieren, indem Sie die Hostwartungsrichtlinie konfigurieren.

Standardmäßig ist für die meisten Instanzen bei Hostereignissen die Live-Migration festgelegt. Sie können dieses Verhalten überschreiben und die Instanzen explizit so einstellen, dass sie beendet und optional neu gestartet werden. Einige Maschinentypen unterstützen keine Livemigration, z. B. Bare-Metal-Instanzen oder VMs mit angeschlossenen GPUs. Diese Instanzen werden während Hostereignissen beendet. Weitere Informationen finden Sie unter Wartung und Neustart.

Arten von Hostereignissen

Es gibt zwei Arten von Host-Ereignissen, die in den folgenden Abschnitten näher beschrieben werden:

Wenn Ihre Instanz nicht mehr reagiert, kann dies auch einen Neustart oder eine Beendigung der Instanz auslösen.

Wartungsereignisse

Ein Wartungsereignis liegt vor, wenn die Compute Engine eine Wartungs- oder Reparaturaktivität ausführen muss, bei der VMs vom Hostserver verschoben werden müssen. Wenn Sie die Hostwartungsrichtlinie für Live-Migration für einen unterstützten Instanztyp aktivieren, verschiebt Compute Engine die Instanz auf einen neuen Host und es kommt zu minimalen Unterbrechungen Ihrer Anwendung.

Das Instanzverhalten während eines Wartungsereignisses kann je nach Mandantenfähigkeit der Instanz und dem Maschinentyp variieren. In der folgenden Tabelle ist das Verhalten bei geplanten Wartungsereignissen zusammengefasst.

Host-Mandantenfähigkeit Ungefähre Häufigkeit von Wartungsereignissen
 Live-Migration wird unterstützt Hostauswahl
Mehrmandantenfähig (freigegeben) Alle 2 Wochen Ja Compute Engine
Einzelner Mandant Alle 4 bis 6 Wochen Abhängig von der Hostwartungsrichtlinie Abhängig von der Hostwartungsrichtlinie
X4 Mindestens 90 Tage Nein Compute Engine
C3 Mindestens 30 Tage Nein Compute Engine

Die Compute Engine wendet auch einige einfache Hypervisor- und Netzwerkupgrades im Hintergrund unterbrechungsfrei an, indem die Instanz auf demselben Host beibehalten wird.

Hostfehler

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

Gelegentlich reagiert eine Compute-Instanz möglicherweise nicht mehr, bevor ein Hostfehler gemeldet wird. Sie können die Zeit verkürzen, die Compute Engine auf den Neustart oder die Beendigung der Instanz wartet. Legen Sie dazu das Zeitlimit für die Fehlerbehebung des Hosts fest (Vorabversion). 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.

Hostwartungsrichtlinie – Übersicht

Die Hostwartungsrichtlinie einer Instanz bestimmt, wie sie sich bei den folgenden Hostereignissen verhält:

  • Wartungsereignis
  • Hostfehlerereignis oder Instanz reagiert nicht

Sie können Instanzen 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 Instanzen beenden.

Sie können die Hostwartungsrichtlinie einer Instanz ändern, indem Sie die folgenden Einstellungen konfigurieren:

  • Wartungsverhalten: Gibt an, ob die Instanz live migriert oder beendet wird, wenn ein Wartungsereignis auftritt.
  • Neustartverhalten: Gibt an, ob Compute Engine die Instanz neu startet oder beendet, wenn die Instanz abstürzt, ein Hostfehler auftritt oder sie nicht mehr reagiert.
  • Erkennungszeit für Hostfehler: Die maximale Zeit, die Compute Engine auf den Neustart oder die Beendigung einer Instanz wartet, nachdem erkannt wurde, dass die Instanz 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.

Die Hostwartungsrichtlinie einer Instanz kann jederzeit aktualisiert werden, um zu steuern, wie sich Ihre Instanzen verhalten sollen.

Wartung und Neustart

Wenn ein Hostereignis auftritt, kann für die Compute-Instanz entweder die Live-Migration verwendet oder die Instanz beendet werden. Wenn eine Instanz beendet wird, können Sie sie selbst neu starten oder die automatische Neustartfunktion der Compute Engine verwenden.

Die folgenden Maschinenserien unterstützen keine Live-Migration und werden bei Hostereignissen stattdessen beendet:

Live-Migration

Standardmäßig ist für die meisten Instanztypen die Live-Migration festgelegt, mit folgenden Ausnahmen:

  • Instanzen mit angehängten GPUs und TPUs
  • C3-Bare-Metal- oder X4-Instanzen
  • Z3-Instanzen

Bei einer Live-Migration migriert Compute Engine Ihre Instanz automatisch von einem Wartungsereignis der Infrastruktur fort. Die Instanz kann so während der Migration weiterhin ausgeführt werden. Auf der Instanz wird möglicherweise ein vorübergehender Leistungsabfall verzeichnet, aber im Allgemeinen sollten die meisten Instanzen keine nennenswerten Unterschiede aufweisen. Dies ist ideal für Instanzen, die eine konstante Betriebszeit erfordern und eine kurzfristig verminderte Leistung tolerieren.

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

compute.instances.migrateOnHostMaintenance

Beenden und neu starten

Wenn für Ihre Instanz keine Live-Migration ausgeführt werden soll oder Ihr Instanztyp die Live-Migration nicht unterstützt, können Sie stattdessen zulassen, dass Google Cloud die Instanz bei einem Hostereignis beendet. Bei dieser Konfiguration sendet Compute Engine bei einem Hostereignis ein Soft-Off-Signal, um die Instanz herunterzufahren. Anschließend wird 60 Sekunden gewartet, bis die Instanz ordnungsgemäß heruntergefahren ist, und der Instanzstatus wird auf TERMINATED gesetzt. Wenn die Instanz nicht innerhalb von 60 Sekunden ordnungsgemäß heruntergefahren wird, wird sie zwangsweise beendet.

Diese Option ist ideal, wenn Ihre Instanzen eine konstante, maximale Leistung benötigen und die gesamte Anwendung auf die Bewältigung von Instanzausfällen oder Neustarts ausgelegt ist.

Wenn die Compute Engine eine Instanz aufgrund eines Hostereignisses beendet, wird ein Systemereignis gemeldet, das in der Liste der Zonenvorgänge und in den Systemereignisprotokollen veröffentlicht wird. Sie können dieses Ereignis durch Aufrufen der Compute Engine-Vorgänge für eine bestimmte Zone überprüfen. Für Instanzterminierungsereignisse gilt folgender Vorgangstyp:

compute.instances.terminateOnHostMaintenance

Automatischer Neustart

Wenn Ihre Instanz so konfiguriert ist, dass sie bei Wartungsarbeiten beendet wird, oder Ihre Instanz aufgrund eines zugrunde liegenden Hardwarefehlers abstürzt, kann Compute Engine die Instanz automatisch neu starten. Die Instanz wird entweder auf demselben Hostserver neu gestartet oder auf einen anderen Server in derselben Zone verschoben, der nicht am Wartungsereignis teilnimmt.

Standardmäßig versucht Compute Engine, Instanzen mit angehängten lokalen SSD-Laufwerken eine Stunde lang wiederherzustellen. Wenn das Zeitlimit erreicht ist, versucht Compute Engine, die Instanz auf einem anderen Hostserver in derselben Zone neu zu starten. Z3- und X4-Instanzen haben unterschiedliche Standardwartezeiten. Diese Instanztypen werden nach der Instanzbeendigung auf demselben Hostserver neu gestartet.

Wenn Sie den automatischen Neustart konfigurieren möchten, setzen Sie das Feld für die Hostwartungsrichtlinie automaticRestart auf true. Diese Einstellung gilt nicht, wenn die Instanz aufgrund eines Zonenausfalls oder durch eine Nutzeraktion offline genommen wurde, z. B. durch den Aufruf von sudo shutdown im Gastbetriebssystem.

Beim automatischen Neustart der Instanz von Compute Engine 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 automatische Neustartereignisse gilt folgender Vorgangstyp:

compute.instances.automaticRestart

Laufwerkspeicher nach Instanzbeendigung

Da Persistent Disks undHyperdisks mit dem Netzwerk verbunden sind, hängt Compute Engine beim Neustart der Instanz das Bootlaufwerk und alle sekundären Laufwerke wieder an die Instanz an. Die Daten auf diesen Laufwerken bleiben über die Live-Migration und den Neustart der Instanz hinweg erhalten.

Compute Engine behält die Daten auf lokalen SSDs nach einem Hostereignis nach Möglichkeit bei. Die Compute Engine garantiert jedoch nicht die Datenpersistenz auf lokalen SSDs.

  • Lokale SSDs werden in folgenden Fällen beibehalten:

    • Sie konfigurieren Ihre Instanz für die Live-Migration und eine Hostwartung wird durchgeführt.
    • Ein Hostfehler tritt auf und Compute Engine stellt die Verbindung der Instanz innerhalb des Zeitlimits wieder mit den lokalen SSD-Laufwerken her.
    • Für eine Compute-Instanz mit angehängten lokalen SSD-Laufwerken, die nur die Beendigung und den automatischen Neustart unterstützt, wird ein Wartungsereignis ausgeführt. Die Instanz wird an Ort und Stelle neu gestartet, wobei die Daten auf der lokalen SSD erhalten bleiben, anstatt zu einem neuen Host migriert zu werden.

  • Lokale SSDs werden in folgenden Fällen nicht beibehalten:

    • Sie fahren das Gastbetriebssystem herunter und erzwingen das Anhalten der Instanz.
    • Sie konfigurieren die Instanz so, dass sie bei einer Hostwartung beendet wird, und eine solche Hostwartung findet statt.
    • Ein Hostfehler tritt auf und Compute Engine kann die Laufwerke nicht vor Ablauf des Zeitlimits wieder mit der Instanz verbinden. In diesem Fall wird die Instanz neu gestartet, ohne dass die lokalen SSDs wiederhergestellt werden. Beim Neustart der Instanz hängt Compute Engine leere lokale SSDs an die neu gestartete Instanz an. Sie müssen diese Laufwerke formatieren und bereitstellen, damit sie von der Instanz verwendet werden können. Die Daten auf den ursprünglichen lokalen SSDs können nicht wiederhergestellt werden.

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. Weitere Informationen dazu, wann lokale SSD-Laufwerke erhalten bleiben, finden Sie unter Persistenz lokaler SSD-Daten.

Zeitlimit für Wiederherstellung lokaler SSDs

Wenn ein Hostfehler auftritt, versucht Compute Engine, alle lokalen SSDs wiederherzustellen, die an die Instanz angehängt sind. Mit der Einstellung für die Hostrichtlinie localSsdRecoveryTimeout 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 für diese Einstellung liegen jedoch zwischen 0 und 168, in Schritten von 1 Stunde. Bei Z3-Instanzen ist der Standardwert 6. Das bedeutet, dass Z3-Instanzen 6 Stunden lang versuchen, die lokalen SSD-Daten wiederherzustellen, bevor das Zeitlimit erreicht wird.

Wenn Sie das Zeitlimit für die Wiederherstellung des lokalen SSD auf „0“ festlegen, versucht Compute Engine nicht, angehängte lokale SSD-Laufwerke wiederherzustellen. Die Instanz wird so schnell wie möglich neu gestartet und die Daten auf dem lokalen SSD können nicht wiederhergestellt werden. Verwenden Sie diese Konfiguration, wenn die Fortsetzung der Arbeitslast wichtiger ist als die Wiederherstellung der lokalen SSD-Daten.

Wenn das Zeitlimit für die Wiederherstellung nicht auf „0“ festgelegt ist, aber das Zeitlimit erreicht wird, bevor die Daten auf dem lokalen SSD wiederhergestellt werden, startet Compute Engine die Instanz ohne das lokale SSD-Laufwerk neu. Compute Engine hängt der neu gestarteten Instanz neue, leere lokale SSD-Laufwerke an. Sie müssen diese Laufwerke formatieren und bereitstellen, bevor sie von der Instanz verwendet werden können.

Die Instanz befindet sich im Status REPAIRING, während Compute Engine versucht, die lokalen SSD-Laufwerke wiederherzustellen. Die Instanz und die lokalen SSDs sind während dieser Zeit nicht verfügbar.

Wenn Sie das Zeitlimit für die lokale SSD-Wiederherstellung auf den maximalen Wert von 168 festlegen, bleibt die Instanz bis zu sieben Tage lang im Status REPAIRING, während Compute Engine versucht, die lokalen SSD-Laufwerke wiederherzustellen.

Wiederherstellung lokaler SSDs beenden

Sie können den Wiederherstellungsprozess des lokalen SSD-Laufwerks unterbrechen, bevor Compute Engine das Zeitlimit für die Wiederherstellung erreicht. Verwenden Sie dazu den Befehl gcloud compute instances stop mit dem Flag --discard-local-ssd=True.

Dadurch wird der Wiederherstellungsprozess beendet und die Compute-Instanz beendet und die lokalen SSD-Daten werden verworfen. Sie können die Instanz dann neu starten. Weitere Informationen finden Sie unter Instanz mit lokalem SSD anhalten.

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

Wartungsplanung

Google Cloud bietet Features, die eine bessere Kontrolle über die Wartung ermöglichen. Wenn Sie bestimmte Maschinenfamilien verwenden, können Sie Wartungseinstellungen angeben und Benachrichtigungen zu anstehenden Wartungsereignissen über Cloud Logging, den Metadatenserver der Instanz, den gcloud CLI-Befehl compute instances describe oder die REST-Methode instances.describe erhalten. Nach Erhalt einer Benachrichtigung haben Sie einen bestimmten Zeitraum, in dem Sie die geplante Wartung zu einem beliebigen Zeitpunkt starten können. Wenn Sie die geplante Wartung nicht auslösen, tritt das Wartungsereignis am Ende des Benachrichtigungszeitraums auf, also zur in der Benachrichtigung angegebenen geplanten Zeit.

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

Nächste Schritte