Vous avez acheté une pile de disques. Le tableur dit « un énorme vdev RAIDZ2 » est le plus efficace. Puis la production demande « pourquoi la latence a-t-elle grimpé à 80 ms pendant un scrub ? » et votre téléphone d’astreinte annonce « félicitations, c’est votre problème maintenant. »
La planification de la largeur des vdev est l’endroit où le stockage cesse d’être une virée shopping et devient de la gestion du risque. Les vdevs plus larges peuvent sembler offrir de la capacité et du débit gratuit. Ce n’est pas gratuit. Ils modifient les domaines de défaillance, les délais de reconstruction, le comportement des E/S sur petits blocs et la façon dont ZFS distribue le travail.
Le modèle mental : les vdev sont les unités de performance
Les pools ZFS sont construits à partir de vdevs (dispositifs virtuels). Le pool répartit les données en bandes à travers les vdevs, pas à travers les disques individuels. À l’intérieur de chaque vdev, ZFS s’appuie sur le schéma de redondance du vdev (miroir, RAIDZ1/2/3, dRAID, etc.) pour transformer plusieurs disques physiques en un seul périphérique logique.
Cette dernière phrase est le piège. Les gens voient 24 disques et pensent « 24 spindles d’IOPS ». Avec ZFS, vous obtenez approximativement « le nombre de vdevs en IOPS », ajusté selon le layout. Un pool avec un seul vdev RAIDZ2 est une file d’E/S (par vdev de premier niveau) pour les lectures/écritures aléatoires. Un pool avec six vdevs miroir est six files d’E/S. Même nombre brut de disques. Comportement différent sous charge.
La planification de la largeur des vdev consiste à choisir un domaine de défaillance et une forme de performance. Les vdevs plus larges consolident la capacité et peuvent améliorer le débit séquentiel important. Ils concentrent aussi le risque et peuvent rendre les E/S aléatoires petites comme marcher dans du sirop.
Deux règles qui restent vraies quand tout le reste change
- Règle 1 : Si votre charge est dominée par des E/S aléatoires (VM, bases de données), vous voulez généralement plus de vdevs, pas des vdevs plus larges.
- Règle 2 : Si votre charge est principalement séquentielle importante (sauvegardes, médias, archives), des RAIDZ larges peuvent convenir — jusqu’à ce que les fenêtres de reconstruction deviennent votre nouveau hobby.
Une citation à garder au mur, parce que c’est tout le jeu : L’espoir n’est pas une stratégie.
(idée paraphrasée, souvent associée à l’opérations et à la culture fiabilité)
Blague #1 : Un « un seul vdev géant » est comme une route à une seule voie — formidable jusqu’à la première voiture en panne, et alors tout le monde apprend de nouveaux mots.
Faits rapides et contexte historique
Les ingénieurs stockage aiment débattre de la largeur des vdev parce que la « bonne » réponse dépend de la charge, de la tolérance au risque et de votre aversion pour les week-ends. Toutefois, un peu d’histoire aide à expliquer pourquoi les compromis sont tels qu’ils sont.
- ZFS a débuté chez Sun Microsystems au milieu des années 2000 avec un modèle « gestionnaire de volumes intégré + système de fichiers ». C’est pourquoi les vdevs existent : le système de fichiers gère les décisions RAID.
- RAIDZ n’est pas le RAID5/6 matériel classique. ZFS utilise une largeur de bande variable pour RAIDZ, ce qui réduit les problèmes classiques de « RAID5 write hole » lorsqu’il est combiné avec copy-on-write et sommes de contrôle.
- « IOPS par vdev » est devenu une règle empirique parce que ZFS distribue les E/S au niveau du vdev. Ce n’est pas toute l’histoire, mais cela prédit la douleur de façon surprenante.
- Les scrubs ont été conçus comme opérations d’intégrité, pas comme fonctionnalités de performance. Ils lisent tout pour vérifier les checksums. Sur des vdevs larges avec de gros disques, « tout » représente… beaucoup.
- La croissance de capacité des disques a dépassé les IOPS pendant des décennies. Un disque moderne est énorme mais pas rapide. Les vdevs larges amplifient le décalage « gros mais lent » pendant les resilverings.
- La réalité des secteurs 4K (ashift) a changé la planification. Des secteurs mal alignés (mauvais ashift) peuvent multiplier silencieusement l’amplification d’écriture et la latence, surtout en RAIDZ.
- Les SSD ont changé la donne mais n’ont pas effacé la physique. Vous pouvez faire des vdevs larges sur SSD et « ça marche », mais la mathématique de parité et la reconstruction coûtent toujours en CPU et en latence.
- dRAID existe en grande partie parce que le temps de resilver faisait mal. Il répartit la capacité de secours et le travail de reconstruction, réduisant la fenêtre « un disque à la fois pendant des jours » typique des RAIDZ larges sur gros HDD.
Ce que « plus de disques par vdev » coûte réellement
1) Vous achetez de la capacité avec un plus grand domaine de défaillance
Un vdev de premier niveau est l’unité atomique de redondance. Si un vdev RAIDZ2 peut perdre deux disques, alors tout troisième disque défaillant dans ce même vdev est catastrophique pour le pool. Quand vous élargissez le vdev, vous mettez plus de disques dans le même seau « deux pannes tolérées ».
Avec plusieurs vdevs plus petits, les défaillances ont plus de chances d’être réparties entre les vdevs. Avec un vdev large, le destin du pool repose sur le budget de parité de ce groupe unique. C’est le coût du « rayon d’impact ».
2) Les reconstructions prennent plus de temps, et les reconstructions longues sont une taxe sur la fiabilité
ZFS resilver à l’échelle des blocs (seulement les données allouées) dans de nombreux cas, ce qui est excellent. Mais le pool doit toujours scanner les métadonnées, et il faut toujours lire sur les disques survivants et écrire les blocs reconstruits. À mesure que les disques deviennent plus grands, « seulement alloué » peut tout de même représenter plusieurs téraoctets.
Les vdevs larges augmentent le nombre de disques participant aux E/S de reconstruction pour chaque bloc. Cela signifie plus de lectures totales pendant le resilver, plus de chances de rencontrer des erreurs de secteur latentes, plus de contention avec les charges de production et plus de temps passé dans la fenêtre de danger où une deuxième/ troisième défaillance met fin à l’histoire.
3) E/S aléatoires petites : la parité n’est pas gratuite
Les miroirs sont amicaux pour les E/S aléatoires : les lectures peuvent être équilibrées entre les deux côtés, et les petites écritures sont relativement peu coûteuses. RAIDZ doit calculer la parité et souvent faire des read-modify-write pour les bandes partielles. ZFS est intelligent, mais ce n’est pas magique.
À mesure que la largeur du vdev augmente, la taille de « full stripe » augmente. Pour les charges sur petits blocs (courantes avec les VM et les bases de données), vous écrivez souvent des bandes partielles. Cela pousse RAIDZ à effectuer des lectures supplémentaires et des mises à jour de parité. Des vdevs plus larges peuvent signifier plus de travail par écriture et plus de variance de latence.
4) La latence devient plus irrégulière sous travaux d’arrière-plan
Les scrubs, resilvers et lecteurs séquentiels lourds toucheront chaque disque. Dans un vdev large, ces opérations sollicitent plus de disques en même temps, et elles le font plus longtemps. Le pool peut toujours servir des E/S normales, mais les files s’allongent. Les percentiles de latence augmentent. Et ce sont les percentiles qui vous réveillent la nuit, pas la moyenne.
5) Vous n’obtenez pas réellement « plus de performance » comme vous le pensez
Pour le débit séquentiel, des RAIDZ plus larges peuvent aider parce que plus de disques contribuent à chaque bande. Pour les IOPS aléatoires, surtout les écritures, un vdev RAIDZ se comporte comme un seul périphérique avec surcharge de parité. Si vous voulez plus d’IOPS aléatoires, vous voulez plus de vdevs de premier niveau.
Donc l’argument « plus de disques par vdev » est généralement : meilleure efficacité de capacité, parfois meilleur débit séquentiel, moins de vdevs à gérer. La facture arrive sous forme : pire performance aléatoire par To, plus grand domaine de défaillance, reconstructions plus longues, impact plus dur des travaux d’arrière-plan.
6) La planification de l’extension devient maladroite
ZFS a historiquement étendu les pools en ajoutant des vdevs, pas en « ajoutant des disques à un vdev RAIDZ ». L’expansion de RAIDZ est devenue possible dans les OpenZFS modernes, mais ce n’est pas une carte vous dispensant de tout : c’est une opération lourde, qui prend du temps, et vous finissez toujours avec un vdev plus large et tous les coûts ci-dessus.
Planifier la largeur des vdev, c’est aussi planifier la manière dont vous allez croître. Si votre modèle de croissance est « racheter le même shelf », des vdevs plus petits qui correspondent à la géométrie des étagères ont tendance à mieux vieillir.
Adapter la largeur du vdev à la charge : séquentielle, aléatoire, mixte
Large séquentiel (dépôts de sauvegarde, médias, archive)
Les écritures et lectures séquentielles sont l’endroit où RAIDZ peut paraître excellent. Vous streamez de gros blocs, ZFS peut assembler de grandes E/S, et les disques restent occupés de manière prévisible. Des vdevs plus larges peuvent augmenter le débit agrégé parce que plus de disques participent à chaque bande.
Mais : les dépôts de sauvegarde effectuent aussi des scrubs, de l’élagage et parfois de nombreuses restaurations parallèles. Si vous construisez un vdev RAIDZ2 monstre, les travaux d’arrière-plan et les tempêtes de restauration vont se concurrencer dans la même file d’unique vdev. Si vous pouvez tolérer cela (et votre RTO aussi), ok. Si votre restauration est le moment où le CEO découvre le stockage, ne jouez pas.
Charge aléatoire dominante (datastores VM, bases de données)
Ici, RAIDZ large est généralement le mauvais outil. Pas parce qu’il est « lent », mais parce qu’il est imprévisible sous pression. La latence d’écriture aléatoire est le tueur. Les miroirs (ou plus de vdevs RAIDZ plus étroits) répartissent les E/S sur plus de files indépendantes et réduisent la surcharge de parité.
Si vous devez utiliser RAIDZ pour du stockage VM sur HDD, gardez les vdevs plus étroits, utilisez suffisamment de vdevs pour obtenir du parallélisme et soyez honnête sur les attentes de performance. Si c’est SSD/NVMe, RAIDZ peut être acceptable, mais les layouts en miroir l’emportent souvent sur la latence de queue dans de nombreuses charges réelles.
Charges mixtes (partages de fichiers + VM + sauvegardes sur le même pool)
C’est là que « un pool pour tout » devient épicé. Les charges mixtes créent des tailles d’E/S mixtes. RAIDZ déteste les petites écritures aléatoires pendant que quelqu’un d’autre fait des lectures séquentielles. Votre monitoring affichera « utilisation » et « débit » et vous aurez quand même des plaintes parce que la latence est ce que ressentent les humains.
Dans la vie en entreprise, les charges mixtes existent parce que les budgets existent. Si vous ne pouvez pas séparer les pools, au moins séparez les vdevs : plus de vdevs donne à ZFS des options. Envisagez aussi des vdevs spéciaux pour les métadonnées/petits blocs si vous savez ce que vous faites — bien fait, cela peut transformer les charges axées sur les répertoires et les petits fichiers.
Largeur RAIDZ, parité et la physique que vous ne négocierez pas
Niveaux de parité : RAIDZ1 vs RAIDZ2 vs RAIDZ3
La parité est votre police d’assurance. RAIDZ1 (parité simple) est de plus en plus une mauvaise idée avec de gros HDD dans des environnements sérieux parce que les fenêtres de reconstruction sont longues et les erreurs de lecture latentes ne sont pas un conte de fées. RAIDZ2 est la base pratique pour les pools HDD importants. RAIDZ3 existe pour quand vous voulez dormir pendant un long resilver sur des gros disques, mais cela coûte plus en overhead de parité et en performance.
La parité n’évolue pas avec la largeur. Un RAIDZ2 à 6 disques et un RAIDZ2 à 16 disques tolèrent tous deux deux défaillances. Un vdev plus large signifie « même nombre de défaillances autorisées sur plus de disques ». C’est le compromis central de fiabilité.
Recordsize, volblocksize, et pourquoi les « petites écritures » deviennent le problème de tout le monde
ZFS écrit en records (recordsize par défaut souvent 128K pour les systèmes de fichiers), mais les zvols pour périphériques bloc ont volblocksize (souvent 8K/16K). Les bases de données et images VM ont tendance à générer des écritures 4K–16K. Si la largeur de full-stripe RAIDZ est importante et que vos écritures réelles sont petites, vous êtes en territoire de bandes partielles. Les écritures en bandes partielles sont là où la surcharge de parité et le read-modify-write apparaissent sous forme de latence.
La solution n’est pas « tourner des boutons jusqu’à ce que ça ait l’air mieux ». La solution est : choisissez un layout de vdev qui correspond à la forme d’E/S de la charge, et définissez recordsize/volblocksize intentionnellement.
La compression change la mathématique de la largeur (majoritairement en bien)
La compression (comme lz4) réduit les octets écrits. Cela peut réduire le temps disque et parfois réduire le travail de parité. Cela peut aussi rendre les écritures plus petites et plus éparses, ce qui peut augmenter l’agitation des métadonnées. Généralement, la compression est un gain, mais mesurez-la — surtout sur des systèmes déjà liés au CPU.
Vdevs spéciaux et SLOG : outils puissants, aiguisés
Les vdevs spéciaux (métadonnées et petits blocs) peuvent sauver la performance des charges sur petits fichiers en RAIDZ HDD. Mais ils deviennent des périphériques critiques : perdre le vdev spécial peut faire perdre le pool. Cela implique des vdevs spéciaux en miroir avec de bons périphériques et un monitoring.
SLOG (journal séparé) aide uniquement pour les écritures synchrones. Il ne résoudra pas la latence générale. Mettez-en un parce que vous comprenez votre charge sync, pas parce que vous l’avez vu sur un forum.
Blague #2 : Acheter un SLOG pour corriger la latence d’écriture aléatoire, c’est comme acheter un plus beau paillasson pour arrêter un toit qui fuit.
Maths de resilver/reconstruction : temps, fenêtre de risque et rayon d’impact
Pourquoi les vdevs larges rendent le risque de resilver personnel
Pendant un resilver, les disques survivants sont lus fortement et en continu. C’est du stress. C’est aussi le moment où vous découvrez quels disques accumulaient silencieusement des erreurs. Un vdev large signifie que plus de disques sont dans le même groupe de redondance, et plus de disques doivent être lus pour reconstruire les données. Le resilver touche plus de matériel et dure plus longtemps, ce qui augmente la chance qu’autre chose lâche avant la fin.
Données allouées vs disque plein : ZFS aide, mais ne misez pas votre emploi dessus
Le resilvering ZFS est souvent plus rapide que la reconstruction RAID classique parce qu’il peut sauter les blocs non alloués. Super. Mais les pools réels ne sont pas vides, et les métadonnées nécessitent toujours un scan. De plus, « rapide » est relatif quand vos disques font des dizaines de téraoctets et que votre pool est occupé.
Les vdevs larges augmentent les dommages collatéraux pendant la reconstruction
Même si un resilver se termine avec succès, un vdev large a tendance à dégrader la performance davantage pendant le processus parce que plus de disques sont occupés à faire du travail de reconstruction. Si le pool sert des charges sensibles à la latence, la fenêtre de reconstruction devient un incident de performance.
Implication opérationnelle : votre plan de reconstruction fait partie de votre architecture
Ne planifiez pas la largeur des vdev dans le vide. Planifiez-la avec :
- La rapidité à laquelle vous pouvez remplacer un disque (humains, pièces de rechange, SLA fournisseur).
- La dégradation de performance que vous pouvez tolérer pendant un resilver.
- La durée pendant laquelle votre pool peut fonctionner en « redondance réduite » en toute sécurité.
- Ce qui se passe si un second disque tombe en panne au milieu d’un resilver.
Trois mini-récits d’entreprise (anonymisés, tous réels)
1) Incident causé par une mauvaise hypothèse : « 24 disques = beaucoup d’IOPS »
L’entreprise était en pleine croissance, migrant d’un SAN legacy vers un appliance basé ZFS. Ils avaient une exigence sur papier : « supporter la ferme VM existante sans régression de performance ». Un membre de l’équipe fit le calcul familier : 24 HDD, 7200 RPM, donc « beaucoup » d’IOPS. Ils ont construit un unique vdev RAIDZ2 parce que cela maximisait l’espace utilisable et avait l’air propre.
Cela passa les tests initiaux. Le benchmark synthétique utilisait des lectures/écritures séquentielles larges. Les graphiques semblaient héroïques. La migration continua, et pendant une semaine ce fut calme.
Puis l’orage de connexion du lundi matin frappa. Les VM démarrèrent, l’antivirus se mit à jour, Windows fit des choses Windows, et la latence monta. Pas progressivement — en pointes. Le helpdesk reçut des tickets « tout est lent ». Les logs de l’hyperviseur indiquaient « storage latency 100–200ms ». La machine de stockage n’était pas « en panne », juste noyée.
Ils découvrirent l’erreur : le pool n’avait qu’un vdev de premier niveau. Une seule file. Les E/S aléatoires de dizaines de VM s’empilèrent dans cette file, et la surcharge de parité RAIDZ aggravait les écritures. La correction n’était pas un paramètre. La correction fut architecturale : reconstruire le pool en plusieurs vdevs (miroirs dans leur cas), accepter moins de capacité utilisable et obtenir une latence prévisible. La leçon dure : les IOPS viennent du nombre de vdevs et du type de média, pas du simple nombre de disques.
2) Optimisation qui s’est retournée contre eux : « Agrandissons pour réduire l’overhead de parité »
Une autre organisation exploitait un grand dépôt de sauvegarde sur HDD RAIDZ2. Ça fonctionnait. Pas vite, mais acceptable. Ils décidèrent « d’optimiser » en augmentant la largeur des vdev lors d’une expansion : moins de vdevs, chacun plus large, mise en page simplifiée, efficacité de capacité légèrement meilleure. Moins de vdevs signifie aussi moins de choses à surveiller, ce qui sonne toujours bien en réunion.
Pour l’ingestion séquentielle importante, cela s’améliora. Les jobs d’ingestion finirent plus tôt, et tout le monde se félicita. Puis le scrub trimestriel arriva. Les scrubs prirent plus longtemps que prévu, mais cela fut toléré.
La vraie défaillance se manifesta des semaines plus tard lors d’une journée de restaurations intensives. Ils eurent plusieurs restaurations parallèles alors qu’un resilver tournait déjà (parce qu’un disque tombe toujours en panne pendant une période chargée). Le vdev plus large fit que le resilver impliquait plus de disques, ce qui entraîna plus de contention. Les performances de restauration s’effondrèrent, et le RTO promis aux clients internes devint un incident de performance.
L’optimisation « fonctionna » pour le meilleur cas et échoua pour le pire. C’est un piège classique en entreprise : vous benchmarkez la belle journée, puis vous vivez la tempête.
3) Pratique austère mais correcte qui a sauvé la mise : vdevs plutôt étroits, spares chauds, et discipline de scrub
Une troisième équipe exploitait un environnement mixte : répertoires personnels, artefacts de build et un peu de stockage VM. Ils furent prudents. Ils construisirent plusieurs vdevs RAIDZ2 de largeur modérée, gardèrent au moins une spare testée sur site, et programmèrent des scrubs réguliers avec monitoring de la durée et des compteurs d’erreurs.
Ce n’était pas glamour. L’efficacité de capacité n’était pas « maximale ». Ils eurent aussi une règle : pas de pool au-delà d’un certain seuil d’utilisation (ils visaient à garder de l’espace libre réel, pas l’illusion d’espace). La finance se plaignit ; les ingénieurs hochèrent la tête et passèrent à autre chose.
Un vendredi après-midi, un disque tomba. Le spare fut inséré immédiatement et le resilver débuta. Durant la nuit, un second disque dans le même châssis montra des erreurs. Parce que les vdevs étaient plus étroits et que l’historique de scrub avait déjà identifié quelques disques marginaux plus tôt dans l’année, ils avaient des remplacements prêts. La seconde défaillance toucha un vdev différent, donc la redondance tint. Le pool resta en ligne, la performance chuta mais resta utilisable, et le lundi matin il n’y eut pas de revue d’incident.
La pratique austère n’a pas « empêché » la panne. Elle a réduit le rayon d’impact et raccourci le temps passé dans le danger. C’est ce que fait une bonne architecture stockage.
Procédure de diagnostic rapide : trouvez le goulot avant de « tuner »
Quand la performance est mauvaise, les équipes commencent souvent à tourner des boutons ZFS comme on tourne un poste de radio. Ne le faites pas. D’abord, identifiez la ressource limitante et si la limitation est structurelle (largeur/layout du vdev) ou situationnelle (scrub, resilver, un seul disque défaillant).
Première étape : confirmez la topologie du pool et la santé actuelle
- Est-ce un unique vdev RAIDZ large ou plusieurs vdevs ?
- Un scrub/resilver est-il en cours ?
- Y a-t-il des erreurs de lecture/écriture/checksum ?
Deuxième étape : déterminez si la douleur est latence, débit, ou CPU
- Latence élevée avec faible débit signifie souvent mise en file, E/S aléatoires petites, ou disque malade.
- Débit élevé avec latence acceptable signifie que vous allez probablement bien.
- CPU élevé pendant les écritures peut indiquer compression, checksum, travail de parité RAIDZ, ou mismatch de recordsize.
Troisième étape : isolez si un vdev/disque est le dominant
- Si un disque montre une latence élevée ou des erreurs, il peut tirer un vdev RAIDZ entier vers le bas.
- Si un vdev est saturé et que d’autres sont inactifs, vous êtes limité par le nombre de vdevs, pas par le nombre de disques.
Quatrième étape : vérifiez l’espace libre du pool et les indicateurs de fragmentation
- Les pools très pleins se comportent mal, surtout pour RAIDZ avec petits blocs.
- L’espace libre est un budget de performance, pas seulement de capacité.
Cinquième étape : décidez si la correction est opérationnelle ou architecturale
- Corrections opérationnelles : remplacer un disque défaillant, reprogrammer un scrub, limiter le débit du resilver, ajouter un SLOG seulement si le sync l’exige.
- Corrections architecturales : ajouter des vdevs, reconstruire en miroirs, répartir les charges sur des pools, envisager des vdevs spéciaux ou dRAID quand pertinent.
Tâches pratiques : 12+ commandes, sorties et décisions
Voici les commandes à exécuter quand quelqu’un dit « le stockage est lent » et que vous devez répondre avec des preuves. Chaque tâche inclut ce que signifie la sortie et la décision à prendre.
Task 1: Identify vdev layout and current state
cr0x@server:~$ zpool status -v tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 07:12:44 with 0 errors on Tue Dec 24 03:12:01 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
/dev/disk/by-id/ata-d1 ONLINE 0 0 0
/dev/disk/by-id/ata-d2 ONLINE 0 0 0
/dev/disk/by-id/ata-d3 ONLINE 0 0 0
/dev/disk/by-id/ata-d4 ONLINE 0 0 0
/dev/disk/by-id/ata-d5 ONLINE 0 0 0
/dev/disk/by-id/ata-d6 ONLINE 0 0 0
/dev/disk/by-id/ata-d7 ONLINE 0 0 0
/dev/disk/by-id/ata-d8 ONLINE 0 0 0
errors: No known data errors
Signification : Un vdev RAIDZ2 avec 8 disques. Le scrub est terminé, pas d’erreurs.
Décision : Si ce pool héberge des charges E/S aléatoires et que la plainte concerne la latence, vous êtes probablement limité par le nombre de vdevs. Envisagez d’ajouter des vdevs de premier niveau (ou de reconstruire le layout) plutôt que de courir après des réglages.
Task 2: Show vdev-level utilization and latency
cr0x@server:~$ zpool iostat -v tank 1 5
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 22.1T 12.7T 310 420 42.1M 55.8M
raidz2-0 22.1T 12.7T 310 420 42.1M 55.8M
ata-d1 - - 38 52 5.3M 7.1M
ata-d2 - - 40 50 5.4M 6.9M
ata-d3 - - 39 52 5.4M 7.1M
ata-d4 - - 38 53 5.2M 7.2M
ata-d5 - - 39 53 5.4M 7.2M
ata-d6 - - 38 53 5.2M 7.2M
ata-d7 - - 39 53 5.4M 7.2M
ata-d8 - - 39 54 5.4M 7.3M
-------------------------- ----- ----- ----- ----- ----- -----
Signification : Tout le flux I/O passe par un vdev. La distribution des disques semble uniforme (bon), mais cela peut rester un goulot d’unique file pour les I/O aléatoires.
Décision : Si vous avez besoin de plus d’IOPS aléatoires, ajoutez un autre vdev (même redondance) pour augmenter le parallélisme de premier niveau. Élargir ne sert pas ici ; augmenter le nombre de vdevs oui.
Task 3: Catch a failing disk by latency, not just errors
cr0x@server:~$ iostat -x 1 3
Linux 6.8.0 (server) 12/26/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
6.12 0.00 3.44 9.33 0.00 81.11
Device r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 6.0 12.0 512 2048 256.0 0.7 38.2 12.4 51.1 2.4 4.3
sdb 45.0 60.0 5200 7600 245.3 9.9 96.7 90.2 101.5 3.1 32.5
sdc 46.0 59.0 5150 7550 244.9 2.1 19.4 17.2 21.2 2.9 30.8
Signification : sdb a un await beaucoup plus élevé et une profondeur de file plus grande que ses pairs. Il pourrait effectuer des retries ou un remappage interne.
Décision : Exécutez SMART et envisagez un remplacement proactif. Un disque lent peut brider un RAIDZ parce que chaque bande attend le membre le plus lent.
Task 4: Check SMART error counters and self-test history
cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i 'Reallocated|Pending|Uncorrect|Power_On_Hours|SMART overall|Self-test'
SMART overall-health self-assessment test result: PASSED
Power_On_Hours 37124
Reallocated_Sector_Ct 12
Current_Pending_Sector 3
Offline_Uncorrectable 1
SMART Self-test log structure revision number 1
# 1 Extended offline Completed: read failure 90% 37110 12345678
Signification : « PASSED » est un signal faible. Pending/uncorrectable sectors plus un self-test étendu échoué est un signal fort.
Décision : Remplacez le disque avant qu’il ne devienne une seconde panne pendant le resilver. Envisagez aussi d’exécuter un scrub après remplacement pour valider.
Task 5: Verify ashift (sector alignment) for the pool
cr0x@server:~$ zdb -C tank | egrep -m1 'ashift|vdev_tree'
ashift: 12
Signification : ashift=12 signifie que des secteurs 4K sont supposés. Bon pour les HDD/SSD modernes.
Décision : Si vous voyez ashift=9 sur des disques 4K, attendez-vous à une amplification d’écriture et à une mauvaise performance. La correction nécessite de reconstruire le pool correctement ; on ne peut pas « tuner » ashift a posteriori.
Task 6: Identify datasets and whether you’re using zvols (VMs) vs filesystems
cr0x@server:~$ zfs list -o name,type,used,available,recordsize,volblocksize -r tank
NAME TYPE USED AVAIL RECSIZE VOLBLOCK
tank filesystem 22.1T 12.7T 128K -
tank/vmstore filesystem 8.2T 12.7T 128K -
tank/vmstore/zvol1 volume 600G 12.7T - 8K
tank/backups filesystem 10.3T 12.7T 1M -
Signification : Les VM utilisent un zvol avec volblocksize 8K ; le dataset backups utilise recordsize 1M (bon pour le séquentiel).
Décision : Si la latence VM est mauvaise sur RAIDZ large, envisagez de déplacer le stockage VM sur des miroirs ou SSD, ou d’augmenter le nombre de vdevs. Pour les sauvegardes, un RAIDZ large peut convenir.
Task 7: Check sync settings and whether a SLOG would matter
cr0x@server:~$ zfs get -o name,property,value,source sync tank/vmstore/zvol1
NAME PROPERTY VALUE SOURCE
tank/vmstore/zvol1 sync standard local
Signification : Les écritures sync sont honorées. Si votre charge est sync-intensive (bases de données, NFS en sync), la latence peut être dominée par le comportement du ZIL.
Décision : Envisagez un SLOG seulement si vous confirmez une charge d’écritures sync significative et si vous pouvez fournir des périphériques protégés contre la perte de puissance. Sinon, n’en mettez pas.
Task 8: Measure sync write pressure via ZIL stats (Linux OpenZFS)
cr0x@server:~$ cat /proc/spl/kstat/zfs/zil | egrep 'zil_commit|zil_itx_count|zil_itx_indirect_count'
zil_commit 18442
zil_itx_count 9921
zil_itx_indirect_count 144
Signification : Des commits ZIL non triviaux se produisent. Si cela grimpe rapidement pendant la fenêtre de plainte, les écritures sync sont en cause.
Décision : Si la latence des écritures sync est le goulot, évaluez un SLOG (en miroir) ou une mise en lot côté appli. Sinon, ne blâmez pas le ZIL.
Task 9: Confirm if a scrub/resilver is running and how fast it’s progressing
cr0x@server:~$ zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Thu Dec 26 08:11:02 2025
9.21T scanned at 1.12G/s, 2.03T issued at 252M/s, 22.1T total
0B repaired, 9.19% done, 1 day 01:33:40 to go
config:
...
Signification : Un scrub est en cours et durera plus d’un jour. C’est une longue période pour partager les disques avec la production.
Décision : Si cela impacte les charges sensibles à la latence, programmez les scrubs aux heures creuses et envisagez des vdevs plus étroits/plus nombreux pour de futures constructions afin de réduire l’impact par vdev.
Task 10: Check pool free space and special allocation flags
cr0x@server:~$ zpool list -o name,size,alloc,free,cap,health
NAME SIZE ALLOC FREE CAP HEALTH
tank 34.8T 22.1T 12.7T 63% ONLINE
Signification : 63% utilisé est confortable. Si vous êtes régulièrement au-dessus d’environ 80–85% sur RAIDZ avec des charges mixtes, attendez-vous à plus de fragmentation et de latence.
Décision : Si la cap est élevée, planifiez une expansion avant d’atteindre le point critique. L’expansion est plus facile que la récupération, et moins cher que d’expliquer au business pourquoi les écritures sont devenues lentes « sans raison ».
Task 11: Identify block size distribution with a quick fio sample
cr0x@server:~$ fio --name=randwrite --filename=/tank/vmstore/testfile --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 --size=8G --runtime=30 --time_based --direct=1
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=32
...
write: IOPS=820, BW=3.2MiB/s (3.4MB/s)(96MiB/30001msec)
lat (usec): min=450, max=280000, avg=38500.12, stdev=42000.55
Signification : Les écritures aléatoires 4K ont des IOPS faibles avec une latence max/avg très élevée. Sur un RAIDZ HDD, c’est la douleur attendue.
Décision : Si cela ressemble à la charge de production, arrêtez d’essayer de tourner des boutons. Utilisez des miroirs/SSD, augmentez le nombre de vdevs, ou séparez le stockage VM du stockage bulk.
Task 12: Check ARC pressure (memory) and whether reads are cache hits or disk hits
cr0x@server:~$ arcstat 1 3
time read miss miss% dmis dm% pmis pm% arcsz c
08:32:11 12K 4K 33% 2K 16% 2K 16% 96G 110G
08:32:12 11K 5K 45% 3K 27% 2K 18% 96G 110G
08:32:13 13K 4K 30% 2K 15% 2K 15% 96G 110G
Signification : Le hit rate ARC est correct. Si miss% est élevé et que vous êtes lié par la latence de lecture, les disques font le vrai travail.
Décision : Si les lectures ratent l’ARC et que vos disques sont déjà occupés, n’élargissez pas les vdevs en attendant un miracle. Envisagez d’ajouter de la RAM (si raisonnable), de séparer les charges, ou d’utiliser L2ARC/vdev spécial seulement après mesure.
Task 13: Check for checksum errors indicating silent corruption or cabling trouble
cr0x@server:~$ zpool status -v tank | egrep -A2 'READ|WRITE|CKSUM'
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
Signification : Pas d’erreurs. Si vous voyez des CKSUM, ne supposez pas immédiatement un « disque mort » — c’est souvent le câblage, le HBA, l’expander ou l’alimentation.
Décision : Si les CKSUM augmentent, inspectez le chemin hardware (remplacez le câble, changez de port, testez le HBA). Ne reconstruisez pas le layout pour réparer un câble lâche.
Task 14: Inspect dataset properties that influence I/O shape
cr0x@server:~$ zfs get -o name,property,value,source compression,atime,recordsize,logbias,primarycache tank/vmstore tank/backups
NAME PROPERTY VALUE SOURCE
tank/vmstore compression lz4 local
tank/vmstore atime off local
tank/vmstore recordsize 128K default
tank/vmstore logbias latency default
tank/vmstore primarycache all default
tank/backups compression lz4 local
tank/backups atime off local
tank/backups recordsize 1M local
tank/backups logbias throughput local
tank/backups primarycache all default
Signification : Backups est optimisé pour le débit ; le vmstore a des valeurs par défaut qui peuvent convenir mais les choix du zvol importent plus que recordsize.
Décision : Si un dataset est configuré à l’inverse de sa charge (ex. recordsize trop petit pour des backups, sync forcé sans raison), corrigez les propriétés. Mais n’attendez pas des propriétés qu’elles résolvent un mauvais layout de vdev.
Erreurs courantes : symptômes → cause racine → correction
Erreur 1 : « Pics de latence pendant les scrubs ; les utilisateurs se plaignent »
Symptômes : Augmentation prévisible de la latence au démarrage d’un scrub ; charges interactives ralenties ; zpool status montre un scrub en cours.
Cause racine : Vdev large + HDD signifie que le scrub est long et concurrence la bande passante et les files des disques avec les E/S de production.
Correction : Programmer les scrubs hors production ; envisager plusieurs vdevs (plus de parallélisme de premier niveau) pour de futures constructions ; séparer les charges sensibles à la latence des pools bulk.
Erreur 2 : « Nous avons 20+ disques donc la performance VM devrait être excellente »
Symptômes : IOPS faibles, latence tail élevée, le débit semble correct mais les applis expirent ; particulièrement mauvais pendant les boot storms.
Cause racine : Un (ou trop peu) vdev RAIDZ. Les I/O aléatoires sont bridés par le nombre de vdevs et la surcharge de parité.
Correction : Utiliser des miroirs pour VM/bases de données sur HDD, ou augmenter le nombre de vdevs de premier niveau. Si vous devez utiliser RAIDZ, gardez les vdevs plus étroits et en ajoutez davantage.
Erreur 3 : « Le resilver prend une éternité ; nous sommes nerveux pendant des jours »
Symptômes : Estimation de resilver sur plusieurs jours ; performance dégradée ; anxiété liée à une seconde panne.
Cause racine : Vdev large + gros disques + haute utilisation + workload en cours. La fenêtre de reconstruction est longue et stressante.
Correction : Garder une utilisation plus basse ; choisir des vdevs plus étroits ou dRAID si pertinent ; maintenir des spares sur site ; planifier le throttling de reconstruction et des fenêtres de maintenance.
Erreur 4 : « Nous avons ajouté un SLOG et rien n’a changé »
Symptômes : Même latence ; aucune amélioration notable ; parfois pire stabilité à cause d’un SSD bon marché.
Cause racine : La charge n’est pas dominée par les écritures sync, ou le SLOG n’est pas safe power-loss, ou le vrai problème est l’amplification d’écriture aléatoire en RAIDZ large.
Correction : Mesurez le taux d’écritures sync d’abord ; si nécessaire, utilisez des périphériques entreprise et en miroir. Sinon, retirez la complexité.
Erreur 5 : « Un disque est ‘un peu lent’ mais on attendra »
Symptômes : Pas encore d’erreurs ZFS, mais iostat montre un disque avec latence plus élevée ; timeouts occasionnels dans les logs.
Cause racine : Le disque se dégrade, le chemin de câblage est instable, ou un port d’expander est capricieux. Les bandes RAIDZ attendent le membre le plus lent.
Correction : Remplacez ou déplacez proactivement le composant suspect. Validez avec SMART et les logs d’erreur. Ne pas attendre qu’il « tombe » durant un resilver.
Erreur 6 : « Le pool est à 90% et les écritures sont devenues lentes ; ça doit être un bug »
Symptômes : Latence croissante au fil du temps ; espace libre faible ; fragmentation et overhead métadonnées en hausse.
Cause racine : Le copy-on-write a besoin d’espace libre pour allouer efficacement. RAIDZ souffre davantage quand les segments libres se réduisent et que les écritures deviennent éparses.
Correction : Ajoutez de la capacité avant que le pool soit plein ; appliquez des quotas/réservations ; archivez ou supprimez ; envisagez de séparer les données chaudes et froides sur des pools distincts.
Listes de contrôle / plan étape par étape
Planification étape par étape de la largeur des vdev (ce que je ferais avant d’acheter des disques)
- Classifiez la charge : surtout séquentielle, surtout aléatoire, ou mixte. Si vous ne pouvez pas classifier, c’est mixte.
- Décidez de votre tolérance aux pannes : RAIDZ2 baseline pour HDD ; RAIDZ3 pour très gros disques ou temps de remplacement longs ; miroirs pour niveaux faible latence.
- Choisissez une forme de performance cible : combien d’IOPS lecture/écriture aléatoires vous faut-il réellement, et quel percentile de latence est acceptable ?
- Choisissez d’abord le nombre de vdevs : le nombre de vdevs de premier niveau est votre budget de parallélisme. Puis choisissez la largeur par vdev.
- Choisissez la largeur des vdevs de façon conservatrice :
- Pour HDD VM/bases de données : miroirs, plusieurs vdevs.
- Pour HDD sauvegardes/archive : RAIDZ2 de largeur modérée ; évitez « un vdev géant » à moins d’accepter vraiment le risque de reconstruction.
- Planifiez les incréments de croissance : ajoutez des vdevs au fil du temps ; gardez les layouts cohérents. Évitez un vdev isolé qui se comportera différemment.
- Gardez une marge d’utilisation : fixez une limite interne (souvent ~80% pour charges mixtes) et traitez-la comme une politique, pas une suggestion.
- Planifiez les reconstructions : spares sur site, procédure de remplacement documentée et monitoring des signaux de panne précoces.
- Séparez les niveaux si nécessaire : placez les charges sensibles à la latence sur miroirs/SSD, les données bulk sur RAIDZ.
- Testez avec un benchmark représentatif : aléatoire 4K/8K, mixte lecture/écriture, plus un scrub en cours, parce que c’est la réalité.
Checklist opérationnelle (à vérifier mensuellement)
- Programme de scrub et durée du dernier scrub ; investiguer si la durée augmente.
- Compteurs d’erreurs SMART et self-tests échoués ; remplacer tôt.
- Tendance de capacité du pool et date projetée d’atteinte de 80%.
- zpool status propre, pas d’erreurs CKSUM.
- Percentiles de latence (pas seulement les moyennes) pendant les pics et pendant les opérations d’arrière-plan.
FAQ
Q1: « RAIDZ vdev plus large = plus rapide » est-ce vrai parfois ?
Pour le débit séquentiel important, oui : plus de disques par bande peut augmenter la bande passante de lecture/écriture. Pour les E/S aléatoires, surtout les petites écritures, plus large est souvent pire ou au moins pas meilleur.
Q2: Pourquoi les gens disent-ils « les IOPS viennent des vdevs » ?
Parce que ZFS stripe à travers les vdevs de premier niveau. Chaque vdev est une unité de performance avec son propre enchaînement de files. Plus de vdevs signifie plus de parallélisme pour les E/S aléatoires.
Q3: Quelle est une largeur « sûre » pour RAIDZ2 ?
« Sûr » dépend de la taille des disques, du temps de remplacement et de la charge. Pratiquement, des largeurs modérées sont plus faciles à vivre que des très larges parce que les fenêtres de reconstruction et le rayon d’impact croissent avec la largeur.
Q4: Si j’ai 24 disques, dois-je faire un RAIDZ2 à 24 ?
Presque jamais pour des pools généralistes ou lourds en VM. Vous aurez un énorme domaine de défaillance et un comportement d’un seul vdev pour les I/O aléatoires. Répartissez en plusieurs vdevs.
Q5: Les miroirs gaspillent 50% de la capacité. Pourquoi les choisir ?
Parce qu’ils offrent faible latence, IOPS aléatoires élevés, comportement de panne plus simple et souvent des resilvers plus rapides. La capacité coûte moins cher que les interruptions.
Q6: Ajouter L2ARC résout-il les problèmes d’I/O aléatoires sur vdevs larges ?
Parfois cela aide les charges en lecture répétée avec motifs d’accès répétitifs. Cela ne réparera pas la latence d’écriture aléatoire ni l’overhead de parité. De plus, L2ARC a ses propres contraintes mémoire et nécessité de warmup.
Q7: Dois-je utiliser RAIDZ1 si j’ai des disques plus petits ?
Pour tout ce qui est important sur HDD, RAIDZ1 est un pari inutile. RAIDZ2 est le défaut raisonnable. RAIDZ1 peut convenir pour des données non critiques, facilement reproductibles et avec fenêtres de reconstruction courtes.
Q8: Puis-je étendre un vdev RAIDZ en ajoutant des disques plus tard ?
Les OpenZFS modernes supportent l’expansion RAIDZ, mais c’est une opération lourde et vous finissez toujours avec un vdev plus large et ses coûts. Beaucoup préfèrent encore ajouter un nouveau vdev pour croître.
Q9: dRAID résout-il le problème de « reconstruction vdev large » ?
dRAID réduit le temps de resilver en répartissant le travail de reconstruction et la capacité de secours. C’est un bon choix pour les grands pools HDD, mais ce n’est pas un remplacement universel des miroirs pour les charges faible latence.
Q10: Quelle est la plus grande erreur de planification ?
Concevoir d’abord pour l’efficacité de capacité et traiter le comportement de performance/reconstruction comme des « problèmes de tuning ». Le layout est de l’architecture. Le tuning est l’assaisonnement.
Étapes suivantes réalisables cette semaine
- Inventoriez vos pools : listez les layouts vdev, les charges servies, la durée des scrubs et la latence typique.
- Exécutez la procédure de diagnostic rapide pendant une fenêtre de plainte et pendant un scrub ; comparez.
- Décidez ce que vous optimisez : faible latence, haut débit, ou TB utilisable maximal. Choisissez un objectif principal par pool.
- Si vous êtes limité par le nombre de vdevs : planifiez une expansion en ajoutant des vdevs (ou migrez vers des miroirs pour le tier chaud), pas en élargissant le vdev existant.
- Si les fenêtres de resilver vous effraient : réduisez la largeur des vdevs lors du prochain build, conservez plus d’espace libre et gardez des spares testés à portée.
- Rédigez un runbook de reconstruction : étapes de remplacement de disque, comportement de resilver attendu et les métriques qui déclenchent l’escalade.
Si vous retenez une seule ligne directrice de tout cela, gardez ceci : ne construisez pas votre premier pool ZFS comme un unique vdev RAIDZ très large sauf si la charge est vraiment séquentielle et que le risque est vraiment acceptable. Quand ça tourne mal, ça ne le fait pas poliment.