Ph1l's (sys|net)admin [lfo] blog

Le «train» de la virtualisation entraîne avec lui des évolutions importantes aux niveaux réseau et stockage, Au delà des frontières technologiques, les découpages métier sont en train de bouger rapidement. Le temps où les «gens du système» et les «gens du réseau» s'ignoraient cordialement peut être considéré comme révolu.

On observe actuellement des mouvements que l'on peut comparer à ceux d'un ascenseur. Dans un sens, la virtualisation de plusieurs instances de systèmes d'exploitation sur un même système hôte a littéralement aspiré la commutation réseau au sein de ce système hôte. Dans l'autre sens, les besoins de mobilité et de réplication du stockage des données ont provoqué la dispersion des fonctions de stockage à travers le réseau.

Dans un tel contexte, comment évaluer correctement les performances entre des systèmes aux caractéristiques aussi diverses ? Bien avant l'avènement des fonctions de virtualisation, le sujet était déjà très polémique. L'expression consacrée, librement traduite de l'anglais, est toujours aussi éloquente ‐ «Au début il y a eu des mensonges, puis de sacrés mensonges et enfin des benchmarks».

Interrogation supplémentaire, comment sensibiliser les étudiants à une démarche d'évaluation des performances d'une solution de stockage sans ajouter un mensonge de plus ? Il est facile de tenir des propos péremptoires et définitifs sur le thème ‐ «Les constructeurs, tous des menteurs». Il est autrement plus délicat de faire passer une méthode d'évaluation suffisamment rigoureuse.

Tout d'abord, j'ai commencé par réaliser une présentation baptisée Stockage réseau. L'objectif de ce support de cours est de présenter les acronymes DAS, NAS et SAN, d'introduire la distinction entre les accès en mode blocs et en mode fichier, puis de donner quelques pistes sur les contraintes et les solutions en matière de réplication.

Ensuite, j'ai cherché à illustrer les notions sur le stockage avec des travaux pratiques à base de logiciel libre. Logiquement, j'ai pensé à une séance destinée à présenter les accès en mode bloc en utilisant iSCSI et une autre séance pour présenter les accès en mode fichier en utilisant NFS.

Il restait à trouver une méthodologie d'évaluation des performances commune aux deux séances qui permette aux étudiants un début d'analyse critique sur les avantages et inconvénients des solutions présentées. C'est à ce niveau que les difficultés commencent.

Après de nombreuses recherches, j'ai fini par trouver un article du site http://fsbench.filesystems.org/ intitulé Notes on a Nine Year Study of File System and Storage Benchmarking qui résume bien les limites de l'exercice. L'étude en question porte sur 415 benchmarks et 106 publications. L'article met en évidence les nombreux défauts présents dans tous les documents étudiés.

Au niveau le plus général, il faut considérer le fait que les systèmes de fichiers et de stockage ont des propriétés particulières qui les distinguent des autres éléments du système. Il est d'autant plus difficile d'analyser le comportement d'un système que les interactions sont complexes entre les dispositifs d'entrée-sortie, les caches, les démons et les autres composants du noyau. D'autres facteurs de complexité viennent s'ajouter comme les optimisations et les différentes nature de charge de travail réelles.

La question de la reproduction d'une charge de travail utile sur une infrastructure de stockage est un problème à part entière. Si on ne peut pas se contenter de suites d'écritures ou de lectures séquentielles, une distribution totalement aléatoire des écritures et des lectures ne correspondra pas vraiment au profil du trafic généré par de véritables utilisateurs.

Dans une situation idéale, pour exploiter correctement les résultats d'un banc d'essai, le lecteur devrait être capable de vérifier les résultats et comparer les performances entre systèmes. Un certain nombre de critères sont énoncés dans l'article pour s'approcher de cet objectif.

Détailler la configuration de test. Il est important de préciser la configuration matérielle utilisée pour réaliser les tests de performances. Récemment, on a vu apparaître de nombreux chiffres indiquant des performances quasi identiques entre un stockage DAS utilisant la technologie SAS et un stockage SAN utilisant la technologie iSCSI. Les mesures en question peuvent paraître très suspectes si on ne prend pas en compte le fait que la connexion réseau de la baie de stockage iSCSI utilise une agrégation de 4 liens Gigabit Ethernet qui permettent d'atteindre le débit d'une connexion physique SAS à 3 Gigabits par seconde.

Préciser les objectifs du banc d'essai.. On doit pouvoir identifier facilement les motivations qui déterminent les conditions des tests de performances. Entre une solution de stockage destinée à l'hébergement du courrier électronique (fichiers de taille réduite) et solution dédiée au stockage d'un gestionnaire de bases de données (fichiers de taille importante), les conditions d'évaluation des performances diffèrent du tout au tout.

Indiquer la durée des tests effectués. Pour être significatifs, les résultats doivent durer plus de quelques minutes et être répétés plusieurs fois. Si les exécutions multiples d'un test produisent des résultats différents, des éléments statistiques précis doivent aussi être fournis.

Dans l'article cité en référence, les auteurs distinguent trois catégories de benchmarks.

Les Macro-Benchmarks utilisent plusieurs types d'opérations de nature différente et permettent d'obtenir une vue globale des performances d'un système. C'est dans cette catégorie que l'on trouve les mesures de temps de compilation. Le principal défaut de ce style de mesure apparaît assez facilement. Est-ce que le temps de compilation du noyau Linux est représentatif de la charge utile générée par les utilisateurs du système ? On peut en douter. Dans le contexte du stockage, le fait d'effectuer des opérations qui consomment le maximum des ressources des processeurs peut masquer le temps consacré par le système à la gestion des systèmes de fichiers (overhead).

Les tests Trace-based sont basés sur la répétition d'un trafic réel enregistré. Relativement à la catégorie précédente, l'intérêt de ce genre d'évaluation est évident, on cherche à se rapprocher le plus possible d'une charge utile correspondant aux véritables conditions d'exploitation de la solution de stockage. L'objectif est aussi d'obtenir une vue globale des performances. Quatre défauts importants sont identifiés avec cette technique  la méthode de capture, la technique de répétition, la validité de la capture et sa disponibilité. Côté méthode de capture, suivant la couche du système d'exploitation utilisée pour la capture, on introduit un biais dans l'évaluation. Par exemple, si la capture est effectuée au niveau du système de fichiers ou au niveau des appels système, on pourra distinguer les opérations qui ont été servies ou non par le cache. Les trois autres défauts dépendent beaucoup de la solution utilisée pour répéter le profil de charge sur le système à évaluer.

Les Micro-Benchmarks se limitent à un ou deux types d'opérations. Ils sont utiles pour mesurer les caractéristiques d'éléments spécifiques d'un système. Ces tests présentent un intérêt s'ils sont accompagnés d'autres tests appartenant aux autres catégories ; notamment de Macro-Benchmarks.

Une fois la terminologie posée, il faut faire des choix dans le catalogue des outils disponibles. Ce qui ne manquera pas d'introduire de nouveaux biais.

Comme indiqué ci-dessus dans la section consacrée au contexte, le choix des outils d'évaluation des performances doit être compatible avec les enseignements de travaux pratiques. La contrainte principale qui apparaît immédiatement est le temps d'exécution des tests.

# dpkg -i phoronix-test-suite_2.4.1_all.deb
# apt-get -f install

Pour les besoins de ce billet, voici quelques échantillons des résultats obtenus avec mon transportable Dell M6300 dont les caractéristiques sont données ci-après. À titre d'élément de comparaison, les mêmes évaluations ont été lancées sur une instance de machine virtuelle KVM hébergée sur la même plateforme matérielle. La solution utilisée pour la virtualisation est décrite dans l'article Virtualisation système et enseignement.

Bien entendu, les résultats présentés ici n'ont aucune valeur sachant que la seule motivation ici est l'illustration des résultats produits par les outils. Ce ne sont que des exemples.

$ time phoronix-test-suite benchmark disk
<snipped/>
real    292m23.586s
user    7m54.765s
sys     20m31.907s

$ time phoronix-test-suite benchmark phil-24236-10417-13128
<snipped/>
real    453m30.958s
user    11m2.421s
sys     20m43.946s

$ time phoronix-test-suite benchmark computational
<snipped/>
real    212m7.386s
user    77m32.570s
sys     2m27.696s

$ time phoronix-test-suite benchmark phil-24027-7738-19351
<snipped/>
real    75m35.505s
user    62m16.750s
sys     2m4.836s

$ time phoronix-test-suite benchmark linux-system
<snipped/>
real    333m5.239s
user    186m17.410s
sys     11m32.569s

$ time phoronix-test-suite benchmark phil-18060-16906-20793
<snipped/>
real    75m35.505s
user    62m16.750s
sys     2m4.836s

Le micro-benchmark fdtree

Pour réaliser les tests suivants, je me suis appuyé sur l'article du site LINUX Magazine intitulé Improving MetaData Performance of the Ext4 Journaling Device. Voici les résultats de plusieurs tests successifs, réalisés sur le transportable M6300 dont la configuration est donnée ci-dessus.

L'outil fdtree est utilisé suivant 2 modes pour évaluer les performances des opérations sur les méta-données du système de fichiers Ext4. Là encore, la configuration du transportable est un facteur limitant dans la conduite des tests. En effet, le volume total disponible sur la partition utilisée est inférieur à 22GB.

	Avertissement
	Les résultats présentés ci-dessous ne sont que des échantillons. Ils ne constituent pas un véritable banc d'éssai sachant que les commandes n'ont été exécutées qu'une seule fois. Pour bien faire, il aurait fallu faire la moyenne d'au moins 5 mesures de chacune des valeurs affichées dans les deux tableaux.

Arborescence «peu profonde»

Dans ce mode d'évaluation, on lance la création puis l'effacement de 8 répertoires de «premier rang» ayant chacun 4 niveaux de sous-répertoires. L'arborescence ainsi définie est évaluée avec 4 dimensions de fichiers différentes dans chacun des sous-répertoires.

• 16 fichiers dont la taille correspond à 1 bloc, soit 4KB

• 2 fichiers dont la taille correspond à 24 blocs, soit 96KB

• 2 fichiers dont la taille correspond à 32 blocs, soit 128KB

• 1 fichier dont la taille correspond à 48 blocs, soit 192KB

$ for size in "1 16" "24 2" "32 2" "48 1"
do
set -- $size
~/bin/fdtree.bash -d 4 -l 8 -f $2 -s $1 >output_fdtree_short_$1.txt
done

Arborescence «assez profonde»

Dans ce mode d'évaluation, on lance la création puis l'effacement de 4 répertoires de «premier rang» ayant chacun 8 niveaux de sous-répertoires. L'arborescence ainsi définie est évaluée avec 4 dimensions de fichiers différentes dans chacun des sous-répertoires.

• 16 fichiers dont la taille correspond à 1 bloc, soit 4KB

• 8 fichiers dont la taille correspond à 128 blocs, soit 512KB

• 4 fichiers dont la taille correspond à 256 blocs, soit 1MB

• 2 fichiers dont la taille correspond à 1024 blocs, soit 4MB

$ for size in "1 16" "128 8" "256 4" "1024 2"
do
set -- $size
~/bin/fdtree.bash -d 8 -l 4 -f $2 -s $1 >output_fdtree_deep_$1.txt
done

Tableau 4. Arborescence peu profonde

Fichiers par niveau	Volume KiB	Répertoires créés /s	Fichiers créés /s	Volume KiB/s	Fichiers effacés /s	Répertoires effacés /s
Moyenne	15379056	618	284	20114	1459	2137
Écart type	6094159	13	153	10684	1137	116
16	5592384	598	543	2175	3393	1941
2	16777152	615	227	21873	924	2184
2	22369536	624	215	27582	1046	2184
1	16777152	633	150	28826	474	2240

Tableau 5. Arborescence assez profonde

Fichiers par niveau	Volume KiB	Répertoires créés /s	Fichiers créés /s	Volume KiB/s	Fichiers effacés /s	Répertoires effacés /s
Moyenne	19248272	752	225	43206	1521	3511
Écart type	13451914	48	303	26883	1127	1171
16	299584	780	748	2995	4160	4681
8	19173376	780	89	45869	3404	4681
4	19173376	668	44	45220	1101	2340
2	38346752	780	19	78740	1170	2340

Bien que l'outil fdtree soit très intéressant, les valeurs des échantillons présentés dans ces deux tableaux sont un peu trop «dispersées» pour être significatives. En effet, même avec les chiffres du nombre de répertoires créés par seconde pour lesquels le volume de méta-données unitaire est constant, les écarts types sont très importants.

On retrouve ici les deux gros défauts de ces tests effectués à titre d'illustration. Tout d'abord, il aurait fallu répéter un dizaine de fois l'exécution d'un jeu de paramètres et calculer les valeurs moyennes des résultats obtenus. Ensuite, il aurait fallu disposer d'un espace libre suffisant pour pouvoir manipuler un nombre constant de fichiers par niveau.

Bref, même si le temps d'une exécution de l'outil est compatible avec la durée d'une séance de travaux pratiques, il est tout de même nécessaire de disposer d'un temps important pour mener un banc d'essai qui puisse produire des résultats valides.

Le micro-benchmark iozone

Pour réaliser les tests suivants, je me suis appuyé sur l'article du site LINUX Magazine intitulé I Feel the Need for Speed: Linux File System Throughput Performance, Part 1. Voici les résultats de trois tests successifs, réalisés sur le transportable M6300 dont la configuration est donnée ci-dessus.

Le but de ces tests est de caractériser les performances du système de fichiers ext4 en fonction de quatre tailles d'enregistrement  1MB, 4MB, 8MB et 16MB. La taille du fichier de test est fixée à 16GB, c'est à dire une valeur plus importante que celle des caches du processeur, du CPU et du système de fichiers. Le but est justement d'obtenir des mesures de performances indépendantes des optimisations de chacun des éléments du système.

Dans l'ordre des tests lancés ci-après, le fichier de 16GB sera constitué de 16000 enregistrements de 1MB, puis de 4000 enregistrements de 4MB, puis de 2000 enregistrements de 8MB et enfin de 1000 enregistrements de 16MB.

	Avertissement
	De même que dans la section précédente, les résultats présentés ci-dessous ne sont que des échantillons. Ils ne constituent pas un véritable banc d'essai sachant que les commandes n'ont été exécutées qu'une seule fois. Pour bien faire, il aurait fallu faire la moyenne d'au moins 5 mesures de chacune des valeurs affichées dans les deux tableaux.

$ time iozone -Rb spreadsheet_output_1M.wks -s 16G -r 1M > output_1M.txt ;\
 time iozone -Rb spreadsheet_output_4M.wks -s 16G -r 4M > output_4M.txt ;\
 time iozone -Rb spreadsheet_output_8M.wks -s 16G -r 8M > output_8M.txt ;\
 time iozone -Rb spreadsheet_output_16M.wks -s 16G -r 16M > output_16M.txt

real    87m0.101s
user    0m11.215s
sys     6m23.631s

real    77m1.963s
user    0m16.416s
sys     6m46.863s

real    75m35.788s
user    0m15.659s
sys     6m47.312s

real    74m59.931s
user    0m13.853s
sys     6m42.174s

Tableau 6. Débits en lecture

Record MB	Read KB/s	Re-read KB/s	Random Read KB/s	Backward Read KB/s	Stride Read KB/s	Fread KB/s	Re-fread KB/s
Moyenne	49045	49257	40922	45247	45083	49259	49334
Écart type	82	171	7285	5068	6073	246	171
1	48974	49019	28644	36678	34756	49358	49303
4	49111	49416	42400	46472	46650	49177	49391
8	49141	49423	45607	48265	49330	49586	49558
16	48954	49170	47038	49573	49596	48914	49085

Tableau 7. Débits en écriture

Record MB	Write KB/s	Re-write KB/s	Random Write KB/s	Record Rewrite KB/s	Fwrite KB/s	Re-fwrite KB/s
Moyenne	50817	50042	44399	1610483	50392	50635
Écart type	397	395	4400	891097	526	60
1	50139	49791	37177	3149958	51123	50668
4	51053	50147	44554	1200128	50657	50576
8	50948	49595	47546	1059762	49946	50578
16	51129	50634	48318	1032083	49840	50717

À partir des données des deux tableaux ci-dessus, on observe des écarts de performances importants entre la première taille d'enregistrement évaluée (1MB) et les autres. Avec une taille d'enregistrement supérieure ou égale à 4MB les performances sont uniformes et les écarts types assez faibles.

Si on fait abstraction de la première ligne de chaque tableau, on peut considérer que l'on a une image correcte des performances du système de fichiers ext4 sur le transportable M6300 indépendante des optimisations et des caches. En effet, les débits relevés sont suffisamment proches d'une opération à l'autre.

La conclusion de ce billet est en demi-teinte. D'un côté, on dispose d'un premier niveau de méthodologie et de classification qui permet de conduire un banc d'essai de qualité correcte. Le simple fait de ne plus délivrer de conclusions péremptoires sur la base d'un seul outil de test est une victoire modeste, mais une victoire quand même. D'un autre côté, je reste sur ma faim sur le plan pédagogique. Il est quasiment impossible d'obtenir des résultats valides en trois heures de travaux pratiques. Une piste consisterait à préparer des scripts d'exécution en lots pendant une première séance, puis à collecter et exploiter les résultats lors d'une seconde séance le lendemain. La rotation entre plusieurs groupes rend la chose difficile.

Voilà ! Si vous êtes parvenu jusqu'à ces lignes, je vous en remercie et je serais très honoré de partager vos remarques sur le sujet. Il y a manifestement beaucoup à creuser sur la question.

Ce billet est disponible en version imprimable au format PDF : storage-bench.pdf.

$Id: storage-bench.xml 1480 2010-04-23 13:23:15Z latu $