Bonnes pratiques de migration

Cette page présente quelques bonnes pratiques pour migrer des instances de machines virtuelles (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:

    • Partenaires du client
    • Commanditaire et propriétaire du programme
    • L'équipe technique responsable de la migration
    • Les partenaires des 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 de QA
    • 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 de signalement,
    • Données qui ne peuvent pas être migrées et stratégies associées
    • les jalons et les délais

  • Garantir l’alignement de tous les partenaires.

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

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

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

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

  • Identifiez les VM ayant des exigences de mémoire, de processeur ou de stockage qui dépassent la spécification du type de nœud actuel ou qui peuvent entraîner des conflits si elles sont associées à d'autres VM de grande taille.

    Par exemple, les serveurs de base de données peuvent nécessiter de grandes quantités de mémoire ou les serveurs de stockage de fichiers peuvent nécessiter des datastores volumineux.

  • Développez des stratégies avant et après la migration pour le contenu qui ne peut pas être migré en raison de matériel ou de tags persistants, tels que les ISO montés, les tags NSX-T, les appareils passthrough qui utilisent les E/S DirectPath, les disques multi-écrivains et les RDM physiques. Un exemple de stratégie pourrait consister à envisager de convertir les RDM physiques en mode de compatibilité virtuelle.

  • Évaluez les méthodes de migration.

    Optez pour une migration groupée. Tenez compte des exigences 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 de réseau plat soit compatible avec les déploiements de connecteurs HCX et HCX Service Mesh, configurez la gestion HCX et les profils de réseau HCX sur des réseaux et VLAN distincts pour éviter les problèmes de routage et les erreurs de connectivité.

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

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

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

    Les dispositifs de service HCX, tels que HCX-IX et HCX-NE, ne nécessitent pas de sauvegardes individuelles. Un gestionnaire HCX restauré se reconnecte aux dispositifs de service existants qui ont été créés pendant la durée de la sauvegarde. Si les dispositifs de service ne sont plus fonctionnels, HCX Manager déploie de nouvelles VM de dispositifs en fonction de la configuration sauvegardée.

  • Lorsque vous étendez 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 avec ou depuis un cloud privé via une extension HCX L2, configurez le meilleur paramètre de MTU en fonction des configurations de points de terminaison VPN. Cela est particulièrement important lorsqu'une application n'est pas en mesure de contrôler la taille maximale de la charge utile.

    Google recommande un paramètre de MTU de 1 350 octets à 1 390 octets ou moins pour les interfaces de VM qui autorisent le transfert de données comme suit:

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

    Pour obtenir des conseils supplémentaires sur le calcul de la surcharge d'encapsulation, consultez les considérations relatives aux MTU et les VPN VMware NSX-T.

Étapes suivantes