Agrandir
/
Je suis anxieux si je ne peux pas regarder les clignotements dans la grande fenêtre du terminal en arrière-plan pendant que les tests s'exécutent.
Jim Salter
commentaires des lecteurs
110
avec 69 affiches participantes, y compris l'auteur de l'histoire
Partagez cette histoire
Partager sur Facebook
Partager sur Twitter
Partager sur Reddit
Fondamentaux du stockage
OpenZFS 2.1 est sorti - parlons de ses tout nouveaux vdevs dRAID
Retour à RAID : Les lecteurs Ars « Et si ? » édition
ZFS contre RAID : huit disques Ironwolf, deux systèmes de fichiers, un gagnant
ZFS 101—Comprendre le stockage et les performances ZFS
Comprendre le RAID : comment les performances passent d'un disque à huit
Voir plus d'histoires
Dans une couverture précédente opposant ZFS au RAID du noyau Linux, certains lecteurs craignaient que nous ayons manqué quelques astuces pour le réglage de mdraid. En particulier, Louwrentius
voulait
nous pour retester mdadm avec les bitmaps désactivés, et targetnovember
pensée
que XFS pourrait peut-être surpasser ext4.
Écrire l'intention
bitmaps
sont une fonctionnalité mdraid qui permet aux disques qui sont tombés et sont rentrés dans la baie de se resynchroniser plutôt que de reconstruire à partir de zéro. L'« âge » du bitmap sur le disque de retour est utilisé pour déterminer quelles données ont été écrites en son absence, ce qui lui permet d'être mis à jour avec les nouvelles données uniquement, plutôt que de le reconstruire à partir de zéro.
XFS et ext4 sont simplement deux systèmes de fichiers différents. Ext4 est le système de fichiers racine par défaut sur la plupart des distributions, et XFS est un poids lourd d'entreprise le plus souvent vu dans des tableaux de centaines voire de milliers de tébioctets. Nous avons testé les deux cette fois, avec le support bitmap désactivé.
L'exécution de toute la panoplie de tests que nous avons utilisée dans les articles précédents n'est pas triviale : la suite complète, qui teste un large éventail de topologies, de tailles de blocs, de nombres de processus et de types d'E/S, prend environ 18 heures. Mais nous avons trouvé le temps d'effectuer des tests sur les topologies lourdes, c'est-à-dire celles avec les huit disques actifs.
Une note sur les résultats d'aujourd'hui
Les
cadre
que nous avons utilisé pour les tests ZFS détruit, construit, formate et monte automatiquement les tableaux ainsi que l'exécution des tests réels. Nos tests mdadm d'origine ont été exécutés individuellement et manuellement. Pour nous assurer d'avoir la meilleure expérience pomme à pomme, nous avons adapté le cadre pour qu'il fonctionne avec
mddam
.
Lors de cette adaptation, nous avons découvert un problème avec notre test d'écriture asynchrone de 4KiB. Pour ZFS, nous avons utilisé
--numjobs=8 --iodepth=8 --size=512M
. Cela crée huit fichiers séparés de 512 Mo chacun, pour les huit fichiers séparés
fio
processus avec lesquels travailler. Malheureusement, cette taille de fichier est juste assez petite pour que mdraid décide de valider l'intégralité du test dans un seul lot séquentiel, plutôt que d'effectuer réellement 4 Gio d'écritures aléatoires.
Afin de faire coopérer mdadm, nous devions nous ajuster à la hausse jusqu'à ce que nous atteignions
--taille=2G
-à quel point
mddam
Le débit d'écriture de s a chuté à moins de 20 % de son débit « en rafale » lors de l'utilisation de fichiers plus petits. Malheureusement, cela prolonge également considérablement la durée du test d'écriture asynchrone de 4 Ko, et même
fio
's
--time_based
l'option n'aide pas, car dans les premières centaines de millisecondes,
mdraid
a déjà accepté l'intégralité de la charge de travail dans son tampon d'écriture.
Publicité
Étant donné que nos résultats de test seraient autrement légèrement différents
fio
configurations, nous avons effectué de nouveaux tests pour ZFS et mdraid avec les bitmaps par défaut activés, en plus du nouveau
--bitmap aucun
et les tests du système de fichiers XFS.
RAIDz2 contre mdraid6
Bien que nous ne testions aujourd'hui que des configurations à huit disques, nous testons à la fois des configurations de parité agrégée et des configurations de miroir agrégé. Tout d'abord, nous comparerons nos options de parité : ZFS RAIDz2 et Linux mdraid6.
Taille de bloc 1 Mio
La suppression de la prise en charge des bitmaps a accéléré les écritures asynchrones de mdraid6.
La définition de bitmap=none n'a pas aidé avec les écritures de synchronisation.
Les lectures de 1 Mio ne sont pas affectées par la fonction bitmap.
Lorsque nous avons créé un nouveau tableau mdraid6 à huit disques avec la prise en charge des bitmaps désactivée, nos écritures asynchrones se sont considérablement accélérées, mais la bosse supplémentaire de 27,9% n'a toujours pas amené mdraid6 à distance de cri des valeurs par défaut de ZFS, et encore moins du bon
taille d'enregistrement=1M
résultat.
Les lectures et les écritures synchrones n'étaient pas affectées par la prise en charge du bitmap ou son absence. Les écritures RAIDz2 sont plus du double de la vitesse des écritures mdraid6, même avec le bitmap, tandis que les lectures mdraid6 sont un peu moins du double de la vitesse des lectures RAIDz2.
Bien qu'il n'ait été testé que sans bitmap, XFS était à la traîne par rapport à ext4 à chaque test de 1 Mio.
Taille de bloc 4KiB
La suppression des bitmaps n'a eu aucun effet significatif sur les écritures de 4KiB. Mais pour la première fois, XFS surpasse ext4.
La suppression des bitmaps n'a pas aidé l'écriture de synchronisation de 1 Mio, et elles n'ont pas non plus aidé l'écriture de synchronisation de 4 Kio.
Sur les lectures, XFS et ext4 fonctionnent au coude à coude, à un peu plus du double de la vitesse de ZFS.
Les petites opérations aléatoires sont le cauchemar de tout RAID6 conventionnel. Ce n'est pas non plus le scénario idéal de RAIDz2 - mais la capacité de RAIDz2 à éviter d'être piégé dans un cycle de lecture-modification-réécriture lui confère un avantage de performances d'écriture de 6:1 par rapport à mdraid6. Mdraid6 s'en sort bien mieux sur les lectures aléatoires, avec un avantage de lecture 2:1.
Dans ces petits tests de blocs, XFS s'est maintenu avec ext4 et l'a même légèrement surpassé sur les écritures asynchrones de 4 Ko. Aucun de ces changements (prise en charge du système de fichiers ou des bitmaps) n'a eu d'impact significatif sur les performances globales de 4KiB de mdraid6.
Miroirs ZFS contre mdraid10
Les administrateurs qui ont besoin de performances maximales doivent abandonner les baies de parité et passer aux miroirs. Du côté de mdraid, mdraid10 surpasse mdraid6 dans chaque métrique de performance que nous testons, et un pool de miroirs ZFS surpasse de la même manière mdraid10 dans chaque métrique testée.
Publicité
Taille de bloc 1 Mio
La désactivation des bitmaps aide également 1 Mio à écrire pour mdraid10, mais seulement à hauteur de 5 % environ.
La désactivation des bitmaps aide également mdraid10 à effectuer des écritures synchronisées.
La vitesse de lecture n'est pas affectée par un bitmap (ou son absence).
Tout comme les tableaux de parité, mdraid10 gagne un boost d'écriture de 1 Mo, mais beaucoup plus petit que mdraid6, et ce petit boost ne change pas matériellement la relation de mdraid10 avec les miroirs ZFS plus rapides.
La désactivation des bitmaps n'a aucun impact sur les performances de lecture et, contrairement à RAIDz2, les miroirs ZFS gagnent également sur les performances de lecture de 1 Mio.
XFS est à nouveau derrière ext4 sur toutes les métriques testées.
Taille de bloc 4KiB
Les bitmaps n'ont aucun impact sur les performances d'écriture de 4KiB de mdraid10, mais XFS tourne en nombre inférieur à ext4.
mdraid10 effectue la même chose pour les écritures de synchronisation 4KiB, que ce soit XFS ou ext4, des bitmaps internes ou pas de bitmaps.
Les bitmaps n'affectent toujours pas la vitesse de lecture, et vous ne devriez pas vous y attendre.
Avec une taille de bloc de 4 Kio, RAID10 présente un avantage modéré par rapport aux miroirs ZFS : les lectures non mises en cache sont environ 35 % plus rapides. Mais mdraid10 abandonne un avantage de 4:1 en écriture et un avantage de 12:1 en écriture synchrone.
La présence ou l'absence de bitmaps n'a aucune différence visible sur une opération de 4KiB. Les performances de XFS sont égales à celles d'ext4 sur les écritures et les lectures synchronisées, mais un peu plus lentes sur les écritures asynchrones.
Conclusion
Bien que la désactivation du support bitmap ait un certain impact sur les performances d'écriture de mdraid6 et mdraid10, ce n'est pas le jour et la nuit dans nos tests et ne modifie pas matériellement la relation de la topologie avec son équivalent ZFS le plus proche.
Nous ne recommandons pas de désactiver les bitmaps, que vous vous souciez ou non de cette relation de performances avec ZFS. Les fonctions de sécurité sont
important
, et mdraid est un peu plus fragile sans bitmaps. Il existe une option pour les bitmaps "externes", qui peuvent être stockés sur un SSD rapide, mais nous ne le recommandons pas non plus - nous avons vu pas mal de plaintes concernant des problèmes avec des bitmaps externes corrompus.
Si votre grand critère est la performance, nous ne pouvons pas non plus recommander XFS sur ext4. XFS a suivi ext4 dans presque tous les tests, parfois de manière significative. Les administrateurs disposant de baies massives (des centaines de tébioctets ou plus) peuvent avoir d'autres raisons, davantage liées à la stabilité et aux tests, de choisir XFS. Mais les amateurs avec quelques disques sont bien servis avec l'un ou l'autre et, semble-t-il, peuvent obtenir un peu plus de performances avec ext4.
Image de la liste par
Jim Salter
