Azure Managed Disks : diagnostiquer une saturation I/O avant de redimensionner

Une base de données installée sur une VM Azure voit sa latence d’écriture passer de quelques millisecondes à plusieurs dizaines pendant le traitement de nuit. Le disque de données est un Premium SSD, le CPU reste stable et l’équipe propose immédiatement de l’agrandir. Cette action peut augmenter les performances du disque, mais elle ne corrigera rien si le plafond atteint est celui de la VM, si les crédits de burst viennent de s’épuiser ou si la file d’attente se forme dans l’OS.

Le cas d’usage est une VM qui héberge un moteur de données, un indexeur ou un traitement batch avec un profil I/O reproductible. Le but du runbook est d’identifier le premier plafond réellement atteint, puis de choisir entre optimisation du workload, tier de performance, redimensionnement de la VM ou changement d’architecture. La sortie attendue n’est pas « plus d’IOPS », mais une modification testable avec un retour arrière explicite.

Figer la charge et l’impact avant toute modification

Une moyenne sur une heure masque facilement un étranglement de cinq minutes. Commencez par une fenêtre UTC courte, un disque ou LUN précis et une opération métier identifiable. Conservez aussi une exécution saine comparable : même volume, même concurrence et même chemin de données.

incident:
vm: vm-ledger-prod-02
region: westeurope
window_utc:
  start: 2026-09-03T00:55:00Z
  end: 2026-09-03T01:25:00Z

workload:
job: ledger-close
expected_records: <count>
concurrency: 8
affected_operation: transaction-log-write

storage_path:
mount: /var/lib/ledger
lun: 2
managed_disk: disk-ledger-log-prod-02
caching: None

symptom:
application_p95_ms: <value>
guest_await_ms: <value>
queue_depth: <value>

preserve:
- deployment_and_resize_timeline
- vm_size_and_disk_sku
- disk_and_vm_metrics_by_minute
- guest_iostat_sample
- healthy_control_window

Ne lancez pas un benchmark destructif sur un volume de production. Les compteurs de l’application, les métriques Azure et un échantillon invité suffisent généralement à localiser la limite sans ajouter une seconde charge au milieu de l’incident.

Lire le chemin I/O complet

Une requête disque peut rencontrer plusieurs plafonds. Le disque managé porte ses propres limites d’IOPS et de débit. La taille de VM impose aussi des limites agrégées, distinctes pour les chemins cached et uncached. Le host cache modifie le chemin des lectures, tandis que les écritures doivent toujours être interprétées selon le mode de cache et le workload réel.

Le diagnostic doit donc répondre dans cet ordre :

• l’application émet-elle davantage d’I/O ou des I/O plus petites qu’avant ?
• la file et la latence augmentent-elles dans l’OS invité ?
• un disque ou un LUN atteint-il son pourcentage d’IOPS ou de bande passante consommé ?
• la VM atteint-elle son plafond cached ou uncached agrégé ?
• le workload vivait-il au-dessus du niveau nominal grâce au burst ?

Une latence élevée sans compteur de consommation proche du plafond n’autorise pas à conclure à un manque d’IOPS. Il faut encore contrôler CPU steal, mémoire, swap, verrouillage applicatif, multipathing éventuel et incidents de plateforme.

Inventorier ce qui est réellement attaché

Le ticket décrit souvent un « P30 », alors que la VM utilise un autre LUN, un tier temporairement relevé ou un mode de cache différent de l’IaC. Exportez l’état effectif avant de raisonner sur les limites théoriques.

RG="rg-ledger-prod"
VM="vm-ledger-prod-02"
DISK="disk-ledger-log-prod-02"

az vm show --resource-group "$RG" --name "$VM" --query "{size:hardwareProfile.vmSize,storage:storageProfile}" --output json

az disk show --resource-group "$RG" --name "$DISK" --query "{id:id,sku:sku.name,sizeGiB:diskSizeGb,tier:tier,iops:diskIopsReadWrite,mbps:diskMbpsReadWrite,bursting:burstingEnabled,managedBy:managedBy}" --output json

Rapprochez managedBy, LUN, mount point et identifiant du disque. Sur Linux, lsblk, findmnt et les liens stables sous /dev/disk/azure/ évitent de confondre un nom de device qui peut changer avec le volume réellement utilisé.

Corréler latence, file, IOPS et débit

IOPS et débit ne sont pas interchangeables. Un workload de petites écritures peut saturer les IOPS sans approcher le débit maximal ; de grandes lectures séquentielles peuvent faire l’inverse. La profondeur de file indique que les requêtes s’accumulent, mais elle doit être rapprochée de la latence et du niveau de concurrence attendu par l’application.

Dans Azure Monitor, tracez au minimum les métriques suivantes sur la même granularité :

• Data Disk IOPS Consumed Percentage et Data Disk Bandwidth Consumed Percentage, séparées par LUN ;
• VM Uncached IOPS Consumed Percentage et VM Uncached Bandwidth Consumed Percentage pour un disque sans host cache ;
• leurs équivalents cached si le chemin utilise le host cache ;
• Data Disk Latency, Data Disk Queue Depth, lectures et écritures par seconde ;
• les crédits de burst du disque et de la VM lorsqu’ils s’appliquent.

VM_ID=$(az vm show -g "$RG" -n "$VM" --query id -o tsv)

az monitor metrics list --resource "$VM_ID" --metric "Data Disk IOPS Consumed Percentage"          "Data Disk Bandwidth Consumed Percentage"          "VM Uncached IOPS Consumed Percentage"          "VM Uncached Bandwidth Consumed Percentage"          "Data Disk Queue Depth" --start-time "2026-09-03T00:55:00Z" --end-time "2026-09-03T01:25:00Z" --interval PT1M --aggregation Average Maximum --output json

Séparez les métriques par LUN dans le portail ou via l’API de métriques quand la dimension est disponible. Une moyenne agrégée sur quatre disques peut afficher 25 % alors qu’un seul LUN est plafonné à 100 %.

Distinguer plafond disque et plafond VM

Le point décisif est le premier compteur qui atteint sa limite pendant que la file et la latence montent.

One disk reaches 100%, VM remains below its limit
Disk-level cap is the leading hypothesis
Check IOPS versus bandwidth and the affected LUN
Consider a higher performance tier or workload distribution

VM cached or uncached metric reaches 100%, disks remain below their limits
VM aggregate storage cap is the leading hypothesis
A larger disk alone will not remove that cap
Evaluate VM size and cached/uncached path

Disk and VM both reach 100%
Both boundaries are active
Size the pair, not one resource in isolation

Queue and latency rise, Azure utilization stays below limits
Continue in guest and application layers
Check locks, filesystem, memory pressure, IO scheduler and platform health

Throughput reaches 100%, IOPS stays low
Larger IO size or sequential traffic is consuming bandwidth
Do not size the fix from IOPS alone

Cette lecture évite un classique : augmenter le tier d’un disque à 10 000 IOPS derrière une VM qui plafonne déjà son chemin uncached. Le changement coûte plus cher, le graphique du disque paraît confortable, mais la latence métier reste identique.

Vérifier les crédits de burst avant de traiter le pic comme une baseline

Certains disques et certaines tailles de VM peuvent dépasser temporairement leur niveau nominal. Avec le burst à crédits, une exécution démarre vite puis ralentit quand le bucket se vide. Le symptôme ressemble à une dégradation progressive alors que la charge reste stable.

Comparez Target IOPS et Max Burst IOPS, puis l’utilisation des crédits IOPS et débit. Ces métriques de crédits sont émises moins fréquemment que les métriques I/O usuelles ; ne cherchez pas une précision à la minute qu’elles ne fournissent pas. Vérifiez aussi le niveau VM : des crédits disponibles sur le disque ne servent à rien si la VM ne peut plus porter le burst agrégé.

Le burst à crédits convient à un pic court, pas à une charge soutenue devenue nominale. Le burst à la demande peut absorber des pointes sur certains Premium SSD, avec un coût variable. Un tier de performance temporaire offre une capacité définie et une facturation plus prévisible pour une fenêtre planifiée. La décision dépend donc de la durée, de la répétition et du budget, pas seulement du maximum observé.

Choisir le changement le plus étroit

Une fois le plafond prouvé, appliquez une seule hypothèse à la fois :

• plafond disque : relever temporairement le tier d’un Premium SSD compatible, ajuster IOPS/débit sur Premium SSD v2 ou Ultra Disk, ou répartir le workload ;
• plafond VM : choisir une taille dont les limites cached/uncached couvrent l’ensemble des disques avec marge ;
• burst épuisé : réduire le pic, décaler la concurrence ou provisionner une baseline soutenable ;
• problème invité : corriger filesystem, scheduler, mémoire ou comportement applicatif avant toute dépense Azure ;
• charge nouvelle : conserver la capacité seulement si le volume utile, et pas une boucle ou un retry storm, explique la hausse.

Ne changez pas simultanément taille de VM, tier du disque, host cache et concurrence applicative. Vous perdriez la preuve de causalité et compliqueriez le rollback. Le host cache mérite en particulier une validation spécifique aux garanties d’écriture et au moteur de données ; ce n’est pas un accélérateur universel.

Valider sous charge réelle et garder le retour arrière

Préparez le rollback avant le changement. Pour un tier Premium SSD, vérifiez notamment les restrictions de downgrade et leur délai. Pour une taille de VM, confirmez capacité régionale, compatibilité, redémarrage éventuel et retour vers la taille précédente. Pour une modification applicative, conservez version et configuration antérieures.

candidate_change:
type: temporary_performance_tier
target: disk-ledger-log-prod-02
from: P30
to: P40
owner: platform-oncall
expiry: 2026-09-04T06:00:00Z

success_gates:
- same useful workload volume completes
- application p95 returns below agreed threshold
- queue depth drains after the peak
- disk and VM consumed percentages retain headroom
- no new filesystem or database errors appear

rollback_triggers:
- latency does not improve under comparable load
- bottleneck moves to the VM without business gain
- error rate or data durability signal degrades
- observed workload differs from the frozen scope

rollback:
action: restore_previous_tier_when_allowed
evidence_to_keep:
  - before_after_metrics
  - effective_resource_configuration
  - workload_identifier_and_volume
  - decision_and_expiry

La validation doit rejouer une charge utile comparable, pas seulement exécuter fio sur un volume vide. Mesurez le temps métier, la latence, la file, les limites disque et VM, puis contrôlez que la capacité ajoutée ne masque pas une amplification de retries.

Conclusion

Une saturation I/O Azure ne se corrige pas en agrandissant le premier disque visible. Il faut figer la charge, retrouver le LUN réel, corréler IOPS, débit, latence et file, puis comparer les plafonds du disque et de la VM. Les crédits de burst expliquent souvent pourquoi une exécution courte réussit et pourquoi le même traitement soutenu ralentit ensuite.

La décision finale doit nommer le plafond prouvé : relever un tier, redimensionner la VM, lisser le workload, corriger l’OS invité ou ne rien changer côté stockage. Le changement est validé lorsque la même unité de travail retrouve son objectif de latence avec de la marge, et il est rollbacké lorsque cette amélioration n’est pas mesurable ou déplace simplement la saturation.