Le nombre d’opérations d’entrée/sortie par seconde (IOPS) et le débit sont des indicateurs importants pour évaluer la performance du stockage des données sur les disques durs, les SSD et les réseaux de stockage SAN. Cependant, ils ne mesurent pas les mêmes choses et il y a plusieurs facteurs à prendre en compte dans chaque cas.
Si vous voulez directement savoir comment les milliers de clients Pure utilisent FlashArray™ et connaître le ratio des opérations de lecture ou d’écriture effectuées dans l’ensemble de la flotte, cliquez ici.
Si vous préférez consulter le récapitulatif sur les IOPS, le débit et leur calcul, lisez la suite.
Qu’est-ce que le nombre d’IOPS et comment le calculer ?
Il s’agit du nombre d’opérations d’entrée/sortie qu’un périphérique de stockage peut effectuer en une seconde. C’est un critère de performance standard pour les disques de stockage flash, les disques durs, les lecteurs flash et les périphériques de stockage réseau (NAS).
Une « entrée » est une information envoyée à un système informatique par l’intermédiaire d’un dispositif externe, comme un clavier ou une souris. Une « sortie » correspond à la réponse ou au résultat du traitement des données provenant de l’entrée.
Une entrée est considérée comme une opération de « lecture », car l’ordinateur lit les données et les stocke dans sa mémoire, tandis qu’une sortie est considérée comme une opération « d’écriture » parce que l’ordinateur transfère les données en les écrivant à un autre endroit.
Le calcul du nombre d’E/S par seconde peut s’avérer difficile, car de nombreux facteurs entrent en ligne de compte pour déterminer le débit et les performances. Le type de disque est également un facteur déterminant, le calcul ne sera donc pas le même pour un disque dur et un SSD d’une capacité équivalente. Le type de stockage RAID utilisé dans une baie a également des conséquences, car certains entraînent une dégradation de performance. Par exemple, une configuration RAID 6 est beaucoup moins performante qu’une configuration RAID 0, car elle doit répartir la parité sur l’ensemble des disques.
En général, on calcule le nombre d’IOPS comme suit :
(nombre total de lectures + débit en écriture) / temps (en secondes)
Qu’est-ce que le débit et comment le calculer ?
Le débit correspond au nombre d’unités d’information qu’un système peut traiter dans un temps donné. Il se mesure généralement en bits par seconde (bit/s, b/s ou bps), mais il peut aussi se mesurer en octets par seconde (8 bits par octet) ou en paquets de données par seconde (p/s ou pps).
IOPS et débit : quel indicateur utiliser pour évaluer la performance ?
Le débit et les IOPS sont à la fois liés et légèrement différents. Le débit correspond au nombre de bits ou octets par seconde pouvant être traités par un périphérique de stockage. Les IOPS font référence au nombre d’opérations de lecture/écriture par seconde. Les deux peuvent être utilisés conjointement pour décrire la performance d’un système.
En réalité, trois facteurs doivent être combinés pour donner un aperçu complet des performances du stockage : le débit de la bande passante, la latence et le nombre d’opérations d’E/S par seconde. La plupart des fournisseurs de stockage ont tendance à se concentrer sur les IOPS pour vanter la rapidité de leur système de stockage. Toutefois, le fait de mesurer les performances d’un système de stockage via le nombre d’IOPS n’a de valeur que si les charges de travail qui utilisent ce système de stockage impliquent un grand nombre d’opérations d’E/S.
Les professionnels de l’informatique utilisent souvent les IOPS pour évaluer les performances des systèmes de stockage, notamment des baies 100 % flash, mais cela ne donne qu’une indication partielle. Il est tout aussi important de connaître le débit (unités de données traitées par seconde), c’est-à-dire la manière dont les données sont effectivement acheminées vers les baies, en complément des performances des applications réelles. Pour résumer, il est important d’utiliser les deux.
Lorsque la vitesse est importante, la quantité de données pouvant être écrites et lues par un périphérique de stockage est un facteur de performance essentiel. Au niveau de chaque périphérique, un écart dans le nombre d’IOPS peut être négligeable pour les performances, mais dans un datacenter ou un environnement d’entreprise, la quantité d’octets pouvant être lus et écrits sur le stockage affectera les performances des applications de vos clients.
En revanche, connaître le débit seul n’est pas suffisant. La latence, qui correspond au temps nécessaire pour envoyer une requête et recevoir une réponse, joue également un rôle dans les performances du stockage. La mécanique des périphériques, les contrôleurs, la mémoire et les processeurs peuvent également avoir un effet sur la latence. Tous ces facteurs contribuent à la performance d’un système.
Autres lectures sur ce sujet : IOPS allouées en Thick Provisioning dans le cloud public
IOPS sur les disques durs et SSD : aperçu des baies FlashArray
Les SSD et les disques durs sont très différents. Un disque dur stocke les données sur des plateaux en rotation, tandis qu’un SSD est un assemblage de circuits sans pièces mobiles. Sur les disques durs, la vitesse de rotation des plateaux est limitée physiquement, ils n’ont donc pas un débit aussi élevé que les SSD. Les opérations de lecture et d’écriture sur un disque dur dépendent de la vitesse de rotation des plateaux, c’est pourquoi on les utilise souvent pour le stockage, qui ne nécessite pas de lectures/écritures fréquentes.
Les disques durs sont par exemple une solution économique pour le stockage de sauvegarde. Pour les applications actives, on utilise habituellement des SSD, car ils permettent de réaliser les opérations d’E/S plus rapidement. Les circuits peuvent transférer des données plus vite qu’un périphérique physique en rotation, les SSD sont donc la solution de stockage à privilégier pour les applications d’entreprise impliquant de nombreuses lectures/écritures.
Lectures et écritures en E/S : comment les clients Pure utilisent-ils FlashArray ?
Commençons par une question simple : les clients utilisent-ils la baie FlashArray davantage pour les lectures ou les écritures ? À parts égales ? Les deux à la fois ? Certaines baies FlashArray traitent uniquement les lectures, d’autres seulement les écritures, même si les cas sont extrêmement rares. La plupart des baies FlashArray exécutent les deux, avec toutefois davantage de lectures que d’écritures.
La répartition médiane est la suivante : ⅔ de lectures et ⅓ d’écritures, 78 % des baies exécutant des charges de travail comportant plus de lectures que d’écritures. La figure 1 ci-dessous montre la répartition des lectures/écritures sur l’ensemble des baies FlashArray des clients Pure Storage®.
Pourquoi la plupart des clients effectuent-ils davantage de lectures que d’écritures ? 78 %
On parle de lecture lorsqu’un utilisateur demande que des données soient extraites d’un périphérique de stockage, et d’écriture lorsqu’on écrit des uns et des zéros sur le disque en vue d’une extraction ultérieure. Des opérations d’écriture ont lieu lorsque le serveur envoie des données au périphérique de stockage, mais les lectures sont beaucoup plus courantes sur les serveurs d’entreprise où les applications extraient des données et les mettent en cache dans la mémoire où elles peuvent être récupérées. Les périphériques de sauvegarde et le stockage des bases de données peuvent impliquer un nombre de lectures supérieur par rapport à un serveur d’application standard, alors assurez-vous de connaître la fonction du serveur avant de déterminer l’importance des IOPS.
Pourquoi certains clients effectuent-ils davantage d’écritures que de lectures ? 21 %
Les opérations d’écriture sont fréquentes lorsque les utilisateurs stockent des données plus souvent qu’ils ne les récupèrent. Un serveur de base de données peut traiter de nombreuses opérations d’écriture par seconde lorsque les utilisateurs y stockent des données. Les serveurs de sauvegarde sont principalement utilisés pour les opérations d’écriture, les utilisateurs y stockent leurs données, mais les récupèrent rarement. Les périphériques de stockage des serveurs de sauvegarde sont optimisés pour les écritures afin d’accélérer les performances, ce qui est particulièrement nécessaire lorsque plusieurs téraoctets de données doivent être sauvegardés chaque jour.
Pourquoi certains clients réalisent-ils uniquement des opérations d’écriture ? 1 %
Dans certains environnements en miroir, le stockage ne sert parfois qu’au basculement. Dans ce cas, si le disque primaire ne tombe jamais en panne, il n’y a que des écritures et aucune lecture. Il peut y avoir des lectures si le disque principal tombe en panne, vous devez donc vous assurer que les performances de lecture sont suffisantes pour une utilisation temporaire pendant la réparation du disque principal.
Pourquoi la répartition des E/S en lecture et en écriture est-elle importante ?
Pourquoi est-il important de savoir si les clients utilisent la lecture ou l’écriture ?
Dans la plupart des applications d’entreprise stratégiques, l’analyse du logiciel révèle le nombre de lectures et d’écritures effectuées. Les analystes peuvent constater qu’une application passe une part importante du temps à écrire plutôt qu’à lire les données stockées. Le système de stockage doit alors pouvoir donner la priorité aux écritures. Cela ne veut pas dire qu’il faut ignorer complètement les performances de lecture. Les périphériques de stockage dans les systèmes d’entreprise doivent pouvoir effectuer des lectures et des écritures rapides, mais les périphériques installés sur un serveur stratégique doivent être optimisés pour les lectures ou les écritures afin de garantir des performances optimales.
Tailles d’E/S et débit : analyse des baies FlashArray
Nous avons vu que les clients Pure ont tendance à réaliser plus d’opérations de lecture que d’écriture. Quelle taille font ces opérations ?
Nous avons commencé par adopter une approche très directe en étudiant la répartition des E/S dans toutes les baies FlashArray des clients sur la base de leur taille. Ensuite, nous avons établi une moyenne pour l’ensemble des clients. Nous avons ainsi déterminé quelles étaient, en moyenne, les tailles d’E/S les plus fréquentes chez tous les clients. Les résultats sont présentés dans la Figure 2 ci-dessous.
On constate que les opérations de lectures font le plus souvent entre 8 et 16 Ko ou entre 4 et 8 Ko, alors que les opérations d’écritures font généralement entre 4 et 8 Ko.
Lorsqu’on examine la répartition des E/S sur chaque baie, on remarque que la plupart sont de petite taille :
| Majorité d’E/S < 32 Ko | Majorité d’E/S < 16 Ko | |
| Lectures | 73 % des baies | 56 % des baies |
| Écritures | 93 % des baies | 88 % des baies |
Cependant, connaître le nombre d’IOPS (E/S par seconde) n’est pas suffisant. Il est tout aussi important de s’intéresser au débit (octets par seconde), c’est-à-dire à la manière dont les données sont effectivement acheminées vers les baies, en complément des performances des applications réelles.
La taille est similaire à un poids associé à chaque E/S. Une E/S de 64 Ko a un poids huit fois supérieur à une E/S de 8 Ko, car elle implique de déplacer huit fois plus d’octets. On peut alors établir la moyenne pondérée des tailles d’E/S dans chaque baie FlashArray. Les résultats sont présentés dans la Figure 3 ci-dessous.
Les chiffres issus de la moyenne pondérée et des IOPS brutes sont très différents. On constate que la plupart des opérations de lecture font entre 32 et 64 Ko, tandis que les opérations d’écriture font le plus souvent entre 16 et 32 Ko. En fait, la majorité des baies de nos clients traitent des E/S dont la taille pondérée est supérieure à 32 Ko.
| Majorité d’E/S => 32 Ko | Majorité d’E/S => 16 Ko | |
| Lectures | 71 % des baies | 93 % des baies |
| Écritures | 30 % des baies | 79 % des baies |
Comment concilier ces deux visions du monde ? Les IOPS nous apprennent que la plupart des E/S sont de petite taille, mais les IOPS pondérées (débit) révèlent le contraire.
Pour mieux comprendre, reportons les IOPS et le débit sur le même graphique. Les Figures 4 et 5 montrent la répartition des IOPS et le débit par taille d’E/S sur toutes les baies FlashArray de nos clients dans le monde entier. La Figure 4 se rapporte aux écritures, la Figure 5 aux lectures.
Pour les écritures comme pour les lectures, on observe que les IOPS sont majoritairement de petite taille, alors que la majorité de la charge réelle correspond à des E/S importantes.
En moyenne, 79 % des opérations d’écriture font moins de 16 Ko, mais 74 % de toutes les données écrites impliquent des opérations supérieures à 64 Ko. Ainsi, on comprend mieux pourquoi la répartition varie selon qu’on parle d’IOPS ou de débit.
Modalités relatives aux tailles d’E/S : les 4 principaux types de répartition
Jusqu’à présent, nous avons examiné les tailles moyennes des E/S sur l’ensemble des baies FlashArray. Laissons désormais cette agrégation de côté pour voir si des tendances se dégagent dans les types de charges de travail que les clients exécutent.
Il s’avère qu’il existe quatre types de répartition (ou profil) typique, comme le montre la Figure 6 ci-dessous :
- Unimodale : une taille domine toutes les autres
- Bimodale : les E/S sont généralement de deux tailles
- Trimodale : les E/S sont le plus souvent de trois tailles
- Multimodale : les E/S sont de toutes tailles
Le profil unimodal est le type de répartition le plus fréquemment observé, suivi dans l’ordre par le profil multimodal, bimodal et trimodal. Il ne faut pas oublier qu’une répartition unimodale peut représenter plusieurs applications distinctes exécutées sur la baie et utilisant la même taille de bloc.
Conclusion : la taille des E/S et le débit ont chacun leur importance
Nous avons présenté un grand nombre de données différentes ci-dessus. Nous avons vu qu’en général, le nombre de lectures est supérieur au nombre d’écritures. Nous avons également constaté que les E/S n’ont pas la même taille en fonction du point de vue adopté. Lorsqu’on s’intéresse uniquement aux IOPS, elles sont généralement de petite taille, mais lorsqu’on prend en compte le débit, leur taille est plus importante. Nous avons également remarqué que plus de la moitié des baies des clients exécutent une charge de travail avec plus d’une taille d’E/S dominante. Que pouvons-nous déduire concrètement de tous ces éléments ?
Tout d’abord, il faut tenir compte du fait que FlashArray s’inscrit dans un monde évoluant vers la consolidation. Il est plutôt rare qu’un client achète une baie pour exécuter une seule application. Il ne s’agit pas là d’une simple hypothèse. Dans le cadre de notre fonction Pure1® Analytics, nous appliquons un algorithme prédictif pour tenter d’identifier la charge de travail en cours d’exécution dans chacun des volumes d’une baie Pure FlashArray. La précision de ce modèle a été validée en recoupant les prédictions avec les clients. Nous avons constaté que 69 % des baies de nos clients exécutent au moins deux applications distinctes (VDI et SQL, par exemple). Un peu plus de 25 % des baies FlashArray de nos clients exécutent au moins trois charges de travail différentes (VDI, VSI et SQL, par exemple). C’est en raison de la diversité des applications sur une même baie FlashArray et de la variabilité au sein des applications elles-mêmes que les tailles d’E/S évoquées précédemment sont si différentes.
Nous sommes ravis de pouvoir confirmer l’hypothèse de base formulée il y a plus de sept ans lorsque nous avons commencé à créer l’environnement d’exploitation Purity de FlashArray. Contrairement à la plupart des fournisseurs de solutions flash qui se concentrent sur l’accélération d’une seule application, nous nous sommes attachés à créer des baies flash abordables, en donnant la priorité à la virtualisation et à la consolidation des applications dès le départ et en concevant Purity avec une taille de bloc variable et une architecture de métadonnées. Alors que certains concurrents divisent chaque E/S en blocs fixes pour l’analyse (8K pour XtremIO, par exemple) ou exigent que leur déduplication soit désactivée ou adaptée à une taille de bloc fixe pour préserver les performances par volume (cas de Nimble), les services de données de Pure sont conçus pour fonctionner en toute simplicité, sans réglage, quelle que soit les tailles des blocs, selon le principe que chaque baie effectue constamment des E/S mixtes (et il s’avère que même les baies avec une seule application exécutent de nombreuses E/S mixtes). Si votre fournisseur vous demande d’indiquer, d’adapter ou même d’anticiper la taille des E/S de votre application, prenez cela comme un avertissement : dans le modèle cloud, vous ne pouvez pas contrôler ni même demander des précisions sur les charges de travail de votre service de stockage.
Les baies Pure FlashArray sont donc déployées dans des environnements de consolidation, ce qui entraîne une répartition complexe de la taille des E/S, mais qu’est-ce que cela signifie du point de l’évaluation pratique des performances ? La meilleure façon de simuler une telle complexité avec précision est d’essayer d’exécuter les charges de travail réelles que vous avez l’intention d’exécuter en production lors de l’évaluation d’une nouvelle baie de stockage. Ne sélectionnez pas une, deux ou trois tailles de bloc, cette approche limitée n’est pas adaptée aux applications réelles avec plusieurs tailles d’E/S, en particulier dans les environnements de plus en plus consolidés. Essayez plutôt d’exécuter vos charges de travail réelles, c’est la seule façon de vraiment saisir ce qui est important dans votre environnement. Nous nous passionnons depuis des années pour les tests impliquant différentes tailles d’E/S réelles. Vous trouverez une liste des articles publiés à ce sujet à la fin de la page.
Si ce type de test n’est pas réalisable ou pratique, essayez de comprendre comment sont réparties les tailles d’E/S de votre charge de travail et faites des essais en fonction de ces modalités. Et si une taille d’E/S unique est nécessaire, par exemple à des fins de comparaison rapide, nous vous conseillons 32 Ko, car les tailles moyennes pondérées des E/S de toutes les baies des clients convergent vers ce chiffre. En outre, cela permet de s’écarter de la « référence des 4K » que le secteur du stockage a toujours mis en avant à des fins de marketing.
Nous espérons que cet article vous aura permis d’en apprendre davantage sur les performances d’une baie 100 % flash en matière de réduction des données et la manière dont nous utilisons l’analytique et le Big Data dans Pure1 pour comprendre les environnements de nos clients, mais aussi améliorer la conception de nos produits. Pour en savoir plus sur Pure1, consultez la page produit.
Voici une sélection d’articles de blog sur l’évaluation des performances :
Written By:
