Migrer vers Google Cloud : bonnes pratiques pour valider un plan de migration

Last reviewed 2024-11-08 UTC

Ce document décrit les bonnes pratiques pour valider le plan de migration de vos charges de travail vers Google Cloud. Ce document ne répertorie pas toutes les bonnes pratiques possibles pour valider un plan de migration, et ne constitue pas une garantie de résultat. Sa fonction est de vous aider à susciter le débat sur les modifications et améliorations potentielles de votre plan de migration.

Ce document est utile si vous planifiez une migration vers Google Cloud depuis un environnement sur site, un environnement d'hébergement privé ou un autre fournisseur cloud. Ce document est également utile si vous souhaitez évaluer une opportunité de migration, et découvrir à quoi elle pourrait ressembler.

Ce document fait partie d'une série d'articles sur la migration vers Google Cloud:

Évaluation

L'évaluation complète de vos charges de travail et environnements vous aide à acquérir une connaissance approfondie de vos charges de travail et de vos environnements. L'acquisition de ces connaissances va vous aider à réduire les risques de problèmes pendant et après votre migration vers Google Cloud.

Effectuer une évaluation complète

Avant de passer aux étapes qui suivent la phase d'évaluation, effectuez l'évaluation de vos charges de travail et environnements. Pour effectuer une évaluation complète, tenez compte des éléments suivants, qui sont souvent négligés :

  • Inventaire : assurez-vous que l'inventaire des charges de travail à migrer est à jour et que vous en avez effectué l'évaluation. Tenez compte par exemple du degré d'actualisation et de la fiabilité des données sources pour votre évaluation, ainsi qu'aux lacunes qui pourraient exister dans ces données.

  • Temps d'arrêt : identifiez les charges de travail pouvant se permettre de subir un temps d'arrêt et la durée maximale de ces temps d'arrêt. Il est plus difficile de migrer des charges de travail avec des temps d'arrêt nuls ou quasi-nuls que des charges de travail qui peuvent se permettre de subir des temps d'arrêt. Pour effectuer une migration sans temps d'arrêt, vous devez concevoir et mettre en œuvre une redondance pour chaque charge de travail à migrer. Vous devez également coordonner ces instances redondantes.

    Lorsque vous évaluez les temps d'arrêt pouvant être supportés par une charge de travail, déterminez si les avantages commerciaux d'une migration sans temps d'arrêt sont supérieurs à la complexité accrue de la migration. Dans la mesure du possible, évitez de définir une exigence de temps d'arrêt nuls pour une charge de travail.

  • Clustering et redondance : évaluez les charges de travail compatibles avec le clustering et la redondance. Si une charge de travail est compatible avec le clustering et la redondance, vous pouvez déployer plusieurs instances de cette charge, même dans différents environnements, tels que l'environnement source et l'environnement cible. Les déploiements en cluster et redondants peuvent simplifier la migration, car ces charges de travail se coordonnent entre elles avec une intervention limitée.

  • Mises à jour de la configuration : évaluez la manière dont vous mettez à jour la configuration de vos charges de travail. Par exemple, réfléchissez à la manière de diffuser les mises à jour de la configuration de chaque charge de travail que vous souhaitez migrer. Ce point est essentiel au succès de votre migration, car vous devrez peut-être mettre à jour la configuration de vos charges de travail pendant leur migration vers l'environnement cible.

  • Générer plusieurs rapports d'évaluation : pendant la phase d'évaluation, il peut être utile de générer plusieurs rapports d'évaluation pour tenir compte de différents scénarios. Par exemple, vous pouvez générer des rapports pour prendre en compte différents profils de charge pour vos charges de travail (horaires de pics d'activité et de faible activité, par exemple).

Évaluer les modes de défaillance acceptés par vos charges de travail

Connaître le comportement de vos charges de travail dans des circonstances exceptionnelles vous permet de vous assurer de ne pas les exposer à des conditions empêchant toute faculté de récupération. Pour l'évaluation, rassemblez des informations sur les modes de défaillance et leurs effets, qui sont acceptés par vos charges de travail et compatibles avec une récupération automatique, et sur les modes de défaillance nécessitant votre intervention. Par exemple, vous pouvez commencer par vous poser des questions sur les modes de défaillance possibles, telles que celles-ci :

  • Que se passe-t-il si une charge de travail perd la connectivité au réseau ?
  • Une charge de travail peut-elle reprendre là où elle s'était arrêtée après son arrêt ?
  • Que se passe-t-il si les performances d'une charge de travail ou de ses dépendances sont inappropriées ?
  • Que se passe-t-il si l'architecture mêle deux charges de travail ayant le même identifiant ?
  • Que se passe-t-il si une tâche planifiée n'est pas exécutée ?
  • Que se passe-t-il si deux charges de travail traitent la même requête ?

Le plan de migration lui-même constitue une autre source de modes de défaillance non acceptés. Déterminez si votre plan de migration inclut des étapes qui dépendent de la validation d'une condition particulière, et s'il inclut une planification de contingence en cas de condition non validée. Un plan qui inclut ces types de conditions peut indiquer que le plan lui-même peut échouer ou que des composants individuels peuvent échouer lors de la migration.

Après avoir évalué ces modes de défaillance et leurs effets, validez vos résultats dans un environnement non critique en simulant des défaillances et en injectant des pannes qui émulent ces modes de défaillance. Par exemple, si une charge de travail est conçue pour assurer une récupération automatique après une perte de connectivité réseau, validez la récupération automatique en procédant à une interruption forcée de la connectivité et en la restaurant par la suite.

Évaluer vos pipelines de traitement de données

Votre évaluation de la charge de travail doit pouvoir apporter des réponses aux questions suivantes :

  • Les ressources sont-elles correctement dimensionnées pour la migration ?
  • Combien de temps faut-il pour migrer les données nécessaires à vos charges de travail ?
  • L'environnement cible peut-il gérer l'intégralité du volume de données ?
  • Comment vos charges de travail se comportent-elles lorsqu'elles doivent gérer les pics de demande ou les pics de quantité de données qu'elles produisent sur une période spécifique ?
  • En cas de pics de demande ou de pics dans la quantité de données produites par vos charges de travail, ceux-ci produisent-ils des effets négatifs, tels qu'une latence accrue ou des retards dans les réponses ?
  • Une fois vos charges de travail démarrées, ont-elles besoin d'un certain délai pour atteindre les niveaux de performances attendus ?

Les résultats de cette évaluation constituent souvent des modèles de la demande satisfaite par vos charges de travail, ainsi que des données produites par celles-ci sur une période donnée. Lorsque vous collectez des points de données pour produire de tels modèles, pensez qu'ils peuvent varier considérablement entre les périodes de pic et les périodes creuses. Pour en savoir plus sur les méthodes de surveillance et les éléments à surveiller, consultez la page Objectifs de niveau de service dans le manuel sur l'ingénierie de la fiabilité des sites.

Vous assurer de pouvoir mettre à jour et déployer chaque charge de travail à migrer

Pendant la migration, vous devrez peut-être mettre à jour certaines des charges de travail que vous migrez. Par exemple, vous devrez peut-être déployer un correctif pour un problème ou effectuer un rollback sur une modification récente qui pose problème. Pour chaque charge de travail que vous migrez, assurez-vous de pouvoir appliquer et déployer des modifications. Par exemple, si vous migrez une charge de travail pour laquelle vous disposez du code source, assurez-vous d'avoir accès à ce code source, et de pouvoir compiler, empaqueter et déployer le code source si nécessaire.

Votre migration peut inclure des charges de travail auxquelles vous ne pouvez pas appliquer ni déployer de modifications (telles que des logiciels propriétaires). Dans ce scénario, refactorisez votre plan de migration afin d'y intégrer les démarches supplémentaires à mener afin d'atténuer les problèmes qui pourraient survenir après la migration de ces charges de travail.

Évaluer votre infrastructure réseau

Une infrastructure réseau fonctionnelle est essentielle à une migration réussie. Vous pouvez utiliser l'infrastructure réseau comme l'un de vos outils de migration. Par exemple, vous pouvez utiliser des équilibreurs de charge et des serveurs DNS pour diriger le trafic en fonction de votre plan de migration.

Pour éviter les problèmes lors de la migration, il est important d'évaluer votre infrastructure réseau et d'évaluer dans quelle mesure elle peut accepter votre migration. Par exemple, vous pouvez commencer par vous poser ces questions sur votre infrastructure d'équilibrage de charge :

  • Que se passe-t-il lorsque vous reconfigurez vos équilibreurs de charge ?
  • Combien de temps faut-il pour que la configuration mise à jour soit prise en compte ?
  • Lors d'une migration sans temps d'arrêt, que se passe-t-il si vous obtenez un pic de trafic avant que la configuration mise à jour ne soit effective ?

Une fois que vous avez abordé les questions concernant votre infrastructure d'équilibrage de charge, posez-vous ensuite les questions suivantes sur votre infrastructure DNS :

  • Quels enregistrements DNS devez-vous mettre à jour pour qu'ils pointent vers l'environnement cible, et quand les mettre à jour ?
  • Quels sont les clients utilisant ces enregistrements DNS ?
  • Comment la valeur TTL (Time To Live) est-elle configurée pour les enregistrements DNS à mettre à jour ?
  • Pouvez-vous définir la valeur TTL des enregistrements DNS sur son minimum pendant la migration ?
  • Vos clients DNS respectent-ils la valeur TTL des enregistrements DNS à mettre à jour ? Par exemple, vos applications disposent-elles d'une mise en cache DNS côté client qui ignore la valeur TTL que vous avez configurée pour la migration ?
  • Détectez-vous du trafic dirigé vers votre environnement source même après avoir terminé la migration ?

Planification des migrations

Une planification minutieuse de votre migration vous permet d'éviter les problèmes pendant et après celle-ci. La planification vous aide également à tenir compte des tâches imprévues.

Développer une stratégie de rollback pour chaque étape du plan de migration

Au cours de la migration, chacune des étapes du plan de migration que vous exécutez peut entraîner des problèmes imprévus. Pour vous assurer de pouvoir résoudre ces problèmes, préparez une stratégie de rollback pour chaque étape du plan de migration. Pour éviter de perdre du temps lors d'une panne, procédez comme suit :

  • Assurez-vous que vos stratégies de rollback fonctionnent, en examinant et en testant régulièrement chacune d'elles.
  • Définissez une durée d'exécution maximale autorisée pour chaque étape de la migration. Une fois ce délai d'exécution autorisé écoulé, vos équipes vont procéder au rollback de l'étape de migration.

Même si des stratégies de rollback sont prêtes pour chaque étape du plan de migration, certaines de ces étapes peuvent être potentiellement perturbatrices. Une étape potentiellement perturbatrice peut engendrer une perte, de quelque nature que ce soit, même en cas de rollback, par exemple une perte de données. Identifiez les étapes du plan de migration qui sont potentiellement perturbatrices.

Si vous avez automatisé une étape du plan de migration, assurez-vous de disposer d'une procédure planifiée pour chaque étape automatisée, en cas d'échec de l'automatisation. Comme pour les stratégies de rollback, examinez et testez régulièrement chaque procédure planifiée.

Si vous configurez des canaux de communication pour la migration, afin de vous assurer de ne pas être tenu à distance de votre environnement, provisionnez des canaux de secours que vous pouvez utiliser pour effectuer une récupération après une défaillance. Par exemple, si vous configurez une interconnexion partenaire lors de la migration, vous pouvez également configurer un accès de secours via l'Internet public en cas de problème lors du provisionnement et de la configuration.

Planifier des déploiements progressifs

Pour réduire l'ampleur des problèmes pouvant survenir lors de la migration, évitez les changements à grande échelle et concevez votre plan de migration dans une optique de déploiement progressif des modifications. Par exemple, planifiez des déploiements et des modifications de configuration progressifs.

Si vous envisagez d'effectuer des déploiements progressifs, réduisez le nombre et la taille de ces modifications afin de réduire le risque de problèmes imprévus résultant de l'application des modifications. Après avoir identifié et résolu les problèmes dans votre premier déploiement de faible envergure, vous pouvez effectuer les déploiements suivants pour des modifications similaires, mais à plus grande échelle.

Alerter les équipes DevOps

Pour réduire l'impact des problèmes pouvant survenir lors d'une migration, avertissez les équipes responsables de la migration des charges de travail. Alertez également les équipes responsables de l'infrastructure des environnements source et cible.

Si vos équipes travaillent dans des fuseaux horaires différents, vérifiez les points suivants :

  • Vos équipes couvrent correctement ces fuseaux horaires et couvrent plusieurs périodes de travail consécutives, car elles peuvent ne pas être en mesure de résoudre les problèmes au cours d'une seule période de travail posté.
  • Vos équipes sont prêtes à collecter des informations détaillées sur les problèmes auxquels elles pourraient être confrontées. Cette collecte va fournir aux ingénieurs en poste lors de la prochaine période de travail une vision complète des actions et motivations de l'équipe qui les a précédés.
  • Des membres spécifiques de vos équipes ont été désignés pour assumer la responsabilité d'une période de travail donnée.

Supprimer les ressources de démonstration de faisabilité de l'environnement de production cible

Pour l'évaluation, vous avez peut-être utilisé l'environnement cible pour héberger des tests et des démonstrations de faisabilité. Avant la migration, supprimez les ressources que vous avez créées lors de ces tests et démonstrations de faisabilité dans la zone de production de l'environnement cible.

Vous pouvez conserver les ressources dans une zone hors production de l'environnement cible tandis que la migration est en cours, car elles peuvent vous aider à collecter des informations sur tout problème pouvant survenir pendant la migration. Par exemple, pour diagnostiquer les problèmes qui affectent vos charges de travail de production après la migration, vous pouvez comparer les journaux de configuration et de données de la charge de travail de production aux journaux de configuration et de données des démonstrations de faisabilité et des tests.

Une fois la migration terminée, et après avoir vérifié que l'environnement cible fonctionne comme prévu, vous pouvez supprimer les ressources dans la zone hors production de l'environnement cible.

Définir des critères pour supprimer l'environnement source en toute sécurité

Pour éviter de devoir payer indéfiniment pour l'exécution infinie de deux environnements, définissez les conditions qui doivent être remplies pour supprimer l'environnement source en toute sécurité, par exemple :

  • Toutes les charges de travail, y compris leurs sauvegardes et leurs mécanismes de haute disponibilité et de reprise après sinistre, ont été correctement migrés vers l'environnement cible.
  • Les données migrées dans l'environnement cible sont cohérentes, accessibles et exploitables.
  • La précision et l'exhaustivité des données migrées respectent la norme définie.
  • Les ressources restantes dans l'environnement source ne sont pas des dépendances associées à des charges de travail qui ne relèvent pas du champ d'application de la migration.
  • Les performances de vos charges de travail dans l'environnement cible respectent vos cibles de contrat de niveau de service.
  • Vos systèmes de surveillance indiquent qu'il n'y a aucun trafic réseau vers l'environnement source qui doive être redirigé vers l'environnement cible.
  • Après avoir vérifié que les charges de travail s'exécutent sans problème dans l'environnement cible pendant une période que vous aurez définie, vous êtes certain de ne plus avoir besoin de revenir à l'environnement source.

Opérations

Pour gérer efficacement l'environnement source et cible pendant la migration, vous devez également concevoir vos processus opérationnels.

Surveiller vos environnements

Pour observer le comportement de vos environnements source et cible et vous aider à diagnostiquer les problèmes au fur et à mesure qu'ils surviennent, configurez les éléments suivants :

  • Un système de surveillance permettant de collecter des métriques utiles pour votre scénario.
  • Un système de journalisation permettant d'observer le flux des opérations effectuées par vos charges de travail et les autres composants de vos environnements.
  • Un système d'alerte qui vous avertit avant qu'un événement problématique ne se produise.

Google Cloud Observability accepte l'intégration de fonctionnalités de surveillance, de journalisation et d'alerte pour votre environnement Google Cloud.

Étant donné qu'une charge de travail et ses dépendances couvrent plusieurs environnements, vous devrez peut-être envisager d'utiliser plusieurs outils de surveillance et d'alerte pour différents environnements. Tenez compte du moment auquel vous migrez les règles de surveillance et d'alerte sous-jacentes à vos charges de travail. Par exemple, si votre environnement source est configuré pour vous avertir lorsqu'un serveur spécifique est indisponible, l'alerte va se déclencher lorsque vous désactivez intentionnellement ce serveur. Le déclenchement de l'alerte est un comportement certes attendu, mais inutile dans ce contexte. Pour la migration, vous devez ajuster en permanence les alertes pour l'environnement source et les reconfigurer pour l'environnement cible.

Gérer la migration

Pour gérer la migration, vous examinez ses performances afin de collecter des informations que vous pourrez utiliser à titre rétrospectif, une fois la migration terminée. Une fois les informations collectées, vous pouvez vous en servir pour analyser les performances de la migration et préparer les points de données concernant les améliorations potentielles à apporter à vos environnements.

Par exemple, pour commencer à planifier la gestion de la migration, posez-vous les questions suivantes :

  • Combien de temps a pris chaque étape du plan de migration ?
  • Certaines étapes du plan de migration ont-elles pris plus de temps que prévu ?
  • Y a-t-il eu certaines étapes ou vérifications qui n'ont pas été menées, et qui auraient dû l'être ?
  • Des événements défavorables se sont-ils produits lors de la migration ?

Étape suivante

Contributeurs

Auteur: Marco Ferrari | Architecte de solutions cloud