Ü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 Compute-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. Bei allen Maschinenserien außer Z3 können Sie dieses Verhalten überschreiben und die Instanzen explizit so einstellen, dass sie beendet und optional neu gestartet werden. Instanzen, die mit bestimmten Maschinentypen oder Konfigurationen erstellt wurden, unterstützen keine Live-Migration, z. B.:

  • H4D-Instanzen
  • Z3-Instanzen mit mehr als 18 TiB angehängter Titanium-SSD
  • Z4D-Instanzen mit mehr als 42 TiB angehängter Titanium-SSD
  • Bare-Metal-Instanzen
  • 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 drei Arten von Host-Ereignissen, die in den folgenden Abschnitten genauer beschrieben werden:

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

Wartungsereignisse

Ein Wartungsereignis tritt auf, wenn Compute Engine Wartungs- oder Reparaturarbeiten 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 einer minimalen Unterbrechung Ihrer Anwendung.

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

Das Instanzverhalten während eines Wartungsereignisses kann je nach Mandantenfähigkeit der Instanz und Maschinentyp variieren.

Bei VMs für einzelne Mandanten treten geplante Hostwartungsereignisse etwa alle 4 bis 6 Wochen auf. Ob die Live-Migration unterstützt wird, hängt von der Hostwartungsrichtlinie für die VM für einzelne Mandanten ab.

Informationen zum Wartungsverhalten für jeden Maschinentyp finden Sie auf der entsprechenden Maschinenfamilienseite:

Informationen zu beschleunigungsoptimierten Maschinenfamilien finden Sie auf den folgenden Seiten:

Notfallwartung

Ein Notfallwartungsereignis tritt auf, wenn Compute Engine einen bevorstehenden Hostfehler oder ein anderes Hardwareproblem erkennt, das eine dringende Wartung erfordert. Für diese Ereignisse plant Compute Engine das Wartungsereignis und erstellt eine Benachrichtigung. Notfallwartungsereignisse haben in der Regel ein kürzeres Benachrichtigungsfenster als Standardwartungsereignisse.

Bei einem dringenden Wartungsereignis werden Sie in der Regel 7 bis 14 Tage im Voraus benachrichtigt. Je nach Schweregrad des Problems kann das Benachrichtigungsfenster kürzer sein. Sehen Sie sich die Wartungsbenachrichtigung an, um Informationen zu unterstützten Funktionen zu erhalten, z. B. zum Starten der Wartung zu einem Zeitpunkt Ihrer Wahl. Wenn Sie nichts unternehmen oder die Wartung nicht manuell starten können, startet Compute Engine die Wartung automatisch, wenn das Benachrichtigungsfenster endet.

Wenn ein geplantes Wartungsereignis ansteht, wenn Compute Engine eine Benachrichtigung zu einem dringenden Wartungsereignis ausgibt, wird das geplante Wartungsereignis durch das dringende Wartungsereignis ersetzt.

Den Grund für die Notfallwartung finden Sie im Feld maintenanceReasons der Instanzmetadaten. Dieses Feld enthält einen Wert, der die Fehlerkategorie darstellt.

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.

Wenn bei einer Compute-Instanz ein Hostfehler auftritt oder Sie den Host als fehlerhaft melden, ist eine ungeplante Notfallwartung des Hosts der Instanz erforderlich. Standardmäßig kündigt Compute Engine diese Art von Wartung einige Stunden im Voraus an.

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 Richtlinie für eine vorhandene Instanz 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:

Übersicht über die Hostwartungsrichtlinie

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

  • Wartungsereignis
  • 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.

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.
  • Host-Fehlererkennungszeit: Die maximale Zeit, die Compute Engine auf den Neustart oder die Beendigung einer Instanz wartet, nachdem erkannt wurde, dass die Instanz nicht mehr reagiert.

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 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:

  • 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. Ein Beispiel für C3-Bare-Metal-Maschinentypen finden Sie unter Wartung von C3-Instanzen.
  • Confidential 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 sind die meisten Instanztypen auf Live-Migration eingestellt, mit Ausnahme der im vorherigen Abschnitt erwähnten Instanztypen.

    Bei der Live-Migration migriert Compute Engine Ihre Instanz automatisch von einem Wartungsereignis der Infrastruktur weg. Die Instanz wird während der Migration weiterhin 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.

    Wenn Compute Engine Ihre Instanz migriert, 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 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, dassCloud de Confiance by S3NS die Instanz beendet, wenn ein Hostereignis eintritt. Wenn ein Hostereignis eintritt, sendet Compute Engine mit dieser Konfiguration 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 wurde, wird sie beendet.

    Diese Option ist ideal, wenn Ihre Instanzen eine konstante maximale Leistung erfordern und Ihre Anwendung insgesamt für 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 zum Beenden von Instanzen gilt folgender Vorgangstyp:

    compute.instances.terminateOnHostMaintenance

    Automatischer Neustart

    Wenn Ihre Instanz so konfiguriert ist, dass sie bei Wartungsarbeiten beendet wird, oder wenn Ihre Instanz wegen eines zugrundeliegenden 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.

    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 einen manuellen Vorgang offline genommen wird, z. B. durch Aufrufen 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 Hyperdisk Network Attached Storage 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.

    Wartungsplanung

    Cloud de Confiance by S3NS bietet Funktionen, mit denen Sie die Wartung besser steuern können. Durch die Verwendung bestimmter Maschinenfamilien 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 von Ihnen gewählten Zeitpunkt starten können. Wenn Sie die geplante Wartung nicht auslösen, findet das Wartungsereignis am Ende des Benachrichtigungszeitraums statt, 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