Arbeitslasten von ausgemusterter `ve1`-Hardware migrieren

In diesem Dokument wird erläutert, wie Sie Ihre Google Cloud VMware Engine-Arbeitslasten von ausgemusterter ve1-Hardware zu unterstützter 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 Google Cloud VMware Engine mustert die ve1-Hardware der ersten Generation schrittweise aus, da die physische Infrastruktur das Ende ihrer Nutzungsdauer erreicht. Die Ausmusterung erfolgt in Batches basierend auf Placement-Gruppen in verschiedenen Dienstregionen.

Wenn Google Cloud Google Cloud VMware Engine Ihre Hardware zur Ausmusterung plant, erhalten Sie eine gezielte End-of-Life-Benachrichtigung (EoL) mit einem detaillierten Zeitplan, Ressourcenlimits und Migrationsanweisungen. Diese gezielten Benachrichtigungen werden ab dem ersten Quartal 2026 eingeführt und die ersten Batches von ve1-Hardware erreichen das Ende ihrer Nutzungsdauer bis zum ersten Quartal 2027. Wenn das geplante Ausmusterungsdatum Ihrer Placement-Gruppe erreicht ist, können Sie Ihre Arbeitslasten zu neuerer Hardware migrieren.

In diesem Dokument werden die Details der EoL-Benachrichtigung und die Schritte zum Migrieren Ihrer Arbeitslasten beschrieben. Um die Kontinuität des Dienstes aufrechtzuerhalten und die Abdeckung des Service Level Agreement (SLA) zu gewährleisten, müssen Sie die Migration abschließen, bevor Ihre Cluster das Ende ihrer Nutzungsdauer erreichen.

Hinweis

Bevor Sie neue Ressourcen konfigurieren, lesen Sie in diesem Abschnitt die Anforderungen, Einschränkungen und Faktoren, die Ihre Migration blockieren könnten. 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-Migrationsfenster:Google unterstützt Ihre Migration maximal 60 Tage nach Genehmigung Ihrer Kontingentanfrage für die Zielkapazität:
    • Sie müssen die Migration der Arbeitslast und die Außerbetriebnahme der ausgemusterten Hardware innerhalb dieses Zeitraums abschließen.
    • Wenn die Migration Ihrer Arbeitslast nach der Bereitstellung des Zielclusters länger als 60 Tage dauert, müssen Sie Ihre eigene Broadcom-Lizenz (Bring Your Own License, BYOL) mitbringen, um den Verbrauch zu decken, der über die Standardansprüche hinausgeht.

Die Faktoren, die Ihre Migration möglicherweise blockieren, sind:

  • Blockierung des IP-Adressbereichs (Blockierung von Option 1) : Für Option 1 (private Cloud mit gemischten Knoten) muss Ihre vorhandene private Cloud ausreichend kostenlosen IP-Adressbereich für die Verwaltung haben. Sie benötigen genügend Platz, um den hinzugefügten Zielcluster zu unterstützen, der mindestens drei Knoten erfordert. Wenn Ihr vorhandener CIDR-Block mindestens drei zusätzliche Knoten nicht unterstützen kann, können Sie Option 1 nicht verwenden. In diesem Fall müssen Sie stattdessen eine neue private Cloud bereitstellen (Option 2). Prüfen Sie unter Kapazität für den IP-Adressbereich planen, ob Sie die Voraussetzungen erfüllen.
  • Unterstützung für Live-Migration von Datenbanken:Einige Datenbankplattformen vertragen keine Live-vMotion-Migrationen. Identifizieren Sie diese VM-Datenbankinstanzen und planen Sie, sie direkt im Zielcluster neu zu erstellen.
  • VMware HCX-Verbindung:VMware HCX Fleet-Appliances unterstützen keine Standard-Live-vMotion. 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.

Kapazität für den IP-Adressbereich planen

Wenn Sie mit einer privaten Cloud mit gemischten Knoten migrieren (Option 1), prüfen Sie, ob in Ihrer vorhandenen privaten Cloud genügend freier Speicherplatz im IP-Adressbereich für die Verwaltung vorhanden ist. Der hinzugefügte Zielcluster erfordert mindestens drei Knoten.

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

Wenn Ihr CIDR-Block mindestens drei zusätzliche Knoten nicht 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 bestimmen. Technische Spezifikationen finden Sie unter VMware Engine-HCI-Knotentypen.

Lizenz- und Softwareanforderungen

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

  • Broadcom-Lizenzen: Wenn die Migration Ihrer Arbeitslast nach der Bereitstellung des Zielclusters länger als 60 Tage dauert, müssen Sie Ihre eigene Broadcom-Lizenz mitbringen, um den Verbrauch zu decken, der über Ihre Standardansprüche hinausgeht.
  • VMware HCX-Service-Meshes: VMware HCX Fleet-Appliances unterstützen keine vMotion. 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 für die Verwaltung: 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. Für neue private Clouds müssen Sie Ihrem Account-Management-Team den geplanten Namen der privaten Cloud mitteilen, bevor Sie die private Cloud erstellen, damit Google sie in der richtigen Placement-Gruppe konfiguriert.

Verpflichtungen und Abrechnung planen

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

  • Einschränkungen für ve1-CUDs:Es sind nur einjährige ve1-CUDs mit Preisoptionen für übertragbare Lizenzen verfügbar. Wenn Sie eine neue einjährige Verpflichtung anwenden möchten, müssen Sie zu einer neuen ve1-Placement-Gruppe in derselben Region migrieren.
  • Unterstützung für ve2-CUDs:Dreijährige CUD-Verpflichtungen werden nur für die ve2-Knotenfamilien unterstützt.
  • Prüfung der Anspruchsberechtigung:Da neue Verpflichtungen von der verbleibenden Lebensdauer der Knoten-Placement-Gruppen in Ihrer Region abhängen, müssen Sie mit Ihrem Google Cloud Account-Management-Team zusammenarbeiten, um Ihre Anspruchsberechtigung zu prüfen.

Informationen zur EoL-Benachrichtigung für `ve1`

Die EoL-Benachrichtigung für ve1 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-Benachrichtigung gilt.
  • Ihre aktuelle Nutzung: Alle Ihre aktiven Projekte und ve1 privaten Clouds in der Region werden aufgelistet, mit folgenden Details:
    • Name der privaten Cloud
    • Projektnummer
    • Cluster name
    • ve1-Knotentyp (HCI oder SON)
    • Anzahl der ve1-Knoten jedes Typs
    • Datum des Endes der Nutzungsdauer, nach dem der Cluster nicht mehr unterstützt wird
  • Zukünftiges Kapazitätsangebot: Die EoL-Benachrichtigung enthält ein zukünftiges Kapazitätsangebot für jeden ve1 Cluster in der Region:
    • Wenn das Angebot für die Zielkapazität `ve1` ist: Dieselbe Anzahl von Knoten wie im aktuellen ve1 Cluster, mit einer Konfiguration mit ausreichend längerer Nutzungsdauer.
    • Wenn das Angebot für die Zielkapazität `ve2` ist: ve2-mega-128 Knotentyp, mit Ressourcen für Rechenleistung, Arbeitsspeicher und Speicherplatz, die gleich oder höher sind.
    • SLA und Failure-to-Tolerate (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

Ihre Migration besteht aus den folgenden Schritten:

  1. Prüfen Sie das Angebot für die Zielkapazität für jeden Cluster, der das Ende seiner Nutzungsdauer erreicht. Wenn Sie eine andere Konfiguration (Knotentypen oder -menge) benötigen, arbeiten Sie mit Ihrem Google Cloud Account-Management-Team zusammen, um das Kapazitätsangebot anzupassen.
  2. Rabatte für zugesicherte Nutzung (CUDs) verwalten: Wenn Sie aktive ve1-CUD-Verpflichtungen haben, die über das Ende der Nutzungsdauer der Hardware hinausgehen, arbeiten Sie mit Ihrem Account-Management-Team zusammen, um sie anzupassen oder zu beenden.
  3. Wählen Sie Ihren Migrationspfad aus: Sie haben die Wahl zwischen dem Erstellen einer privaten Cloud mit gemischten Knoten oder der Bereitstellung einer neuen privaten Cloud. Um Ihnen die Entscheidung zu erleichtern, vergleichen Sie die Migrationsmethoden im folgenden Abschnitt.
  4. Migration ausführen: Migrieren Sie Ihre Arbeitslasten über den ausgewählten Pfad. Nachdem Google Ihre Kontingentanfrage genehmigt hat, haben Sie maximal 60 Tage Zeit, um die Migration abzuschließen.
  5. Außerbetriebnahme der alten Hardware: Löschen Sie die ausgemusterten ve1-Cluster und die zugehörigen Kontingente, um die Migration abzuschließen.

Migrationsoptionen vergleichen

Wenn Sie den richtigen Migrationspfad auswählen, können Sie Ihr Netzwerk korrekt konfigurieren. Außerdem können Sie Dienstunterbrechungen während der Migration vermeiden. In der folgenden Tabelle werden die technischen, Netzwerk- und betrieblichen Kriterien für jede Option verglichen.

Funktion Option 1: Private Cloud mit gemischten Knoten (Hybrid) Option 2: Bereitstellung einer neuen privaten Cloud
Beschreibung Fügen Sie der vorhandenen privaten Cloud direkt Cluster der Zielhardwarefamilie hinzu. Stellen Sie eine völlig neue private Cloud auf der Zielhardware bereit.
Anforderung für den IP-Bereich für die Verwaltung Erfordert ausreichend kostenlosen CIDR-Bereich in der vorhandenen privaten Cloud, um den hinzugefügten Cluster zu unterstützen (mindestens drei Knoten). Ein unzureichender Bereich ist ein Blockierungsfaktor für Option 1. Flexibel. Verwendet einen völlig neuen IP-Adressbereich für die Verwaltung.
Auswirkungen auf Netzwerk und DNS Minimal. Behält die aktuellen Netzwerke, Subnetze und Verwaltungsschnittstellen bei. Hoch. Erfordert die Konfiguration neuer Netzwerktopologien, DNS und Zugriffskoordinaten.
Migrationsworkflow Standard-Live-VMware-vMotion und Storage vMotion. Umfassende Migrationen mit VMware HCX.
Erstellungsmethode Wird über ein Cloud Customer Care-Ticket angefordert (Sie können selbst keine Cluster zu privaten Hybrid-Clouds 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 Ihrer vorhandenen privaten Cloud direkt Cluster der Zielhardwarefamilie hinzufügen und Arbeitslasten clusterweise migrieren. Das 60-Tage-Migrationslimit gilt für jede Clustermigration.

Kontingentanfrage für Zielhardware senden

  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 sehen.

Zielcluster in Ihrer privaten Cloud erstellen

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

Arbeitslasten migrieren

Nachdem der Zielcluster bereit ist, verwenden Sie die Kombination aus VMware vMotion und Storage vMotion, um Arbeitslast-VMs und VM-Laufwerke zu migrieren:

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

VMs für die Verwaltung privater Clouds migrieren

Wenn der Cluster, den Sie ausmustern, der primäre (erste) Cluster der privaten Cloud ist, müssen Sie die VMs für die Verwaltung migrieren:

  1. Verwenden Sie die Google Cloud VMware Engine Console oder die REST API, um VMs für die Verwaltung zum neuen Cluster zu migrieren. Eine detaillierte Anleitung finden Sie unter Ressourcen privater Clouds verwalten.
  2. Führen Sie während der Migration keine anderen Clusteraktivitäten aus (z. B. Knoten hinzufügen). Der Status der privaten Cloud ändert sich während des Vorgangs in „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 keine vMotion. Stellen Sie die HCX-Service-Mesh-Komponenten im Zielcluster neu bereit. Weitere Informationen finden Sie im Broadcom-Artikel Migrating HCX appliances to a different SSO, PSC, or vCenter. Senden Sie ein Support-Ticket, wenn Sie Unterstützung benötigen.
  • Aria-Produkte: Migrieren Sie Aria-Anwendungs-VMs ähnlich wie Standard- Arbeitslast-VMs. Migrieren Sie außerdem alle zugehörigen Content Library-Elemente zu den Datenspeichern des Zielclusters.
  • Datenbankplattformen: Erstellen Sie Datenbankinstanzen im Zielcluster neu, wenn sie vMotion nicht vertragen.

Ausgemusterten Cluster außer Betrieb nehmen

  1. Nachdem Sie die Migration von Arbeitslasten und VMs für die Verwaltung abgeschlossen und geprüft haben, löschen Sie den ausgemusterten Cluster über die Google Cloud Console, die REST API oder die Google Cloud CLI-Befehlszeile.
  2. Senden Sie eine Kontingentanfrage, um das Kontingent der Quellclusterhardware zu reduzieren. 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)]"

Option 2: Migration einer neuen privaten Cloud

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

Kontingent anfordern

  1. Senden Sie eine Kontingentanfrage für die Zielhardware.
  2. Geben Sie in der Beschreibung der Anfrage explizit 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 Ihre aktuelle Bereitstellung ein älteres VMware Engine-Netzwerk verwendet (ein VMware Engine-Netzwerk, das vor November 2022 erstellt wurde), erstellen Sie die neue private Cloud im selben Projekt, um weiterhin ein älteres VMware Engine-Netzwerk zu verwenden. Weitere Informationen finden Sie unter Standard- und ältere Google Cloud VMware Engine-Netzwerke.

Arbeitslasten mit HCX migrieren

  1. Richten Sie VMware HCX in der neuen privaten Cloud ein.
  2. Verknüpfen Sie die HCX-Setups und konfigurieren Sie Migrations-Meshes, um Arbeitslasten und Daten aus den ausgemusterten Clustern der privaten Cloud zu verschieben. Wenn Ihre ausgemusterte private Cloud mehrere Cluster hat, müssen Ihre HCX-Rechenprofile und -Service-Meshes so konfiguriert sein, dass alle Cluster enthalten sind, aus denen Sie Arbeitslasten migrieren müssen.
  3. Planen Sie Migrations-Batches während geeigneter Wartungsfenster.

Dienste und Anwendungen anpassen

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

Alte private Cloud außer Betrieb nehmen

  1. Nachdem Sie geprü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 ausgemusterte Kontingent freizugeben. 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)]"

Verpflichtungen und Abrechnung verwalten

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

Anpassungen des Rabatts für zugesicherte Nutzung (CUD)

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

  • Zeitliche Überschneidung: Wenn Ihre CUD-Verpflichtungen vor dem Ende der Nutzungsdauer der aktuellen Knoten Placement-Gruppe ablaufen, ändert sich nichts an Ihrer Abrechnung.
  • Migration auf ve1-Knoten: Wenn Ihr Angebot für die Zielkapazität neue ve1 Hardware verwendet, bleiben Ihre Rabatte für zugesicherte Nutzung bis zum Ende ihrer Laufzeit gültig.
  • Migration zu `ve2`-Knoten: Da CUD-Typen an bestimmte Hardware kategorien gebunden sind, müssen Sie mit Ihrem Account-Management-Team zusammenarbeiten, um aktive ve1 Verträge zu beenden oder umzuwandeln:
    • Nicht umwandelbare CUDs: Sie müssen vorhandene Standard-CUDs kündigen und neue Standard-ve2-CUDs erwerben.
    • Umwandelbare CUDs: Sie können aktive Standard-ve1 CUDs in `ve2`-CUDs mit übertragbarer Lizenz umwandeln.ve2
Aktuelle Nutzung Zeitachsen Zukünftiges Angebot Auswirkungen auf CUD
ve1 Alle ve1-CUDs laufen vor dem Ende der Nutzungsdauer ab ve1 oder ve2 Bestehende CUDs sind davon nicht betroffen.
ve1 Einige ve1-CUDs laufen nach dem Ende der Nutzungsdauer ab ve1 Die Migration wirkt sich nicht auf bestehende CUDs aus. Die Ziel-Placement-Gruppe ve1 hat eine ausreichend lange Nutzungsdauer.
ve1 Einige nicht umwandelbare ve1-CUDs laufen nach dem Ende der Nutzungsdauer ab ve2 Sie müssen vorhandene ve1-CUDs beenden und neue ve2-CUDs erwerben. Arbeiten Sie mit Ihrem Account-Management-Team zusammen.
ve1 Einige umwandelbare ve1-CUDs laufen nach dem Ende der Nutzungsdauer ab ve2 Wandeln Sie ve1-CUDs in entsprechende ve2-CUDs mit übertragbarer Lizenz um. Arbeiten Sie mit Ihrem Account-Management-Team zusammen.

Nächste Schritte