PowerStore : techniques efficaces d’évaluation des performances des baies de stockage

Remarque : L’analyse comparative n’est valide que si tout est configuré conformément aux pratiques d’excellence PowerStore et qu’il n’y a aucun problème de connectivité ou de configuration. Dans le cas contraire, le test produira probablement des données non pertinentes.

• Testez en utilisant des variables qui ressemblent à ce que sera la charge applicative/l’environnement réel. N’oubliez pas que la plupart des outils sont des simulateurs et n’atteignent jamais 100 % d’une véritable charge de travail de production simulée.
• Si la charge applicative varie considérablement, envisagez d’effectuer plusieurs itérations de tests de lecture/écriture avec des tailles de blocs et des modèles d’accès variables.
• Utilisez des opérations ou des tests multithread et asynchrones pour garantir des performances parallèles ou simultanées et vous assurer que le potentiel de débit global agrégé est en cours d’exercice. 
• Analysez et passez en revue les points de référence standard du secteur pour les équipements évalués en rapport avec la charge applicative de production de votre entreprise.
• N’effectuez pas de tests sur des systèmes de fichiers et/ou des volumes vides ou à faible utilisation d’espace. Si vous n’allouez pas au préalable d’espace sur les charges applicatives d’écriture, vous pouvez constater la latence due à l’allocation d’espace à la volée pendant le test.
• N’oubliez pas de tester les E/S de lecture, car il s’agit généralement de la prédominance des deux dans la plupart des environnements. Tenez compte des pertes de paquets/trames dans l’infrastructure réseau pendant le test.
• Vérifiez que vous effectuez des tests sur plusieurs appareils afin de simuler un environnement classique avec de nombreux hôtes ou clients. Par exemple, sur PowerStore, un nombre approprié est de 16 volumes. Le nombre de volumes correspond généralement au nombre d’hôtes ou de clients utilisés (physiques ou virtuels). C’est là que la concurrence est atteinte.

 

Outils et simulateurs
d’analyse comparativeGardez à l’esprit que la plupart des outils sont des simulateurs et qu’ils ne pourront probablement jamais être composés à 100 % d’une véritable charge applicative de production. Ces outils d’analyse comparative sont utilisés pour vous faire une idée de la façon dont les performances pourraient, devraient ou seraient dans certaines situations. Dell ne possède pas ces outils et n’est pas responsable des problèmes qui pourraient y être associés.

Dans toutes les situations de test de performances, assurez-vous que des outils dotés de fonctionnalités asynchrones et multithreading sont utilisés. Exemples de ces outils :

• Testeur d’E/S flexible (FIO)
• IOmeter
• Vdbench (nécessite un compte Oracle)
• NFSometer (Fedora/NFS uniquement)
• Liste de contrôle des performances NAS d’Intel

 

Évitez les types de tests suivants :

• Copier et coller
• Glisser-déposer
• Sauvegarde d’un système de fichiers unique sur disque
• Tests DD
• Rlarge
• Wlarge
• Mkfile
• Décompression, extraction et compression

Certains éléments doivent être pris en compte dans la plupart des scénarios d’analyse comparative. Cette section ne remplace pas la compréhension de la taille et des caractéristiques des charges applicatives. Toutefois, si vous manquez de données antérieures et avez besoin d’une estimation approximative du comportement de votre application pour évaluer les fonctionnalités de PowerStore (et non les performances spécifiques de la charge applicative), tenez compte des facteurs suivants :

 

 

IODepth (profondeur de file d’attente)
Une faible profondeur d’E/S (ou pas assez élevée) peut limiter votre débit potentiel en fonction de la situation. Par conséquent, il est toujours important de vérifier que IOdepth est suffisamment élevée pour refléter ou émuler les exigences de concurrence d’un ensemble de données. Une IOdepth trop faible peut ne pas permettre d’utiliser l’appareil à son plein potentiel. De plus, méfiez-vous d’une IOdepth trop élevée, cela peut entraîner une mise en file d’attente importante sur l’appareil et, en fonction du temps de service de l’appareil, les temps de réponse peuvent être plus importants. Cela peut être le reflet de ce à quoi pourrait ressembler un système surchargé.

Pour ce test, les chiffres sont significativement plus faibles lorsqu’il y a une profondeur d’E/S de un par rapport à une profondeur d’E/S de quelque chose de plus réel, comme 64. Gardez à l’esprit qu’il s’agit d’une baie All-Flash et que ce concept est donc vu sous sa forme extrême, mais de plus en plus courante.

IOdepth=1", soit environ ~30 000 opérations d’entrée et de sortie par seconde (IOPS) en moyenne pour le test.

 

« IOdepth=64 » correspond à environ 107 000 IOPS en moyenne pour le test.

 

 

« IOdepth=256 » correspond à environ 142 000 IOPS en moyenne pour le test.

 

 

Comme mentionné, les performances se situent à une certaine IOdepth dans la plupart des configurations. Dans ce cas, la profondeur de file d’attente est de 512 et il n’y a qu’une légère augmentation des IOPS par rapport à une profondeur d’IOPS de 64.

« IOdepth=512 » correspond à environ 146 000 IOPS en moyenne pour le test.

 

 


Asynchrone vs Synchrone
Deux grands moteurs distincts sont utilisés. Les plus populaires et de loin les plus efficaces en termes de performances sont les « E/S asynchrones ». Le type de moteur le moins efficace et le moins performant correspond aux E/S synchrones et est généralement utilisé avec des applications qui ont des exigences strictes en matière d’intégrité et d’assurance des données. Les E/S synchrones sont également disponibles dans les technologies de réplication de point de récupération proche de zéro (RPO). En matière de tests et d’analyse comparative des performances, du point de vue de l’hôte, asynchrone signifie qu’un accusé de réception n’est pas nécessaire pour une seule E/S afin de demander l’E/S suivante. Dans les charges applicatives synchrones, un accusé de réception est nécessaire pour une E/S avant que la suivante ne soit émise, et un accusé de réception (ACK) pour chaque E/S suivante demandée. Par conséquent, les E/S synchrones ont généralement une file d’attente de 1 ou moins et n’utilisent jamais pleinement la ressource à son plein potentiel. Le couplage d’opérations synchrones avec un nombre de threads faible ou unique peut limiter considérablement le potentiel de performances. Vérifiez donc toujours que vous effectuez des tests asynchrones, et si vous utilisez des tests synchrones, assurez-vous d’utiliser plusieurs threads, sauf si l’environnement applicatif vous indique explicitement de ne pas le faire.

Asynchrone (Libaio - asynchrone native Linux) = 1 thread



Sync (E/S synchrones) :  

 

 

Nombre de threads
Les fils sont importants. Les tests doivent toujours être effectués à l’aide de plusieurs threads, en particulier dans les tests/charges applicatives synchrones. Il s’agit d’essayer de simuler plusieurs itérations d’une tâche/d’un test en fonction du comportement du processus d’une application d’entreprise. Plusieurs threads associés à une activité simultanée permettent d’atteindre le débit agrégé d’un système. La plupart des moteurs asynchrones utilisent plusieurs threads, vous n’avez donc pas à vous soucier autant du nombre de threads. Si vous ne disposez pas de suffisamment de threads lors de charges applicatives synchrones, vous pouvez limiter considérablement le débit potentiel total d’un test de charge par rapport à un système.

« Multithread » signifie que plusieurs threads travaillent en parallèle. Par exemple, si vous disposez d’un seul appareil capable de traiter 1 000 E/S par seconde dans une charge applicative synchrone, le temps de réponse de l’appareil est de 1 ms sans file d’attente (donc sans file d’attente, temps de service et temps de réponse doivent être synonymes). Évidemment, les appareils avec des temps de réponse de 1 ms peuvent faire beaucoup plus de travail que 1 000 IOPS, et cela est réalisé en empilant plusieurs threads ou flux parallèles de la même charge applicative. Ainsi, si vous augmentez le nombre de threads (ou « choses faisant ce travail spécifique ») à 10, vous avez maintenant 10 threads individuels effectuant des E/S vers un appareil à 1 ms. Chaque thread de charge applicative individuel obtient toujours 1 ms, ce qui signifie que chaque thread n’atteint toujours que 1 000 IOPS, mais que l’ensemble du « processus » ou de la « tâche » exécuté par ces multiples threads obtient désormais 10 000 IOPS.

Il existe des outils et des charges applicatives qui peuvent atteindre les limites d’un appareil avec un seul thread, et d’autres en ont besoin de plus. En résumé, lorsque vous simulez une charge synchrone, vous devez avoir autant de threads/workers/flux que possible sans affecter le temps de réponse global. Il peut arriver que l’augmentation du nombre de threads cesse d’avoir un effet positif (lorsque l’appareil est occupé à 100 %). En général, avec les charges applicatives asynchrones, le nombre de threads est géré par défaut. Par exemple, vous pouvez toujours voir ci-dessous une différence entre 1 thread et 10 pour une charge applicative asynchrone, bien que non significative. Morale : avec les charges applicatives asynchrones, vous ne devriez pas avoir à vous soucier autant des threads. 

Un seul thread peut atteindre 68 000 IOPS à l’aide du moteur « libaio » (async). 

 

Si vous augmentez le nombre de threads (numjobs) à 10, vous constaterez toujours une augmentation des E/S par seconde.

 

En ce qui concerne les charges applicatives synchrones, bien qu’il s’agisse d’un cas extrême, deux facteurs majeurs peuvent rendre ce test peu performant, à savoir la nature synchrone. 

envoyer les E/S 1, attendre l’accusé de réception, envoyer les E/S 2, attendre l’accusé de réception, etc.

 Et de ne pas pouvoir empiler plusieurs threads dans le même but. 

job1=envoyer I/O-1 - job2=envoyer I/O-1 - job3=envoyer I/O-1..... job1=get ack, send I/O-2 - job2=get ack, send I/O-2 - job3= get ack, send I/O-2 ainsi de suite

Balise directe

Avec certains outils, en particulier les outils/systèmes d’exploitation basés sur *nix, vous pouvez voir une option « Direct I/O ». Elle peut être utilisée avec les moteurs « asynchrones » et ne doit pas être confondue avec les E/S « synchrones ». Dans certains outils sans cette balise spécifiée, vous pouvez écrire dans le cache du serveur et non directement sur le disque. L’hôte souhaite contourner son propre cache et écrire directement sur le disque. Il s’agit d’un facteur essentiel lors du test du stockage. Lorsque vous avez défini la balise « direct », vous écrivez techniquement sur le disque, bien que le « disque » dans ce cas soit en fait du cache de stockage. Cela reste acceptable à des fins de test, car même avec la charge applicative appropriée, vous continuez à simuler et à imiter avec précision le comportement de cette charge applicative dans un environnement réel, car la charge de production atteint également le cache avant de renvoyer l’accusé de réception. (Ne vous sentez pas floué simplement parce que vous obtenez des nombres de performances de cache impliqués et pas seulement les piles de back-end.)

 

Bande passante (Mo/s) vs. débit (IOPS)

Vous pouvez tester deux perspectives majeures. Dans le domaine de la gestion du réseau et des performances, le débit est généralement associé au transfert de données, mais dans un environnement SAN/bloc, il est courant d’utiliser le terme « débit » pour représenter les IOPS. Par conséquent, vous devez d’abord comprendre les caractéristiques des charges applicatives que vous testez.

Bande passante (Mo/s) : la bande passante est la mesure des données que vous pouvez stocker en une seule fois (ou dans un intervalle de X, généralement « par seconde ») sur un canal ou un système. Cela signifie qu’elle mesure la quantité de données que vous avez transférées sur une période donnée. Bien que la bande passante et les E/S par seconde ne s’excluent pas mutuellement, vous pouvez avoir des nombres de bande passante plus ou moins élevés avec la même quantité d’E/S par seconde, tout dépend de la taille de bloc. N’oubliez pas que vous ne mesurez pas la vitesse avec la bande passante. La vitesse est quelque chose de totalement différent et, bien qu’elle affecte la bande passante, elle est généralement quelque chose que vous ne pouvez pas contrôler avec des charges applicatives à bande passante élevée. Par conséquent, si vous testez la bande passante, utilisez toujours des blocs plus volumineux (dans la limite du raisonnable) afin que vos données par E/S soient plus volumineuses que si vous testiez les E/S par seconde, car la maintenance des blocs plus volumineux prendra naturellement plus de temps. Par exemple, si vous souhaitez atteindre 1 Mo/s, mais que vous utilisez des tailles de bloc de 8 Ko, vous devez envoyer environ 125 IOPS pour y parvenir. Toutefois, si vous utilisiez des blocs de 512 Ko, cela ne prendrait que deux (2) IOPS.
(Si vous deviez conserver les 125 IOPS tout en augmentant la taille de bloc de 8 Ko à 512 Ko, vous poussez maintenant 64 Mo/s !)

Toutefois, étant donné qu’il y a plus de données dans une seule E/S, il faut généralement plus de temps pour « regrouper » cette E/S (recherche, enchaînement, etc.). Par conséquent, les temps de service peuvent naturellement être plus élevés. Parfois, vous avez une file d’attente plus petite, de sorte que vos temps de réponse, bien que naturellement plus élevés, devraient être plutôt proches. N’oubliez pas que, bien que le temps de réponse joue un rôle dans la quantité de bande passante que vous pouvez atteindre, l’augmentation de la quantité de données par E/S l’emporte généralement sur toute légère augmentation du temps de réponse (RT) par type d’E/S. Étant donné que les temps de réponse sont plus élevés, il n’est pas souhaitable que les charges applicatives utilisant des blocs volumineux soient aléatoires. Les charges applicatives de bande passante ont tendance à être séquentielles. Lorsque vous introduisez une nature aléatoire dans une charge applicative en mode bloc volumineuse, votre taux de transfert de données régulier est régulièrement interrompu et vous commencez à ressentir les effets des temps de réponse légèrement plus élevés par E/S.

Débit (E/S par seconde) : le débit/E/S par seconde est la perspective la plus courante avec les charges applicatives en mode bloc de petite taille, en particulier lorsqu’elles deviennent plus aléatoires. Toute taille supérieure à 32 Ko-64 Ko peut être considérée comme un grand bloc. En ce qui concerne la capacité de traitement, les facteurs mentionnés ci-dessus sont les plus importants (par exemple, le nombre de threads, synchrone ou asynchrone, la profondeur de file d’attente, etc.). Ici, vous essayez de mesurer non pas la quantité globale de données que vous pouvez transférer pendant l’intervalle X, mais plutôt le nombre de packages individuels (demandes d’E/S) transportant ces données que vous essayez de traiter (tous les intervalles x). Les environnements tels que les OLTP (banques) se soucient peu de la quantité de données qu’ils peuvent transférer, car leur empreinte est généralement faible. Toutefois, ces petits jeux de données peuvent être et sont normalement occupés. Ces jeux de données ont un décalage élevé (une petite quantité d’espace est référencée, mais varie de manière agressive et cohérente). Les petits paquets de données contiennent généralement uniquement des demandes de modification/mise à jour des blocs avec des valeurs numériques ou de chaîne plus petites. Par conséquent, les paquets d’E/S volumineux ne sont pas requis. Toutefois, en raison de la nature des transactions et de leur nombre élevé, nous voulons vérifier que nous pouvons répondre à chaque demande individuelle. En général, plus la taille de bloc est petite, plus vous pouvez atteindre d’E/S par seconde dans un scénario donné. Bien que les charges applicatives en mode bloc de petite taille soient principalement associées à un accès aléatoire, vous pouvez atteindre un débit encore plus élevé avec des charges applicatives séquentielles en mode bloc de petite taille. En revanche, les charges applicatives séquentielles en petits blocs sont spécifiques et moins courantes. Par conséquent, testez ces scénarios uniquement si votre environnement l’exige.