Arbeitslasten von der ausgemusterten ve1-Hardware migrieren

In diesem Dokument wird beschrieben, wie Sie Ihre Google Cloud VMware Engine-Arbeitslasten von der ausgemusterten ve1-Hardware auf unterstützte ve1- oder ve2-Hardware migrieren. Sie können Arbeitslasten mit einer von zwei Methoden migrieren: Bei Option 1 werden einer vorhandenen privaten Cloud neue Hardwarecluster hinzugefügt, um eine private Cloud mit gemischten Knoten zu erstellen. Bei Option 2 wird eine neue private Cloud mit neuer Hardware bereitgestellt.

Google Cloud stellt die Hardware der ersten Generation ve1 nach und nach ein, da die physische Infrastruktur das Ende ihrer Nutzungsdauer erreicht. Die Außerbetriebnahme erfolgt in Batches basierend auf Placement-Gruppen in verschiedenen Serviceregionen.

Wenn Google Cloud die Hardware für die Außerbetriebnahme plant, erhalten Sie eine gezielte Benachrichtigung zum Ende des Lebenszyklus (End-of-Life, EoL) mit einem detaillierten Zeitplan, Ressourcenlimits und Migrationsanleitungen. Diese gezielten Benachrichtigungen werden ab dem 1. Quartal 2026 eingeführt. Die ersten Chargen von ve1-Hardware erreichen bis zum 1. Quartal 2027 das Ende ihrer Lebensdauer. Wenn Ihre Placement-Gruppe das geplante Außerbetriebnahmedatum erreicht, können Sie Ihre Arbeitslasten auf neuere Hardware migrieren.

In diesem Dokument werden die Details zur EoL-Benachrichtigung und die Schritte zur Migration Ihrer Arbeitslasten beschrieben. Damit der Dienst weiterhin verfügbar ist und das Service Level Agreement (SLA) eingehalten wird, müssen Sie die Migration vor dem EoL-Datum Ihrer Cluster abschließen.

Hinweis

Bevor Sie neue Ressourcen konfigurieren, sollten Sie sich die Anforderungen, Einschränkungen und Faktoren ansehen, die die Migration möglicherweise verhindern. Diese Informationen helfen Ihnen, eine erfolgreiche Migration zu planen und Dienstunterbrechungen zu vermeiden.

Die wichtigsten Anforderungen, die Sie vor Beginn einer Migration berücksichtigen müssen, sind:

  • Strenges 60‑Tage-Migrationszeitfenster:Google unterstützt Ihre Migration maximal 60 Tage nach Genehmigung Ihres Antrags auf das Zielkapazitätskontingent:
    • Sie müssen die Arbeitslastmigration abschließen und die außer Betrieb genommene Hardware innerhalb dieses Zeitraums außer Betrieb nehmen.
    • Wenn die Migration Ihrer Arbeitslast nach der Bereitstellung des Zielclusters länger als 60 Tage dauert, müssen Sie eine eigene Broadcom-Lizenz (BYOL) mitbringen, um den Verbrauch zu decken, der über die Standardberechtigungen hinausgeht.

Folgende Faktoren können eine Migration verhindern:

  • IP-Adressbereichsblocker (Blocker für Option 1): Für Option 1 (Private Cloud mit gemischten Knoten) muss Ihre vorhandene Private Cloud über ausreichend kostenlosen IP-Adressbereich für die Verwaltung verfügen. Sie benötigen genügend Speicherplatz für den zusätzlichen Zielcluster, der mindestens drei Knoten erfordert. Wenn Ihr vorhandener CIDR-Block nicht mindestens drei zusätzliche Knoten unterstützen kann, können Sie Option 1 nicht verwenden. In diesem Fall müssen Sie stattdessen eine neue Private Cloud bereitstellen (Option 2). Unter Kapazität für den IP-Adressbereich planen können Sie prüfen, ob Sie die Voraussetzungen erfüllen.
  • Unterstützung von Datenbanken für die Live-Migration:Einige Datenbankplattformen können keine Live-vMotion-Migrationen tolerieren. Identifizieren Sie diese VM-Datenbankinstanzen und planen Sie, sie direkt im Zielcluster neu zu erstellen.
  • VMware HCX-Verbindung: VMware HCX Fleet-Appliances unterstützen kein standardmäßiges Live-vMotion. Sie müssen die erneute Bereitstellung Ihrer HCX-Servicemeshs im Zielcluster planen. Weitere Informationen finden Sie im Broadcom-Artikel Migrating HCX appliances to a different SSO, PSC, or vCenter.

Kapazität für den IP-Adressbereich planen

Wenn Sie die Migration mit einer privaten Cloud mit gemischten Knoten (Option 1) durchführen, prüfen Sie, ob in Ihrer vorhandenen privaten Cloud genügend Speicherplatz im IP-Adressbereich für die Verwaltung vorhanden ist. Für den hinzugefügten Zielcluster sind mindestens drei Knoten erforderlich.

  1. IP-Adressbereich für die Verwaltung und IP-Planversion Ihrer privaten Cloud ansehen. Weitere Informationen finden Sie unter Versionen der CIDR-Bereichsaufteilung von Subnetzen.
  2. Zählen Sie die aktuelle Anzahl der Knoten in Ihrer privaten Cloud.
  3. Prüfen Sie die maximale Anzahl von Knoten, die von Ihrer CIDR-Größe unterstützt werden. Weitere Informationen finden Sie in der Tabelle CIDR-Bereichsgröße von vSphere-/vSAN-Subnetzen.
  4. Berechnen: Existing node count + 3 ≤ maximum nodes supported by CIDR size

Wenn Ihr CIDR-Block nicht mindestens drei zusätzliche Knoten unterstützen kann, können Sie keine private Cloud mit gemischten Knoten verwenden. In diesem Fall müssen Sie stattdessen eine neue private Cloud bereitstellen (Option 2).

Knotenkapazität planen

Wenn in Ihrem zukünftigen Kapazitätsangebot ve2-Knoten angegeben sind, arbeiten Sie mit Ihrem Google Cloud -Account-Management-Team zusammen, um die richtigen ve2-Knotentypen (mega, large, standard oder small) und die Anzahl für Ihre Arbeitslasten zu ermitteln. Technische Spezifikationen finden Sie unter VMware Engine-HCI-Knotentypen.

Lizenz- und Softwareanforderungen

Beachten Sie die folgenden Lizenz- und Softwareanforderungen für die Migration:

  • Broadcom-Lizenzen: Wenn die Dauer der Migration Ihrer Arbeitslast 60 Tage nach der Bereitstellung des Zielclusters überschreitet, müssen Sie Ihre eigene Broadcom-Lizenz mitbringen, um die Nutzung zu decken, die über Ihre Standardberechtigungen hinausgeht.
  • VMware HCX-Service-Meshs: VMware HCX Fleet-Appliances unterstützen vMotion nicht. Sie müssen Ihre HCX-Service-Meshes im Zielcluster neu bereitstellen. Weitere Informationen finden Sie im Broadcom-Artikel Migrating HCX appliances to a different SSO, PSC, or vCenter.
  • Placement-Gruppen verwalten: Google stellt Kapazität in den richtigen Placement-Gruppen bereit. Bei Setups mit gemischten Knoten richtet Cloud Customer Care den neuen Cluster in der Ziel-Placement-Gruppe ein. Bei neuen privaten Clouds müssen Sie den geplanten Namen der privaten Cloud an Ihr Account-Management-Team senden, bevor Sie die private Cloud erstellen, damit Google sie in der richtigen Placement-Gruppe konfiguriert.

Tarifzusicherungen und Abrechnung

Bevor Sie einen Migrationspfad auswählen, sollten Sie die folgenden Einschränkungen für Rabatte für zugesicherte Nutzung (Committed Use Discounts, CUDs) beachten:

  • ve1-Einschränkungen:Es sind nur einjährige ve1-Rabatte für zugesicherte Nutzung mit Preisoptionen für übertragbare Lizenzen verfügbar. Wenn Sie eine neue einjährige Mindestlaufzeit anwenden möchten, müssen Sie zur neuen ve1-Placement-Gruppe in derselben Region migrieren.
  • ve2-CUD-Support:Dreijährige Zusicherungen für zugesicherte Nutzung werden nur für die ve2-Knotenfamilien unterstützt.
  • Berechtigungsprüfung:Da neue Zusicherungen von der verbleibenden Lebensdauer der Knotengruppen in Ihrer Region abhängen, müssen Sie mit Ihrem Google Cloud Account-Management-Team zusammenarbeiten, um Ihre Berechtigung zu prüfen.

Informationen zur Einstellung des ve1

Die ve1-Benachrichtigung zum End of Life (EoL) ist eine offizielle E-Mail, in der Sie darüber informiert werden, dass die Nutzungsdauer Ihrer ve1-Bare-Metal-Knoten bald abläuft.

Wichtige Komponenten der EoL-Benachrichtigung

Die Benachrichtigung enthält die folgenden Details:

  • Region und Zone, für die die EoL-Mitteilung gilt.
  • Aktuelle Nutzung: Hier werden alle Ihre aktiven Projekte und ve1-Private Clouds in der Region aufgeführt, mit folgenden Details:
    • Name der privaten Cloud
    • Projektnummer
    • Clustername
    • ve1-Knotentyp (HCI oder SON)
    • Anzahl der ve1-Knoten jedes Typs
    • End-of-Life-Datum, nach dem der Cluster nicht mehr unterstützt wird
  • Zukünftiges Kapazitätsangebot: Die EoL-Mitteilung enthält für jeden ve1-Cluster in der Region ein zukünftiges Kapazitätsangebot:
    • Wenn das Angebot für die Zielkapazität ve1 ist: Dieselbe Anzahl von Knoten wie im aktuellen ve1-Cluster, mit einer Konfiguration mit ausreichend langer Nutzungsdauer.
    • Wenn das Angebot für die Zielkapazität ve2 ist: ve2-mega-128-Knotentyp mit gleichwertigen oder höheren Ressourcen für Rechenleistung, Arbeitsspeicher und Speicher.
    • SLA und Fehlertoleranz (FTT): Für jeden Cluster mit mindestens drei Knoten besteht das zukünftige Angebot aus mindestens drei Knoten. Dadurch wird ein Standard-FTT-Wert von 1 sichergestellt.

Wichtige Migrationsschritte

Die Migration besteht aus den folgenden Schritten:

  1. Sehen Sie sich das Angebot für die Zielkapazität für jeden Cluster an, der vom EoL betroffen ist. Wenn Sie eine andere Konfiguration (Knotentypen oder ‑anzahl) benötigen, wenden Sie sich an IhrGoogle Cloud Account-Management-Team, um das Kapazitätsangebot anzupassen.
  2. Rabatte für zugesicherte Nutzung (Committed Use Discounts, CUDs) verwalten: Wenn Sie aktive ve1-CUD-Zusagen haben, die über das EoL-Datum der Hardware hinausgehen, wenden Sie sich an Ihr Account-Management-Team, um diese anzupassen oder zu kündigen.
  3. Wählen Sie Ihren Migrationspfad aus: Sie können entweder eine private Cloud mit gemischten Knoten erstellen oder eine neue private Cloud-Bereitstellung. Im folgenden Abschnitt finden Sie einen Vergleich der Migrationsmethoden, der Ihnen bei der Entscheidung helfen soll.
  4. Migration ausführen: Migrieren Sie Ihre Arbeitslasten über den ausgewählten Pfad. Nachdem Google Ihren Kontingentantrag genehmigt hat, haben Sie maximal 60 Tage Zeit, die Migration abzuschließen.
  5. Alte Hardware außer Betrieb nehmen: Löschen Sie die ve1-Cluster, die ausgemustert werden, und die zugehörigen Kontingente, um die Migration abzuschließen.

Migrationsoptionen vergleichen

Wenn Sie den richtigen Migrationspfad auswählen, können Sie Ihr Netzwerk richtig konfigurieren. Außerdem können Sie so Dienstunterbrechungen während der Migration vermeiden. In der folgenden Tabelle werden die technischen, Netzwerk- und Betriebsbedingungen für die einzelnen Optionen verglichen.

Funktion Option 1: Private Cloud mit gemischten Knoten (Hybrid) Option 2: Neue Private Cloud-Bereitstellung
Beschreibung Fügen Sie der vorhandenen privaten Cloud direkt Zielhardware-Familiencluster hinzu. Eine völlig neue private Cloud auf der Zielhardware bereitstellen.
Anforderung für den IP-Adressbereich für die Verwaltung Es muss ausreichend kostenloser CIDR-Bereich in der vorhandenen privaten Cloud vorhanden sein, um den zusätzlichen Cluster zu unterstützen (mindestens drei Knoten). Nicht genügend Speicherplatz ist ein Ausschlusskriterium für Option 1. Flexibel. Es wird ein völlig neuer IP-Adressbereich für die Verwaltung verwendet.
Auswirkungen auf Netzwerk und DNS Minimal. Die aktuellen Netzwerke, Subnetze und Verwaltungsschnittstellen bleiben erhalten. Hoch Erfordert die Konfiguration neuer Netzwerktopologien, DNS und Zugriffskoordinaten.
Migrationsworkflow Standard-Live-VMware vMotion und Storage vMotion. Umfangreiche Migrationen mit VMware HCX.
Erstellungsmethode Über ein Cloud Customer Care-Ticket angefordert (Sie können Hybrid-Private-Cloud-Cluster nicht selbst hinzufügen). Vollständiger Self-Service (Console, REST API, Google Cloud CLI oder Terraform).

Option 1: Migration einer privaten Cloud mit gemischten Knoten

Mit dieser Methode können Sie Cluster mit Zielhardwarefamilien direkt zu Ihrer vorhandenen privaten Cloud hinzufügen und Arbeitslasten clusterweise migrieren. Beachten Sie, dass das 60‑Tage-Limit für die Migration für jede Clustermigration gilt.

Kontingentanfrage für Zielhardware einreichen

  1. Senden Sie in der Google Cloud Console eine Kontingentanfrage für die neue Zielhardwarefamilie (ve1 oder ve2) und die Anzahl der Knoten.
  2. Geben Sie in der Beschreibung der Kontingentanfrage explizit die folgenden Eigenschaften an:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
  3. Nachdem Google die Anfrage genehmigt hat, können Sie das neue Kontingent in der Console ansehen.

Zielcluster in Ihrer privaten Cloud erstellen

  1. Sie können keine Cluster in privaten Clouds mit gemischten Knoten erstellen. Reichen Sie ein Support-Ticket ein, um die Einrichtung eines Clusters anzufordern.
  2. Geben Sie im Support-Ticket die folgenden Informationen an:
    • Projektnummer
    • Name der privaten Cloud
    • Name des neuen Zielclusters
    • Neue Maschinenfamilie (ve1 oder ve2) und Knotentyp
    • Anzahl der HCI-Knoten
    • Anzahl der reinen Speicherknoten (falls zutreffend)
  3. Cloud Customer Care benachrichtigt Sie, wenn der Zielcluster online ist.

Arbeitslasten migrieren

Wenn der Zielcluster bereit ist, migrieren Sie Arbeitslast-VMs und VM-Laufwerke mit einer Kombination aus VMware vMotion und Storage vMotion:

  1. Klicken Sie im vSphere Client mit der rechten Maustaste auf die VM und wählen Sie Migrieren aus.
  2. Wählen Sie Sowohl Computing-Ressource als auch Speicher ändern aus.
  3. Wählen Sie den neuen Cluster und die Zieldatenspeicher aus.

Verwaltungs-VMs einer Private Cloud migrieren

Wenn der Cluster, den Sie außer Betrieb nehmen, der primäre (erste) Cluster der privaten Cloud ist, müssen Sie die Verwaltungs-VMs migrieren:

  1. Verwenden Sie die Google Cloud VMware Engine Console oder die REST API, um Verwaltungs-VMs zum neuen Cluster zu migrieren. Eine ausführliche Anleitung finden Sie unter Ressourcen in privater Cloud verwalten.
  2. Führen Sie während der Migration keine anderen Clusteraktivitäten aus, z. B. das Hinzufügen von Knoten. Der Status der privaten Cloud ändert sich während des Vorgangs zu „Wird aktualisiert“.
  3. Heben Sie die Bereitstellung aller NFS-Datenspeicher auf, die mit den alten ve1-Clustern verbunden sind.

Andere Konfigurationen und Anwendungen anpassen

  • VMware HCX-Service-Meshes: Fleet-Appliances unterstützen vMotion nicht. Stellen Sie die HCX-Service-Mesh-Komponenten im Zielcluster noch einmal bereit. Weitere Informationen finden Sie im Broadcom-Artikel Migrating HCX appliances to a different SSO, PSC, or vCenter. Wenn Sie Unterstützung benötigen, senden Sie ein Support-Ticket.
  • Aria-Anwendungen: Aria-Anwendungs-VMs werden ähnlich wie Standard-Arbeitslast-VMs migriert.
  • Datenbankplattformen: Erstellen Sie Datenbankinstanzen im Zielcluster neu, wenn sie vMotion nicht unterstützen.

Außerbetriebnahme des ausgemusterten Clusters

  1. Nachdem Sie die Migration von Arbeitslasten und Verwaltungs-VMs abgeschlossen und überprüft haben, löschen Sie den Cluster, der eingestellt wird, über die Google Cloud Console, die REST API oder die Google Cloud CLI-Befehlszeile.
  2. Senden Sie eine Kontingentanfrage, um das Kontingent der Hardware des Quellclusters zu verringern. Geben Sie in der Anfragenbeschreibung Folgendes an:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Option 2: Migration in eine neue private Cloud

Mit dieser Methode können Sie eine völlig neue private Cloud auf der Zielhardware bereitstellen und Arbeitslasten aus der alten privaten Cloud mit VMware HCX migrieren.

Anfragekontingent

  1. Senden Sie eine Kontingentanfrage für die Zielhardware.
  2. Geben Sie in der Beschreibung der Anfrage Folgendes an:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
    • "New PC Name: [YOUR_NEW_PC_NAME]"

Neue private Cloud erstellen

  1. Verwenden Sie die Google Cloud Console, die REST API, die Google Cloud CLI oder Terraform, um Ihre neue private Cloud auf der Zielhardware bereitzustellen.
  2. Wenn für Ihre aktuelle Bereitstellung ein altes VMware Engine-Netzwerk verwendet wird (ein VMware Engine-Netzwerk, das vor November 2022 erstellt wurde), erstellen Sie die neue private Cloud im selben Projekt, um weiterhin Standardnetzwerkfunktionen zu verwenden. Weitere Informationen finden Sie unter Standard- und Legacy-Netzwerke für Google Cloud VMware Engine.

Arbeitslasten mit HCX migrieren

  1. Richten Sie VMware HCX in der neuen privaten Cloud ein.
  2. Verknüpfen Sie die HCX-Einrichtungen und konfigurieren Sie Migrationsnetze, um Arbeitslasten und Daten aus den zu deaktivierenden Private Cloud-Clustern zu verschieben. Wenn Ihre private Cloud, die Sie einstellen, mehrere Cluster hat, müssen Sie dafür sorgen, dass Ihre HCX-Rechenprofile und Servicemeshs so konfiguriert sind, dass sie alle Cluster enthalten, aus denen Sie Arbeitslasten migrieren müssen.
  3. Planen Sie Migrationsbatches während geeigneter Wartungsfenster.

Dienste und Anwendungen anpassen

  • VMware HCX: Stellen Sie HCX-Servicemeshs in der neuen privaten Cloud bereit.
  • Aria-Produkte: Wenn Sie von Google lizenzierte Aria-Suites verwenden, fordern Sie Support an, um Aria Suite Lifecycle Manager (LCM) in der neuen privaten Cloud zu installieren.

Alte Private Cloud außer Betrieb nehmen

  1. Nachdem Sie überprüft haben, ob alle Arbeitslasten in der neuen privaten Cloud funktionieren, löschen Sie die alten Cluster und die private Cloud selbst.
  2. Senden Sie eine Kontingentanfrage, um das eingestellte Kontingent freizugeben. Geben Sie in der Anfragenbeschreibung Folgendes an:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Zusicherungen und Abrechnung verwalten

Arbeiten Sie mit Ihrem Account-Management-Team zusammen, um Abrechnungsstrukturen zu organisieren und Rabatte für zugesicherte Nutzung während der Migration abzustimmen.

Anreize für die doppelte Nutzung

Um die Kosten für die gleichzeitige (doppelte) Nutzung zu senken, die mit der Ausführung sowohl der ausgemusterten als auch der Zielinfrastruktur während des Migrationszeitraums verbunden sind, bietet Google Anreize, um die Kosten für die doppelte Nutzung für einen bestimmten Zeitraum zu senken. Planen Sie Ihren Migrationszeitraum sorgfältig, um diese Vorteile nutzen zu können.

Anpassungen des Rabatts für zugesicherte Nutzung

Die Auswirkungen Ihrer ve1-Hardwaremigrationen auf Ihre aktiven ve1-Rabatte für zugesicherte Nutzung (Committed Use Discounts, CUDs) hängen von den Zeitplänen und Kapazitätsangeboten ab:

  • Zeitachsenüberschneidung: Wenn Ihre CUD-Zusicherungen vor dem EOL-Datum der aktuellen Knotengruppe ablaufen, ändert sich Ihre Abrechnung nicht.
  • Migration auf ve1-Knoten: Wenn für Ihr Angebot mit Zielkapazität neue ve1-Hardware verwendet wird, bleiben Ihre CUD-Zusicherungen während ihrer Laufzeit gültig.
  • Migration zu ve2-Knoten: Da Rabatte für zugesicherte Nutzung an bestimmte Hardwarekategorien gebunden sind, müssen Sie mit Ihrem Account-Management-Team zusammenarbeiten, um aktive ve1-Verträge zu kündigen oder zu konvertieren:
    • Nicht umwandelbare Rabatte für zugesicherte Nutzung: Sie müssen vorhandene Standardrabatte für zugesicherte Nutzung kündigen und neue Standardrabatte für zugesicherte Nutzung für ve2 erwerben.
    • Umwandelbare Rabatte für zugesicherte Nutzung: Sie können aktive Standardrabatte für zugesicherte Nutzung für ve1 in Rabatte für zugesicherte Nutzung für ve2 mit übertragbarer Lizenz umwandeln.
Aktuelle Nutzung Zeitachsen Zukünftiges Angebot Auswirkung von Rabatten für zugesicherte Nutzung
ve1 Alle ve1-Rabatte für zugesicherte Nutzung laufen vor dem EoL ab ve1 oder ve2 Bestehende CUDs sind davon nicht betroffen.
ve1 Einige ve1-Rabatte für zugesicherte Nutzung laufen nach dem EoL ab ve1 Die Migration hat keine Auswirkungen auf bestehende CUDs. Die Ziel-ve1-Placement-Gruppe hat eine ausreichende Nutzungsdauer.
ve1 Einige nicht konvertierbare ve1-CUDs laufen nach dem EoL ab ve2 Sie müssen vorhandene ve1-Rabatte für zugesicherte Nutzung kündigen und neue ve2-Rabatte für zugesicherte Nutzung kaufen. Wenden Sie sich an Ihr Account-Management-Team.
ve1 Einige umwandelbare ve1-Rabatte für zugesicherte Nutzung laufen nach dem EoL ab ve2 Wandeln Sie ve1-CUDs in entsprechende ve2-CUDs mit übertragbarer Lizenz um. Wenden Sie sich an Ihr Account-Management-Team.

Nächste Schritte