Migrer des charges de travail vers Azure VMware Solution

Cet article fournit des conseils pour aider les décideurs à définir leur stratégie de migration pour Azure VMware Solution, notamment la planification, l’exécution et les phases de désaffectation.

Diagramme montrant le processus de Cloud Adoption Framework Microsoft pour l’adoption de Azure VMware Solution.

Azure VMware Solution fournit un chemin structuré pour la migration de charges de travail basées sur VMware vers Azure avec une modification minimale de l’application. La réussite dépend de plus que de déplacer des machines virtuelles. Les organisations ont besoin de stratégies de migration claires, de critères d’évaluation de charge de travail, de normes de validation et de contrôles d’exécution qui réduisent les risques, maintiennent la continuité opérationnelle et prennent en charge les objectifs de plateforme à long terme.

Recommandation : Définissez votre stratégie de migration, l’approche d’évaluation des charges de travail, la séquence de migration et les exigences de validation avant de migrer des charges de travail vers Azure VMware Solution.

1. Planification de la migration

Avant de concevoir quoi que ce soit, créez une image claire de ce que vous migrez, dans quel ordre et pourquoi. Utilisez la méthodologie Cloud Adoption Framework Plan pour évaluer votre patrimoine. Azure VMware Solution convient le mieux à une approche de réhébergement, où vous avez besoin d’une interruption minimale et aucune modernisation à court terme. Ce n’est pas le bon environnement pour toutes les applications, et c’est au cours de la phase de planification que vous en déciderez.

1.1 Découverte et inventaire

Azure Migrate analyse votre environnement vSphere local et génère un inventaire des machines virtuelles, de leur utilisation des ressources et de leurs dépendances. Ces données informent le dimensionnement (nombre d’hôtes et le type d’hôte) et la planification des vagues (les charges de travail qui se déplacent ensemble). Azure Migrate n'effectue pas le déplacement dans Azure VMware Solution. Il vous donne la preuve de la taille et de la séquence du projet.

1.2 Stratégie de migration

Azure VMware Solution prend principalement en charge l’approche de réhébergement. Les applications qui ont besoin d’un traitement de refactorisation ou de rearchitecture peuvent être mieux prises en charge par le calcul natif Azure. Enregistrez ces décisions afin que le plan reflète les choix délibérés plutôt que les valeurs par défaut. Consultez Sélectionner une stratégie de migration cloud.

1.3 Évaluation de la charge de travail

Chaque charge de travail n’est pas un candidat tout aussi approprié pour Azure VMware Solution. Avant d’affecter des charges de travail à des vagues de migration, évaluez leurs exigences techniques, leurs dépendances opérationnelles et leur adéquation de plateforme. Une évaluation structurée vous permet d’identifier les risques précoces, de valider l’adéquation et de s’assurer que les plans de migration reflètent les priorités de l’entreprise plutôt que les hypothèses.

1.3.1 Configuration requise

Avant d’affecter une charge de travail à une vague de migration, évaluez les exigences techniques, opérationnelles et métier qui influencent son succès sur Azure VMware Solution. Cette évaluation vous aide à déterminer l’adéquation de la plateforme, à identifier les défis potentiels de migration et à fournir les informations nécessaires au dimensionnement, au séquencement et aux décisions de préparation. Lors de l’évaluation de chaque charge de travail, concentrez-vous sur :

  • Exigences en matière de performances : Comprendre les demandes de processeur, de mémoire, d’IOPS de stockage et de débit réseau. Associez ces exigences aux références SKU d’hôte Azure VMware Solution et aux stratégies de stockage vSAN, y compris la configuration RAID et les paramètres de pannes à tolérer (FTT).

  • Dépendances d’application : Identifiez les systèmes avec lesquels chaque charge de travail communique. Les dépendances déterminent la planification des vagues de migration et indiquent si les systèmes dépendants doivent se déplacer ensemble.

  • Exigences de compatibilité : Vérifiez que les systèmes d’exploitation invités et les logiciels tiers sont pris en charge sur Azure VMware Solution. La plupart des charges de travail qui fonctionnent sur un environnement vSphere local fonctionnent sur Azure VMware Solution sans modification, mais il convient de le vérifier plutôt que de le supposer, et de veiller à tester votre stratégie de retour arrière pour les migrations problématiques.

  • Configuration réseau requise : Documentez les segments réseau, les adresses IP, les configurations DNS et les règles de pare-feu dont chaque charge de travail a besoin. Identifiez les charges de travail sensibles à la latence et assurez-vous que l’architecture réseau est optimisée pour prendre en charge leurs demandes.

1.3.2 Traitement de la charge de travail

L’évaluation de la charge de travail identifie les besoins d’une charge de travail. Le traitement de la charge de travail détermine l’action à entreprendre. Les décideurs doivent évaluer si chaque application appartient à Azure VMware Solution, s’il doit rester en local ou si certaines parties de l’application sont mieux prises en charge par les services natifs Azure. Pour chaque charge de travail, déterminez :

  • Indique si la charge de travail y appartient. Les charges de travail qui s’exécutent déjà bien sur vSphere sont des candidats naturels, en particulier ceux sans plan de modernisation à court terme. Pour une charge de travail destinée à être retirée ou remplacée par une solution SaaS, évaluez si sa migration apporte de la valeur ou s’il vaut mieux la laisser en l’état jusqu’à sa fin de vie.

  • Indique si chaque niveau appartient à cet emplacement. Une charge de travail comporte souvent plusieurs niveaux, tels qu’un serveur frontal web et une base de données. Vous pouvez exécuter les machines virtuelles d’application sur Azure VMware Solution et les connecter à des services de données natifs Azure tels que Azure SQL Database. Cette configuration vous offre des avantages de base de données managée en même temps que vos charges de travail VMware et réduit les coûts de votre hôte et de votre licence VMware.

1.4 Préparation de la migration

Définissez les exigences minimales en matière d’exploitation, de performances, de sécurité et de gouvernance que chaque charge de travail doit respecter avant de l’approuver pour une utilisation en production.

Appliquez une infrastructure de validation cohérente à chaque vague de migration. Le cadre doit définir les vérifications requises, les critères d’approbation et les éléments de preuve que les équipes doivent fournir avant l’approbation du basculement. Au minimum, validez :

  • État de la réplication HCX

  • Routabilité du segment NSX

  • État de santé de l’hôte ESXi

  • Accessibilité de l’identité et de l’authentification à partir du segment cible

  • État des services de support tels que la sauvegarde et la supervision

Déterminez si les équipes doivent capturer les métriques de performances de référence à partir de l’environnement source avant la migration. Ces mesures fournissent un point de référence pour valider les performances après la migration et identifier les régressions.

Avant le basculement, demandez aux équipes de déterminer si des enregistrements DNS externes, des configurations d’équilibreur de charge, des points de terminaison d’application ou d’autres dépendances de connectivité nécessitent des mises à jour. Incluez toutes les modifications requises dans le plan de basculement par vague afin de réduire le risque d’interruption de service.

Séquence de migration Azure VMware Solution 1.5

Le séquencement de migration détermine les charges de travail qui passent à Azure VMware Solution premier, deuxième, et ainsi de suite. Une bonne planification des vagues réduit les risques et évite les perturbations inutiles.

  • Regrouper par dépendance : Utilisez les données de dépendance de la découverte pour rechercher des ensembles de machines virtuelles qui fonctionnent en étroite collaboration, comme un serveur d’applications et sa base de données. Déplacez-les dans la même vague afin que le trafic ne traverse pas le réseau pour chaque requête quand une partie attend toujours localement.

  • Mapper les règles existantes : Documentez toutes les règles d’affinité ou d’anti-affinité à partir de votre environnement local et planifiez leur reproduction. Les stratégies de placement d’Azure VMware Solution imposent l’affinité entre machines virtuelles et hôtes, ce qui est important pour les contraintes de licence, comme celles de SQL Server, et pour des exigences strictes en matière de performances.

  • Séquence par risque : Commencez par des charges de travail à faible risque, telles que des systèmes ou des applications hors production avec peu de dépendances. Votre équipe est confiante avec le processus avant de prendre en charge les applications critiques pour l’entreprise. Passez à des charges de travail plus complexes à mesure que l’expérience augmente.

  • Alignez-vous sur les plans d’extension du réseau : Définissez votre séquence en fonction de la topologie de votre réseau local. Lorsque plusieurs applications partagent un segment réseau, migrez-les dans la même vague ou dans des vagues consécutives. Vous pouvez ensuite basculer rapidement le segment vers un réseau natif d’Azure VMware Solution et supprimer l’extension temporaire.

1.6 Outils de migration

Utilisez VMware HCX pour déplacer des charges de travail vers Azure VMware Solution avec une interruption minimale. HCX Enterprise est inclus sans frais supplémentaires et installé par défaut, ce qui déverrouille les options telles que Replication Assisted vMotion et Mobility Optimized Networking. Vous n’avez pas besoin d’utiliser HCX, et vous pouvez également migrer des charges de travail physiques à l’aide d’une solution de migration d’un partenaire.

1.6.1 Approche de migration

vMotion déplace une charge de travail en cours d’exécution sans interruption de service et, sur Generation 2, est généralement plus rapide que les méthodes de transfert en bloc. La migration en bloc et assistée par la réplication peut s’exécuter plus lentement sur la génération 2 aujourd’hui. Prévoyez donc des fenêtres plus longues et planifiez les vagues en conséquence. Consultez les considérations relatives à la conception du cloud privé Azure VMware Solution de génération 2.

1.6.2 Gouvernance des extensions réseau

Certaines équipes traitent l’extension réseau comme une conception permanente. Ce n’est pas le cas. Conservez les extensions ouvertes uniquement pour la fenêtre de migration. L’extension réseau HCX étend un réseau local en Azure VMware Solution au niveau de la couche 2, ce qui permet aux charges de travail de conserver leurs adresses existantes pendant le déplacement. Cette conception évite de reconfigurer les applications à l’avance et comporte des compromis qu’un décideur doit régir.

  • Dépendance locale. Un réseau étendu conserve généralement sa passerelle locale, de sorte que la charge de travail dépend toujours du site source après son déplacement.

  • Routage inefficace. Le trafic peut faire un aller-retour vers l’environnement local, selon un schéma appelé « tromboning », qui augmente la latence et multiplie les points de défaillance.

Définir une stratégie ferme. Étendez un réseau uniquement lorsqu’une charge de travail ne peut pas modifier son adresse et supprimez chaque extension une fois que ses charges de travail sont déplacées. Évaluez d’abord votre réseau local pour savoir quels segments ont besoin d’une extension et pendant combien de temps. Cette évaluation alimente à la fois votre plan d’onde et votre chronologie d’extension. La mise en réseau optimisée pour la mobilité peut réduire l’effet trombone dans certains cas ; assurez-vous donc de vérifier les configurations prises en charge avant de l’activer. Consultez Configurer l’extension réseau HCX.

2. Préparation de la migration

La séquence de déploiement suivante reflète les dépendances entre les phases. Chaque étape suppose que l’étape précédente est terminée et validée.

  1. Zone d’atterrissage de la plateforme : Vérifiez que tous les services de mise en réseau, d’identité, de sécurité et de surveillance centralisés requis sont prêts à s’intégrer aux charges de travail VMware Azure. Appliquez les bases de référence de gouvernance et de sécurité via Azure Policy à votre hiérarchie de groupe d’administration qui vous aident à atteindre vos exigences de conformité. La génération 2 est déployée sur votre réseau virtuel. Par conséquent, une ligne de base de stratégie qui applique des règles strictes sur les groupes de sécurité réseau ou les tables de routage peut bloquer le déploiement. Supprimez ces stratégies spécifiques du réseau virtuel du cloud privé avant de déployer, puis réappliquez-les ensuite. Planifiez cette exception dans votre base de référence afin que la gouvernance ne bloque pas le déploiement.

  2. Zones d’atterrissage : Placez vos zones d’atterrissage de charge de travail (abonnements) dans le groupe d’administration approprié, qu’il soit en ligne ou interne (« Corp »).

  3. Plages d’adresses IP : Réservez un bloc d’adresses /22 minimum pour le cloud privé. Pour la génération 2, réservez également deux blocs d’adresses IP /24 supplémentaires pour la gestion HCX et la liaison montante. Vérifiez qu’aucune de ces plages ne chevauche votre espace d’adressage cloud local, Azure ou autre. Vous ne pouvez pas corriger facilement cette condition après le déploiement. Consultez les considérations relatives à la conception de la génération 2.

  4. Demande de quota : Demander un quota tôt, car l’allocation peut prendre jusqu’à cinq jours ouvrables. Prévoyez des ressources suffisantes pour la croissance et la reprise après sinistre, par exemple une redondance N+1, soit un hôte de plus que ce dont la charge de travail a besoin. Confirmez la licence Portable VMware Cloud Foundation requise pour les nouveaux déploiements. Consultez Demander un quota d’hôte.

  5. Déploiement du cloud privé Azure VMware Solution : Déployez le cloud privé de génération 2 dans son réseau virtuel Azure. Consultez Créer un cloud privé de génération 2.

  6. Configuration de la mise en réseau et de l’identité : Appairez le réseau de cloud privé à votre hub et établissez une connectivité locale. Connectez vCenter Server à votre source d’identité externe afin que les administrateurs se connectent avec des comptes managés au lieu d’informations d’identification intégrées partagées.

  7. Surveillance et gestion : Transférez les journaux à votre solution de gestion des journaux et configurez les alertes Service Health. Intégrez des machines virtuelles invitées via Azure Arc afin de pouvoir les régir avec les mêmes outils Azure que vous utilisez ailleurs.

  8. Installation HCX : Installez HCX et testez la connectivité de site à site avant de commencer la première vague.

3. Exécution de la migration

Définissez ce que signifie « fait » avant chaque vague. Une vague est terminée lorsque la charge de travail est validée, que l’extension réseau est supprimée et que l’application est saine dans son état permanent.

Définissez les critères de retour arrière avant chaque vague et testez la procédure de retour arrière avant de migrer les systèmes de production. HCX prend en charge la migration inversée et l’approche exacte dépend du type de migration que vous avez utilisé. Les critères de réussite des vagues sont les suivants :

  1. Chaque machine virtuelle de la vague s’exécute sur Azure VMware Solution et ne dépend plus de l’extension réseau pour le trafic de production.

  2. Chaque application est accessible par ses utilisateurs et ses systèmes dépendants.

  3. Chaque machine virtuelle apparaît dans vos outils de surveillance sans avertissements ni erreurs.

  4. Le retour arrière n’est plus nécessaire et vous pouvez le clôturer officiellement.

  5. Les performances de l’application correspondent aux performances de référence ou les dépassent.

  6. Les charges de travail répondent à vos exigences de sécurité et de conformité.

  7. La charge de travail a été correctement intégrée aux solutions de sauvegarde et de récupération d’urgence.

4. Évaluation et désactivation de la migration

La migration ne se termine pas lorsque les charges de travail sont activées dans Azure VMware Solution. Vérifiez que les charges de travail fonctionnent correctement dans leur nouvel environnement, vérifiez que les hébergements de migration temporaire sont supprimés et retirent formellement l’infrastructure source. Le maintien de votre infrastructure sur site peut engendrer des dépendances inconnues et non documentées. Un processus d’évaluation et de mise hors service discipliné permet à l’organisation de réaliser les avantages attendus de la migration sans porter de coûts opérationnels ou de risques inutiles.

4.1 Préparation de la production après basculement

Définissez des critères post-basculement confirmant que la charge de travail se comporte comme prévu. Vérifiez l’accessibilité du réseau et la résolution de noms. Vérifiez la fonction d’application et la communication avec les systèmes dépendants. Une fois chaque machine virtuelle déplacée, vérifiez qu’elle démarre, que ses ressources correspondent au plan et que la stratégie de stockage appropriée s’applique. Comparez les performances à la base de référence de pré-migration.

Décidez de votre stratégie de parité. La décision clé est de savoir si une charge de travail migrée doit atteindre une parité complète avec l’état local avant de l’appeler prêt pour la production, ou si vous autorisez des écarts temporaires. De nombreuses organisations demandent une parité immédiate des performances pour les systèmes côté client, mais accordent aux applications internes une courte période de stabilisation avec une échéance de correction fixe.

Validation de la connectivité 4.2

Validez la connectivité de bout en bout sur l’ensemble d’Azure VMware Solution, d’Azure, de l’environnement local, d’Internet et de la résolution de noms. Exécutez des tests de validation élémentaire de l’application afin de vérifier que la charge de travail remplit sa fonction. Vérifiez si les enregistrements de noms externes ou les paramètres d’équilibreur de charge ont besoin de mises à jour dans le cadre du basculement.

Si vous avez créé une instance secondaire de Azure VMware Solution pour la récupération d'urgence, assurez-vous qu'elle est accessible à partir de l'instance principale et de tous les clients ou services de prise en charge qui doivent se connecter à celui-ci s'il est activé.

4.3 Dissolution de l’extension réseau

Une fois que toutes les charges de travail d’un segment étendu ont été déplacées, supprimez l’extension de couche 2 HCX et confirmez que la passerelle native d’Azure VMware Solution effectue correctement le routage. Ne laissez pas une extension en place au-delà de la durée nécessaire à la migration.

4.4 Désactiver l’environnement source

La désaffectation libère formellement la capacité source, les licences et la couverture opérationnelle. Traitez-le comme un transfert régi plutôt qu’une tâche de nettoyage. Si vous faites l’impasse sur la mise hors service, vous payez pour des infrastructures inutilisées et vous maintenez un risque de sécurité. Utilisez la désactivation des charges de travail sources après la migration vers le cloud pour définir l’ordre des opérations, la période de rétention des sauvegardes sources, les approbations nécessaires à la mise hors tension des systèmes sources et les critères de récupération des licences et du matériel.

Étapes suivantes

Conception de la charge de travail :

  • Last updated on