Diese Seite wurde von der Cloud Translation API übersetzt.

Arbeitslast auf eine neue Compute-Instanz verschieben

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

Mit den neuen Maschinentypen können Sie schnellere Speicher- oder Netzwerkgeschwindigkeiten nutzen. Beispielsweise ein Upgrade von C2 auf H3 für eine verbesserte Netzwerkbandbreite.
Sie profitieren von einem besseren Preis-Leistungs-Verhältnis im Vergleich zur Quell-VM-Instanz. Beispiel: Sie können von N1 auf N4 umstellen, um den Intel Xeon-Prozessor der 5. Generation zu einem besseren Preis zu nutzen.
Funktionen nutzen, die nur auf der neuen VM-Instanz verfügbar sind. Beispielsweise können Sie von N4 auf C4 umstellen, um zusätzliche Optionen für Leistung und Wartung zu nutzen.
Eine 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 Maschinenreihe der neuesten Generation durchführen, können Sie möglicherweise das einfachere Verfahren verwenden, das unter Maschinentyp einer Compute-Instanz bearbeiten beschrieben wird, wenn die folgende Bedingungen von der aktuellen VM (Quell-VM) erfüllt sind:

Die Betriebssystemversion wird von der neuen Maschinenreihe unterstützt.
Der Laufwerktyp des an die Quell-VM angeschlossenen Bootlaufwerks wird von der neuen Maschinenreihe 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 Maschinenreihe 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 bei Compute Engine authentifizieren. Wählen Sie dazu eine der folgenden Optionen aus:

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
1. Install the Google Cloud CLI, then initialize it by running the following command:
  gcloud init
  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
2. Set a default region and zone.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, um die Berechtigungen zum Bearbeiten oder Ändern einer VM zu 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 nehmen Sie Änderungen am Netzwerktyp vor:
- 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 mit dem Gastbetriebssystem der Quelle und der neuen Maschinenserie.

Rechenanforderungen

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

In der Dokumentation zur Ressource „Maschinenfamilie“ finden Sie Informationen dazu, welche Maschinentypen für Ihre Arbeitslast geeignet sind. Überlegen Sie, ob für Ihre Anwendung spezielle Hardware (GPUs), eine hohe Leistung oder niedrigere Kosten erforderlich sind.
Sehen Sie sich die Funktionen der vom neuen Maschinentyp unterstützten Laufwerkstypen an. Die meisten, aber nicht alle Funktionen von Persistent Disk werden von Hyperdisk unterstützt. Hyperdisk bietet jedoch zusätzliche Funktionen, die mit Persistent Disk nicht verfügbar sind.
Sehen Sie sich die Funktionen der gewünschten Maschinenreihe an. Die neue Maschinenreihe unterstützt möglicherweise nicht dieselben Funktionen wie Ihre aktuelle Maschinenreihe, z. B. benutzerdefinierte Maschinentypen, lokale SSDs oder Shielded VM.
Prüfen Sie die Regionen und Zonen, um sicherzustellen, dass die neue Maschinenreihe in allen Regionen wie 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 für die neue VM eine neuere Version des Betriebssystems erforderlich ist, 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 bzw. der Ihre Anwendungen ausgeführt werden sollen, und prüfen Sie, ob Ihre Anwendungen mit dem neuen Betriebssystem kompatibel sind.
Es ist möglich, von einer C3-VM-Instanz zu einer C3-Bare-Metal-Instanz zu migrieren, 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 jedoch auch jedes C3 Metal-unterstützte Betriebssystem ausführen, solange der IDPF-Treiber aktiviert ist. Bare-Metal-Instanzen verwenden die IDPF-Netzwerkschnittstelle, die nur als physische Funktion und nicht als virtuelle Funktion dargestellt wird.

Speicherbedarf

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

Prüfen Sie die unterstützten Speichertypen und die unterstützten Speicherschnittstellen für die neue Maschinenreihe.
- Standardmäßig verwenden Maschinenreihen der ersten und zweiten Generation nur den Speichertyp „Persistent Disk“ und die VirtIO-SCSI-Schnittstellen.
- Maschinen der dritten Generation und neuer (z. B. M3, C3 und N4) unterstützen nur die NVMe-Schnittstelle. Einige unterstützen nur Hyperdisk und lokale SSD-Speichertypen.
- Bare-Metal-Instanzen (z. B. C3 und X4) unterstützen nur Hyperdisk.
Laufwerkkompatibilität:
- Wenn das Bootlaufwerk einen Laufwerktyp verwendet, der von der neuen Maschinenreihe 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 dem Quell-Boot-Laufwerk gehen verloren, es sei denn, Sie kopieren sie auf ein temporäres Laufwerk, das nicht als Boot-Laufwerk verwendet wird. Als Nächstes erstellen Sie ein neues Bootlaufwerk und kopieren die auf dem temporären Nicht-Bootlaufwerk gespeicherten Daten auf das neue Bootlaufwerk.
- Wenn Sie die Betriebssystemversion nicht aktualisieren, können Sie einen Snapshot Ihres aktuellen Bootlaufwerks erstellen und 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 Laufwerktyp verwendet, der von der neuen Maschinenreihe nicht unterstützt wird, können Sie mit einem Snapshot das Quelllaufwerk in einen neuen Laufwerktyp ändern, wie unter Laufwerktyp ändern beschrieben.
Lokale SSD-Laufwerke können nicht auf eine neue VM verschoben werden. Sie können ein Laufwerk an Ihre aktuelle VM anhängen, das groß genug ist, um alle Daten des lokalen SSD zu speichern. Verwenden Sie dann einen Snapshot, um das Quelllaufwerk in 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 wieder auf die lokalen SSD-Laufwerke kopieren.
Wenn Ihre aktuelle VM-Instanz Laufwerke in einem Speicherpool verwendet, Sie Ihre Arbeitslast aber 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 Maschinenreihe eine andere Laufwerkschnittstelle verwendet (z. B. NVMe anstelle von SCSI), unterscheiden sich die Laufwerkgerätenamen im Gastbetriebssystem. Achten Sie darauf, dass in Ihren Anwendungen und Scripts entweder nichtflüchtige Gerätenamen oder Symlinks verwendet werden, wenn auf die angeschlossenen Laufwerke verwiesen wird.

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 (z. B. M3, C3 und N4) unterstützen nur die gVNIC-Netzwerkschnittstelle.
- Bare-Metal-Instanzen unterstützen nur die IDPF-Netzwerkschnittstelle.
Achten Sie darauf, dass 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. In diesem Fall müssen Sie die IP-Adressen in statische IP-Adressen umwandeln.
Wenn Sie die Netzwerkleistung der VM_Tier_1 für Ihre aktuelle VM verwenden, prüfen Sie, ob diese Funktion für die neue Maschinenreihe verfügbar oder erforderlich ist. Sie können beispielsweise Tier_1-Netzwerke mit einem C2-Maschinentyp verwenden, bei einer H3-VM ist dies jedoch nicht erforderlich.

Um den Netzwerkschnittstellentyp Ihrer aktuellen VM zu ermitteln, verwenden Sie den Befehl gcloud compute instances describe, um die nic-type der VM aufzurufen:

  gcloud compute instances describe VM_NAME --zone=ZONE

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

Vorhandene VMs für den Umzug vorbereiten

Nachdem Sie den Abschnitt zur Bewertung abgeschlossen haben, müssen Sie Ihre VM-Instanzen verschieben. Dazu müssen Sie Ressourcen für die neue VM-Instanz anfordern und Sicherungen der Quell-VM-Instanz vorbereiten.

Rechenressourcen vorbereiten

Führen Sie die folgenden Schritte aus, um die Migration Ihrer aktuellen Instanz zu einer neuen Instanz vorzubereiten:

Fordern Sie ein Kontingent in der Region und den Zonen an, in die Sie Ihre Ressourcen verschieben möchten. Wenn Sie bereits ein Kontingent für einen Maschinentyp haben, können Sie eine Verschiebung dieses Kontingents beantragen. 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. Informieren Sie sich darüber, wie reservierte Ressourcen verbraucht werden, und testen Sie, ob Sie reservierte Ressourcen verbrauchen können.
Erweitern Sie Ihre Pläne für Hochverfügbarkeit und Notfallwiederherstellung auf die neue Region.
Aktualisieren Sie bei Bedarf das Betriebssystem auf der aktuellen VM.
1. Führen Sie, sofern vom Betriebssystemanbieter unterstützt, ein In-Place-Upgrade Ihres Betriebssystems auf eine Version durch, die von der neuen Maschinenreihe unterstützt wird. Prüfen Sie dann, ob Ihre Arbeitslast unter der neuen Betriebssystemversion wie erwartet funktioniert.
2. Wenn ein In-Place-Upgrade des Betriebssystems nicht unterstützt wird, müssen Sie beim Erstellen einer neuen VM ein neues Bootlaufwerk erstellen. Legen Sie fest, welche Informationen Sie vom aktuellen Bootlaufwerk kopieren müssen, und kopieren Sie sie an einen temporären Speicherort auf einem Laufwerk ohne Startfunktion, damit sie auf die neue VM übertragen werden können. Wenn Sie Ihrer aktuellen VM keine Nicht-Bootlaufwerke angeschlossen haben:
  - 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 unter /etc/udev/rules.d/ die udev-Regeln, falls für Ihre Linux-Distribution zutreffend. Diese Datei kann Einträge enthalten, die für die Hardwarekonfiguration der aktuellen Instanz relevant sind, aber nicht für die neue Instanz. Mit dem folgenden Eintrag wird beispielsweise sichergestellt, dass eth0 vom virtio-pci-Treiber (VirtIO Net) bereitgestellt wird. Dadurch wird verhindert, dass der gve-Treiber (gVNIC) diese Schnittstelle bereitstellt. Dies kann zu Netzwerkstartskripts und Verbindungsproblemen 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 mit Ihrer aktuellen Instanz verbunden sind, auf eine neue Instanz umzuverarbeiten:

Testen Sie auf Linux-Systemen Ihre aktualisierten Anwendungen und Scripts, um sicherzustellen, dass sie mit nichtflüchtigen Gerätenamen oder Symlinks statt mit den 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, damit der Microsoft NVMe-Treiber (StorNVMe) verwendet wird. Folgen Sie der Anleitung, um Ihr Bootgerät zu aktualisieren.
Wenn Ihre neue VM nicht dieselben Laufwerktypen wie Ihre aktuelle VM unterstützt, müssen Sie möglicherweise Ihre Bereitstellungsscripts oder Instanzvorlagen aktualisieren, um die neue Maschinenreihe zu unterstützen.
Wenn Ihre aktuelle VM einen Laufwerktyp für das Bootlaufwerk verwendet, der von der neuen Maschinenreihe nicht unterstützt wird, und Sie mehrere VMs mit derselben Konfiguration migrieren, erstellen Sie ein benutzerdefiniertes Image, das beim Erstellen der neuen VMs verwendet werden soll:
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 auf lokalen SSDs verschieben möchten, erstellen Sie ein leeres Laufwerk, das groß genug ist, um Ihre lokalen SSDs 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 VM 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 bereit.
4. Kopieren Sie die Daten von den lokalen SSDs, die an die aktuelle VM angehängt sind, auf dieses temporäre Laufwerk.
Ändern Sie den Laufwerkstyp aller Laufwerke, die mit der aktuellen VM verbunden sind und einen Laufwerkstyp verwenden, der von der neuen VM nicht unterstützt wird. Wenn Sie die Laufwerkdaten 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 nicht erfasst. Da Snapshots inkrementell sind, können Sie nach dem Beenden der VM einen zweiten Snapshot erstellen, um alle letzten Änderungen zu erfassen. Mit diesem Ansatz sollte die Zeit, in der die VM nicht verfügbar ist, während Sie zu einer neuen VM wechseln, minimiert werden.
2. Alternativ können Sie alle Laufwerk-Snapshots erstellen, nachdem Sie die VM gestoppt haben. Wir empfehlen, einen Snapshot aller an Ihre VM angeschlossenen Laufwerke zu erstellen, auch wenn der Laufwerkstyp von der neuen Maschinenreihe unterstützt wird. Geben Sie alle temporären Laufwerke an, die die kopierten lokalen SSD-Daten enthalten.
3. Wie lange es dauert, einen Snapshot eines Laufwerks zu erstellen, hängt von mehreren Faktoren ab, z. B. von der Laufwerksgröße und der Datenmenge auf dem Laufwerk. Wenn Sie beispielsweise einen Snapshot eines 1-TiB-Laufwerks erstellen, das zu 85% belegt ist, kann es fünf Minuten dauern, bis der Vorgang abgeschlossen ist. Wenn Sie jedoch einen Snapshot eines 100 TiB großen Laufwerks erstellen, das zu 85% belegt ist, kann das bis zu 11 Minuten dauern. Wir empfehlen Ihnen, vor Beginn der Migration Test-Snapshots Ihrer Laufwerke zu erstellen, um zu erfahren, wie lange das Erstellen von Snapshots dauert.
Wenn Sie ein Laufwerk haben, das offline geschaltet werden kann, können Sie die Daten mit der folgenden Methode auf ein neues Laufwerk verschieben, während die Quell-VM noch verfügbar ist:
1. Trennen Sie das Laufwerk von der VM.
2. Erstellen Sie einen Snapshot des Laufwerks.
3. Verwenden Sie den Snapshot, um ein neues Laufwerk mit einem Laufwerktyp zu erstellen, der von der neuen Maschinenreihe unterstützt wird. Das neue Laufwerk muss entweder dieselbe Größe haben oder größer sein als das Quelllaufwerk.

Netzwerkressourcen vorbereiten

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

Wenn Ihre aktuelle VM keine gVNIC verwendet, müssen Sie eine neue Instanz mit einer Netzwerkschnittstelle erstellen, die gVNIC verwendet. In der Übersicht über die Verwendung von gVNIC mit Compute Engine-VMs erfahren Sie, welche Schritte Sie beim Erstellen einer neuen Instanz ausführen müssen.
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

Erstellen Sie das initramfs (Initial RAM-Dateisystem) neu, um hardwarespezifische Abhängigkeiten zu vermeiden. Dazu gehört ein breiteres Spektrum an Treibern und Modulen, wodurch das Betriebssystem mit anderen Instanztypen kompatibel ist. Andernfalls tritt das bekannte Problem auf, das verhindert, dass die VM richtig gestartet wird.

Führen Sie vor dem Herunterfahren des Systems 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, ist der nächste Schritt, Ihre Arbeitslast auf die neue VM zu verschieben.

Wenn Sie Ihre VMs von der ersten Generation in die Maschinenreihe der zweiten Generation verschieben, lesen Sie die Anleitung auf der Seite Maschinentyp einer VM bearbeiten. Wenn Sie den Namen einer vorhandenen VM ändern möchten, lesen Sie den Hilfeartikel 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. Dabei 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-Boot-Laufwerke mit einem Laufwerktyp verwendet, der von der neuen Maschinenreihe 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 ausgewählten Maschinenserie aus.
- Wählen Sie ein unterstütztes Betriebssystem-Image aus oder verwenden Sie ein zuvor erstelltes benutzerdefiniertes Image.
- Wählen Sie einen unterstützten Laufwerkstyp für das Bootlaufwerk aus.
- Wenn Sie neue Laufwerke aus Snapshots der ursprünglichen Laufwerke erstellt haben, schließen Sie diese neuen Laufwerke ein.
- 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 zugewiesen 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 von der neuen VM nicht unterstützten Laufwerktyp verwenden, 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 für die ursprünglichen Laufwerke, die für die neue VM neu erstellt wurden, eine Ressourcenrichtlinie verwendet wurde, 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 von lokalen SSD-Laufwerken auf ein temporäres Laufwerk verschoben haben und an die neue VM ein lokales SSD-Speichergerät angehängt ist, können Sie die Daten nach dem Formatieren und Bereitstellen der Laufwerke vom temporären Laufwerk auf die lokalen SSD-Laufwerke verschieben.
Weisen Sie der neuen VM alle statischen IP-Adressen zu, die der Quell-VM zugeordnet sind.
Führen Sie alle zusätzlichen Aufgaben aus, die erforderlich sind, um die Verfügbarkeit Ihrer neuen VM zu erhöhen, z. B. die Konfiguration von Load Balancern und das Aktualisieren der Weiterleitungsregeln.
Optional: Aktualisieren Sie bei Bedarf die DNS-Einträge für die neue VM.
Empfohlen: Planen Sie Laufwerksicherungen für die neuen Laufwerke.
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

Im folgenden Beispiel wird eine n1-standard-8-VM zu einer n4-standard-8-VM migriert. Die n1-standard-8-VM hat ein PD-SSD-Bootlaufwerk mit einem Ubuntu1804-Image und ein PD-SSD-Datenlaufwerk. Verwenden Sie für diesen Vorgang die Befehlszeile oder die REST API.

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

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 auf dem nichtflüchtigen Speicher, erstellen aus diesen Snapshots Hyperdisk Balanced-Laufwerke, binden 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 aus dem Snapshot des Bootlaufwerks ein neues Hyperdisk-Balanced-Laufwerk erstellen, das Sie aber als Nicht-Bootlaufwerk an die N4-VM anhängen. Anschließend können Sie nicht systemeigene Daten 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 SSDs oder GPUs angeschlossen sind und die VM nicht Teil einer verwalteten Instanzgruppe (Managed Instance Group, MIG) ist, können Sie den Maschinentyp von N1 in N4 ändern. Sie müssen jedoch die Persistent Disk-Laufwerktypen in Hyperdisk Balanced-Laufwerke ändern. Sie müssen zuerst die Boot- und Datenlaufwerke des nichtflüchtigen Speichers trennen, Snapshots der Laufwerke erstellen, Hyperdisk Balanced-Laufwerke mit den Snapshots als Quelle erstellen und dann die neuen Hyperdisk Balanced-Laufwerke an Ihre N4-VM anhängen, nachdem Sie den Maschinentyp geändert haben. Wenn Ihrer VM GPUs zugeordnet sind, müssen Sie sie 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 TBs auf einem Laufwerk. Wenn Sie beispielsweise einen Snapshot eines 1-TB-Laufwerks erstellen, das zu 85% belegt ist, kann es fünf Minuten dauern, bis der Snapshot erstellt ist. Wenn Sie jedoch einen Snapshot eines 100-TB-Laufwerks erstellen, das zu 85% belegt ist, kann der Vorgang 11 Minuten dauern. Google empfiehlt, Test-Snapshots Ihrer Laufwerke vor Beginn des Migrationsvorgangs zu erstellen, um zu erfahren, wie lange das Erstellen von Snapshots dauert.

gcloud

Option 1: Neue N4-VM mit Snapshot-Laufwerken erstellen:

Beenden Sie die VM mit dem Befehl 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 sowohl des nichtflüchtigen Bootlaufwerks als auch des Datenlaufwerks zu erstellen, das mit der VM verbunden ist.
```
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. Wiederholen Sie dazu den vorherigen Schritt und geben Sie die Informationen zum Datenlaufwerk anstelle des Bootlaufwerks an. 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 Snapshot-Laufwerk erstellen.
- PROJECT_NAME ist der Name Ihres Projekts.
- DISK_TYPE: Der neue Laufwerktyp. In diesem Beispiel ist es ein abgestimmtes Hyperdisk-Laufwerk.
- DISK_SIZE: Die Größe des Laufwerks (Beispiel: 100GB).
- ZONE ist die Zone, in der sich das neue Laufwerk befindet.
- SNAPSHOT_NAME: Der Name des Quelllaufwerks für den Snapshot.
- Optional: PROVISIONED_IOPS: Die IOPS-Leistung des Laufwerks (Beispiel: 3600).
- Optional: PROVISIONED_THROUGHPUT: Die Durchsatzleistung für die Bereitstellung des Laufwerks (Beispiel: 290).
Wiederholen Sie den vorherigen Schritt für alle Laufwerke, für die Snapshots erstellt wurden.
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 n4-standard-8.
- BOOT_DISK_NAME: Name des Hyperdisk Balanced-Bootlaufwerks, das Sie aus dem Snapshot des Quelllaufwerks erstellt haben, der an die VM n1-standard-8 angehängt ist.
- NON_BOOT_DISK_NAME: Der Name des Hyperdisk Balanced-Datenlaufwerks, das Sie aus dem Quell-Snapshot-Laufwerk erstellt haben, das mit der VM n1-standard-8 verbunden ist.
Starten Sie die VM n4-standard-8 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 ausfü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 angeschlossen 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 ausgegeben.

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

REST

Option 1: Neue N4-VM mit Snapshot-Laufwerken erstellen:

Beenden Sie die VM mithilfe 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 Methode disks.createSnapshot Snapshots Ihrer Laufwerke, um einen Snapshot sowohl des nichtflüchtigen Bootlaufwerks als auch des Datenlaufwerks zu erstellen, das mit der Instanz verbunden ist.
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/disks/DISK_NAME/createSnapshot
```
Geben Sie im Text der Anfrage den Namen des neuen nichtflüchtigen Speichers an, für den ein Snapshot erstellt wurde.

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 einzubeziehen, und ein zweites Mal, um die name Ihrer Datenlaufwerke einzubeziehen. Verwenden Sie die sourceSnapshot für die neuen Hyperdisk Balanced-Boot- und Datenlaufwerke, die type des Laufwerks, „Hyperdisk Balanced“ und die sizeGB des Laufwerks im Anfragetext.
```
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 mithilfe 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 ausführen:

Diese Option ist nur verfügbar, wenn Ihre N1-VM die gvnic-Netzwerkschnittstelle verwendet, keine lokalen SSD-Laufwerke oder GPUs angeschlossen 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 ausgegeben.

Beenden Sie die VM mithilfe der Methode „instances.stop“.
Trennen Sie die Laufwerke mit der Methode instances.detachDisk, um das ursprüngliche nichtflüchtige Bootlaufwerk 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 Methode disks.createSnapshot, um einen Snapshot sowohl des Persistent Disk-Bootlaufwerks als auch der Datenlaufwerke zu erstellen, die an die Instanz angehängt sind.
Erstellen Sie mit der Methode „disks.insert“ ein abgestimmtes Hyperdisk-Boot- und Datenlaufwerk. Geben Sie die name Ihres abgestimmten Hyperdisk-Laufwerks, sourceSnapshot für das neue abgestimmte Hyperdisk-Laufwerk, die type des Laufwerks, „Hyperdisk Balanced“ und sizeGB des Laufwerks im Anfragetext an.
Führen Sie ein In-Place-Upgrade des Maschinentyps mit der Methode „instances.setMachineType“ durch und geben Sie die machineType im Anfragetext an:
```
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 VM, die aktualisiert werden soll.
- MACHINE_TYPE: Der neue Maschinentyp.
Geben Sie im Anfragetext Folgendes an:
```
{
 "machineType": "projects/PROJECT_NAME/zones/ZONE/machineTypes/MACHINE_TYPE",
}
```
Verwenden Sie die Methode instances.attachDisk, 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 Laufwerk pd-ssd 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 überprüft haben, dass Sie eine Verbindung zur neuen VM herstellen können und 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 Daten des lokalen SSD auf die neue VM erstellt wurde.
Die Quell-VM und alle angehängten Laufwerke.

Nächste Schritte

Informationen zu bekannten Problemen für Linux- und Windows-Server
Lesen Sie die Tipps zur Fehlerbehebung
Weitere Informationen zum Migrationslebenszyklus

Arbeitslast auf eine neue Compute-Instanz verschieben

Hinweise

Console

gcloud

REST

Erforderliche Rollen

Erforderliche Berechtigungen

VM-Migrationsoptionen bewerten

Rechenanforderungen

Speicherbedarf

Netzwerkanforderungen

Vorhandene VMs für den Umzug vorbereiten

Rechenressourcen 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