Über Hostereignisse

Während der Lebensdauer einer VM-Instanz oder einer Bare-Metal-Instanz können auf dem Hostcomputer, auf dem die Instanz ausgeführt wird, mehrere Hostereignisse auftreten. 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.

Standardmäßig ist für die meisten Instanzen die Live-Migration während Hostereignissen festgelegt. Für alle Maschinenserien außer Z3 können Sie dieses Verhalten überschreiben und die Instanzen explizit so einstellen, dass sie beendet und optional neu gestartet werden. Einige Maschinentypen unterstützen die Live-Migration nicht, z. B. H4D-Instanzen, Bare-Metal-Instanzen, Instanzen mit angehängten GPUs oder Z3-Instanzen mit mehr als 18 TiB angehängter Titanium-SSD. Diese Instanzen werden beendet während Hostereignissen. Weitere Informationen finden Sie unter Wartungs- und Neustartverhalten.

Arten von Hostereignissen

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

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

Wartungsereignisse

Ein Wartungsereignis ist ein Zeitpunkt, zu dem Compute Engine eine Wartungs- oder Reparaturaktivität durchführen muss, für die VMs vom Hostserver entfernt werden müssen. Wenn Sie die Live-Migration Hostwartungsrichtlinie 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 beibehalten wird.

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

Informationen zu den Wartungsrichtlinien für Instanzen mit angehängten GPUs finden Sie unter GPU-Hostwartungsereignisse verarbeiten.

Bei VMs für einzelne Mandanten liegt die ungefähre Häufigkeit geplanter Hostwartungsereignisse bei alle 4 bis 6 Wochen. 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 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 Compute Engine Ihre Instanz in der Regel innerhalb von drei Minuten ab dem Fehler war erkannt. Je nach Problem kann der Neustart bis zu 5, 5 Minuten dauern.

Manchmal 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. 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.

Überblick ü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: Hostwartungsrichtlinie

  • 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 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 Maschinenserien unterstützen möglicherweise keine Live-Migration und müssen stattdessen während Hostereignissen beendet werden:

  • Z3- (einschließlich Z3-Metal), X4- und H4D-Instanzen werden beendet und direkt neu gestartet.
  • Bare-Metal Instanzen werden beendet und neu gestartet. Das bedeutet, dass sie möglicherweise auf einem anderen Host neu gestartet werden. Weitere Informationen finden Sie in der Dokumentation zur Wartung für die jeweilige Maschinenserie. Informationen zu C3-Bare-Metal-Maschinentypen finden Sie beispielsweise unter Wartung für C3-Instanzen.
  • Vertrauliche VM-Instanzen mit Ausnahme von N2D-Maschinentypen mit AMD EPYC Milan-CPU-Plattformen , auf denen AMD SEV ausgeführt wird.
  • Instanzen mit GPUs
  • Instanzen mit TPUs

Live-Migration

Standardmäßig ist für die meisten Instanztypen die Live-Migrationfestgelegt, mit Ausnahme der im vorherigen Abschnitt genannten Instanztypen.

Während der Live-Migration migriert Compute Engine Ihre Instanz automatisch an eine andere Stelle und sorgt dafür, dass die Instanz, wenn möglich, während der Migration weiter ausgeführt wird. 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 Aufruf 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,Google Cloud dass die Instanz bei einem Hostereignis beendet wird. Bei dieser Konfiguration sendet Compute Engine bei einem Hostereignis 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 Systemereignisprotokollen angezeigt wird. Sie können dieses Ereignis durch Aufruf der Compute Engine-Vorgänge für eine bestimmte Zone überprüfen. Für Instanzbeendigungsereignisse 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. Für Z3-, X4- und H4D-Instanzen gelten andere Standardwartezeiten. Diese Instanztypen werden nach der Beendigung der Instanz auf demselben Hostserver neu gestartet.

Wenn Sie den automatischen Neustart konfigurieren möchten, setzen Sie das Feld automaticRestart der Hostwartungsrichtlinie auf true. Diese Einstellung gilt nicht, wenn die Instanz aufgrund eines Zonenausfalls oder durch manuelle Vorgänge 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 überprüfen. Für automatische Neustartereignisse gilt folgender Vorgangstyp:

compute.instances.automaticRestart

Laufwerkpersistenz nach der Beendigung der Instanz

Da Persistent Disk und Hyperdisk 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 die Neustarts 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 keine Datenpersistenz auf lokalen SSDs.

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

    • Sie starten das Gastbetriebssystem neu.
    • Sie konfigurieren für Ihre Instanz die Live-Migration und eine Hostwartung wird durchgeführt.
    • Ein Hostfehler tritt auf und Compute Engine stellt die Verbindung der Instanz zu den lokalen SSD-Laufwerken innerhalb des Zeitlimits wieder her.
    • Sie entscheiden sich dafür, die lokalen SSD-Daten beizubehalten, wenn Sie die Instanz beenden oder anhalten (Vorschau).
    • Eine Compute-Instanz mit angehängten lokalen SSD-Laufwerken, die nur die Beendigung und den automatischen Neustart unterstützt, wird gewartet. Die Instanz wird direkt neu gestartet, wobei die lokalen SSD-Daten beibehalten werden, 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 erstellen eine Spot-VM oder VM auf Abruf und die VM durchläuft den vorzeitigen Beendigungsprozess.
    • Sie konfigurieren die Instanz so, dass sie bei Hostwartungsereignissen beendet wird, anstatt die Live-Migration zu verwenden, und eine Hostwartung wird durchgeführt.
    • Sie konfigurieren ein lokales SSD-Laufwerk falsch und es ist nicht mehr erreichbar.
    • Sie deaktivieren die Projektabrechnung, wodurch die Instanz beendet wird.
    • Wenn automaticRestart auf Ihrer Instanz nicht konfiguriert ist.
    • Ein Hostfehler tritt auf und Compute Engine kann die Laufwerke nicht wieder mit der Instanz verbinden, bevor das Zeitlimit abläuft. In diesem Fall wird die Instanz neu gestartet, ohne die lokalen SSD-Laufwerke wiederherzustellen. Beim Neustart der Instanz 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 Ihre lokalen SSD-Daten intakt zu halten. Es gibt jedoch Fälle, in denen Daten nicht wiederhergestellt werden können, z. B. bei einem Zeitlimitü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 SSD-Laufwerke wiederherzustellen, die an die Instanz angehängt sind. Mit der Einstellung localSsdRecoveryTimeout der Hostrichtlinie 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 6 Stunden lang versuchen, die lokalen SSD-Daten wiederherzustellen, bevor das Zeitlimit erreicht wird.

Wenn Sie das Zeitlimit für die Wiederherstellung der lokalen SSD auf 0 setzen, versucht Compute Engine nicht, angehängte lokale SSD-Laufwerke wiederherzustellen. Die Instanz wird so schnell wie möglich neu gestartet und die lokalen SSD-Daten 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 gesetzt ist, das Zeitlimit jedoch erreicht wird, bevor die lokalen SSD-Daten 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 REPAIRING Status, während Compute Engine versucht, die lokalen SSD-Laufwerke wiederherzustellen. Die Instanz und die lokalen SSD-Laufwerke sind in dieser Zeit nicht verfügbar.

Wenn Sie das Zeitlimit für die Wiederherstellung der lokalen SSD auf den Maximalwert von 168 setzen, 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.

Dieser Befehl beendet den Wiederherstellungsprozess, beendet die Compute-Instanz und verwirft die lokalen SSD-Daten. Anschließend können Sie die Instanz neu starten. Weitere Informationen finden Sie unter Instanz mit lokaler SSD beenden.

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. Durch die Verwendung bestimmter Maschinenfamilien, können Sie Wartungseinstellungen angeben und Benachrichtigungen über bevorstehende Wartungsereignisse über Cloud Logging, den Metadatenserver der Instanz, den gcloud CLI compute instances describe Befehl oder die REST instances.describe Methode erhalten. Nach Erhalt einer Benachrichtigung, haben Sie einen bestimmten Zeitraum, in dem Sie die geplante Wartung zu einem von Ihnen gewählten Zeitpunkt starten können. Wenn Sie die geplante Wartung nicht auslösen, findet das Wartungsereignis am Ende des Benachrichtigungszeitraums statt. Das ist der in der Benachrichtigung angegebene geplante Zeitpunkt.

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

Nächste Schritte