Optimiser le coût après la migration
Après avoir migré vos charges de travail vers Azure, vous devez optimiser les coûts pour vous assurer que vous n’êtes pas surdépendé. Cet article fournit des conseils sur la façon d’optimiser vos coûts après la migration et de désactiver les ressources retirées avec des interruptions d’activité minimales.
Optimiser les charges de travail migrées pour réduire les coûts
Après avoir migré vos charges de travail et désactivé des 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 pouvez constater que la charge de travail s’exécute dans Azure qu’il existe des économies de coûts supplémentaires disponibles.
Outils permettant d’optimiser les coûts
Une fois que vous avez migré vers Azure, vous disposez de nouveaux outils disponibles pour gérer vos coûts de ressources. Utilisez la liste suivante pour gérer vos dépenses cloud.
| Outil | Description | Ressource |
|---|---|---|
| Ajuster la taille des ressources | Passez en revue les métriques d’utilisation du service et rightsisez-les pour qu’elles correspondent aux exigences de charge de travail. | |
| Instances de machines virtuelles réservées Azure | Les instances réservées vous permettent de valider des ressources dans Azure qui s’exécutent fréquemment. Envisagez de réserver des instances pour les charges de travail qui restent actives. | |
| Plans d’épargne Azure | Les plans d’épargne Azure permettent d’économiser jusqu’à 65% par rapport aux tarifs de paiement à l’utilisation lorsque vous vous engagez à dépenser un montant horaire fixe sur les services de calcul pendant un ou trois ans. | |
| Gestion des coûts | Vous pouvez utiliser Microsoft Cost Management pour surveiller et gérer les coûts de l’environnement. | |
| L’infrastructure FinOps | FinOps est une discipline qui combine les principes de gestion financière avec l’ingénierie et les opérations cloud pour fournir aux organisations une meilleure compréhension de leurs dépenses cloud. |
Désaffecter les ressources supprimées
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 actifs consomment encore de l’électricité et d’autres ressources qui augmentent les coûts. Par conséquent, il est judicieux d’arrêter et de supprimer des actifs retraités pour réduire les dépenses.
L’arrêt et la suppression d’anciens biens et équipements peuvent sembler simples, mais des problèmes inattendus peuvent se produire. Voici quelques conseils sur la façon d’arrêter et de supprimer en toute sécurité les anciennes ressources sans provoquer de problèmes pour votre entreprise.
Continuer la surveillance
Une fois que vous avez promu une charge de travail migrée en production, vous devez continuer à surveiller les actifs prévus pour la mise hors service afin de vous assurer que le trafic de production est correctement routé.
Bien que les ressources soient désactivées, elles peuvent toujours utiliser le stockage, le réseau et d’autres ressources d’infrastructure. S’ils sont réactivés, ils peuvent provoquer des problèmes inattendus, sauf s’ils ont été supprimés.
Surveillez les signaux suivants pour les ressources :
- Calcul: utilisation des ressources de calcul, comme le processeur 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 inclut 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 d’activité : journaux d’activité pour Windows et les applications.
- Autres signaux: tous les autres signaux que vous avez utilisés pour surveiller les ressources lorsqu’elles ont été hébergées dans leur environnement de production précédent.
Dans 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 cohérente des signaux d’infrastructure, ainsi que l’activité réseau ou les nouveaux logs, peuvent indiquer que la ressource est toujours en cours d’utilisation.
Test des fenêtres et de la validation des dépendances
Même avec la meilleure planification, les charges de travail de production peuvent toujours contenir des dépendances sur les ressources présumées supprimées. Dans ce cas, la désactivation d’une ressource retirée peut entraîner une défaillance système inattendue. Par conséquent, traitez l’arrêt de toutes les ressources avec le même soin que l’activité de maintenance du système.
Établissez des fenêtres de test et de panne appropriées 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 de temps 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.
- Effacer les cas de test: identifiez les cas de test clairs que vous pouvez effectuer pendant la fenêtre de test correspondant 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é. Vous pouvez réutiliser les cas de test à partir de votre migration si vous les avez. Si vous avez des utilisateurs ou d’autres membres de l’équipe qui travaillent fréquemment dans l’application, essayez d’effectuer les tests.
- Planifier et communiquer : planifiez une fenêtre de maintenance pour la durée que vous avez de disponible. Vous devez viser un minimum de quatre heures.
- Planifier : programmez la fenêtre afin que les utilisateurs de l’application puissent planifier à l’avance. Deux semaines sont raisonnables.
- Communiquer : annoncez la modification à l’avance. Définissez l’attente qu’il peut y avoir une panne pendant cette fenêtre de maintenance et que le système ne soit pas réactif. Les utilisateurs ne doivent pas s’attendre à ce que l’application soit disponible pendant ce temps.
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 l’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 l’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.
- Éteignez les équipements s'ils sont toujours allumés.
- Supprimez les ressources de tous les équilibreurs de charge et confirmez 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.
- Tests réussis sans échec: les ressources ne sont pas utilisées pour l’instant.
- Communiquez une fin à la fenêtre de modification afin que les utilisateurs sachent qu’ils peuvent s’attendre à la stabilité dans l’application à nouveau.
- Passez à la section suivante une fois les tests réussis.
- Tests ont échoué: les ressources peuvent être en cours d’utilisation pour l’instant et d’autres tests sont nécessaires.
- Réactivez les ressources signalées pour la désactivation et répétez les cas de tests échoués.
- Si les cas de test continuent d’échouer, il peut y avoir un problème non lié. Vous devez tester davantage dans la fenêtre de maintenance et commencer l’escalade pour vous assurer que vous disposez du bon niveau de support.
- 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.
- Tests réussis sans échec: les ressources ne sont pas utilisées pour l’instant.
Durée de conservation et validation des données
Une fois que vous avez terminé votre fenêtre de test, toutes les ressources signalées pour la désactivation doivent être désactivées et déconnectées afin de pouvoir utiliser la charge de travail. Vous pouvez passer à la prochaine phase de désaffectation, mais ne supprimez pas immédiatement les ressources.
Envisager une période d’attente
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 plus anciennes qui ne sont pas consultées régulièrement. Conservez une ressource retirée pendant un certain temps pour servir de sauvegarde temporaire des données. Vous devez autoriser au moins 30 jours de conservation et de test avant la suppression des ressources retirées.
Prendre en compte les exigences de gouvernance des données
L’équipe de gouvernance des données de votre organisation peut avoir plus d’exigences au-delà d’une période de conservation de 30 jours.
- Comprendre les obligations de période d’attente: vous devez vérifier avec les équipes nécessaires pour comprendre l’obligation de conserver l’information et de créer une liste de contrôle de validation pour vos exigences légales spécifiques.
- Le fait d’avoir l’actif opérationnel n’est pas important pour l’instant. Au lieu de cela, les données sur les informations doivent être récupérables. 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 les conserver en tant que ressource récupérable. Vous pouvez ensuite désactiver la machine virtuelle et définir une durée d’attente pour mettre hors service la sauvegarde.
Étape suivante
La migration est terminée après la mise hors service des ressources supprimées. Cela permet d’améliorer le processus de migration avec une rétrospective pour apprendre et améliorer.