Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Best practice per la migrazione
Questa pagina presenta alcune best practice per la migrazione delle istanze di macchine virtuali (VM) VMware al tuo cloud privato utilizzando Google Cloud VMware Engine.
Pianifica il progetto di migrazione
Prima di eseguire la migrazione delle VM VMware al tuo cloud privato, pianifica la migrazione come segue:
Identifica il personale, tra cui:
Stakeholder dei clienti
Sponsor e proprietario del programma
Il team tecnico responsabile della migrazione
Gli stakeholder per i sistemi e le applicazioni inclusi nell'ambito
Il Technical Account Manager (TAM), il Partner Engineering Manager (PEM) o il Customer Engineer (CE) di Google pertinente
gli obiettivi e i criteri di successo, inclusi gli script UAT e QA
i ruoli e le responsabilità
il modello di comunicazione, inclusi riepiloghi giornalieri, report sullo stato, percorsi di riassegnazione, chat room
i dati di cui non è possibile eseguire la migrazione e le strategie correlate
traguardi e tempistiche
Assicurati l'allineamento con tutti gli stakeholder.
Valutare le opzioni di migrazione
Per valutare le diverse opzioni di migrazione per VMware Engine,
prendi in considerazione le seguenti opzioni:
Valuta la possibilità di pianificare la migrazione a più riprese.
Tieni conto delle dipendenze e delle mappature delle applicazioni.
Raggruppa le VM in base alla pianificazione della manutenzione.
Per evitare più cicli di alimentazione, identifica le VM con aggiornamenti di sistema in attesa e allinea la pianificazione ai riavvii di passaggio della migrazione.
Assicurati che vSphere, vCenter, HCX e, se applicabile, NSX-T on-premisesoddisfano la compatibilità di versionamento minima con le versioni dei componenti di VMware Engine.
Identifica le VM con requisiti di memoria, CPU o archiviazione che superano le specifiche del tipo di nodo corrente o che potrebbero causare contese se combinate con altre VM di grandi dimensioni.
Ad esempio, i server di database potrebbero richiedere grandi quantità di memoria o
i server di archiviazione file potrebbero richiedere datastore di grandi dimensioni.
Sviluppare strategie di pre e post-migrazione per i contenuti di cui non è possibile eseguire la migrazione a causa di hardware o tagging persistenti, ad esempio ISO montate, tag NSX-T, dispositivi passthrough che utilizzano I/O DirectPath, dischi multi-autore e RDM fisici. Un esempio di strategia potrebbe essere valutare la possibilità di convertire le unità RDM fisiche in modalità di compatibilità virtuale.
Preferisci la migrazione collettiva.
Tieni conto dei requisiti e delle limitazioni correlati.
Utilizzare VMware HCX per le migrazioni
Quando utilizzi HCX per la migrazione,
prendi in considerazione i seguenti consigli:
Sebbene una topologia di rete piatta sia supportata per gli implementazioni di HCX Connector e HCX Service Mesh, per evitare problemi di routing ed errori di connettività, configura la gestione di HCX e i profili di rete di HCX Uplink su reti e VLAN distinte.
Il team SRE gestisce i backup di HCX Manager, ma non quelli di HCX Connector.
Le appliance di servizio HCX, tra cui HCX-IX e HCX-NE, non richiedono backup individuali. Un HCX Manager ripristinato si riconnette alle appliance di servizio esistenti create durante la durata del backup. Se le appliance di servizio non sono più funzionali, HCX Manager esegue il deployment di nuove VM appliance in base alla configurazione di cui è stato eseguito il backup.
Per le VM che comunicano con o da un cloud privato tramite un'estensione L2 HCX, configura l'impostazione MTU migliore in base alle configurazioni degli endpoint VPN. Questo è particolarmente importante nei casi in cui un'applicazione non sia in grado di controllare la dimensione massima del payload.
Google consiglia un'impostazione MTU compresa tra 1350 e 1390 byte o inferiore per le interfacce VM che consentono il trasferimento di dati nei seguenti modi:
Da un endpoint on-premise a un cloud privato e viceversa
Da una VM in un cloud privato a una VM in un altro cloud privato tramite un'estensione L2
Esplora architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Per ulteriori informazioni, visita il Cloud Architecture Center.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[],[],null,["# Migration best practices\n========================\n\nThis page presents some best practices for migrating VMware virtual machine (VM)\ninstances to your private cloud by using Google Cloud VMware Engine.\n\nPlan the migration project\n--------------------------\n\nBefore migrating VMware VMs to your private cloud, plan the migration as follows:\n\n- Identify the personnel, including the following:\n\n - Customer stakeholders\n - Program sponsor and owner\n - The technical team responsible for the migration\n - The stakeholders for in-scope systems and applications\n - The relevant Google Technical Account Manager (TAM), Partner Engineering Manager (PEM), or Customer Engineer (CE)\n- Assess the [source environment](/vmware-engine/docs/workloads/classic-console/howto-migrate-workloads#assess_the_source_environment).\n\n- Create a plan that defines the following:\n\n - the migration strategy\n - the architecture of the new environment\n - the goals and success criteria, including the UAT and QA scripts\n - the roles and responsibilities\n - the communication model, including daily standups, status reporting, escalation paths, chat rooms\n - the data that cannot be migrated and related strategies\n - milestones and timings\n- Ensure alignment with all stakeholders.\n\nEvaluate migration options\n--------------------------\n\nTo evaluate the different migration options for VMware Engine,\nconsider the following options:\n\n- Consider planning the migration in waves.\n\n - Factor in application dependencies and mappings.\n - Group VMs based on their maintenance schedule.\n - To avoid multiple power cycles, identify the VMs with pending system updates and align the schedule with the migration switchover reboots.\n- Establish a backup and DR strategy for VMs. Consider using\n [Google Cloud Backup and DR](/backup-disaster-recovery/docs) and\n [VMware Engine Protected](/vmware-engine/docs/concepts-vmware-engine-protected).\n\n- Ensure that vSphere, vCenter, HCX, and, if applicable, NSX-T on-premises\n meet the minimum versioning compatibility with\n [VMware Engine component versions](/vmware-engine/docs/concepts-vmware-components#vmware_component_versions).\n\n- Identify VMs with memory, CPU, or storage requirements that exceed the\n specification of the current node type or that might cause contention if\n combined with other large VMs.\n\n For example, database servers might require large amounts of memory or\n file storage servers might require large datastores.\n- Develop pre- and post-migration strategies for content that cannot be\n migrated due to persistent hardware or tagging, such as mounted ISOs, NSX-T\n tags, passthrough devices that use\n [DirectPath I/O](https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-BF2770C3-39ED-4BC5-A8EF-77D55EFE924C.html),\n [multi-writer disks](https://core.vmware.com/blog/migrating-vms-shared-or-multi-writer-disks),\n and physical RDMs. An example strategy might be to consider converting\n physical RDMs to\n [virtual compatibility mode](https://knowledge.broadcom.com/external/article?legacyId=1006599).\n\n- Assess and evaluate [migration methods](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-user-guide/GUID-8A31731C-AA28-4714-9C23-D9E924DBB666.html).\n\n Prefer [bulk migration](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-user-guide/GUID-20EA2946-57CD-4A87-AE25-866E5336AEA9.html#GUID-20EA2946-57CD-4A87-AE25-866E5336AEA9).\n Consider the related requirements and restrictions.\n\nUse VMware HCX for migrations\n-----------------------------\n\nWhen using [HCX for migration](/vmware-engine/docs/workloads/howto-migrate-vms-using-hcx),\nconsider the following recommendations:\n\n- Although a flat network topology is supported for HCX Connector and HCX\n Service Mesh deployments, to avoid routing problems and connectivity\n errors, set up HCX Management and the HCX Uplink [network profiles](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-getting-started/GUID-AB56D9A9-7E2C-436F-9E20-445E447E300F.html)\n on separate networks and VLANs.\n\n- Ensure that your VMware environment has the latest HCX versions. For more\n information, see\n [HCX Service Update Procedures](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-user-guide/GUID-77111C61-EC4C-4C8C-8340-5828CC4D489D.html).\n\n- Be sure to configure\n [HCX backups and restore operations](https://docs.vmware.com/en/VMware-HCX/4.9/hcx-user-guide/GUID-50C416BC-5415-42AB-AA7A-3A5CB46A60C7.html),\n as required.\n\n The SRE team manages HCX Manager backups, but not HCX Connector backups.\n\n HCX service appliances, including HCX-IX and HCX-NE, don't require\n individual backups. A restored HCX Manager reconnects to existing service\n appliances that were created within the backup duration. If the service\n appliances are no longer functional, the HCX Manager deploys new appliance\n VMs based on the backed-up configuration.\n- When stretching a Layer 2 network by using HCX network extensions, enable\n TCP Flow Conditioning. For related information, see\n [Traffic engineering features provided in HCX](https://blogs.vmware.com/cloud/2020/01/16/traffic-engineering-hcx-enterprise/).\n\n- For VMs that communicate to or from a private cloud over an HCX L2\n extension, configure the best MTU setting based on VPN endpoint\n configurations. This is especially important in cases where an application\n isn't able to control the maximum payload size.\n\n Google recommends an MTU setting of 1350 bytes to 1390 bytes or lower for VM\n interfaces that allow data transfer in the following ways:\n - From an on-premises endpoint to a private cloud and conversely\n - From a VM in one private cloud to a VM in another private cloud over an L2 extension\n\n For additional guidance on calculating encapsulation overhead, see\n [MTU considerations](/network-connectivity/docs/vpn/concepts/mtu-considerations)\n and [VMware NSX-T VPNs](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.0/administration/GUID-A8B113EC-3D53-41A5-919E-78F1A3705F58.html).\n\nWhat's next\n-----------\n\n- Read about best practices for [compute](/vmware-engine/docs/best-practices-compute), [networking](/vmware-engine/docs/best-practices-networking), [security](/vmware-engine/docs/best-practices-security), [storage](/vmware-engine/docs/best-practices-storage), and [costs](/vmware-engine/docs/best-practices-costs).\n- Try out VMware Engine. Visit [features, benefits, and use\n cases](/vmware-engine/docs/overview) for more information.\n- Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Visit [Cloud Architecture Center](/architecture) for more information."]]