Diese Seite wurde von der Cloud Translation API übersetzt.

Arbeitslast auf eine neue Compute-Instanz verschieben

In bestimmten Situationen möchten Sie möglicherweise Ihre Arbeitslast von einer vorhandenen VM-Instanz auf eine neuere VM verschieben. Gründe für den Umzug zu einer neuen VM sind:

Nutzen Sie die neuen Maschinentypen für schnellere Speicher- oder Netzwerkgeschwindigkeiten. Beispielsweise ein Upgrade von C2 auf H3 für eine höhere Netzwerkbandbreite.
Sie profitieren von einem besseren Preis-Leistungs-Verhältnis im Vergleich zur Quell-VM-Instanz. Beispielsweise können Sie von N1 auf N4 upgraden, um von der 5. Generation des Intel Xeon-Prozessors zu profitieren.
Funktionen nutzen, die nur in der neuen VM-Instanz verfügbar sind. Beispielsweise können Sie von N4 auf C4 upgraden, um von zusätzlicher Leistung und Wartungsoptionen zu profitieren.
VM-Instanz in eine Bare-Metal-Instanz ändern
Fügen Sie Ihrer C3- oder C3D-VM-Instanz lokale SSD-Laufwerke hinzu.

Wenn Sie ein Upgrade auf die neueste Generation von Maschinenserien durchführen, können Sie möglicherweise das einfachere Verfahren verwenden, das unter Maschinentyp einer Compute-Instanz bearbeiten beschrieben wird, wenn die folgenden Bedingungen für die aktuelle (Quell-)VM erfüllt sind:

Die Betriebssystemversion wird von der neuen Maschinenserie unterstützt.
Der Laufwerkstyp des Bootlaufwerks, das an die Quell-VM angehängt ist, wird von der neuen Maschinenserie unterstützt.
Die VM verwendet keinen lokalen SSD-Speicher.
Ihre VM mit angehängten GPUs verwendet einen G2-Maschinentyp. Weitere Informationen finden Sie unter GPUs hinzufügen oder entfernen.
Die VM verwendet nur Funktionen, die von der neuen Maschinenserie unterstützt werden.
Die VM ist nicht Teil einer verwalteten Instanzgruppe (MIG).
Die VM verwendet die gVNIC-Netzwerkschnittstelle.

Hinweise

Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud -Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich so bei Compute Engine authentifizieren.
<x0A>
Select the tab for how you plan to use the samples on this page:
Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, damit Sie die Berechtigungen zum Bearbeiten oder Ändern einer VM erhalten:

Compute-Instanzadministrator (Version 1) (roles/compute.admin.v1)
So ändern Sie den Netzwerktyp: Compute Engine-Netzwerkadministrator (roles/compute.networkAdmin)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Bearbeiten oder Ändern einer VM erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind zum Bearbeiten oder Ändern einer VM erforderlich:

So ändern Sie den Maschinentyp:
- compute.instances.stop für das Projekt
- compute.instances.create für das Projekt
- compute.instances.start für das Projekt
- compute.instances.setMachineType für die Instanz
Um einen Snapshot der Persistent Disk zu erstellen:
- compute.snapshots.create für das Projekt
- compute.disks.createSnapshot für das Laufwerk
So erstellen Sie ein neues Laufwerk:
- compute.disks.list für das Projekt
- compute.disks.create für das Projekt
- compute.disks.update für das Projekt
Um ein Laufwerk zu einer VM hinzuzufügen:
- compute.instances.attachDisk für die Instanz
- compute.disks.use für das Laufwerk
Um ein Laufwerk zu löschen: compute.disks.delete für das Projekt
So ändern Sie den Netzwerktyp:
- compute.networks.list für das Projekt
- compute.networks.update für das Projekt

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

VM-Migrationsoptionen bewerten

Die Migration von einem Maschinentyp zu einem anderen hängt von mehreren Faktoren ab, darunter die regionale Verfügbarkeit des neuen Maschinentyps und die Kompatibilität der Speicheroptionen und Netzwerkschnittstellen in Bezug auf das Gastbetriebssystem der Quell- und der neuen Maschinenserie.

Computing-Anforderungen

Prüfen Sie die folgenden Anforderungen für Ihre aktuelle Instanz und den neuen Maschinentyp:

In der Dokumentation zur Maschinenfamilienressource finden Sie Informationen dazu, welche Maschinentypen für Ihre Arbeitslast geeignet sind. Überlegen Sie, ob Ihre Anwendung spezielle Hardware (GPUs), hohe Leistung oder niedrigere Kosten erfordert.
Prüfen Sie die Funktionen der vom neuen Maschinentyp unterstützten Laufwerkstypen. Die meisten Funktionen von Persistent Disk, aber nicht alle, werden von Hyperdisk unterstützt. Hyperdisk bietet jedoch zusätzliche Funktionen, die bei Persistent Disk nicht verfügbar sind.
Sehen Sie sich die Funktionen der infrage kommenden Maschinenreihe an. Die neuen Maschinentypen unterstützen möglicherweise nicht dieselben Funktionen wie Ihre aktuellen Maschinentypen, z. B. benutzerdefinierte Maschinentypen, lokale SSDs oder Shielded VMs.
Prüfen Sie die Regionen und Zonen, um sicherzustellen, dass die neue Maschinenserie in allen Regionen als Ihre aktuelle VM verfügbar ist. Möglicherweise müssen Sie Ihre Bereitstellungs-, Hochverfügbarkeits- und Notfallwiederherstellungspläne anpassen.
Prüfen Sie Ihren Migrationsplan für das Betriebssystem:
- Wenn die neue VM eine neuere Version des Betriebssystems erfordert, prüfen Sie, ob Ihre Anwendungen mit der neueren Betriebssystemversion kompatibel sind.
- Wenn Sie zu Arm wechseln und für Ihre aktuelle Betriebssystemversion kein Arm-Image verfügbar ist, wählen Sie ein neues Betriebssystem oder eine neue Betriebssystemversion aus, auf dem Ihre Anwendungen ausgeführt werden sollen, und prüfen Sie, ob Ihre Anwendungen mit dem neuen Betriebssystem kompatibel sind.
Die Migration von einer C3-VM-Instanz zu einer C3-Bare-Metal-Instanz ist möglich, sofern die Quell-C3-VM-Instanz ein unterstütztes Betriebssystem und einen unterstützten Netzwerktreiber verwendet.
Wenn Sie von einer anderen Maschinenserie als C3 zu einer Bare-Metal-Instanz wechseln, müssen Sie eine neue Instanz erstellen. Möglicherweise müssen Sie Ihren eigenen Hypervisor ausführen. Sie können aber auch jedes von C3 Metal unterstützte Betriebssystem ausführen, sofern der IDPF-Treiber aktiviert ist. Bei Bare-Metal-Instanzen wird die IDPF-Netzwerkschnittstelle nur als physische Funktion und nicht als virtuelle Funktion dargestellt.

Speicherbedarf

Prüfen Sie die folgenden Speicheranforderungen für Ihre aktuelle Instanz und den neuen Instanztyp:

Prüfen Sie die unterstützten Speichertypen und Speicherschnittstellen für die neue Maschinenserie.
- Standardmäßig verwenden Maschinenreihen der ersten und zweiten Generation nur den Persistent Disk-Speichertyp und die VirtIO-SCSI-Schnittstellen.
- Maschinenserien der dritten Generation und neuer (wie M3, C3 und N4) unterstützen nur die NVMe-Schnittstelle und einige unterstützen nur die Speichertypen Hyperdisk und lokale SSD.
- Bare-Metal-Instanzen unterstützen nur Hyperdisk.
Laufwerkskompatibilität:
- Wenn das Bootlaufwerk einen Laufwerktyp verwendet, der von der neuen Maschinenserie nicht unterstützt wird, z. B. pd-standard, müssen Sie ein neues Bootlaufwerk für die neue VM erstellen.
- Wenn Sie das Betriebssystem auf eine neue Version aktualisieren und das Betriebssystem keine In-Place-Upgrades unterstützt, müssen Sie ein neues Bootlaufwerk erstellen. Alle Daten auf der Quell-Bootdisk gehen verloren, sofern Sie sie nicht auf eine temporäre Nicht-Bootdisk kopieren. Als Nächstes erstellen Sie ein neues Bootlaufwerk und kopieren die Daten, die auf dem temporären Nicht-Bootlaufwerk gespeichert sind, auf das neue Bootlaufwerk.
- Wenn Sie die Betriebssystemversion nicht aktualisieren, können Sie einen Snapshot Ihres aktuellen Bootlaufwerks erstellen und ihn auf dem neuen, unterstützten Laufwerkstyp wiederherstellen. Wenn Sie eine VM erstellen, können Sie dieses neue Laufwerk als Bootlaufwerk verwenden.
- Wenn ein Nicht-Bootlaufwerk einen Laufwerkstyp verwendet, der von der neuen Maschinenserie nicht unterstützt wird, können Sie einen Snapshot verwenden, um das Quelllaufwerk auf einen neuen Laufwerkstyp zu ändern, wie unter Laufwerkstyp ändern beschrieben.
Lokale SSD-Laufwerke können nicht auf eine neue VM verschoben werden. Sie können ein Laufwerk, das groß genug ist, um alle lokalen SSD-Daten zu speichern, an Ihre aktuelle VM anhängen und dann einen Snapshot verwenden, um das Quelllaufwerk auf einen neuen Laufwerktyp zu ändern, wie unter Laufwerktyp ändern beschrieben. Nachdem Sie eine VM mit angehängten lokalen SSD-Laufwerken erstellt haben, können Sie die Daten zurück auf die lokalen SSD-Laufwerke kopieren.
Wenn Ihre aktuelle VM-Instanz Laufwerke in einem Speicherpool verwendet, Sie Ihre Arbeitslast jedoch auf eine VM in einer anderen Region verschieben, müssen Sie die Laufwerke und den Speicherpool in der neuen Region neu erstellen.
Wenn die neue Maschinenserie eine andere Festplattenschnittstelle verwendet (z. B. NVMe anstelle von SCSI), sind die Namen der Festplatten in der Gast-VM unterschiedlich. Achten Sie darauf, dass Ihre Anwendungen und Skripts entweder nichtflüchtige Gerätenamen oder Symlinks verwenden, wenn sie auf die angehängten Laufwerke verweisen.

Netzwerkanforderungen

Sehen Sie sich die folgenden Netzwerkanforderungen für Ihre aktuelle Instanz und den neuen Instanztyp an:

Prüfen Sie die unterstützten Netzwerkschnittstellen für die neue VM.
- Standardmäßig verwenden Maschinenreihen der ersten und zweiten Generation nur die VirtIO-Netzwerkschnittstelle.
- Maschinenserien der dritten Generation und neuer (wie M3, C3 und N4) unterstützen nur die gVNIC-Netzwerkschnittstelle.
- Bare-Metal-Instanzen unterstützen nur die IDPF-Netzwerkschnittstelle.
Prüfen Sie, ob Ihre Anwendung und Ihr Betriebssystem die für die Maschinenreihe verfügbaren Schnittstellen unterstützen.
Prüfen Sie die Netzwerkkonfiguration Ihrer VM, um festzustellen, ob Sie die zugewiesenen IP-Adressen beibehalten müssen. Wenn ja, müssen Sie die IP-Adressen in statische IP-Adressen umwandeln.
Wenn Sie die Tier_1-Netzwerkleistung pro VM mit Ihrer aktuellen VM verwenden, prüfen Sie, ob sie mit der neuen Maschinenserie verfügbar oder erforderlich ist. Sie können beispielsweise das Tier_1-Netzwerk mit einem C2-Maschinentyp verwenden, es ist aber nicht für eine H3-VM erforderlich.

Verwenden Sie den Befehl gcloud compute instances describe, um die nic-type der VM aufzurufen und den Typ der Netzwerkschnittstelle der aktuellen VM zu ermitteln:

  gcloud compute instances describe VM_NAME --zone=ZONE

Wenn für Ihre VM nic-type auf VIRTIO festgelegt ist, können Sie den Typ der Netzwerkschnittstelle nicht ändern. Sie müssen eine neue VM erstellen und den Netzwerkschnittstellentyp auf gVNIC festlegen.

Umzug vorhandener VMs vorbereiten

Nachdem Sie den Evaluierungsabschnitt abgeschlossen haben, müssen Sie die Migration Ihrer VM-Instanzen vorbereiten. Dazu fordern Sie Ressourcen für die neue VM-Instanz an und erstellen Back-ups der Quell-VM-Instanz.

Compute-Ressourcen vorbereiten

Führen Sie die folgenden Schritte aus, um die Migration Ihrer aktuellen Instanz auf eine neue Instanz vorzubereiten:

Fordern Sie Kontingent in der Region und den Zonen an, in die Sie Ihre Ressourcen verschieben möchten. Wenn Sie ein vorhandenes Kontingent für einen Maschinentyp haben, können Sie beantragen, dass dieses Kontingent verschoben wird. Der Vorgang dauert einige Tage.
Erstellen Sie eine Reservierung für die neuen VM-Instanzen, damit die Maschinenressourcen in der neuen Region und den neuen Zonen verfügbar sind. Sie müssen wissen, wie reservierte Ressourcen genutzt werden, und testen, ob Sie reservierte Ressourcen nutzen können.
Erweitern Sie Ihre Pläne für Hochverfügbarkeit und Notfallwiederherstellung auf die neue Region.
Führen Sie bei Bedarf ein Upgrade des Betriebssystems auf der aktuellen VM durch.
1. Wenn der Betriebssystemanbieter dies unterstützt, führen Sie ein In-Place-Upgrade Ihres Betriebssystems auf eine Version durch, die von der neuen Maschinenserie unterstützt wird, und prüfen Sie, ob Ihre Arbeitslast in der neuen Betriebssystemversion wie erwartet ausgeführt wird.
2. Wenn ein In-Place-Upgrade des Betriebssystems nicht unterstützt wird, müssen Sie beim Erstellen einer neuen VM ein neues Bootlaufwerk erstellen. Ermitteln Sie, welche Informationen Sie vom aktuellen Bootlaufwerk kopieren müssen, und kopieren Sie sie an einen temporären Speicherort auf einem Nicht-Bootlaufwerk, damit sie auf die neue VM übertragen werden können. Wenn an Ihre aktuelle VM keine Nicht-Bootlaufwerke angehängt sind:
  - Informationen zu Maschinentypen der ersten und zweiten Generation finden Sie unter Nichtflüchtigen Speicher zu VM hinzufügen.
  - Informationen zu Maschinentypen der dritten Generation und höher finden Sie unter Hyperdisk-Speicher zur VM hinzufügen.
Prüfen Sie, falls für Ihre Linux-Distribution zutreffend, die udev-Regeln unter /etc/udev/rules.d/. Diese Datei enthält möglicherweise Einträge, die für die Hardwarekonfiguration der aktuellen Instanz, nicht aber für die neue Instanz relevant sind. Der folgende Eintrag sorgt beispielsweise dafür, dass eth0 vom virtio-pci-Treiber (VirtIO Net) bereitgestellt wird. Dadurch wird verhindert, dass der gve-Treiber (gVNIC) diese Schnittstelle bereitstellt. Dies kann zu Problemen mit Netzwerk-Startskripts und der Konnektivität in der neuen Instanz führen:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="virtio-pci", ATTR{dev_id}=="0x0", KERNELS=="0000:00:04.0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Speicherressourcen vorbereiten

Führen Sie die folgenden Schritte aus, um die Daten auf den Laufwerken, die an Ihre aktuelle Instanz angehängt sind, auf eine neue Instanz zu übertragen:

Testen Sie auf Linux-Systemen Ihre aktualisierten Anwendungen und Skripts, um sicherzustellen, dass sie mit nichtflüchtigen Gerätenamen oder Symlinks anstelle der Gerätenamen des Laufwerks funktionieren.
Wenn Sie von einer VM migrieren, auf der Microsoft Windows ausgeführt wird:
- Sie müssen den NVMe-Treiber auf VMs aktualisieren, die vor Mai 2022 erstellt wurden. Dies gilt für das Bootlaufwerk in der aktuellen VM und in zuvor erstellten Snapshots oder benutzerdefinierten Images, die zum Erstellen einer VM verwendet werden.
- Windows muss neu konfiguriert werden, um den Microsoft NVMe-Treiber (StorNVMe) zu verwenden. Folgen Sie der Anleitung, um Ihr Startgerät zu aktualisieren.
Wenn Ihre neue VM nicht dieselben Laufwerkstypen wie Ihre aktuelle VM unterstützt, müssen Sie möglicherweise Ihre Bereitstellungsskripts oder Instanzvorlagen aktualisieren, um die neue Maschinenserie zu unterstützen.
Wenn Ihre aktuelle VM einen Laufwerkstyp für das Bootlaufwerk verwendet, der von der neuen Maschinenserie nicht unterstützt wird, und Sie mehrere VMs mit derselben Konfiguration migrieren, erstellen Sie ein benutzerdefiniertes Image, das Sie beim Erstellen der neuen VMs verwenden können:
1. Erstellen Sie einen Snapshot des pd-standard-Bootlaufwerks Ihrer aktuellen VM.
2. Erstellen Sie ein benutzerdefiniertes Image. Verwenden Sie dabei den Laufwerk-Snapshot als Quelle.
Wenn Sie Informationen von lokalen SSDs verschieben müssen, erstellen Sie ein leeres Laufwerk, das groß genug ist, um Ihre lokalen SSD-Laufwerke zu sichern.
1. Verwenden Sie nach Möglichkeit einen Laufwerktyp, der von der neuen VM unterstützt wird.
2. Wenn es keine Laufwerktypen gibt, die sowohl von der aktuellen als auch von der neuen VM unterstützt werden, erstellen Sie ein temporäres Laufwerk mit einem Laufwerktyp, der von der aktuellen VM unterstützt wird.
3. Hängen Sie das neue Laufwerk an die aktuelle VM an und formatieren und stellen Sie es dann bereit.
4. Kopieren Sie die Daten von den lokalen SSD-Laufwerken, die an die aktuelle VM angehängt sind, auf dieses temporäre Laufwerk.
Ändern Sie den Laufwerkstyp aller Laufwerke, die an die aktuelle VM angehängt sind und einen Laufwerkstyp verwenden, der von der neuen VM nicht unterstützt wird. Wenn Sie die Laufwerksdaten auf neue Laufwerke verschieben möchten, erstellen Sie Snapshots der Laufwerke. Alternativ können Sie Dateien von einer VM auf die andere übertragen.
1. Sie können die Snapshots erstellen, während die VM ausgeführt wird. Alle Daten, die nach dem Erstellen des Snapshots auf die Laufwerke geschrieben werden, werden jedoch nicht erfasst. Da Snapshots inkrementell sind, können Sie einen zweiten Snapshot erstellen, nachdem Sie die VM beendet haben, um alle aktuellen Änderungen zu erfassen. Dieser Ansatz sollte die Zeit minimieren, in der die VM nicht verfügbar ist, während Sie zu einer neuen VM wechseln.
2. Alternativ können Sie alle Laufwerk-Snapshots erstellen, nachdem Sie die VM beendet haben. Wir empfehlen, einen Snapshot aller Laufwerke zu erstellen, die an Ihre VM angehängt sind, auch wenn der Laufwerkstyp von der neuen Maschinenserie unterstützt wird. Fügen Sie alle temporären Laufwerke ein, die die kopierten lokalen SSD-Daten enthalten.
3. Die Zeit, die zum Erstellen eines Snapshots eines Laufwerks benötigt wird, hängt von mehreren Faktoren ab, z. B. von der Größe des Laufwerks und der Menge der auf dem Laufwerk enthaltenen Daten. Wenn Sie beispielsweise einen Snapshot eines 1 TiB großen Laufwerks erstellen, das zu 85% belegt ist, kann es 5 Minuten dauern, bis der Snapshot fertig ist. Wenn Sie jedoch einen Snapshot eines 100 TiB-Laufwerks erstellen, das zu 85% belegt ist, kann es 11 Minuten dauern, bis der Vorgang abgeschlossen ist. Wir empfehlen, vor Beginn der Migration Test-Snapshots Ihrer Laufwerke zu erstellen, um zu sehen, wie lange das Erstellen von Snapshots dauert.
Wenn Sie ein Laufwerk haben, das offline genommen werden kann, können Sie die Daten mit dem folgenden Verfahren auf ein neues Laufwerk verschieben, während die Quell-VM noch verfügbar ist:
1. Trennen Sie das Laufwerk von Ihrer VM.
2. Snapshot des Laufwerks erstellen
3. Verwenden Sie den Snapshot, um ein neues Laufwerk mit einem Laufwerkstyp zu erstellen, der von der neuen Maschinenserie unterstützt wird. Das neue Laufwerk muss entweder dieselbe Größe wie das Quelllaufwerk oder größer sein.

Netzwerkressourcen vorbereiten

Führen Sie die folgenden Schritte aus, um die Netzwerkkonfiguration zu aktualisieren, die von Ihrer aktuellen Instanz verwendet wird, damit die neue Instanz unterstützt wird:

Wenn Ihre aktuelle VM gVNIC nicht verwendet, müssen Sie eine neue Instanz mit einer Netzwerkschnittstelle erstellen, die gVNIC verwendet. Lesen Sie den Abschnitt Übersicht über die Verwendung von gVNIC mit Compute Engine-VMs, um zu erfahren, welche Schritte beim Erstellen einer neuen Instanz erforderlich sind.
Wenn Sie eine VM in einer neuen Region erstellen, erstellen Sie ein VPC-Netzwerk und Subnetze in der neuen Region.
Wenn Sie die Anzahl benutzerdefinierter NIC-Warteschlangen konfiguriert haben, lesen Sie die Informationen unter Warteschlangenzuweisung und Änderungen von Maschinentypen.
Wenn Sie die von der Quell-VM verwendeten IP-Adressen beibehalten möchten, wandeln Sie die IP-Adressen in statische IP-Adressen um.
Heben Sie die Zuweisung der statischen IP-Adresse auf, bevor Sie die Quell-VM beenden.

Betriebssystem SUSE Enterprise Linux Server vorbereiten

Um hardwarespezifische Abhängigkeiten zu vermeiden, erstellen Sie das initramfs (Initial RAM-Dateisystem) neu. Dazu gehören eine größere Auswahl an Treibern und Modulen, wodurch das Betriebssystem mit anderen Instanztypen kompatibel ist. Andernfalls tritt das bekannte Problem auf, das verhindert, dass die VM ordnungsgemäß gebootet wird.

Bevor Sie das System herunterfahren, führen Sie den folgenden Befehl als Root aus, um initramfs mit allen Treibern neu zu erstellen:

  sudo dracut --force --no-hostonly

Arbeitslast auf die neue VM verschieben

Nachdem Sie Ihre VMs für die Migration vorbereitet haben, verschieben Sie Ihre Arbeitslast auf die neue VM.

Wenn Sie Ihre VMs von der ersten zur zweiten Generation der Maschinenserie verschieben, lesen Sie die Anleitung auf der Seite Maschinentyp einer VM bearbeiten. Wenn Sie den Namen Ihrer vorhandenen VM ändern möchten, lesen Sie die Informationen unter VM umbenennen.

Erforderliche Berechtigungen für diese Aufgabe

Zum Ausführen dieser Aufgabe benötigen Sie die folgende Berechtigung:

compute.instances.setMachineType auf der VM

In diesem Abschnitt wird beschrieben, wie Sie Ihre Arbeitslast von einer VM der ersten oder zweiten Generation auf eine VM der dritten (oder neueren) Generation verschieben. In diesem Verfahren erstellen Sie eine neue VM-Instanz und verschieben Ihre Arbeitslasten dann auf die neue VM.

Wählen Sie beim Erstellen der neuen VM einen der unterstützten Laufwerkstypen für das Bootlaufwerk aus, z. B. Hyperdisk Balanced.

Neue VM erstellen

Wenn Sie Ihre Arbeitslasten von VMs der ersten oder zweiten Generation (z. B. N1 oder N2) auf VMs der dritten Generation oder höher verschieben, müssen Sie zuerst eine neue VM erstellen und dann Ihre Arbeitslasten verschieben.

Wenn die Quell-VM Nicht-Bootlaufwerke mit einem Laufwerktyp verwendet, der von der neuen Maschinenserie unterstützt wird, trennen Sie die Laufwerke von der VM.
Beenden Sie die Quell-VM.
Erstellen Sie Snapshots aller Laufwerke, die noch an die Quell-VM angehängt sind.
Erstellen Sie eine neue Compute-VM-Instanz mit einem öffentlichen Image oder einem benutzerdefinierten Image, das für die Verwendung von gVNIC konfiguriert ist. Wählen Sie beim Erstellen der neuen VM die folgenden Optionen aus:
- Wählen Sie den Maschinentyp aus der von Ihnen ausgewählten Maschinenserie aus.
- Wählen Sie ein unterstütztes Betriebssystem-Image aus oder verwenden Sie ein benutzerdefiniertes Image, das Sie zuvor erstellt haben.
- Wählen Sie einen unterstützten Laufwerkstyp für das Bootlaufwerk aus.
- Wenn Sie neue Laufwerke aus Snapshots der ursprünglichen Laufwerke erstellt haben, fügen Sie diese neuen Laufwerke hinzu.
- Geben Sie das neue VPC-Netzwerk an, wenn Sie die Instanz in einer anderen Region erstellen.
- Wenn sowohl VirtIO als auch gVNIC für die neue Instanz unterstützt werden, wählen Sie gVNIC aus.
- Geben Sie die statischen IP-Adressen an, wenn Sie die sitzungsspezifischen IP-Adressen der Quell-VM umgewandelt haben.
Starten Sie die neue VM.

Nach dem Start der Instanz

Nachdem die neue Instanz erstellt und gestartet wurde, führen Sie die folgenden Schritte aus, um die Konfiguration der neuen Instanz abzuschließen und alle Daten aus der Quellinstanz zu kopieren.

Hängen Sie die Laufwerke, die Sie von der Quell-VM getrennt haben, an die neue VM an.
Für alle Laufwerke, die an die Quell-VM angehängt sind und einen Laufwerktyp verwenden, der von der neuen VM nicht unterstützt wird, erstellen Sie ein Laufwerk aus einem Snapshot und hängen Sie es an die neue Instanz an. Wählen Sie beim Erstellen des neuen Laufwerks einen Laufwerkstyp aus, der von der neuen VM unterstützt wird, und geben Sie eine Größe an, die mindestens so groß wie das ursprüngliche Laufwerk ist.
Wenn die ursprüngliche VM eine Ressourcenrichtlinie für alle Laufwerke verwendet hat, die für die neue VM neu erstellt wurden, müssen Sie die Ressourcenrichtlinie den neuen Laufwerken hinzufügen.
Wenn Sie die neue VM mit einem öffentlichen Betriebssystem-Image und nicht mit einem benutzerdefinierten Image erstellt haben, gehen Sie so vor:
1. Konfigurieren Sie die Nutzer, Treiber, Pakete und Dateiverzeichnisse auf der neuen Instanz, die Ihre Arbeitslast unterstützen.
2. Installieren Sie die geänderten Anwendungen und Programme auf der neuen VM. Kompilieren Sie die Programme bei Bedarf im neuen Betriebssystem oder in der neuen Architektur.
Optional: Wenn Sie den Inhalt der lokalen SSD-Laufwerke auf ein temporäres Laufwerk verschoben haben und an die neue VM lokaler SSD-Speicher angehängt ist, können Sie die Daten vom temporären Laufwerk auf die lokalen SSD-Laufwerke verschieben, nachdem Sie die Laufwerke formatiert und bereitgestellt haben.
Weisen Sie der Quell-VM alle statischen IP-Adressen zu, die der Quell-VM zugeordnet sind.
Führen Sie alle zusätzlichen Aufgaben aus, die erforderlich sind, um Ihre neue VM hochverfügbar zu machen, z. B. das Konfigurieren von Load-Balancern und das Aktualisieren der Weiterleitungsregeln.
Optional: Aktualisieren Sie bei Bedarf die DNS-Einträge für die neue VM.
Empfohlen: Laufwerksicherungen für die neuen Laufwerke planen.
Empfohlen: Wenn Sie das Betriebssystem in eine andere Version oder Architektur geändert haben, kompilieren Sie Ihre Anwendungen neu.

Wenn beim Verschieben Ihrer Arbeitslast Probleme auftreten, wenden Sie sich an Ihren Technical Account Manager (TAM) oder die Google Professional Services Organization (PSO).

Beispiel für die Migration von n1-standard-8 zu n4-standard-8

Das folgende Beispiel zeigt die Migration einer n1-standard-8-VM zu einer n4-standard-8-VM. Die n1-standard-8-VM hat ein PD-SSD-Bootlaufwerk mit einem Ubuntu1804-Image und ein PD-SSD-Datenlaufwerk. Für dieses Verfahren müssen Sie die CLI oder REST API verwenden.

Es gibt zwei Möglichkeiten, Ihre N1-VM auf eine N4-VM zu aktualisieren:

Option 1:Wenn Ihre N1-VM die VirtIO-Netzwerkschnittstelle verwendet, müssen Sie eine neue N4-VM erstellen. N4 unterstützt nur die gvnic-Netzwerkschnittstelle und Hyperdisk Balanced-Laufwerke. Sie erstellen einen Snapshot Ihrer Boot- und Datenlaufwerke des nichtflüchtigen Speichers, erstellen Hyperdisk Balanced-Laufwerke aus diesen Snapshots, hängen die Hyperdisk Balanced-Laufwerke an und erstellen die neue N4-VM mit den Hyperdisk Balanced-Laufwerken.

Sie können auch ein neues Hyperdisk Balanced-Bootlaufwerk mit einer neueren Version des Ubuntu-Betriebssystems erstellen. In diesem Szenario können Sie ein neues Hyperdisk Balanced-Laufwerk aus dem Bootlaufwerk-Snapshot erstellen, dieses Laufwerk aber als Nicht-Bootlaufwerk an die N4-VM anhängen. Anschließend können Sie Nicht-Systemdaten aus dem wiederhergestellten Snapshot auf das neue Bootlaufwerk kopieren.

Option 2:Wenn Ihre N1-VM die gvnic-Netzwerkschnittstelle verwendet, das Betriebssystem einen NVMe-Speichergerätetreiber hat, keine lokalen SSD-Laufwerke oder GPUs angehängt sind und die VM nicht Teil einer verwalteten Instanzgruppe (MIG) ist, können Sie den Maschinentyp von N1 in N4 ändern. Sie müssen jedoch weiterhin die Persistent Disk-Laufwerkstypen in Hyperdisk Balanced-Laufwerke ändern. Sie müssen zuerst die Boot- und Datenlaufwerke Ihres nichtflüchtigen Speichers trennen, Snapshots der Laufwerke erstellen, Hyperdisk Balanced-Laufwerke mit den Snapshots als Quelle erstellen und die neuen Hyperdisk Balanced-Laufwerke dann an Ihre N4-VM anhängen, nachdem Sie den Maschinentyp geändert haben. Wenn Ihrer VM GPUs zugeordnet sind, müssen Sie diese zuerst trennen.

Die Zeit, die zum Erstellen eines Snapshots eines Laufwerks benötigt wird, hängt von mehreren Faktoren ab, z. B. von der Gesamtzahl der Terabyte auf einem Laufwerk. Wenn Sie beispielsweise einen Snapshot eines 1 TB großen Laufwerks erstellen, das zu 85% belegt ist, kann es 5 Minuten dauern, bis der Snapshot fertig ist. Wenn Sie jedoch einen Snapshot eines 100 TB-Laufwerks erstellen, das zu 85% belegt ist, kann dies 11 Minuten dauern. Google empfiehlt, vor Beginn der Migration Test-Snapshots Ihrer Laufwerke zu erstellen, um zu sehen, wie lange das Erstellen von Snapshots dauert.

gcloud

Option 1: Neue N4-VM mit Snapshots von Laufwerken erstellen:

Beenden Sie die VM mit gcloud compute instances stop:
```
gcloud compute instances stop VM_NAME \
  --zone=ZONE
```
Ersetzen Sie Folgendes:
- VM_NAME Der Name Ihrer aktuellen n1-standard-8-VM.
- ZONE: Die Zone, in der sich die VM befindet.
Erstellen Sie Snapshots Ihrer Laufwerke. Verwenden Sie den Befehl gcloud compute snapshots create, um einen Snapshot des Persistent Disk-Bootlaufwerks und des an die VM angehängten Datenlaufwerks zu erstellen.
```
gcloud compute snapshots create SNAPSHOT_NAME \
    --source-disk=SOURCE_DISK_NAME \
    --source-disk-zone=SOURCE_DISK_ZONE
```
Ersetzen Sie Folgendes:
- SNAPSHOT_NAME: Der Name des Snapshots, den Sie erstellen möchten.
- SOURCE_DISK_NAME: Der Name des Quelllaufwerks.
- SOURCE_DISK_ZONE: Die Zone des Quelllaufwerks.
Erstellen Sie ein neues Hyperdisk Balanced-Laufwerk für das Datenlaufwerk, indem Sie den vorherigen Schritt wiederholen und die Informationen zum Datenlaufwerk anstelle des Bootlaufwerks angeben. gcloud compute disks create:
```
gcloud compute disks create DISK_NAME \
    --project=PROJECT_NAME \
    --type=DISK_TYPE \
    --size=DISK_SIZE \
    --zone=ZONE \
    --source-snapshot=SNAPSHOT_NAME \
    --provisioned-iops=PROVISIONED_IOPS \
    --provisioned-throughput=PROVISIONED_THROUGHPUT
```
Ersetzen Sie Folgendes:
- DISK_NAME: Der Name des neuen Laufwerks, das Sie aus dem Laufwerk-Snapshot erstellen.
- PROJECT_NAME ist der Name Ihres Projekts.
- DISK_TYPE: Der neue Laufwerkstyp. In diesem Beispiel ist es ein abgestimmtes Hyperdisk-Laufwerk.
- DISK_SIZE: Die Größe des Laufwerks (Beispiel: 100GB).
- ZONE: Die Zone, in der sich das neue Laufwerk befindet.
- SNAPSHOT_NAME: Der Name des Quelllaufwerks des Snapshots.
- Optional: PROVISIONED_IOPS: Die IOPS-Leistung für das Laufwerk (Beispiel: 3600).
- Optional: PROVISIONED_THROUGHPUT: Die Durchsatzleistung, die für das Laufwerk bereitgestellt werden soll (Beispiel: 290).
Wiederholen Sie den vorherigen Schritt für jeden Snapshot-Datenträger.
Erstellen Sie die n4-standard-8-VM und hängen Sie die Hyperdisk Balanced-Laufwerke mit dem Befehl gcloud compute instances create an:
```
gcloud compute instances create VM_NAME \
    --project=PROJECT_NAME \
    --zone=ZONE \
    --machine-type=NEW_MACHINE_TYPE \
    --boot-disk-device-name=BOOT_DISK_NAME \
    --disk=name=NON_BOOT_DISK_NAME, boot=no \
    --network-interface=nic-type=GVNIC
```
Ersetzen Sie Folgendes:
- VM_NAME: Der Name der neuen VM-Instanz.
- PROJECT_NAME ist der Name Ihres Projekts.
- ZONE: Die Zone, in der sich die neue VM befindet.
- NEW_MACHINE_TYPE: Der Maschinentyp. In diesem Beispiel ist es n4-standard-8.
- BOOT_DISK_NAME Der Name des Hyperdisk Balanced-Bootlaufwerks, das Sie aus dem Snapshot des Quelllaufwerks erstellt haben, das an die n1-standard-8-VM angehängt ist.
- NON_BOOT_DISK_NAME: Der Name des Hyperdisk Balanced-Datenlaufwerks, das Sie aus dem Quell-Snapshot-Laufwerk erstellt haben, das an die n1-standard-8-VM angehängt ist.
Starten Sie die n4-standard-8-VM mit dem Befehl gcloud compute instances start:
```
gcloud compute instances start VM_NAME
```
Ersetzen Sie VM_NAME durch den Namen der neuen VM.

Option 2: Direktes Upgrade des Computers durchführen:

Diese Option ist nur verfügbar, wenn Ihre N1-VM die gvnic-Netzwerkschnittstelle verwendet, das Betriebssystem einen NVMe-Speichergerätetreiber hat, keine lokalen SSD-Laufwerke oder GPUs angehängt sind und die VM nicht Teil einer verwalteten Instanzgruppe (Managed Instance Group, MIG) ist. Wenn Sie dieses Verfahren mit einer N1-VM mit einer VirtIO-Netzwerkschnittstelle ausführen, wird der Fehler VM-Inkompatibilität generiert.

Beenden Sie die VM.
Trennen Sie die Laufwerke von der VM.
Erstellen Sie einen Snapshot des Boot- und des Datenlaufwerks.
Hyperdisk Balanced-Boot- und ‑Datenlaufwerke erstellen: Verwenden Sie einen Laufwerk-Snapshot als Quelle für jedes Laufwerk.
Legen Sie den Maschinentyp auf eine N4-VM fest.
Hängen Sie das abgestimmte Hyperdisk-Bootlaufwerk und das abgestimmte Hyperdisk-Datenlaufwerk an.
Starten Sie die N4-VM.

REST

Option 1: Neue N4-VM mit Snapshots von Laufwerken erstellen:

Beenden Sie die VM mit der Methode instances.stop:
```
 POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instances/VM_NAME/stop
```
Ersetzen Sie Folgendes:
- PROJECT_NAME: die Projekt-ID
- ZONE: Die Zone mit der VM.
- VM_NAME: Der Name Ihrer aktuellen n1-standard-8-VM.
Erstellen Sie mit der disks.createSnapshot-Methode Snapshots Ihrer Laufwerke, um einen Snapshot des Bootlaufwerks und des Datenlaufwerks des nichtflüchtigen Speichers zu erstellen, die an die Instanz angehängt sind.
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/disks/DISK_NAME/createSnapshot
```
Geben Sie im Text der Anfrage den Namen für den neuen nichtflüchtigen Speicher an, von dem Sie einen Snapshot erstellen.

Beispiel:
```
{
    "name": "SNAPSHOT_NAME"
}
```
Ersetzen Sie Folgendes:
- PROJECT_NAME ist der Name Ihres Projekts.
- ZONE: Die Zone, in der sich das Laufwerk befindet.
- DISK_NAME: Das Laufwerk, für das Sie einen Snapshot erstellen möchten.
- SNAPSHOT_NAME: Ein Name für den Snapshot, z. B. hdb-boot-disk oder hdb-data-disk.
Erstellen Sie ein Hyperdisk Balanced-Laufwerk mit der Methode „disks.insert“. Sie führen diesen Schritt zweimal aus: einmal, um die name Ihres Hyperdisk Balanced-Bootlaufwerks einzuschließen, und ein zweites Mal, um die name Ihrer Datenlaufwerke einzuschließen. Verwenden Sie die sourceSnapshot für die neuen abgestimmten Hyperdisk-Boot- und ‑Datenlaufwerke, die type des Laufwerks, Hyperdisk Balanced, und die sizeGB des Laufwerks im Anfragebody.
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONEdisks
```
Ersetzen Sie Folgendes:
- PROJECT_NAME ist der Name Ihres Projekts.
- ZONE: Die Zone, in der sich das Laufwerk befindet.
Geben Sie im Anfragetext Folgendes an:

Beispiel:
```
{
    "name": "my-hdb-boot-disk" or "my-hdb-data-disk",
    "sourceSnapshot": "projects/your-project/global/snapshots/SNAPSHOT_NAME",
    "type": "projects/your-project/zones/us-central1-a/diskTypes/hyperdisk-balanced",
    "sizeGb": "100"
}'
```

Verwenden Sie die Methode instances.insert, um die neue N4-VM zu erstellen.


POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instances

Ersetzen Sie Folgendes:

PROJECT_NAME ist der Name Ihres Projekts.
ZONE: Die Zone, in der sich das Laufwerk befindet.

Geben Sie im Anfragetext Folgendes an:


  {
    "machineType":"projects/your-project/zones/us-central1-a/machineTypes/n4-standard-8" "name":"VM_NAME",
    "disks": [
      {
        "boot": true,
        "deviceName": "my-hdb-boot-disk",
        "source": "projects/your-project/zones/us-central1-a/disks/my-hdb-boot-disk",
        "type": "PERSISTENT"
      },

      {
        "boot": false,
        "deviceName": "my-hdb-data-disk",
        "source": "projects/your-project/zones/us-central1-a/disks/my-hdb-data-disk",
        "type": "PERSISTENT"
      }
      ],
        "networkInterfaces":[
          {
            "network":"global/networks/NETWORK_NAME",
            "subnetwork":"regions/REGION/subnetworks/SUBNET_NAME",
            "nicType": "GVNIC"
          }
       ]
     }

Ersetzen Sie Folgendes:

VM_NAME: der Name der VM
NETWORK_NAME: Der Name des Netzwerks.
REGION: Der Name der Region.
SUBNET_NAME: Der Name des Subnetzes.

Starten Sie die VM mit der Methode instances.start:
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instances/VM_NAME/start
```
Ersetzen Sie Folgendes:
- PROJECT_NAME ist der Name Ihres Projekts.
- ZONE: Die Zone, in der sich Ihre VM befindet.
- VM_NAME: der Name der VM

Option 2: Direktes Upgrade des Computers durchführen:

Diese Option ist nur verfügbar, wenn Ihre N1-VM die Netzwerkschnittstelle gvnic verwendet, keine angehängten lokalen SSD-Festplatten oder GPUs hat und nicht Teil einer verwalteten Instanzgruppe (Managed Instance Group, MIG) ist. Wenn Sie dieses Verfahren mit einer N1-VM mit einer VirtIO-Netzwerkschnittstelle ausführen, wird der Fehler VM-Inkompatibilität generiert.

Beenden Sie die VM mit der Methode instances.stop.
Trennen Sie die Laufwerke mit der Methode „instances.detachDisk“, um das ursprüngliche Bootlaufwerk des nichtflüchtigen Speichers von der N1-VM zu trennen. Außerdem müssen Sie alle Datenlaufwerke von der VM trennen.
```
https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instances/VM_NAME/detachDisk?deviceName=DISK_NAME
```
Ersetzen Sie Folgendes:
- PROJECT_NAME ist der Name Ihres Projekts.
- ZONE: Die Zone, in der sich das Laufwerk befindet.
- VM_NAME: Der Name der Quell-VM, an die das Laufwerk pd-ssd angehängt ist.
- DISK_NAME: Das Laufwerk, das Sie trennen möchten.
Erstellen Sie Snapshots der Laufwerke. Verwenden Sie die disks.createSnapshot-Methode, um einen Snapshot des Bootlaufwerks und der Datenlaufwerke des nichtflüchtigen Speichers zu erstellen, die an die Instanz angehängt sind.
Erstellen Sie ein Hyperdisk Balanced-Boot- und -Datenlaufwerk mit der Methode „disks.insert“. Fügen Sie den name Ihres Hyperdisk Balanced-Laufwerks, sourceSnapshot für das neue Hyperdisk Balanced-Laufwerk, den type des Laufwerks, Hyperdisk Balanced, und den sizeGB des Laufwerks im Anfragebody ein.
Führen Sie ein In-Place-Upgrade des Maschinentyps mit der Methode „instances.setMachineType“ durch. Fügen Sie dazu machineType in den Anfragetext ein:
```
POST  https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONEinstances/VM_NAME/setMachineTypeMACHINE_TYPE
```
Ersetzen Sie Folgendes:
- PROJECT_NAME ist der Name Ihres Projekts.
- ZONE: Die Zone, in der sich das Laufwerk befindet.
- VM_NAME: Der Name der zu aktualisierenden VM.
- MACHINE_TYPE: Der neue Maschinentyp.
Geben Sie im Anfragetext Folgendes an:
```
{
 "machineType": "projects/PROJECT_NAME/zones/ZONE/machineTypes/MACHINE_TYPE",
}
```
Verwenden Sie die instances.attachDisk-Methode, um das neue Hyperdisk Balanced-Bootlaufwerk und die Hyperdisk Balanced-Datenlaufwerke an die N4-VM anzuhängen.
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instancesVM_NAMEattachDiskDISK_NAME
```
Ersetzen Sie Folgendes:
- PROJECT_NAME ist der Name Ihres Projekts.
- ZONE: Die Zone, in der sich das Laufwerk befindet.
- VM_NAME: Der Name der Quell-VM-Instanz, an die das pd-ssd-Laufwerk angehängt ist.
- DISK_NAME Das Laufwerk, das Sie anhängen möchten.
Geben Sie im Anfragetext Folgendes an:
```
{
"source": "projects/your-project/zones/us-central1-a/disks/my-hdb-boot-disk",
"deviceName":"my-hdb-boot-disk","boot":true
}
```
```
{
"source": "projects/your-project/zones/us-central1-a/disks/my-hdb-data-disk",
"deviceName":"my-hdb-data-disk","boot":false
}
```
Starten Sie die N4-VM mit der Methode „instances.start“.
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONEinstances/VM_NAME/start
```
Ersetzen Sie Folgendes:
- PROJECT_NAME ist der Name Ihres Projekts.
- ZONE: Die Zone, in der sich das Laufwerk befindet.
- VM_NAME: der Name der VM

Bereinigen

Nachdem Sie bestätigt haben, dass Sie eine Verbindung zur neuen VM herstellen können und dass Ihre Arbeitslast wie erwartet auf der neuen VM ausgeführt wird, können Sie die nicht mehr benötigten Ressourcen entfernen:

Die Snapshots, die Sie für die Laufwerke erstellt haben, die an die Quell-VM angehängt sind.
Alle Snapshot-Zeitpläne für die Laufwerke, die an die Quell-VM angehängt waren.
Das temporäre Laufwerk, das zum Kopieren der lokalen SSD-Daten auf die neue VM erstellt wurde.
Die Quell-VM und alle angehängten Laufwerke.

Nächste Schritte

Bekannte Probleme bei Linux- und Windows-Servern
Lesen Sie die Tipps zur Fehlerbehebung
Weitere Informationen zum Migrationslebenszyklus

Arbeitslast auf eine neue Compute-Instanz verschieben Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweise

Console

gcloud

REST

Erforderliche Rollen

Erforderliche Berechtigungen

VM-Migrationsoptionen bewerten

Computing-Anforderungen

Speicherbedarf

Netzwerkanforderungen

Umzug vorhandener VMs vorbereiten

Compute-Ressourcen vorbereiten

Speicherressourcen vorbereiten

Netzwerkressourcen vorbereiten

Betriebssystem SUSE Enterprise Linux Server vorbereiten

Arbeitslast auf die neue VM verschieben

Erforderliche Berechtigungen für diese Aufgabe

Neue VM erstellen

Nach dem Start der Instanz

Beispiel für die Migration von n1-standard-8 zu n4-standard-8

gcloud

REST

Bereinigen

Nächste Schritte

Arbeitslast auf eine neue Compute-Instanz verschieben