Performances du stockage cloud : latence, débit et IOPS

Le chiffre de performance annoncé par un fournisseur est un plafond, pas une promesse. Il suppose une taille de bloc, une profondeur de file et un motif d'accès que votre application n'a probablement pas. Cette leçon définit les trois grandeurs qui comptent (latence, débit, IOPS), compare ce que les trois familles de stockage tiennent réellement, puis vous apprend à mesurer un volume avec fio sans produire un chiffre qui ne veut rien dire. Elle s'adresse à qui sait déjà ce que sont un disque et un volume cloud, et doit choisir ou dimensionner un stockage.

Ce que vous allez apprendre

• Distinguer latence, débit et IOPS, et savoir lequel limite votre application.
• Comparer les trois familles de stockage sur ces grandeurs.
• Mesurer un volume avec fio dans des conditions valides, et lire les percentiles.
• Interpréter le plafond contractuel d'un volume cloud et le burst.
• Choisir un type et une taille de disque selon la charge.

Latence, débit et IOPS : de quoi parle-t-on ?

Ces trois grandeurs décrivent le même disque sous trois angles, et on les confond constamment. La latence est le temps que prend une seule opération, de la demande à la réponse, exprimé en microsecondes ou en millisecondes. Le débit est la quantité de données transportées par seconde, en mégaoctets par seconde. Les IOPS (Input/Output Operations Per Second) sont le nombre d'opérations de lecture ou d'écriture traitées par seconde.

Deux réglages relient ces grandeurs. La taille de bloc est la quantité de données déplacée par opération : le débit vaut à peu près les IOPS multipliés par cette taille. La profondeur de file (iodepth dans fio) est le nombre de requêtes envoyées en même temps au volume. Un même volume affiche donc des IOPS très élevés avec des blocs de 4 Ko et un faible débit, ou l'inverse avec des blocs de 1 Mo : un chiffre d'IOPS sans sa taille de bloc ne veut rien dire.

Comparaison des performances

Les performances des différents types de stockage varient considérablement en fonction de leurs architectures respectives et des cas d'utilisation. Comprendre ces différences est indispensable pour choisir la solution la plus adaptée à vos besoins en termes de rapidité d'accès, de traitement des données et d'efficacité globale.

Performances du stockage blocs

Le stockage blocs est réputé pour ses performances élevées, en particulier dans les environnements qui nécessitent un accès rapide et une faible latence. Les systèmes utilisant le stockage blocs, tels que les bases de données transactionnelles et les systèmes de fichiers de machines virtuelles, bénéficient de la capacité du stockage blocs à lire et écrire rapidement de petites portions de données. Cette technologie permet également une gestion efficace des entrées/sorties (I/O), rendant les systèmes rapides et réactifs même sous des charges de travail importantes.

Les performances du stockage blocs dépendent souvent de la vitesse du support sous-jacent, qu'il s'agisse de disques durs traditionnels (HDD) ou de disques à état solide (SSD). Les SSD, en particulier, offrent des vitesses d'I/O supérieures, ce qui améliore encore les performances dans les environnements critiques.

Performances du stockage de fichiers

Le stockage de fichiers est généralement plus lent que le stockage blocs en termes de performances brutes, principalement en raison de la structure hiérarchique utilisée pour organiser les données. Toutefois, cette méthode de stockage est optimisée pour le partage de fichiers et la collaboration, où l'accent est mis sur l'accessibilité et la facilité d'utilisation plutôt que sur la vitesse pure.

Les systèmes de stockage de fichiers performants peuvent être atteints en utilisant des configurations RAID (Redundant Array of Independent Disks) pour améliorer la vitesse de lecture/écriture, ou en combinant des SSD pour le stockage de fichiers fréquemment utilisés avec des HDD pour le stockage à long terme de fichiers moins accédés. De plus, les performances peuvent varier en fonction du protocole de partage de fichiers utilisé, comme NFS (Network File System) ou SMB (Server Message Block).

Performances du stockage objets

Le stockage objets est conçu pour la scalabilité plutôt que pour des performances I/O ultra-rapides. Cependant, il peut gérer efficacement des volumes massifs de données, en particulier lorsqu'il s'agit de données non structurées comme des fichiers multimédias, des sauvegardes, ou des archives.

La performance du stockage objets dépend de plusieurs facteurs, notamment la vitesse du réseau et l'optimisation des accès via des CDN (Content Delivery Networks) pour les systèmes distribués. Dans les cas où les performances d'accès aux données sont critiques, les configurations hybrides peuvent être mises en place, combinant des systèmes de cache rapide avec des solutions de stockage d'objets pour équilibrer la scalabilité avec des besoins de performance spécifiques.

En résumé, le stockage blocs est la solution privilégiée pour les applications nécessitant des performances élevées et une faible latence. Le stockage de fichiers offre des performances adéquates pour des applications axées sur le partage et la collaboration, tandis que le stockage objets excelle dans la gestion de grandes quantités de données avec une approche scalable, malgré une vitesse d'accès moins rapide. Le choix du type de stockage doit être basé sur les exigences spécifiques en matière de performances et sur le type de données à gérer.

Peut-on calculer les IOPS d'un disque ?

Les IOPS d'un disque mécanique, où une seule opération est servie à la fois, se déduisent du temps que prend cette opération. Les durées étant en millisecondes, on divise donc 1 000 par leur somme :

IOPS = 1000 / (temps de recherche + temps de rotation + temps de transfert)
       durées exprimées en millisecondes

Cette formule ne décrit pas un SSD ni un volume cloud

Elle suppose que le disque traite une opération après l'autre. C'est vrai d'un plateau qui tourne, et faux d'un SSD ou d'un volume cloud, qui servent des dizaines de requêtes en parallèle.

Sur ces supports, les IOPS ne se déduisent pas de la latence : ils dépendent du parallélisme que vous envoyez (la profondeur de file), de la taille des blocs, du rapport lecture/écriture, et surtout de la limite contractuelle du volume et de l'instance. C'est pourquoi la section suivante mesure plutôt qu'elle ne calcule.

Chaque élément de la formule influence directement les IOPS d'un disque mécanique. Voici une explication des termes.

1. Temps de recherche (seek) : Le temps de recherche est le temps que met la tête de lecture à se déplacer jusqu'à la bonne piste du plateau. C'est le premier délai d'une opération sur un disque mécanique, et il ne s'applique qu'à lui. Un temps de recherche court améliore les IOPS.
2. Temps de rotation : Le temps de rotation s’applique aux disques mécaniques (HDD). C’est le temps nécessaire pour que les données se positionnent sous la tête de lecture.
3. Temps de transfert : Le temps de transfert est le temps pour lire ou écrire les données une fois qu’elles sont accessibles. Il dépend de la vitesse du disque et de la taille des blocs.

La formule montre que pour augmenter les IOPS, il faut réduire le temps de recherche, le temps de rotation (pour les HDD) et le temps de transfert. C’est pourquoi les SSD et NVMe, qui ont des temps très faibles pour ces facteurs, offrent des performances bien supérieures aux HDD traditionnels.

Exemple de calcul - HDD vs SSD :

Prenons deux exemples pour illustrer le calcul théorique.

• HDD 7 200 RPM :
  • Temps de recherche (valeur d'exemple) : 4 ms
  • Temps de rotation moyen : 4,17 ms
  • Temps de transfert pour 4 Ko : 0,005 ms

temps par opération = 4 + 4,17 + 0,005 = 8,175 ms = 0,008175 s
IOPS = 1 / 0,008175 ≈ 122 IOPS

La conversion d'unité n'est pas un détail de présentation. La formule donne des opérations par seconde ; si vous divisez 1 par une durée exprimée en millisecondes, vous obtenez 0,12 et non 122, soit un facteur 1 000. C'est l'erreur la plus commune de ce calcul, et elle passe inaperçue parce que le résultat attendu est connu d'avance.

• SSD SATA :
  • Temps d'accès (équivalent du temps de recherche, sans mouvement mécanique) : 0,1 ms
  • Temps de rotation : 0 ms (pas de plateaux mécaniques)
  • Temps de transfert pour 4 Ko : 0,002 ms

temps par opération = 0,1 + 0 + 0,002 = 0,102 ms = 0,000102 s
IOPS = 1 / 0,000102 ≈ 9 800 IOPS

Ces deux calculs restent théoriques : ils décrivent un disque sollicité par une seule requête à la fois (une profondeur de file de 1). Un disque réel, et plus encore un volume cloud, en traite plusieurs en parallèle, et c'est précisément ce que la mesure qui suit va montrer.

Comment mesurer les IOPS réels ?

Le calcul théorique des IOPS donne une estimation idéale des performances, mais pour connaître les IOPS réels de votre système, il faut effectuer des tests pratiques dans des conditions proches de l’environnement d’exploitation. Ces tests prennent en compte les charges de travail, les configurations matérielles et les contraintes logicielles.

Deux outils reviennent partout, et ils ne mesurent pas la même chose :

• dd donne un débit séquentiel indicatif, en une seule requête à la fois. Il ne mesure pas les IOPS.
• fio est la seule mesure de ce chapitre qui donne des IOPS et des percentiles de latence, à condition de bien le régler.

Les deux tests créent des fichiers de test de plusieurs centaines de mégaoctets à quelques gigaoctets : lancez-les depuis un répertoire du volume à mesurer (pas depuis /tmp, souvent situé sur un autre disque ou en mémoire), vérifiez l'espace libre avec df -h ., et supprimez les fichiers de test à la fin.

Mesure rapide avec dd : un débit séquentiel indicatif

dd écrit un fichier bloc après bloc, une requête à la fois : il répond à la question « à quel débit sait-on écrire à la suite sur ce volume ? », pas à « combien d'IOPS rend-il ? ». Placez-vous dans un répertoire du volume visé, écrivez le fichier de test, puis supprimez-le.

dd if=/dev/zero of=testfile bs=4k count=100000 oflag=direct

La commande affiche un compte rendu de ce type (les chiffres varient selon le volume) :

100000+0 records in
100000+0 records out
409600000 bytes (410 MB, 391 MiB) copied, 3,94857 s, 104 MB/s

Supprimez ensuite le fichier de test :

rm testfile

• if=/dev/zero : Génère des données nulles pour l’écriture.
• of=testfile : Fichier de sortie, créé dans le répertoire courant (celui du volume à mesurer).
• bs=4k : Définit la taille des blocs (4 Ko ici).
• count=100000 : Nombre de blocs à écrire.
• oflag=direct : Évite la mise en cache pour des résultats plus réalistes.

Le résultat indique le débit :

• Taille totale transférée : 409 600 000 octets, soit environ 410 Mo.
• Temps total : 3,94857 secondes.
• Débit : 104 Mo/s.

Ce chiffre est un ordre de grandeur de débit séquentiel avec une profondeur de file de 1. Le diviser par la taille de bloc pour en tirer des « IOPS » donnerait un nombre trompeur, parce que dd n'envoie jamais plusieurs requêtes en parallèle : il ne sait pas atteindre le plafond d'un volume cloud, qui demande justement du parallélisme (voir plus bas).

La taille des blocs joue en revanche un rôle net sur le débit obtenu :

• Petits blocs (4 Ko, 8 Ko) : beaucoup d'opérations pour peu de données, donc un débit faible et une plus grande charge CPU.
• Grands blocs (64 Ko, 128 Ko) : moins d'opérations pour la même quantité de données, donc un débit plus élevé, idéal pour les transferts séquentiels de gros fichiers.

Vous pouvez tester avec dd différentes tailles de blocs pour voir l’impact sur vos résultats. Par exemple :

dd if=/dev/zero of=testfile bs=64k count=10000 oflag=direct
rm testfile

Avec le même volume, 10 000 blocs de 64 Ko écrits en 2,12744 s représentent environ 655 Mo, soit un débit voisin de 308 Mo/s : trois fois plus que les blocs de 4 Ko, pour une machine et un disque identiques.

Mesure avec fio

fio est l'outil de référence, et il est très facile de lui faire produire un chiffre qui ne veut rien dire. Trois options décident de la validité de la mesure, et les oublier donne des résultats qui semblent plausibles tout en mesurant autre chose que ce que l'on croit. Le moteur d'E/S (--ioengine) est la façon dont fio parle au disque : libaio envoie plusieurs requêtes sans attendre chaque réponse, psync les envoie une par une. Installez fio depuis le paquet du même nom de votre distribution, et lancez les commandes ci-dessous depuis un répertoire du volume à mesurer : fio y crée ses fichiers de test.

Option	Sans elle	Pourquoi c'est indispensable
--ioengine=libaio	fio utilise psync, synchrone	avec un moteur synchrone, iodepth est plafonné à 1 : vous demandez 16 requêtes en vol, vous en obtenez une
--direct=1	les lectures passent par le cache du système	vous mesurez la vitesse de la mémoire, pas celle du disque
--size adapté	sur un fichier de test, fio refuse de démarrer sans taille (you need to specify size=) ; une taille trop grande pour le volume échoue en cours de route	quatre jobs de 1 Go réclament 4 Go libres, sinon l'un d'eux s'arrête sur l'erreur ENOSPC (plus d'espace disque)

Glissez pour voir

La mesure la plus fréquente sur Internet est invalide

Cette ligne circule partout, et elle ne mesure pas ce qu'elle annonce :

# ❌ à ne pas reproduire
fio --name=test --rw=randread --bs=4k --size=1G --numjobs=4 --iodepth=16 --runtime=30 --time_based

Et fio ne vous prévient pas. C'est le point le plus dangereux de cette commande : avec fio 3.28 (essai du 10 septembre 2026), cette ligne s'exécute sans le moindre avertissement. L'en-tête affiche même tranquillement la valeur que vous avez demandée, ce qui achève de rassurer :

demo: (g=0): rw=randread, bs=(R) 4096B-4096B, ioengine=psync, iodepth=16

La seule trace de la vérité se trouve au bas du rapport, dans une ligne que personne ne lit :

IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%

La profondeur réellement utilisée était 1, pas 16. Le chiffre d'IOPS obtenu est donc celui d'un accès strictement séquentiel dans le temps, très inférieur à ce que le disque sait faire, et il ne dit rien de la capacité du volume à absorber du parallélisme.

Retenez le geste plutôt que le message : lisez la ligne IO depths avant de lire la ligne d'IOPS. C'est la seule qui dise ce que fio a réellement fait, et aucun avertissement ne viendra vous la signaler.

Le test correct

fio --name=randread --rw=randread --bs=4k --size=256M --numjobs=4 \
    --iodepth=16 --ioengine=libaio --direct=1 \
    --runtime=15 --time_based --group_reporting

Relevé sur un poste de travail à disque NVMe, en septembre 2026 :

randread: (g=0): rw=randread, bs=(R) 4096B-4096B, ioengine=libaio, iodepth=16
  read: IOPS=605k, BW=2365MiB/s (2480MB/s)(34.6GiB/15001msec)
    clat percentiles (usec):
     |  1.00th=[   63],  5.00th=[   71], 10.00th=[   97], 20.00th=[  147],
     | 50.00th=[  318], 70.00th=[  478], 90.00th=[  799], 95.00th=[  988],
     | 99.00th=[ 1369], 99.50th=[ 1500], 99.90th=[ 1811], 99.95th=[ 1942],
  IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%

Vérifiez toujours la dernière ligne avant de croire la première. Ici 16=100.0% atteste que la profondeur demandée a bien été tenue ; la mesure de 605 000 IOPS est donc exploitable.

Ce que le cache fait à votre mesure

Le même test relancé sans --direct=1 donne, sur la même machine :

  read: IOPS=47.3k, BW=185MiB/s (194MB/s)

Le chiffre s'effondre au lieu d'augmenter, ce qui surprend. La raison tient au moteur : libaio ne sait pas travailler de façon réellement asynchrone sur des entrées-sorties passant par le cache, et retombe alors sur un comportement bloquant. Vous ne mesurez donc plus ni le disque, ni le cache, mais un montage hybride dont le résultat ne se compare à rien.

Retenez la règle simple : avec libaio, --direct=1 n'est pas une option de réglage fin, c'est une condition de validité. Pour mesurer délibérément l'effet du cache, utilisez plutôt le moteur psync, et sachez que vous mesurez alors la mémoire.

Lire les percentiles plutôt que la moyenne

La latence moyenne ne dit rien de l'expérience réelle. Ce sont les percentiles qui comptent, et fio les donne en microsecondes.

Percentile	Valeur relevée	Ce qu'il signifie
50e	318 µs	la moitié des requêtes sont plus rapides
95e	988 µs	une requête sur vingt dépasse cette durée
99e	1 369 µs	une sur cent, soit plusieurs par seconde à ce débit
99,95e	1 942 µs	six fois la médiane

Glissez pour voir

Une page web qui déclenche vingt requêtes disque attend le plus lent des vingt. C'est pourquoi une infrastructure se juge sur son 95e ou son 99e centile : la moyenne masque exactement ce que vos utilisateurs ressentent.

Mesurer le débit, un autre profil

Les IOPS et le débit ne se mesurent pas avec le même test. Petits blocs et accès aléatoire donnent des IOPS ; gros blocs et accès séquentiel donnent des mégaoctets par seconde.

fio --name=seqread --rw=read --bs=1M --size=512M --numjobs=2 \
    --iodepth=8 --ioengine=libaio --direct=1 \
    --runtime=15 --time_based --group_reporting

  read: IOPS=4700, BW=4700MiB/s (4928MB/s)(68.9GiB/15004msec)

Le même matériel qui affichait 605 000 IOPS n'en fait plus que 4 700, et c'est normal : chaque opération transporte 1 Mo au lieu de 4 Ko. Comparer deux chiffres d'IOPS obtenus avec des tailles de bloc différentes n'a aucun sens, et c'est l'erreur la plus fréquente quand on lit des tableaux comparatifs.

Nettoyez en fin de mesure. fio laisse ses fichiers de test dans le répertoire courant, nommés d'après le test (randread.0.0, randread.1.0, et ainsi de suite), soit environ 1 Go pour chacun des deux tests ci-dessus, 2 Go au total. Listez-les avec ls, puis supprimez-les :

ls randread.* seqread.*
rm -f randread.*.* seqread.*.*

Combien d'IOPS un volume cloud rend-il vraiment ?

Un volume cloud n'a pas une performance, il a un plafond contractuel, et l'atteindre demande de lui envoyer assez de requêtes en parallèle. C'est la différence la plus importante avec le disque de votre poste, et elle ne se voit qu'en faisant varier la profondeur de file.

Le relevé ci-dessous a été fait le 10 septembre 2026 sur un volume Block Storage Scaleway de 20 Go créé avec perf-iops=5000, attaché à une instance DEV1-S en fr-par-1, avec fio 3.28. Les mesures portent sur le périphérique brut, sans système de fichiers, en lecture aléatoire de 4 Ko pendant 30 secondes par palier. Voici la commande d'un palier, à répéter en faisant varier --iodepth (et --ioengine=psync pour la première ligne) :

lsblk
sudo fio --name=palier --filename=/dev/sdb --readonly --rw=randread --bs=4k \
    --iodepth=8 --ioengine=libaio --direct=1 \
    --runtime=30 --time_based

lsblk liste les disques : repérez le volume à mesurer par sa taille et remplacez /dev/sdb par son nom, sans quoi vous viseriez le mauvais périphérique. Écrire sur un disque brut détruit les données qu'il porte. L'option --readonly interdit toute écriture à fio et rend donc ce test de lecture sans danger ; les mesures en écriture ne se font que sur un volume vierge et jetable, jamais sur un disque qui contient des données. Pour une mesure sur un système de fichiers monté, voir mesurer les performances d'un disque sous Linux. Lisez le tableau de haut en bas : c'est la progression qui enseigne, pas une ligne isolée.

Profondeur de file	IOPS	p50	p95	p99
psync, iodepth=16 demandé, 1 obtenu	2 126	387 µs	619 µs	1 434 µs
libaio, iodepth=1	2 153	367 µs	569 µs	1 057 µs
libaio, iodepth=2	4 510	354 µs	545 µs	1 090 µs
libaio, iodepth=4	4 902	383 µs	946 µs	18 481 µs
libaio, iodepth=8	5 150	412 µs	1 319 µs	36 962 µs
libaio, iodepth=16	5 038	444 µs	41 681 µs	43 778 µs
libaio, iodepth=32	5 041	594 µs	45 875 µs	46 400 µs
libaio, iodepth=64	5 041	1 139 µs	47 448 µs	47 972 µs

Glissez pour voir

Trois enseignements sortent de ce tableau, et aucun n'est visible sur une mesure unique.

Le mauvais benchmark coûte plus de la moitié du volume. La première ligne et la deuxième donnent le même résultat, 2 126 contre 2 153 IOPS : le moteur synchrone n'était pas le problème en soi, c'est la profondeur plafonnée à 1 qui l'était. Autrement dit, la commande fautive mesurait un volume à 5 000 IOPS et en annonçait 43 %. Quelqu'un qui prend cette décision sur ce chiffre paie un volume plus cher pour un besoin qu'il satisfaisait déjà.

Le plafond annoncé est réel, et il est atteint dès la profondeur 8. Les 5 150 IOPS relevés à iodepth=8 collent au plafond contractuel de 5 000, aux arrondis de mesure près. Au-delà, la courbe est plate : 5 038, 5 041, 5 041. Vous ne payez pas pour un maximum théorique, vous payez pour une limite que le fournisseur applique, et il faut la solliciter correctement pour la constater.

Passé la saturation, le parallélisme n'achète plus que de la latence. C'est le résultat le plus contre-intuitif : entre iodepth=8 et iodepth=64, les IOPS ne bougent pas, mais le 99e centile passe de 37 ms à 48 ms et la médiane est multipliée par près de trois. Empiler les requêtes sur un volume déjà saturé ne le rend pas plus rapide, cela allonge la file d'attente. Une application qui augmente son parallélisme d'accès disque pour « aller plus vite » dégrade en réalité le temps de réponse qu'elle cherchait à améliorer.

Le même volume, deux autres profils

En écriture aléatoire, à iodepth=32, le même volume rend 5 156 IOPS avec un 99e centile à 43 ms : le plafond s'applique aussi bien en écriture qu'en lecture.

En lecture séquentielle de blocs de 1 Mo, il rend 100,5 Mio/s pour seulement 101 IOPS. Le disque n'est pas devenu cinquante fois plus lent : il transporte simplement 1 Mo par opération au lieu de 4 Ko. C'est la démonstration la plus nette qu'un chiffre d'IOPS sans sa taille de bloc ne veut rien dire.

Ce que cela change pour votre dimensionnement. Avant de payer un volume plus performant, vérifiez d'abord que votre mesure sollicite le volume actuel à une profondeur suffisante, puis regardez si votre application sait elle-même paralléliser ses accès. Un volume à 15 000 IOPS ne servira à rien à une application qui émet ses requêtes une par une : elle restera aux 2 000 IOPS que sa latence lui impose, exactement comme la ligne iodepth=1 de ce tableau.

Qu’est-ce que le burst ?

Le burst est une fonctionnalité proposée par certains volumes de stockage dans le cloud qui permet de dépasser temporairement les performances normales (en termes de IOPS ou de débit). Cela s’avère particulièrement utile pour gérer des pics de charge ponctuels, lorsque les besoins en performance augmentent brièvement.

Lorsque les volumes ne sont pas utilisés à pleine capacité, ils accumulent des crédits de burst. Ces crédits s’accumulent avec le temps et peuvent être consommés lors de pics d’activité pour fournir des performances bien supérieures aux niveaux standards. Une fois ces crédits épuisés, le volume revient à ses performances normales, limitées à sa capacité de base.

Les avantages du burst

Le burst est particulièrement intéressant pour :

• Gérer les pics de charge : Il permet de répondre à des demandes élevées sans devoir surdimensionner le stockage.
• Optimiser les coûts : Les volumes avec burst sont généralement moins coûteux que ceux aux performances garanties.
• Charges imprévisibles : Idéal pour des besoins fluctuant, comme les démarrages de systèmes ou des analyses ponctuelles.

Les limitations

Le burst a toutefois des contraintes :

• Pas de performances élevées en continu : Une fois les crédits épuisés, les performances redescendent au niveau de base.
• Surveillance nécessaire : Sans un suivi attentif, le risque de baisse soudaine de performance peut poser problème, surtout pour des applications critiques.

En résumé

Le burst est une solution idéale pour des charges de travail aux besoins irréguliers et pour gérer des pics courts. Cependant, pour des charges intensives et continues, il est préférable d’opter pour des volumes offrant des performances garanties, afin d’assurer une constance dans les traitements.

Le choix des types et tailles de disques dans le cloud

Le type et la taille des disques dans le cloud influencent directement les performances (IOPS et débit) et les coûts. Voici comment faire les bons choix.

Types de disques

Attention à un abus de langage courant : on aligne souvent « HDD, SSD, NVMe » comme trois familles comparables, alors que les deux premiers désignent une technologie de support et le troisième une interface. Un disque NVMe est un SSD ; il se distingue par la façon dont il est relié à la machine, non par la manière dont il stocke.

	Ce que c'est	Ordre de grandeur en IOPS	Usage typique
HDD	plateaux magnétiques en rotation	100 à 200	archivage, gros fichiers séquentiels
SSD (SATA)	mémoire flash, interface héritée du disque dur	quelques dizaines de milliers	usage général
SSD NVMe	même flash, interface directe sur le bus PCIe	des centaines de milliers	bases de données, charges critiques

Glissez pour voir

Ce qui sépare vraiment le SSD SATA du SSD NVMe, c'est le parallélisme que l'interface autorise : là où SATA sérialise les requêtes dans une file unique, NVMe en gère plusieurs milliers en parallèle. C'est exactement ce que mesure la profondeur de file mesurée plus haut.

Pourquoi la taille influence les performances

Sur certaines offres, les performances d'un volume dépendent de sa taille, et c'était même la règle générale il y a quelques années :

• IOPS liés à la capacité : le fournisseur accorde un nombre d'IOPS par gigaoctet alloué, par exemple 3 IOPS par Go. Agrandir le volume est alors le seul moyen d'aller plus vite.
• Débit lié à la capacité de la même façon.

Ce modèle recule. Beaucoup d'offres récentes permettent de choisir la capacité, les IOPS et le débit indépendamment, et de payer chaque dimension séparément. Sur ces volumes, agrandir le disque pour gagner en performance revient à payer du stockage inutile alors qu'il suffisait de provisionner les IOPS.

Vérifiez donc, dans la grille tarifaire du type de volume que vous utilisez, laquelle des deux logiques s'applique avant de dimensionner. La réponse change complètement l'arbitrage.

Critères de choix

• Nature de la charge :
  • Transactionnelles : SSD ou NVMe.
  • Big Data : Disques à haut débit.
  • Archivage : HDD.
• Optimisation des coûts :
  • Sur une offre où les performances suivent la capacité, un volume plus grand apporte plus d'IOPS ; sur une offre à IOPS provisionnés, réglez les IOPS plutôt que la taille.
  • Préférez des disques provisionnés uniquement pour des besoins constants.

Adaptez vos choix de disque (type et taille) à vos besoins spécifiques. Une bonne planification garantit des performances optimales sans exploser votre budget cloud.

Quelles applications dépendent le plus des IOPS ?

Les charges qui lisent et écrivent de petites quantités de données, de façon aléatoire et en continu, sont celles qui butent en premier sur les IOPS. Les bases de données transactionnelles en sont le cas type : elles ne tolèrent pas une latence élevée. Les machines virtuelles et les volumes persistants de conteneurs partagent le stockage de leur hôte et peuvent se gêner mutuellement. À l'inverse, le streaming ou la sauvegarde sont limités par le débit. Mesurez donc d'abord le profil de votre charge (petits blocs aléatoires ou gros blocs séquentiels) avant de payer des IOPS.

À retenir

• Le chiffre annoncé est un plafond, atteint seulement avec la bonne taille de bloc et assez de requêtes en parallèle.
• Latence, débit et IOPS sont liés par la taille de bloc : un chiffre d'IOPS sans taille de bloc ne se compare à rien.
• dd ne mesure qu'un débit séquentiel indicatif ; seul fio donne des IOPS et des percentiles. Supprimez les fichiers de test après la mesure.
• Avec fio, trois options décident de la validité : --ioengine=libaio, --direct=1 et un --size adapté. Lisez la ligne IO depths avant celle des IOPS.
• Jugez sur les percentiles (95e, 99e), pas sur la moyenne.
• Un volume cloud a un plafond contractuel : passé la saturation, le parallélisme ajoute de la latence sans ajouter d'IOPS.
• Le burst dépanne les pics courts, pas les charges continues ; vérifiez si la performance suit la capacité ou se règle à part.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →