Bonnes pratiques de migration

Cette page présente quelques bonnes pratiques pour migrer des instances de machine virtuelle (VM) VMware vers votre cloud privé à l'aide de Google Cloud VMware Engine.

Planifier le projet de migration

Avant de migrer des VM VMware vers votre cloud privé, planifiez la migration comme suit:

  • Identifiez le personnel, y compris les éléments suivants:

    • Personnes concernées par le client
    • Sponsor et propriétaire du programme
    • L'équipe technique chargée de la migration
    • Les personnes concernées par les systèmes et applications concernés
    • Le responsable de compte technique (TAM), le responsable de l'ingénierie partenaire (PEM) ou l'ingénieur client (CE) Google concerné

  • Évaluez l'environnement source.

  • Créez un plan qui définit les éléments suivants:

    • la stratégie de migration ;
    • l'architecture du nouvel environnement ;
    • les objectifs et les critères de réussite, y compris les scripts d'UAT et d'assurance qualité ;
    • les rôles et les responsabilités
    • le modèle de communication, y compris les réunions quotidiennes, les rapports d'état, les procédures d'escalade et les salons de discussion ;
    • les données qui ne peuvent pas être migrées et les stratégies associées ;
    • les jalons et les délais ;

  • Assurez-vous que le plan est en phase avec toutes les parties prenantes.

Évaluer les options de migration

Pour évaluer les différentes options de migration pour VMware Engine, envisagez les options suivantes:

  • Envisagez de planifier la migration par vagues.

    • Tenez compte des dépendances et des mappages des applications.
    • Regroupez les VM en fonction de leur calendrier de maintenance.
    • Pour éviter plusieurs cycles d'alimentation, identifiez les VM avec des mises à jour système en attente et alignez le calendrier sur les redémarrages de basculement de la migration.

  • Établissez une stratégie de sauvegarde et de reprise après sinistre pour les VM. Envisagez d'utiliser Sauvegarde et reprise après sinistre Google Cloud et VMware Engine Protected.

  • Assurez-vous que vSphere, vCenter, HCX et, le cas échéant, NSX-T sur site répondent à la compatibilité de version minimale avec les versions des composants VMware Engine.

  • Identifiez les VM dont les exigences en termes de mémoire, de processeur ou de stockage dépassent les spécifications du type de nœud actuel ou qui peuvent entraîner des conflits si elles sont combinées à d'autres VM volumineuses.

    Par exemple, les serveurs de base de données peuvent nécessiter de grandes quantités de mémoire, tandis que les serveurs de stockage de fichiers peuvent nécessiter de grands datastores.

  • Développez des stratégies de pré- et post-migration pour les contenus qui ne peuvent pas être migrés en raison d'un matériel ou d'un taggage persistant, tels que les ISO montées, les balises NSX-T, les appareils passthrough qui utilisent l'I/O DirectPath, les disques multi-écrivains et les RDM physiques. Par exemple, vous pouvez envisager de convertir les RDM physiques en mode de compatibilité virtuel.

  • Évaluez les méthodes de migration.

    Privilégiez la migration groupée. Tenez compte des conditions requises et des restrictions associées.

Utiliser VMware HCX pour les migrations

Lorsque vous utilisez HCX pour la migration, tenez compte des recommandations suivantes:

  • Bien qu'une topologie réseau plate soit prise en charge pour les déploiements du connecteur HCX et du maillage de services HCX, pour éviter les problèmes de routage et les erreurs de connectivité, configurez la gestion HCX et les profils réseau de la liaison montante HCX sur des réseaux et des VLAN distincts.

  • Assurez-vous que votre environnement VMware dispose des dernières versions de HCX. Pour en savoir plus, consultez les procédures de mise à jour du service HCX.

  • Veillez à configurer les opérations de sauvegarde et de restauration HCX, si nécessaire.

    L'équipe SRE gère les sauvegardes de HCX Manager, mais pas celles du connecteur HCX.

    Les appliances de service HCX, y compris HCX-IX et HCX-NE, ne nécessitent pas de sauvegardes individuelles. Un HCX Manager restauré se reconnecte aux dispositifs de service existants créés pendant la durée de la sauvegarde. Si les appliances de service ne sont plus fonctionnelles, HCX Manager déploie de nouvelles VM d'appliances en fonction de la configuration sauvegardée.

  • Lorsque vous étirez un réseau de couche 2 à l'aide d'extensions réseau HCX, activez le conditionnement de flux TCP. Pour en savoir plus, consultez la section Fonctionnalités d'ingénierie du trafic fournies dans HCX.

  • Pour les VM qui communiquent vers ou depuis un cloud privé via une extension HCX L2, configurez le paramètre de MTU optimal en fonction des configurations des points de terminaison du VPN. Cela est particulièrement important dans les cas où une application n'est pas en mesure de contrôler la taille de la charge utile maximale.

    Google recommande de définir la MTU sur 1 350 octets à 1 390 octets ou moins pour les interfaces de VM qui permettent le transfert de données comme suit:

    • d'un point de terminaison sur site vers un cloud privé et inversement
    • d'une VM dans un cloud privé vers une VM dans un autre cloud privé via une extension L2

    Pour plus d'informations sur le calcul de la surcharge d'encapsulation, consultez les sections Considérations concernant les MTU et VPN VMware NSX-T.

Étape suivante