Corriger les ressources avant la migration

Pendant le processus d’évaluation de la migration, l’équipe identifie les configurations qui rendraient une ressource incompatible avec le fournisseur de cloud choisi. La correction est un point de contrôle dans le processus de migration que vous pouvez utiliser pour résoudre les incompatibilités.

Cet article décrit quelques tâches de correction courantes, et vous aide à décider si la correction est un investissement judicieux.

Types de correction

Il existe deux types principaux d’activités de correction que vous devez planifier tout au long de votre déploiement.

  • Sur la base des résultats des activités d’évaluation
    • Activités de correction qui doivent être effectuées pour autoriser la réplication et le déploiement.
    • Vous avez déterminé ces activités de correction dans votre évaluation de la charge de travail pendant la phase d’évaluation. Vous devez effectuer ces tâches pour vous assurer que vous pouvez répliquer et simuler correctement votre charge de travail dans le cloud.
    • Il s’agit principalement des serveurs sources en cours de migration.
  • Sur la base des résultats des activités de test
    • Il s’agit de tester les activités de migration et d’effectuer des tests d’entreprise.
    • Ces activités de correction se concentrent sur la configuration des serveurs de destination répliqués et sur tous les services d’aide tels que les équilibreurs de charge, les réseaux virtuels et les comptes de stockage.
    • Ces tâches sont probablement plus itératives. Les tests et les corrections doivent être effectués sur plusieurs cycles jusqu’à ce que tous les cas de test soient réussis.

Suivre les activités de correction

Tout au long de l’itération, vous pouvez identifier les tâches de correction de vos charges de travail via l’évaluation ou le test. Vous devez suivre ces tâches en tant qu’activités de projet pour vous assurer qu’elles sont terminées.

Alors que les petites vagues de migration peuvent utiliser des tableurs pour suivre les éléments, les vagues plus importantes comportant de nombreuses tâches de correction génèrent de multiples éléments. Vous pouvez utiliser des outils tels qu’Azure DevOps pour créer et hiérarchiser les éléments de travail et parcourir des phases spécifiques pour vous aider à effectuer un scale-out. Même si vous n’utilisez pas Azure DevOps pour d’autres efforts, vous pouvez l’utiliser pour trier les problèmes de correction et organiser les tâches pour le processus de migration.

Lorsque vous créez ces tâches, vous devez vous assurer de les reconnecter à la charge de travail qu’elles affectent. Cela vous permet d’évaluer les charges de travail susceptibles d’être retardées par des tâches de correction. Vous pouvez ensuite classer le travail par ordre de priorité de la charge de travail.

Certains problèmes peuvent affecter plusieurs charges de travail. Il s’agit généralement d’éléments avec l’hôte, une configuration étendue ou des problèmes avec la zone d’atterrissage dans son ensemble. Ces problèmes devraient être les premiers à faire l’objet de corrections.

Tâches de correction courantes

La dette technique est une partie saine et attendue de l’environnement de l’entreprise. Les décisions architecturales adaptées à un environnement local peuvent ne pas convenir à une plateforme cloud. Dans un cas comme dans l’autre, des tâches de correction courantes peuvent être nécessaires pour préparer les ressources à la migration. Voici quelques exemples :

  • Mises à niveau mineures de l’hôte : parfois, un hôte obsolète doit être mis à niveau avant la réplication.
  • Mises à niveau mineures du système d’exploitation invité : vous devez probablement corriger ou mettre à niveau votre système d’exploitation avant la réplication.
  • Modifications du contrat de niveau de service (contrat SLA) : la sauvegarde et la récupération changent considérablement dans une plateforme cloud. Il peut être nécessaire de modifier les processus de sauvegarde des ressources migrées pour s’assurer qu’ils continuent à respecter les SLA nécessaires dans le cloud.
  • Modifications de la configuration de l’application : les applications migrées peuvent nécessiter des ajustements de variables, telles que les chemins d’accès réseau aux ressources dépendantes, les modifications de compte de service ou les mises à jour des adresses IP dépendantes.
  • Modifications mineures apportées aux chemins d’accès réseau : Il peut être nécessaire de modifier les modèles de routage pour acheminer correctement le trafic utilisateur vers les nouvelles ressources. Il ne s’agit pas d’un routage de production vers les nouvelles ressources, mais d’une configuration permettant un routage approprié vers les ressources en général.

Tâches de correction à grande échelle

Lorsqu’un centre de données est correctement entretenu et mis à jour et qu’il reçoit les correctifs appropriés, il est peu probable qu’il soit nécessaire de le corriger. Les environnements avec de nombreuses mises à jour ont tendance à être courants dans les grandes entreprises. Cela peut inclure des organisations faisant face à une diminution drastique de la taille du service informatique, un service géré hérité et des environnements aux nombreuses acquisitions. Dans chacun de ces environnements, la correction comprend une grande partie de l’effort de migration. Les tâches de correction suivantes peuvent apparaître fréquemment, ou nuire à la vitesse ou à la cohérence de la migration. Dans ce cas, répartissez la correction en un effort et une équipe parallèles, comme avec l’adoption cloud et la gouvernance cloud.

  • Mises à niveau fréquentes de l’hôte : la mise à niveau de plusieurs hôtes pour achever la migration d’une charge de travail peut retarder l’équipe de migration. Isolez les applications concernées et traitez les étapes de correction avant d’inclure les applications concernées dans des mises en production planifiées.
  • Mise à niveau fréquente du système d’exploitation invité : Les grandes entreprises ont généralement des serveurs s’exécutant sur des versions obsolètes de Linux ou Windows. Outre les risques de sécurité liés à l’exploitation d’un système d’exploitation obsolète, il existe également des problèmes d’incompatibilité qui empêchent la migration des charges de travail concernées. Lorsque plusieurs ordinateurs virtuels nécessitent une correction du système d’exploitation, essayez de séparer ces efforts en itération parallèle. Certaines mises à niveau peuvent être effectuées par les outils de migration dans le cadre du processus de migration, comme la fonctionnalité de mise à niveau de Windows Server dans Azure Migrate et la Moderniser.

Traiter les corrections à grande échelle

Étant donné que la correction de charges de travail plus petites peut être simple, choisissez des charges de travail plus petites pour vos vagues de migration initiales. À mesure que vos efforts de migration arrivent à maturité et que vous commencez à faire face à des charges de travail plus importantes, la correction peut s’avérer un processus long et coûteux. Par exemple, les efforts de correction pour une migration de Windows Server 2003 impliquant un pool de ressources de plus de 5 000 ordinateurs virtuels peuvent retarder une migration de plusieurs mois. Lorsque cette correction à grande échelle est nécessaire, il se peut que vous deviez modifier vos plans de migration des charges de travail affectées. Dans ce cas, les activités de modernisation pour maximiser la valeur des efforts de correction peuvent être plus efficaces et productives.

Les questions suivantes peuvent vous aider à prendre des décisions :

  • Toutes les charges de travail concernées par la correction ont-elles été identifiées et annotées dans le backlog de migration ?
  • Pour les charges de travail qui ne sont pas concernées, une migration produit-elle un retour sur investissement (ROI) similaire ?
  • Les ressources concernées peuvent-elles être corrigées en fonction de la chronologie de la migration d’origine ? Quel est l’effet des changements de chronologie sur le ROI ?
  • Est-il possible économiquement de corriger les ressources parallèlement aux efforts de migration ?

Si vous ne trouvez pas de réponse aux questions précédentes, envisagez les approches de modernisation suivantes :

  • Conteneurisation : certaines ressources peuvent être hébergées dans un environnement en conteneur sans être corrigées. Cela peut produire des niveaux de performance peu favorables et ne résout pas les problèmes de sécurité ou de conformité.
  • Automation : selon les exigences de charge de travail et de correction, il peut être plus rentable de générer un script du déploiement sur les nouvelles ressources à l’aide d’une approche DevOps.
  • Régénérer : lorsque les coûts de correction et la valeur commerciale sont aussi élevés l’un que l’autre, une charge de travail peut être une bonne candidate à la régénération ou à la réarchitecture.

Étape suivante