Redimensionnement des VM Azure : un guide pratique

Le redimensionnement des VM Azure est la pratique consistant à faire correspondre la taille d'une machine virtuelle, son SKU, au processeur, à la mémoire et au réseau qu'elle utilise réellement, plutôt qu'à la taille à laquelle elle a été déployée. Dans la plupart des parcs, certaines machines ont été dimensionnées pour un pic de lancement ou reprises d'un matériel sur site, et fonctionnent sous ce plafond depuis. Pour redimensionner correctement les machines virtuelles Azure, vous collectez des preuves d'utilisation sur une période représentative, généralement 30 jours, trouvez les machines dont l'usage soutenu et de pointe se situe bien en dessous de leur capacité provisionnée, puis les faites passer à un SKU plus petit avec une marge raisonnable. Menée avec des preuves plutôt qu'avec une intuition, c'est l'une des façons les plus reproductibles de réduire le coût de calcul Azure pendant que la charge de travail continue de fonctionner.

Ce guide parcourt la boucle complète : pourquoi les machines finissent surdimensionnées, comment collecter les preuves, lire les recommandations d'Advisor, choisir une taille cible, redimensionner une VM Azure en toute sécurité, et consigner le résultat. Les chiffres sont directionnels, car ils dépendent de votre parc, mais la méthode s'applique partout.

Pourquoi les machines virtuelles finissent surdimensionnées

Le surdimensionnement commence rarement comme une erreur. Il commence comme une prudence qui n'est jamais réexaminée.

• Dimensionnée pour le pic de lancement. Une machine est provisionnée pour le jour le plus chargé qu'elle pourrait connaître, une bascule de migration, un lancement, un pic saisonnier, puis le jour chargé passe et la taille reste.
• Habitudes de lift-and-shift. Lorsqu'une charge de travail migre depuis un serveur physique ou sur site, les équipes reproduisent souvent les anciens décomptes de cœurs et de mémoire à l'identique, même si cette machine avait elle-même été achetée avec des années de marge intégrées.
• La marge comme assurance. Une taille plus grande semble plus sûre qu'un choix qui s'avère un peu juste, de sorte que l'option en apparence plus sûre l'emporte par défaut.
• Personne ne prend en charge la revue. La taille est fixée une fois au déploiement et jamais confrontée à ce que fait la machine, de sorte que la facture reflète discrètement une décision qui n'est plus valable.

Aucune de ces raisons n'est déraisonnable sur le moment. Le problème, c'est que le moment prend fin, mais pas la taille.

Collecter les preuves avec Azure Monitor

Redimensionner sans données, c'est deviner avec des étapes en plus, alors commencez par l'utilisation. Azure Monitor collecte automatiquement les métriques de plateforme pour chaque machine virtuelle, sans agent ni configuration requis.

Dans le portail, ouvrez Machines virtuelles, sélectionnez la machine, puis sous Surveillance choisissez Mesures pour des graphiques bruts ou Insights puis l'onglet Performances pour une vue organisée. La métrique la plus importante pour le dimensionnement du calcul est Percentage CPU, une métrique de plateforme au niveau de l'hôte exprimée en pourcentage, avec un grain d'une minute et une agrégation par moyenne par défaut. Ne jugez pas sur la seule moyenne : tracez ensemble la ligne soutenue et le 95e centile, car une machine peut sembler calme en moyenne tout en ayant besoin de marge pour de courtes rafales régulières. Le graphique d'utilisation du processeur de la vue Performances affiche par défaut la moyenne et le 95e centile supérieur.

La mémoire demande un peu de soin. Les métriques de plateforme de l'hôte exposent Available Memory Bytes, mais les compteurs granulaires au niveau de l'invité qui suivent la quantité de mémoire que le système d'exploitation engage réellement sont collectés via l'agent Azure Monitor à l'intérieur de la machine, pas par défaut. Si vous prévoyez de dimensionner sur la mémoire autant que sur le processeur, mettez d'abord l'agent en place, puis lisez la mémoire disponible sur la même fenêtre. Le graphique de mémoire disponible de la vue Performances affiche par défaut la moyenne ainsi que le 5e et le 10e centile supérieurs, montrant les moments tendus plutôt que les moments confortables.

Observez sur au moins 30 jours pour qu'un week-end calme ou une semaine chargée ne fausse pas le tableau. Ce que vous voulez avant d'agir, c'est une machine dont le processeur au 95e centile et la mémoire disponible la plus basse se situent tous deux confortablement en dessous de sa taille provisionnée.

La boucle de redimensionnement fonctionne sur des preuves : mesurer, présélectionner, vérifier les limites, redimensionner, puis vérifier et consigner.

Lire les recommandations d'Azure Advisor

Une fois que vous avez une idée de l'utilisation, laissez Azure Advisor faire le gros de la reconnaissance de schémas. Sous Advisor puis l'onglet Coût, cherchez Redimensionner ou arrêter les machines virtuelles sous-utilisées. Advisor utilise des modèles d'apprentissage automatique sur votre utilisation pour suggérer un redimensionnement ou un arrêt pour chaque candidat, et affiche la taille actuelle et la taille cible pour un redimensionnement.

Il est utile de savoir à grands traits comment elles sont établies, afin de leur faire confiance sans les prendre pour parole d'évangile :

• Les recommandations d'arrêt signalent les machines de fait inutilisées sur la fenêtre d'analyse. Les critères utilisent l'utilisation du processeur et du réseau sortant, pas de la mémoire, et un arrêt est suggéré lorsque, par exemple, le 95e centile du processeur maximal cumulé sur les cœurs reste sous 3 pour cent et le réseau sortant sous 2 pour cent.
• Les recommandations de redimensionnement peuvent traverser la famille et la version de SKU, et tiennent compte de contraintes telles que le fait que la cible prenne en charge la mise en réseau accélérée et le stockage premium, qu'elle soit disponible dans la région, et que la machine se trouve dans un groupe à haute disponibilité.
• La période d'analyse est de sept jours par défaut mais configurable à 7, 14, 21, 30, 60 ou 90 jours, et un changement peut mettre jusqu'à 48 heures à se propager. Vous pouvez aussi filtrer les machines qui apparaissent en fixant un seuil de processeur moyen sous Configuration puis l'onglet Redimensionnement des VM/VMSS (droits de propriétaire d'abonnement, jusqu'à 24 heures pour s'appliquer), ce qui change ce que vous voyez, pas la manière dont les recommandations sont générées.

Deux réserves honnêtes. Les chiffres d'économies d'Advisor utilisent les tarifs publics et ignorent toute remise de réservation ou de plan d'économies que vous détenez, de sorte que le chiffre affiché peut sembler plus élevé que ce que vous réaliserez. Et l'économie annuelle potentielle totale affichée correspond à l'arrêt ou à la suppression d'une machine ; le redimensionnement fait généralement économiser de l'argent réel, mais pas ce montant total. Traitez les recommandations comme une présélection solidement étayée, pas comme une promesse.

Choisir le SKU cible

La suggestion d'Advisor est un point de départ, pas la seule option. Lorsque vous choisissez une taille cible, pesez plusieurs éléments ensemble.

• Adéquation de la famille. La série D à usage général convient aux charges équilibrées, la série E optimisée pour la mémoire convient aux bases de données et aux caches, la série F optimisée pour le calcul convient au travail limité par le processeur, et la série B burstable convient aux charges à faible moyenne avec des pics. Descendre au sein de la bonne famille est plus propre que sauter d'une famille à l'autre.
• Tailles à cœurs contraints. Là où la licence par cœur est le véritable facteur de coût, les tailles à vCPU contraints conservent la mémoire, le stockage et la bande passante d'un SKU plus grand tout en réduisant le nombre de cœurs facturables.
• Disponibilité régionale. Une taille proposée dans une région peut ne pas exister dans une autre, alors confirmez que la cible est disponible là où réside la machine.
• Limites de disque et de réseau. Le nombre maximal de disques de données, les IOPS, le débit et le nombre d'interfaces réseau sont tous liés à la taille. Descendre trop bas peut brider une machine qui n'était jamais limitée par le processeur, alors vérifiez les limites de la cible face à ce que la charge de travail attache et sollicite.

Gardez de la marge. L'objectif est une taille qui couvre confortablement la charge au 95e centile, pas une qui chauffe dès le premier après-midi chargé.

Effectuer le redimensionnement, et prévoir un redémarrage

Le redimensionnement est rapide, mais perturbateur, alors planifiez-le comme tel. Changer la taille d'une machine virtuelle en cours d'exécution provoque son redémarrage, à faire de préférence en dehors des heures de pointe. Si la taille cible n'est pas disponible sur le cluster matériel qui héberge actuellement la machine, vous devez d'abord la désallouer, ce qui arrête la machine, libère toute adresse IP publique dynamique et peut effacer le disque temporaire ; les disques du système d'exploitation et de données ne sont pas affectés.

Il existe trois façons courantes de le faire :

• Portail. Ouvrez la machine, allez dans Disponibilité + mise à l'échelle puis Taille, choisissez dans la liste disponible et sélectionnez Redimensionner.
• Azure CLI. Listez les options du cluster avec az vm list-vm-resize-options, puis exécutez az vm resize --size <NewSize>. Si la taille n'est pas répertoriée, faites d'abord az vm deallocate, redimensionnez, puis az vm start.
• PowerShell. Listez les options avec Get-AzVMSize, définissez $vm.HardwareProfile.VmSize, puis appliquez avec Update-AzVM.

Si la machine se trouve dans un groupe à haute disponibilité et que la nouvelle taille n'est pas sur le cluster actuel, vous devrez peut-être d'abord désallouer chaque machine du groupe. Planifiez-le et prévenez le propriétaire de la charge de travail avant, pas après.

Vérifier le changement et consigner l'économie

Un redimensionnement n'est pas terminé quand la machine redémarre. Revérifiez les mêmes métriques Azure Monitor d'utilisation du processeur et de mémoire disponible au cours des jours suivants pour confirmer que la taille réduite tient sous charge réelle avec la marge intacte. Si elle chauffe, remontez ; cela fait partie de la boucle, pas d'un échec.

Consignez ensuite les preuves. Notez la taille avant/après et l'évolution du coût mensuel, et conservez l'export de coûts d'Advisor (onglet Coût d'Advisor, téléchargement au format CSV) comme référence. Ce relevé avant/après transforme un changement technique en une économie défendable lorsque la finance ou un propriétaire demande ce qui a changé.

En faire une cadence, pas un événement isolé

La dérive du dimensionnement est continue, donc un seul passage ne suffit pas. Les schémas d'utilisation évoluent et les charges de travail se déplacent, de sorte que le bon choix d'hier devient le surdimensionnement du prochain trimestre. Inscrivez le redimensionnement à une revue mensuelle ou trimestrielle pour que le parc continue de suivre l'utilisation observée plutôt qu'une supposition faite le jour du déploiement. Cela va de pair avec l'élimination du gaspillage plus largement ; pour les ressources facturées alors qu'elles font peu ou pas de travail, voyez comment les ressources Azure inactives deviennent une dette de conception sur la facture.

La place d'EtherInsights

Exécuter cette boucle à la main sur une poignée de machines est gérable. Sur un parc en croissance, ou de nombreux clients pour un fournisseur de services managés, cela devient vite un métier à part entière, et c'est là qu'EtherInsights gagne sa place. Il fait remonter les machines virtuelles surdimensionnées et sous-utilisées à partir de preuves d'utilisation, présente chacune comme une action rattachée à un propriétaire plutôt qu'une métrique brute, et suit l'avant/après pour qu'un redimensionnement repose sur des preuves plutôt que sur une intuition.

Cette approche fondée d'abord sur les preuves est tout l'intérêt de notre service de redimensionnement des VM Azure, qui transforme les données d'utilisation en actions de redimensionnement que votre équipe peut évaluer et prendre en charge, avec les chiffres pour les appuyer. Le calcul n'est qu'une ligne sur la facture, alors réunir le redimensionnement avec le travail sur les licences, le stockage et les ressources inactives au sein d'un seul programme d'optimisation des coûts cloud permet au parc de continuer à payer pour le travail qu'il accomplit réellement, et non pour la forme qu'on lui a d'abord donnée.

Le redimensionnement n'est pas un nettoyage unique ni une coupe budgétaire brutale. C'est une boucle disciplinée et guidée par les preuves : mesurer, présélectionner, vérifier les limites, redimensionner avec soin, puis vérifier et consigner. Menez-la à une cadence et le calcul Azure continue de correspondre à la demande réelle plutôt qu'à une supposition périmée depuis longtemps.

Découvrez le redimensionnement des VM Azure pour voir comment les preuves d'utilisation deviennent des actions de redimensionnement rattachées à un propriétaire, avec les preuves pour les appuyer.