Esegui la migrazione dei workload dall'hardware ve1 ritirato

Questo documento spiega come eseguire la migrazione dei carichi di lavoro Google Cloud VMware Engine dall'hardware ve1 in fase di ritiro all'hardware ve1 o ve2 supportato. Puoi eseguire la migrazione dei workload utilizzando uno dei due metodi: l'opzione 1 prevede l'aggiunta di nuovi cluster hardware a un cloud privato esistente per creare un cloud privato con nodi misti, mentre l'opzione 2 prevede il deployment di un nuovo cloud privato utilizzando nuovo hardware.

Google Cloud ritirerà l'hardware ve1 di prima generazione in modo graduale man mano che l'infrastruttura fisica raggiungerà la fine del suo ciclo di vita utile. I ritiri vengono eseguiti in batch in base ai gruppi di posizionamento in diverse regioni di servizio.

Quando Google Cloud pianifica il ritiro dell'hardware, ricevi una notifica mirata di fine ciclo di vita (EoL) contenente una cronologia dettagliata, limiti delle risorse e istruzioni per la migrazione. Queste notifiche mirate inizieranno a essere implementate nel primo trimestre del 2026 e i primi lotti di hardware ve1 raggiungeranno la fine del ciclo di vita entro il primo trimestre del 2027. Quando il gruppo di posizionamento raggiunge la data di ritiro pianificata, puoi eseguire la migrazione dei tuoi carichi di lavoro a hardware più recente.

Questo documento descrive i dettagli della notifica di fine ciclo di vita e i passaggi per eseguire la migrazione dei carichi di lavoro. Per mantenere la continuità del servizio e garantire la copertura dell'accordo sul livello del servizio (SLA), completa la migrazione prima che i cluster raggiungano le date di fine ciclo di vita.

Prima di iniziare

Prima di configurare nuove risorse, esamina i requisiti, le limitazioni e i fattori che potrebbero bloccare la migrazione in questa sezione. Queste informazioni ti aiutano a pianificare una migrazione ottimale ed evitare interruzioni del servizio.

I requisiti fondamentali da considerare prima di iniziare una migrazione sono i seguenti:

  • Finestra di migrazione rigorosa di 60 giorni:Google supporta la migrazione per un massimo di 60 giorni dopo l'approvazione della richiesta di quota di capacità di destinazione:
    • Devi completare la migrazione del carico di lavoro e dismettere l'hardware ritirato entro questo periodo.
    • Se la durata della migrazione del workload supera i 60 giorni dopo il provisioning del cluster di destinazione, devi portare la tua licenza Broadcom (BYOL) per coprire qualsiasi consumo che superi i diritti standard.

I fattori che potrebbero potenzialmente bloccare la migrazione sono i seguenti:

  • Blocco dello spazio di indirizzi IP (blocco dell'opzione 1): l'opzione 1 (cloud privato con nodi misti) richiede che il tuo cloud privato esistente disponga di spazio di indirizzi IP di gestione libero sufficiente. Devi avere spazio sufficiente per supportare il cluster di destinazione aggiunto, che richiede un minimo di tre nodi. Se il blocco CIDR esistente non può supportare almeno tre nodi aggiuntivi, non puoi utilizzare l'opzione 1. In questo caso, devi invece eseguire il deployment di un nuovo cloud privato (opzione 2). Esamina Pianifica la capacità per lo spazio di indirizzi IP per determinare la tua idoneità.
  • Supporto del database per la migrazione live:alcune piattaforme di database non tollerano le migrazioni live di vMotion. Identifica queste istanze di database VM e pianifica di ricompilarle direttamente sul cluster di destinazione.
  • Connettività VMware HCX: gli appliance VMware HCX Fleet non supportano vMotion live standard. Devi pianificare il redeployment dei mesh di servizi HCX sul cluster di destinazione. Per ulteriori informazioni, consulta l'articolo di Broadcom Migrazione delle appliance HCX a un altro SSO, PSC o vCenter.

Pianifica la capacità per lo spazio degli indirizzi IP

Se esegui la migrazione utilizzando un cloud privato con nodi misti (opzione 1), verifica che il cloud privato esistente disponga di spazio sufficiente nell'intervallo di indirizzi IP di gestione. Il cluster di destinazione aggiunto richiede un minimo di tre nodi.

  1. Visualizza l'intervallo di indirizzi IP di gestione e la versione del piano IP del tuo cloud privato. Per riferimento, vedi Versioni della divisione dell'intervallo CIDR delle subnet.
  2. Conta il numero attuale di nodi nel tuo cloud privato.
  3. Controlla il numero massimo di nodi supportati dalle dimensioni del CIDR. Consulta la tabella Dimensioni intervallo CIDR subnet vSphere e vSAN.
  4. Calcola: Existing node count + 3 ≤ maximum nodes supported by CIDR size

Se il tuo blocco CIDR non può supportare almeno tre nodi aggiuntivi, non puoi utilizzare un cloud privato con nodi misti. In questo caso, devi eseguire il deployment di un nuovo cloud privato (opzione 2).

Pianificare la capacità dei nodi

Se la tua offerta di capacità futura specifica ve2 nodi, collabora con il tuo team dedicato all'account Google Cloud per dimensionare e determinare i tipi di nodi ve2 corretti (mega, large, standard o small) e i conteggi per i tuoi carichi di lavoro. Per le specifiche tecniche, consulta Tipi di nodi HCI di VMware Engine.

Requisiti relativi alle licenze e al software

Tieni presente i seguenti requisiti di licenza e software per la migrazione:

  • Licenze Broadcom: se la durata della migrazione del carico di lavoro supera i 60 giorni dopo il provisioning del cluster di destinazione, devi portare la tua licenza Broadcom per coprire qualsiasi consumo che superi i tuoi diritti standard.
  • Service mesh VMware HCX: gli appliance VMware HCX Fleet non supportano vMotion. Devi rieseguire il deployment dei mesh di servizi HCX nel cluster di destinazione. Per ulteriori informazioni, consulta l'articolo di Broadcom Migrazione delle appliance HCX a un altro SSO, PSC o vCenter.
  • Gruppi di posizionamenti di gestione: Google esegue il provisioning della capacità nei gruppi di posizionamenti corretti. Per le configurazioni con nodi misti, l'assistenza clienti Google Cloud configura il nuovo cluster nel gruppo di posizionamento di destinazione. Per i nuovi cloud privati, invia il nome del cloud privato pianificato al tuo team dedicato all'account prima di creare il cloud privato per assicurarti che Google lo configuri nel gruppo di posizionamento corretto.

Impegni del piano e fatturazione

Prima di selezionare un percorso di migrazione, esamina i seguenti vincoli per gli sconti per impegno di utilizzo (CUD):

  • ve1 Limitazioni del CUD: sono disponibili solo CUD di un anno con opzioni di prezzo per licenze portatili.ve1 Per applicare un nuovo impegno di un anno, devi eseguire la migrazione a un nuovo gruppo di posizionamento ve1 nella stessa regione.
  • Supporto del CUD per ve2: gli impegni di tre anni con sconto per impegno di utilizzo (CUD) sono supportati solo nelle famiglie di nodi ve2.
  • Controllo dell'idoneità:poiché i nuovi impegni dipendono dalla durata residua dei gruppi di posizionamento dei nodi nella tua regione, devi collaborare con il tuo Google Cloud team dedicato all'account per verificare la tua idoneità.

Comprendere la notifica di fine vita di ve1

L'avviso di fine ciclo di vita (EoL) ve1 è un'email ufficiale che ti informa che i tuoi nodi bare metal ve1 stanno raggiungendo la fine del loro ciclo di vita utile.

Componenti chiave della notifica di fine ciclo di vita

La notifica include i seguenti dettagli:

  • Regione e zona a cui si applica la notifica di fine del ciclo di vita.
  • Utilizzo attuale: elenco di tutti i tuoi progetti attivi e dei cloud privati ve1 nella regione, con i seguenti dettagli:
    • Nome del cloud privato
    • Numero progetto
    • Nome del cluster
    • Tipo di nodo ve1 (HCI o SON)
    • Numero di nodi ve1 di ogni tipo
    • Data di fine del ciclo di vita dopo la quale il cluster non è più supportato
  • Offerta di capacità futura: la notifica di fine ciclo di vita fornisce un'offerta di capacità futura per ogni cluster ve1 nella regione:
    • Se l'offerta di capacità target è ve1: stesso numero di nodi del cluster ve1 attuale, con una configurazione della vita utile sufficientemente più lunga.
    • Se l'offerta di capacità target è ve2: tipo di nodo ve2-mega-128, che offre risorse di calcolo, memoria e capacità di archiviazione equivalenti o superiori.
    • SLA e tolleranza agli errori (FTT): per qualsiasi cluster con tre o più nodi, l'offerta futura è costituita da un minimo di tre nodi. In questo modo, viene garantito un valore FTT predefinito pari a 1.

Passaggi chiave per la migrazione

La migrazione è costituita dalla seguente sequenza di passaggi:

  1. Esamina l'offerta di capacità target per ogni cluster soggetto al termine del ciclo di vita. Se hai bisogno di una configurazione diversa (tipi o quantità di nodi), collabora con il team dedicato all'accountGoogle Cloud per modificare l'offerta di capacità.
  2. Gestisci gli sconti per impegno di utilizzo (CUD): se hai impegni CUD ve1 attivi che superano le date di fine ciclo di vita dell'hardware, collabora con il tuo team dedicato all'account per modificarli o terminarli.
  3. Seleziona il percorso di migrazione: scegli tra la creazione di un cloud privato con famiglia di nodi misti o un nuovo deployment del cloud privato. Per aiutarti a decidere, confronta i metodi di migrazione nella sezione seguente.
  4. Esegui la migrazione: esegui la migrazione dei carichi di lavoro utilizzando il percorso scelto. Hai una finestra di assistenza massima di 60 giorni per completare la migrazione dopo che Google ha approvato la tua richiesta di quota.
  5. Dismetti l'hardware precedente: elimina i cluster ve1 ritirati e le quote associate per completare la migrazione.

Confronta le opzioni di migrazione

La scelta del percorso di migrazione corretto ti aiuta a configurare correttamente la rete. Inoltre, ti aiuta a evitare interruzioni del servizio durante la migrazione. La tabella seguente confronta i criteri tecnici, di rete e operativi per ogni opzione.

Funzionalità Opzione 1: cloud privato ibrido (con nodi misti) Opzione 2: nuovo deployment del cloud privato
Descrizione Aggiungi i cluster di famiglie di hardware di destinazione direttamente al cloud privato esistente. Esegui il deployment di un cloud privato completamente nuovo sull'hardware di destinazione.
Requisito per l'intervallo IP di gestione Richiede uno spazio CIDR libero sufficiente nel cloud privato esistente per supportare il cluster aggiunto (minimo tre nodi). Lo spazio insufficiente è un fattore bloccante per l'opzione 1. Flessibile. Utilizza un intervallo di indirizzi IP di gestione completamente nuovo.
Impatto di networking e DNS Minima. Conserva le reti, le subnet e le interfacce di gestione attuali. Alto. Richiede la configurazione di nuove topologie di rete, DNS e coordinate di accesso.
Workflow di migrazione VMware vMotion e Storage vMotion live standard. Migrazioni su vasta scala utilizzando VMware HCX.
Metodo di creazione Richiesto tramite ticket dell'assistenza clienti Google Cloud (non puoi aggiungere cluster ai cloud privati ibridi autonomamente). Completamente self-service (console, API REST, Google Cloud CLI o Terraform).

Opzione 1: migrazione del cloud privato con nodi misti

Questo metodo ti consente di aggiungere cluster di famiglie di hardware di destinazione direttamente al tuo cloud privato esistente e di eseguire la migrazione dei carichi di lavoro cluster per cluster. Tieni presente che il limite di 60 giorni per la migrazione si applica a ogni migrazione del cluster.

Inviare una richiesta di quota per l'hardware di destinazione

  1. Nella console Google Cloud , invia una richiesta di quota per la nuova famiglia di hardware di destinazione (ve1 o ve2) e i conteggi dei nodi.
  2. Nella descrizione della richiesta di quota, scrivi esplicitamente le seguenti proprietà:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
  3. Dopo l'approvazione della richiesta da parte di Google, puoi visualizzare la nuova quota nella console.

Crea il cluster di destinazione nel cloud privato

  1. Non puoi creare cluster nei cloud privati con nodi misti autonomamente. Invia un ticket di assistenza per richiedere la configurazione del cluster.
  2. Fornisci i seguenti dettagli nel ticket di assistenza:
    • Numero progetto
    • Nome del cloud privato
    • Nuovo nome del cluster di destinazione
    • Nuova famiglia di macchine (ve1 o ve2) e tipo di nodo
    • Conteggio dei nodi HCI
    • Conteggio dei nodi solo di archiviazione (se applicabile)
  3. L'assistenza clienti Google Cloud ti avvisa quando il cluster di destinazione è online.

Esegui la migrazione dei workload

Una volta pronto il cluster di destinazione, utilizza la combinazione di VMware vMotion e storage vMotion per eseguire la migrazione delle VM di workload e dei dischi VM:

  1. In vSphere Client, fai clic con il tasto destro del mouse sulla VM e seleziona Migrate (Migra).
  2. Seleziona Modifica sia la risorsa di calcolo che lo spazio di archiviazione.
  3. Scegli il nuovo cluster e gli archivi dati di destinazione.

Migra le VM di gestione del cloud privato

Se il cluster che stai ritirando è il cluster principale (il primo) del cloud privato, devi eseguire la migrazione delle VM di gestione:

  1. Utilizza la console Google Cloud VMware Engine o l'API REST per eseguire la migrazione delle VM di gestione al nuovo cluster. Per istruzioni dettagliate, vedi Gestire le cloud privato private.
  2. Non eseguire altre attività del cluster (ad esempio l'aggiunta di nodi) durante la migrazione. Durante la procedura, lo stato del cloud privato cambia in aggiornamento.
  3. Smonta tutti i datastore NFS collegati ai vecchi cluster ve1.

Modificare altre configurazioni e applicazioni

  • Mesh di servizi VMware HCX: gli appliance della flotta non supportano vMotion. Esegui nuovamente il deployment dei componenti della mesh di servizi HCX sul cluster di destinazione. Per ulteriori informazioni, consulta l'articolo di Broadcom Migrazione delle appliance HCX a un altro SSO, PSC o vCenter. Invia una richiesta di assistenza se hai bisogno di aiuto.
  • Applicazioni Aria: esegui la migrazione delle VM delle applicazioni Aria in modo simile alle VM dei carichi di lavoro standard.
  • Piattaforme di database: ricrea le istanze del database sul cluster di destinazione se non possono tollerare vMotion.

Dismettere il cluster ritirato

  1. Dopo aver completato e verificato la migrazione dei carichi di lavoro e delle VM di gestione, elimina il cluster ritirato utilizzando la console Google Cloud , l'API REST o la riga di comando Google Cloud CLI.
  2. Invia una richiesta di quota per ridurre la quota dell'hardware del cluster di origine. Nella descrizione della richiesta, specifica:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Opzione 2: migrazione del nuovo cloud privato

Questo metodo consente di eseguire il deployment di un cloud privato completamente nuovo sull'hardware di destinazione e di eseguire la migrazione dei carichi di lavoro dal cloud privato ritirato utilizzando VMware HCX.

Quota per le richieste

  1. Invia una richiesta di quota per l'hardware di destinazione.
  2. Nella descrizione della richiesta, scrivi esplicitamente:
    • "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]"

Crea il nuovo cloud privato

  1. Utilizza la console Google Cloud , l'API REST, Google Cloud CLI o Terraform per eseguire il deployment del nuovo cloud privato sull'hardware di destinazione.
  2. Se il deployment attuale utilizza una rete VMware Engine legacy (una rete VMware Engine creata prima di novembre 2022), crea il nuovo cloud privato nello stesso progetto per continuare a utilizzare le funzionalità di rete standard. Per saperne di più, consulta Reti Google Cloud VMware Engine standard e legacy.

Migrazione dei carichi di lavoro utilizzando HCX

  1. Configura VMware HCX nel nuovo cloud privato.
  2. Collega le configurazioni HCX e configura le mesh di migrazione per spostare i carichi di lavoro e i dati dai cluster cloud privato ritirati. Se il tuo cloud privato in fase di ritiro ha più cluster, assicurati che i profili di calcolo e i service mesh di HCX siano configurati in modo da includere tutti i cluster da cui devi eseguire la migrazione dei workload.
  3. Pianifica i batch di migrazione durante i periodi di manutenzione appropriati.

Regolare servizi e applicazioni

  • VMware HCX: esegui il deployment dei service mesh HCX sul nuovo cloud privato.
  • Prodotti Aria: se utilizzi le suite Aria con licenza Google, richiedi assistenza per installare Aria Suite Lifecycle Manager (LCM) sul nuovo cloud privato.

Dismetti il vecchio cloud privato

  1. Dopo aver verificato che tutti i workload funzionano nel nuovo cloud privato, elimina i vecchi cluster e il cloud privato stesso.
  2. Invia una richiesta di quota per rilasciare la quota ritirata. Nella descrizione della richiesta, specifica:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Gestire impegni e fatturazione

Collabora con il team dedicato all'account per organizzare le strutture di fatturazione e allineare gli sconti per impegno di utilizzo (CUD) durante la migrazione.

Aggiustamenti dello sconto per impegno di utilizzo (CUD)

L'impatto delle migrazioni hardware ve1 sugli sconti per impegno di utilizzo (CUD) ve1 attivi dipende dalle tempistiche e dalle offerte di capacità:

  • Sovrapposizione della cronologia: se i tuoi impegni CUD scadono prima della data di fine ciclo di vita del gruppo di posizionamento dei nodi corrente, la fatturazione non cambia.
  • Migrazione sui nodi ve1: se l'offerta di capacità target utilizza nuovo hardware ve1, gli impegni CUD rimangono validi per tutta la durata.
  • Migrazione ai nodi ve2: poiché i tipi di CUD sono associati a categorie di hardware specifiche, devi collaborare con il team dedicato all'account per terminare o convertire i contratti ve1 attivi:
    • Sconti per impegno di utilizzo (CUD) non convertibili: devi annullare i CUD standard esistenti e acquistare nuovi CUD standard ve2.
    • Sconti per impegno di utilizzo (CUD) convertibili: puoi convertire gli sconti per impegno di utilizzo (CUD) standard attivi per ve1 in sconti per impegno di utilizzo (CUD) per licenze portabili per ve2.
Utilizzo attuale Tempistiche Offerta futura Impatto del CUD
ve1 Tutti i CUD ve1 scadono prima della fine del ciclo di vita ve1 o ve2 I CUD esistenti non saranno interessati.
ve1 Alcuni sconti per impegno di utilizzo (CUD) ve1 scadono dopo la fine del ciclo di vita ve1 La migrazione non influirà sui CUD esistenti. Il gruppo di posizionamenti ve1 di destinazione ha una vita utile sufficiente.
ve1 Alcuni CUD ve1 non convertibili scadono dopo la fine del ciclo di vita ve2 Devi terminare i CUD ve1 esistenti e acquistare nuovi CUD ve2. Collabora con il team dedicato all'account.
ve1 Alcuni CUD convertibili ve1 scadono dopo la fine del ciclo di vita ve2 Converti gli sconti per impegno di utilizzo (CUD) ve1 in sconti per impegno di utilizzo (CUD) con licenza portatile ve2 appropriati. Collabora con il team dedicato all'account.

Passaggi successivi