Live-Migrationsprozess während Wartungsereignissen

Während eines geplanten Wartungsereignisses auf der zugrunde liegenden Hardware einer VM-Instanz kann Compute Engine die VM auf einen anderen Host verschieben. Damit eine VM während eines Hostereignisses weiter ausgeführt wird, führt Compute Engine eine Live-Migration der VM zu einem anderen Host in derselben Zone aus. Weitere Informationen zu Hostereignissen finden Sie unter Hostereignisse.

Dank der Live-Migration kann Google Cloud Wartungsarbeiten ausführen, ohne eine Arbeitslast zu unterbrechen, eine VM neu zu starten oder die Attribute der VM zu ändern, z. B. IP-Adressen, Metadaten, Blockspeicherdaten, Anwendungszustand und Netzwerkeinstellungen.

Die Live-Migration hält VMs nicht nur während geplanter Hostereignisse, sondern auch in folgenden Situationen am Laufen:

  • Infrastrukturwartung. Die Infrastrukturwartung umfasst Hosthardware, Netzwerk und Stromnetze in Rechenzentren sowie Hostbetriebssysteme und BIOS.

  • Sicherheitsrelevante Aktualisierungen und Änderungen an der Systemkonfiguration. Dazu gehören Ereignisse wie das Installieren von Sicherheitspatches und das Ändern der Größe der Host-Root-Partition zum Speichern des Host-Betriebssystem-Images und der Pakete.

  • Hardwarefehler. Dazu gehören Ausfälle von Arbeitsspeicher, CPUs, Netzwerkkarten und Laufwerken. Wenn die Hardware vollständig ausfällt oder anderweitig die Live-Migration verhindert, wird die VM beendet, automatisch neu gestartet und Compute Engine protokolliert einen hostError.

Compute Engine führt eine Live-Migration nur für VMs durch, für die die Hostwartungsrichtlinie auf Migration festgelegt wurde. Informationen zum Ändern der Hostwartungsrichtlinie finden Sie unter VM-Hostwartungsrichtlinie festlegen.

Live-Migrationsprozess und lokale SSDs

Compute Engine kann VMs mit angehängten lokalen SSDs live migrieren, wobei die VMs zusammen mit ihrer lokalen SSD auf eine neue Maschine vor einer geplanten Wartung verschoben werden.

Beschränkungen

Die Live-Migration wird für die folgenden VM-Typen nicht unterstützt:

  • Die meisten Confidential VM-Instanzen Die Live-Migration für Confidential VM-Instanzen wird nur auf N2D-Maschinentypen mit AMD EPYC Milan-CPU-Plattformen mit AMD SEV unterstützt. Alle anderen vertraulichen VM-Instanzen unterstützen keine Live-Migration und müssen während eines Hostwartungsereignisses angehalten und optional neu gestartet werden. Weitere Informationen finden Sie unter Live-Migration.

  • VMs mit angehängten GPUs. VM-Instanzen mit angehängten GPUs müssen so eingerichtet sein, dass sie beendet und optional neu gestartet werden können. Compute Engine bietet eine Frist von 60 Minuten, bevor eine VM-Instanz mit angehängter GPU beendet wird. Weitere Informationen zu diesen Wartungsereignisbenachrichtigungen finden Sie unter Live-Migrationsbenachrichtigungen erhalten.

    Näheres zur Hostwartung mit GPUs erfahren Sie unter Hostwartung in der GPU-Dokumentation.

  • Cloud TPUs. Cloud TPUs unterstützen keine Live-Migration.

  • VMs auf Abruf: VMs auf Abruf können Sie nicht für die Live-Migration konfigurieren. Das Verhalten von Instanzen auf Abruf ist standardmäßig immer auf TERMINATE gesetzt. Diese Einstellung können Sie nicht ändern. Sie können die Option für den automatischen Neustart nicht für Instanzen auf Abruf festlegen. Sie können VMs auf Abruf aber auf der Seite VM-Instanzdetails noch einmal manuell starten, nachdem sie vorzeitig beendet wurden.

    Wenn Sie eine Instanz auf Abruf in eine normale Instanz ändern müssen, trennen Sie das Bootlaufwerk von der Instanz auf Abruf und hängen Sie es an eine neue Instanz an, die nicht als Instanz auf Abruf konfiguriert ist. Sie können auch einen Snapshot des Bootlaufwerks erstellen und damit eine neue Instanz erstellen, die nicht auf Abruf ist.

  • Spot-VMs. Spot-VMs können weder die Live-Migration verwenden, um während der Ausführung zu Standard-VMs zu werden, noch so eingestellt werden, dass sie bei Host-Events automatisch neu gestartet werden.

  • Speicheroptimierte VMs Z3-VMs unterstützen keine Live-Migration. Das Wartungsverhalten für Z3-VMs ist auf TERMINATE eingestellt.

Wie funktioniert der Live-Migrationsprozess?

Wenn für eine VM eine Live-Migration geplant ist, stellt Google Cloud eine Benachrichtigung bereit. Während der Live-Migration sorgt Google Cloud für eine minimale Unterbrechungszeit, die in der Regel weit weniger als eine Sekunde ist. Wenn für eine VM keine Live-Migration festgelegt ist, wird die VM von Compute Engine während der Hostwartung beendet. VMs, die so eingestellt sind, dass sie während eines Hostereignisses beendet werden, werden angehalten und (optional) neu gestartet.

Wenn Google Cloud eine laufende VM von einem Host zu einem anderen migriert, wird der gesamte Zustand der VM in einer für das Gast-Betriebssystem und jeden, der damit kommuniziert, transparenten Weise von der Quelle zum Ziel verschoben. Viele Komponenten sind daran beteiligt, dass dies reibungslos abläuft. Die übergeordneten Schritte sind in der folgenden Abbildung dargestellt:

VM und alle zugehörigen Ressourcen zu einem neuen Hostsystem migrieren, ohne dass das Gastbetriebssystem neu gestartet werden muss.
Komponenten der Live-Migration

Der Prozess beginnt mit einer Benachrichtigung, dass VMs von ihrer aktuellen Hostmaschine verschoben werden müssen. Die Benachrichtigung kann mit einer Dateiänderung, die anzeigt, dass eine neue BIOS-Version verfügbar ist, einem Hinweis auf eine geplante Wartung der Hardware oder einem automatischen Signal wegen eines bevorstehenden Hardwarefehlers beginnen.

Die Google Cloud-Cluster-Verwaltungssoftware achtet ständig auf diese Ereignisse und plant sie auf der Grundlage von Richtlinien, die die Rechenzentren steuern, wie z. B. Kapazitätsauslastungsraten und der Anzahl der VMs, die ein einzelner Kunde sofort migrieren kann.

Nachdem eine VM für die Migration ausgewählt wurde, benachrichtigt Google Cloud den Gast über die kurz bevorstehende Migration. Nach einer Wartezeit wird ein Zielhost ausgewählt und der Host wird aufgefordert, eine neue, leere "Ziel"-VM einzurichten, um die migrierende "Quell"-VM zu empfangen. Für die Herstellung einer Verbindung zwischen Quelle und Ziel erfolgt eine Authentifizierung.

Die VM-Migration umfasst drei Phasen:

  1. Teilausfall der Quelle. Die VM wird noch in der Quelle ausgeführt, während ein Großteil des Zustands von der Quelle zum Ziel gesendet wird. So kopiert Google Cloud zum Beispiel den gesamten Gastspeicher auf das Ziel und verfolgt die Seiten, die auf der Quelle geändert wurden. Die Dauer des Teilausfalls der Quelle hängt von der Größe des Gastspeichers und der Geschwindigkeit ab, mit der sich die Seiten ändern.

  2. Ausfall. Wenn die VM kurz nirgendwo ausgeführt wird, ist der VM-Betrieb unterbrochen und der übrige für den Beginn der VM-Ausführung auf dem Ziel erforderliche Zustand wird gesendet. Die VM tritt in die Ausfallphase ein, wenn das Senden des Zustands während des Teilausfalls der Quelle anfängt, rückläufige Ergebnisse zu liefern. Ein Algorithmus wägt die Anzahl der gesendeten Speicherbyte gegen die Rate ab, mit der sich die Gast-VM verändert.

    Bei Ausfällen wird die Systemuhr scheinbar um bis zu fünf Sekunden vorgestellt. Wenn ein Ausfall länger als fünf Sekunden dauert, hält Google Cloud die Uhr an und synchronisiert sie mit einem Daemon, der Bestandteil der VM-Gastpakete ist.

  3. Teilausfalls des Ziels. Die VM wird auf der Ziel-VM ausgeführt. Die Quell-VM ist vorhanden und kann als Unterstützung für die Ziel-VM fungieren. Beispielsweise leistet sie Weiterleitungsdienste für Pakete zu und von der Ziel-VM, bis die Netzwerkstruktur mit dem neuen Standort der Ziel-VM aktualisiert wurde.

Schließlich ist die Migration abgeschlossen und das System löscht die Quell-VM. Sie können aus Ihren VM-Logs ersehen, dass die Migration stattgefunden hat.

Manueller Live-Migrationsprozess

Während die Arbeitslast ausgeführt wird, können Sie VMs in einen anderen Knoten oder eine andere Knotengruppe verschieben. Mit Einzelmandantenfähigkeit können Sie VMs auf einen bestimmten Knoten für einen einzelnen Mandanten oder in eine Gruppe von Knoten verschieben. Wenn Sie eine VM in eine Gruppe von Knoten verschieben, bestimmt Compute Engine, auf welchem Knoten sie platziert wird. Informationen zur Einzelmandantenfähigkeit finden Sie unter Einzelne Mandanten.

Wenn Sie VMs für einzelne Mandanten in einen anderen Knoten oder eine andere Knotengruppe verschieben möchten, können Sie manuell eine Live-Migration initiieren. Sie können auch manuell eine Live-Migration initiieren, um eine mehrmandantenfähige VM in Einzelmandantenfähigkeit zu verschieben. Weitere Informationen finden Sie unter VMs manuell live migrieren.

Nächste Schritte