Über Hostereignisse

Während der Lebensdauer einer VM-Instanz oder Bare-Metal-Instanz kann es auf dem Hostcomputer, auf dem Ihre Instanz ausgeführt wird, zu mehreren Hostereignissen kommen. Ein Hostereignis kann die reguläre 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.

Die meisten Instanzen sind standardmäßig für die Live-Migration bei Hostereignissen konfiguriert. Sie können dieses Verhalten überschreiben und explizit festlegen, dass die Instanzen beendet und optional neu gestartet werden sollen. Einige Maschinentypen unterstützen keine Live-Migration, z. B. Z3-Instanzen mit mehr als 18 TiB angehängter Titanium-SSD, Bare-Metal-Instanzen oder Instanzen mit angehängten GPUs. Diese Instanzen werden während Hostereignissen beendet. Weitere Informationen finden Sie unter Wartungs- und Neustartverhalten.

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 das Beenden der Instanz auslösen.

Wartungsereignisse

Ein Wartungsereignis tritt ein, wenn Compute Engine eine Wartungs- oder Reparaturmaßnahme durchführen muss, für die 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.

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

Das Instanzverhalten während eines Wartungsereignisses kann je nach Mandantenfähigkeit der Instanz und Maschinentyp variieren. Informationen zum Wartungsverhalten für jeden Maschinentyp finden Sie auf der jeweiligen Maschinenfamilienseite:

Informationen zu den Wartungsrichtlinien für bestimmte Maschinenserien finden Sie im Vergleich der Maschinenserien.

Bei VMs für einzelne Mandanten finden geplante Hostwartungsereignisse etwa alle vier bis sechs Wochen statt. Ob die Live-Migration unterstützt wird, hängt von der Hostwartungsrichtlinie für die VM für einzelne Mandanten ab.

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 führte. 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 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.

Manchmal reagiert eine Compute-Instanz möglicherweise nicht mehr, bevor ein Hostfehler signalisiert 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. 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.

Übersicht über die Hostwartungsrichtlinie

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 Instanz beenden.

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

  • Wartungsverhalten:Gibt an, ob die Instanz live migriert oder beendet wird, wenn ein Wartungsereignis auftritt.
  • Neuverhalten:Gibt an, ob Compute Engine die Instanz neu startet oder beendet, wenn die Instanz abstürzt, ein Hostfehler auftritt oder die Instanz 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.

Wartungs- und Neustartverhalten

Wenn ein Hostereignis auftritt, kann die Compute-Instanz entweder die Live-Migration verwenden oder die Instanz kann beendet werden. Wenn eine Instanz beendet wird, können Sie sie selbst neu starten oder Compute Engine sie automatisch neu starten lassen.

Die folgenden Maschinenreihen unterstützen möglicherweise keine Live-Migration und erfordern stattdessen die Beendigung während Hostereignissen:

Live-Migration

Für die meisten Instanztypen ist standardmäßig Live-Migration festgelegt, mit Ausnahme der im vorherigen Abschnitt genannten Instanztypen.

Bei der Live-Migration migriert Compute Engine Ihre Instanz automatisch von einem Wartungsereignis der Infrastruktur weg. Die Instanz wird während der Migration weiter ausgeführt. 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 Systemereignislogs 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 keine Live-Migration unterstützt, können Sie stattdessen zulassen, dassGoogle Cloud die Instanz bei einem Hostereignis beendet. Bei dieser Konfiguration sendet Compute Engine bei einem Host-Ereignis ein Soft-Power-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 Compute Engine eine Instanz aufgrund eines Hostereignisses beendet, wird ein Systemereignis gemeldet, das in der Liste der Zonenvorgänge und in den Systemereignislogs angezeigt wird. Sie können dieses Ereignis durch Aufrufen der Compute Engine-Vorgänge für eine bestimmte Zone überprüfen. Für Ereignisse zur Beendigung von Instanzen gilt folgender Vorgangstyp:

compute.instances.terminateOnHostMaintenance

Automatischer Neustart

Wenn Ihre Instanz so konfiguriert ist, dass sie bei einem Wartungsereignis beendet wird, oder wenn Ihre Instanz aufgrund eines zugrunde liegenden Hardwareproblems 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 dem Beenden der Instanz auf demselben Hostserver neu gestartet.

Wenn Sie den automatischen Neustart konfigurieren möchten, legen Sie das Feld für die Hostwartungsrichtlinie automaticRestart auf true fest. Diese Einstellung gilt nicht, wenn die Instanz aufgrund eines Zonenausfalls oder durch einen manuellen Vorgang offline genommen wird, 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

Laufwerkpersistenz nach Beendigung der Instanz

Da Persistent Disk undHyperdisk netzwerkgebundener Speicher 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 SSD-Laufwerken nach einem Hostereignis nach Möglichkeit bei. Compute Engine garantiert jedoch nicht die Datenpersistenz auf lokalen SSDs.

  • Lokale SSD-Laufwerke bleiben in den folgenden Szenarien erhalten:

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

  • Lokale SSD-Laufwerke bleiben in den folgenden Szenarien nicht erhalten:

    • Sie fahren das Gastbetriebssystem herunter und erzwingen so das Anhalten der Instanz.
    • Sie konfigurieren die Instanz so, dass sie bei einer Hostwartung beendet wird, und eine solche Hostwartung findet statt.
    • Es tritt ein Hostfehler auf und Compute Engine kann die Verbindung der Laufwerke zur Instanz nicht wiederherstellen, bevor das Zeitlimit abläuft. In diesem Fall wird die Instanz neu gestartet, ohne die lokalen SSDs wiederherzustellen. Wenn die Instanz neu gestartet wird, hängt Compute Engine leere lokale SSD-Laufwerke an die neu gestartete Instanz an. Sie müssen diese Laufwerke formatieren und bereitstellen, bevor die Instanz sie verwenden kann. Die Daten auf den ursprünglichen lokalen SSD-Laufwerken 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 beibehalten werden, finden Sie unter Datenpersistenz auf lokalen SSDs.

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 Hostrichtlinieneinstellung 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. Für Z3-Instanzen ist der Standardwert 6. Das bedeutet, dass Z3-Instanzen sechs Stunden lang versuchen, die Daten der lokalen SSD wiederherzustellen, bevor das Zeitlimit erreicht wird.

Wenn Sie das Zeitlimit für die Wiederherstellung lokaler SSDs 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 der lokalen SSD sind nicht wiederherstellbar. 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 gesetzt ist, das Zeitlimit jedoch erreicht wird, bevor die Daten auf der 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 die Instanz sie verwenden kann.

Die Instanz befindet sich im Zustand REPAIRING, während Compute Engine versucht, die lokalen SSD-Laufwerke wiederherzustellen. Die Instanz und die lokalen SSDs sind in diesem Zeitraum nicht verfügbar.

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

Wiederherstellung lokaler SSD-Laufwerke beenden

Sie können den Wiederherstellungsprozess für lokale SSD-Laufwerke 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.

Durch diesen Befehl wird der Wiederherstellungsprozess beendet, die Compute-Instanz beendet und die lokalen SSD-Daten werden verworfen. Anschließend können Sie die Instanz neu starten. Weitere Informationen finden Sie unter Instanz mit lokaler SSD anhalten.

Diese Option ist für Z3-Instanzen nicht verfügbar.

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

Wartungsplanung

Google Cloud bietet Funktionen, die eine bessere Kontrolle über die Wartung ermöglichen. Wenn Sie bestimmte Maschinentypen verwenden, können Sie Wartungseinstellungen angeben und Benachrichtigungen über anstehende Wartungsereignisse ü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 Zeitpunkt Ihrer Wahl starten können. Wenn Sie die geplante Wartung nicht auslösen, erfolgt das Wartungsereignis am Ende des Benachrichtigungszeitraums, 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