Live-Migrationsprozess während Wartungsereignissen

Während eines geplanten Wartungsereignisses für die zugrunde liegende Hardware einer virtuellen Maschine (VM)-Instanz oder Bare Metal-Instanzist der Hostserver nicht verfügbar. Damit eine Instanz während eines Hostereignisses weiter ausgeführt wird, führt Compute Engine eine Live-Migration der Instanz zu einem anderen Hostserver 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 Instanz neu zu starten oder die Attribute der Instanz zu ändern, z. B. IP-Adressen, Metadaten, Blockspeicherdaten, Anwendungsstatus oder Netzwerkeinstellungen.

Die Live-Migration hält Instanzen 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 der Fehler erkannt wird, bevor ein vollständiger Serverausfall auftritt, führt Compute Engine eine präventive Live-Migration der Instanz zu einem neuen Hostserver durch. Wenn die Hardware vollständig ausfällt oder anderweitig die Live-Migration verhindert, wird die Instanz beendet und automatisch neu gestartet.

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 Instanzen mit angehängten lokalen SSDs live migrieren (mit Ausnahme von Z3-Instanzen mit mehr als 18 TiB angehängter Titanium-SSD). Compute Engine verschiebt die Compute-Instanzen zusammen mit ihren lokalen SSD-Daten vor einer geplanten Wartung auf einen neuen Hostserver.

Beschränkungen

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

  • H4D-Instanzen mit lokaler SSD.
  • Bare-Metal-Instanzen. Instanzen, die mit einem Bare-Metal-Maschinentyp erstellt wurden, unterstützen keine Live-Migration. Das Wartungsverhalten für diese Instanzen ist auf TERMINATE bzw. RESTART, festgelegt.
  • Die meisten Confidential VM-Instanzen. Die Live-Migration für Confidential VM-Instanzen wird auf N2D- und C3D-Maschinentypen mit AMD SEV unterstützt. Alle anderen Confidential VM-Instanzen unterstützen keine Live-Migration und müssen so eingestellt sein, dass sie während eines Hostwartungsereignisses beendet 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 Benachrichtigung bevor eine VM-Instanz mit angehängter GPU beendet wird. Die Frist hängt vom GPU Typ ab:

    • Bei den meisten GPUs bietet Compute Engine eine Frist von 60 Minuten.
    • Bei A4X-, A4- oder A3 Ultra-Instanzen, bietet Compute Engine eine Frist von 10 Minuten.

    Weitere Informationen zu diesen Wartungsereignisbenachrichtigungen finden Sie unter Metadatenserver nach Wartungsereignisbenachrichtigungen abfragen.

    Weitere Informationen zum Umgang mit Hostwartung mit GPUs finden Sie in der GPU-Dokumentation unter Umgang mit Hostwartung.

  • Cloud TPUs. Cloud TPUs unterstützen keine Live-Migration.
  • Speicheroptimierte VMs. Z3-VMs mit mehr als 18 TiB angehängter Titanium-SSD unterstützen keine Live-Migration. Das Wartungsverhalten für diese VMs ist auf TERMINATE und RESTART festgelegt.Compute Engine behält die Daten auf der Titanium-SSD während des Wartungsverständnisses bei, wie unter Datenpersistenz nach dem Beenden von Instanzen beschrieben.
  • Compute-optimierte VMs : H4D-VMs unterstützen keine Live-Migration, da die Live Migration für RDMA-fähige VMs nicht unterstützt wird. Aus Sicht einer HPC-Anwendung würde die Live-Migration einer Instanz die Anwendungsleistung erheblich beeinträchtigen. Es ist besser, wenn Anwendungen an einem Prüfpunkt starten. Das Wartungsverhalten für diese VMs ist auf TERMINATE und RESTART festgelegt. Compute Engine behält die Daten auf der Titanium-SSD während des Wartungsereignisses bei, wie unter Datenpersistenz nach dem Beenden von Instanzen beschrieben.

Wie funktioniert der Live-Migrationsprozess?

Wenn für eine VM eine Live-Migration geplant ist, stellt Compute Engine eine Benachrichtigung bereit, damit Sie Ihre Arbeitslasten und Anwendungen auf diese Live-Migration Unterbrechung vorbereiten können. Während der Live-Migration, Google Cloud sorgt 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 angehalten und (optional) neu gestartet.

Wenn Google Cloud eine laufende VM von einem Host zu einem anderen migriert, wird der vollständige Status der VM von der Quelle zum Ziel verschoben. Dies ist für das Gastbetriebssystem und alle Komponenten, die mit ihm kommunizieren, transparent. 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 eine VM von ihrem aktuellen Hostrechner verschoben werden muss. 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.

Google CloudDie Clusterverwaltungssoftware von 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, Google Cloud wird der Gast benachrichtigt, dass bald eine Migration stattfindet. 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. Die Authentifizierung wird verwendet, um eine Verbindung zwischen Quelle und Ziel herzustellen.

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 zum Beispiel Google Cloud 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. Ein sehr kurzer Moment, in dem die VM nirgendwo ausgeführt wird. Die Quell-VM wird angehalten und der gesamte verbleibende Status, der zum Ausführen der VM auf dem Ziel erforderlich ist, wird gesendet. Die VM wechselt in die Ausfallphase, wenn das Senden von Statusänderungen während der Teilausfallphase der Quelle einen Punkt erreicht, an dem der Aufwand den Nutzen übersteigt. 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 die Uhr an und synchronisiert sie mit einem Daemon, der Bestandteil der VM-Gastpakete ist. Google Cloud

  3. Teilausfall des Ziels. Die VM wird auf der Ziel-VM ausgeführt. Die Quell-VM ist vorhanden und kann die Ziel-VM unterstützen. Bis das Netzwerk mit dem neuen Standort der Ziel-VM synchronisiert ist, bietet die Quell-VM beispielsweise Weiterleitungsdienste für Pakete von und zur Ziel-VM.

Schließlich ist die Migration abgeschlossen und das System löscht die Quell-VM. Sie können in den Cloud Logging-Logs für Ihre VM sehen, dass die Migration stattgefunden hat.

Live-Migration von VMs für einzelne Mandanten

Während die Arbeitslast ausgeführt wird, können Sie VMs in einen anderen Knoten oder eine andere Knotengruppe für einzelne Mandanten 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 VM auf einem mandantenfähigen Host in einen Knoten für einzelne Mandanten zu verschieben. Weitere Informationen finden Sie unter VMs manuell live migrieren.

Nächste Schritte