Optimiser le coût après la migration

Après avoir migré vos charges de travail vers Azure, vous devez optimiser les coûts afin de vous assurer que vous ne dépensez pas trop. Cet article fournit des conseils sur la manière d’optimiser vos coûts après la migration et sur la manière de mettre hors service les ressources retirées en limitant au maximum les interruptions d’activité.

Optimiser le coût des charges de travail migrées

Après avoir migré vos charges de travail et mis hors service les ressources inutiles, vous pouvez économiser sur les coûts en optimisant votre charge de travail en fonction de ses données actives.

Vous pouvez redimensionner les charges de travail en fonction de leurs performances lors d’une évaluation, mais vous pourriez constater, pendant que la charge de travail s’exécute dans Azure, qu’il est possible de réaliser des économies supplémentaires.

Outils pour l’optimisation des coûts

Après avoir migré vers Azure, vous disposez de nouveaux outils pour gérer le coût de vos ressources. Utilisez la liste suivante pour gérer vos dépenses cloud.

Désactiver les ressources hors service

Une fois que vous avez promu une charge de travail migrée en production, les ressources qui ont exécuté la charge de travail ne sont plus nécessaires et sont considérées comme hors service. Mais ces ressources consomment encore de l’électricité et d’autres ressources, ce qui augmente les coûts. Par conséquent, il est judicieux d’arrêter et de supprimer les ressources mises hors service afin de réduire les dépenses.

L’arrêt et la suppression de ressources et d’équipements anciens peuvent sembler simples, mais des problèmes inattendus peuvent se produire. Voici quelques conseils sur la manière de fermer et de supprimer les anciennes ressources en toute sécurité, sans causer de problèmes à votre Entreprise.

Surveillance continue

Une fois que vous avez promu une charge de travail migrée en production, vous devez continuer à surveiller les ressources dont la mise hors service est planifiée afin de vous assurer que le trafic de production est correctement acheminé.

Bien que les ressources soient désactivées, elles peuvent toujours utiliser le stockage, le réseau et d’autres ressources d’infrastructure. Si elles sont réactivées, elles peuvent provoquer des problèmes inattendus, sauf si elles ont été supprimées.

Surveillez les signaux suivants pour les ressources :

• Calcul : utilisation du calcul des ressources, comme l’UC et la RAM.
• Stockage : utilisation du stockage de ressources, comme l’entrée/sortie de disque (E/S).
• Réseau : utilisation du réseau de ressources qui comprend la mise en réseau entrante et sortante à partir d’appliances. Par exemple, inspectez les ressources qui utilisent des pare-feu et des équilibreurs de charge pour la communication.
• Journaux : journaux Windows et d’applications.
• Autres signaux : tout autre signal utilisé pour surveiller les ressources lorsqu’elles étaient hébergées dans leur environnement de production précédent.

Lors de certaines migrations, les ressources ne sont pas désactivées. Au lieu de cela, elles sont dupliquées. Des pics soudains ou même une utilisation modérée et constante des signaux de l’infrastructure, ainsi que l’activité réseau ou les nouveaux journaux, peuvent indiquer que la ressource est toujours en cours d’utilisation.

Fenêtres de test et validation des dépendances

Même avec la meilleure planification, les charges de travail de production peuvent encore contenir des dépendances à l’égard de ressources supposées mises hors service. Dans de tels cas, la désactivation d’une ressource mise hors service peut entraîner une défaillance système inattendue. Par conséquent, l’arrêt de toute ressource doit être traité avec le même soin que l’activité de maintenance du système.

Des fenêtres appropriées de test et d’interruption doivent être établies pour faciliter l’arrêt de la ressource. Vous avez besoin d’une fenêtre de maintenance pour tester correctement vos ressources avant l’arrêt. Choisissez une période pendant laquelle vous pouvez tester les ressources sans provoquer d’interruptions d’activité.

Définir une fenêtre de test et de maintenance

• Périodes à faible impact : identifiez une période à faible impact pour votre fenêtre de test. Choisissez une heure à laquelle l’utilisation de l’application est la plus basse.
• Cas de test clairs : identifiez des cas de test clairs que vous pouvez exécuter pendant la fenêtre de test qui correspond aux activités réelles effectuées par les utilisateurs de l’application. Ces activités ne doivent pas être au niveau de la surface, mais doivent plutôt mapper chaque processus utilisé. Si vous disposez des cas de test de votre migration, vous pouvez les réutiliser. Si vous avez des utilisateurs ou d’autres membres de l’équipe qui travaillent fréquemment dans l’application, demandez-leur d’effectuer les tests.
• Planifier et communiquer : planifiez une fenêtre de maintenance pour la durée dont vous disposez. Vous devez prévoir un minimum de quatre heures.
  • Planification : planifiez la fenêtre afin que les utilisateurs de l’application puissent anticiper. Deux semaines sont raisonnables.
  • Communiquer : annoncez la modification à l’avance. Expliquez qu’il peut y avoir une panne pendant cette fenêtre de maintenance et que le système peut ne pas être réactif. Les utilisateurs ne doivent pas s’attendre à ce que l’application soit disponible pendant cette période.

Avant la fenêtre de maintenance

• Effectuer des cas de test : exécutez les cas de test et surveillez toute utilisation des ressources.
  • Si vous découvrez une utilisation, vous ne devez pas poursuivre la fenêtre de maintenance. Au lieu de cela, vous devez examiner plus en détail si les ressources sont toujours en cours d’utilisation.
  • Si vous ne découvrez pas d’utilisation, vous pouvez poursuivre la fenêtre de maintenance.

Pendant la fenêtre de maintenance

• Désactiver les ressources : désactivez les ressources marquées pour la mise hors service.
  • Arrêtez les ressources si elles sont toujours sous tension.
  • Supprimez les ressources des équilibreurs de charge et vérifiez qu’elles ne sont pas en mesure de répondre aux demandes entrantes.
• Effectuer des tests : effectuez vos cas de test sur la charge de travail qui s’exécute dans Azure.
  • Les tests se sont déroulés sans problème : les ressources ne sont pas utilisées pour le moment.
    • Indiquez la fin de la fenêtre de changement afin que les utilisateurs sachent qu’ils peuvent à nouveau s’attendre à la stabilité de l’application.
    • Passez à la section suivante une fois les tests réussis.
  • Échec des tests : les ressources peuvent être en cours d’utilisation à ce moment-là et d’autres tests sont nécessaires.
    • Réactivez les ressources marquées pour la mise hors service et répétez les cas de test qui ont échoué.
    • Si les cas de test continuent d’échouer, il se peut qu’il y ait un problème indépendant. Vous devez effectuer davantage de tests au cours de la fenêtre de maintenance et vous devez également faire remonter l’information pour vous assurer que vous disposez du niveau d’assistance adéquat.
    • Si les cas de test cessent d’échouer, le problème est probablement lié. Vous devez laisser les ressources activées et fermer la fenêtre de maintenance après avoir terminé les tests.
    • Examinez le problème en dehors de la fenêtre de maintenance planifiée. Planifiez une autre fenêtre de maintenance pour les modifications apportées à la charge de travail migrée et planifiez des fenêtres de maintenance supplémentaires pour les tests.

Période de conservation et validation des données

Une fois que vous avez terminé votre fenêtre de test, toutes les ressources marquées pour la mise hors service doivent être désactivées et déconnectées afin que vous puissiez utiliser la charge de travail. Vous pouvez passer à la prochaine phase de mise hors service, mais ne supprimez pas immédiatement les ressources.

Envisager une période de conservation

Il n’est pas rare que les migrations manquent de données pendant les processus de réplication. Cela est particulièrement vrai pour les données qui ne sont pas consultées régulièrement. Conservez une ressource mise hors service pendant un certain temps pour servir de sauvegarde temporaire des données. Vous devez prévoir un délai d’au moins 30 jours de conservation et de test avant de supprimer les ressources mises hors service.

Prendre en compte les exigences de gouvernance des données

L’équipe de gouvernance des données de votre organisation peut avoir d’autres d’exigences au-delà d’une période de conservation de 30 jours.

• Comprendre les obligations relatives à la période de conservation : vous devez consulter les équipes nécessaires pour comprendre les obligations en matière de conservation des informations et créer une liste de contrôle de validation pour vos exigences légales spécifiques.
  • Il n’est pas important pour l’instant que la ressource soit opérationnelle. En revanche, les données contenues dans l’information doivent pouvoir être récupérées. Conservez les disques ou les sauvegardes pour restaurer les données si nécessaire.
  • Par exemple, si vous disposez d’un serveur de base de données SQL dans votre centre de données physique, vous pouvez sauvegarder ses données et le conserver en tant que ressource récupérable. Vous pouvez ensuite désactiver l’ordinateur virtuel et définir une durée de conservation pour mettre hors service la sauvegarde.

Étape suivante

La migration est terminée lorsque vous avez supprimé les ressources mises hors service. C’est l’occasion de perfectionner le processus de migration en procédant à une rétrospective afin d’apprendre et de s’améliorer.