Les administrateurs ZFS ne craignent pas tant les pannes de disque que le temps. Le temps passé à attendre un resilver pendant que le pool fonctionne en mode dégradé. Le temps passé à expliquer à la direction pourquoi « un disque est tombé » est devenu « il nous manque une marge avant la catastrophe ». Et le temps passé à regarder une reconstruction ramper à la vitesse d’« un projet de week-end sur un dock USB ».
dRAID arrive avec une promesse séduisante : des resilvers plus rapides et mieux répartis par conception. Mais les systèmes de production ne paient pas pour la nouveauté ; ils paient pour une récupération prévisible. Ce guide terrain sur le dRAID explique ce qu’il change vraiment, ce qu’il ne change pas, et comment le faire tourner sans transformer votre cluster de stockage en spectacle d’improvisation avec un on-call en vedette.
Ce qu’est dRAID (et ce qu’il n’est pas)
Commençons par une définition claire : ZFS dRAID (distributed RAID) est un type de vdev ZFS conçu pour accélérer les resilvers en répartissant la capacité de spare et le travail de reconstruction sur beaucoup de disques, plutôt que de le canaliser vers une seule spare chaude ou un seul périphérique de remplacement. Le titre est « resilver plus rapide », mais l’histoire plus profonde est « moins de points chauds et plus de parallélisme lors de la reconstruction ».
dRAID n’est pas un mode magique de performance. Il ne supprime pas la physique consistant à lire les données survivantes et écrire les données reconstruites. Il ne rend pas les disques lents rapides, et il n’immunise pas un pool contre de mauvaises pratiques opérationnelles. Il change surtout la façon dont le travail de reconstruction est distribué, et les contraintes de disposition que vous acceptez pour l’obtenir.
Un modèle mental pratique : le RAIDZ traditionnel ressemble à remplacer un pneu en soulevant un coin de la voiture et en espérant que le cric ne glisse pas. dRAID ressemble à mettre la voiture sur un pont élévateur : plus stable et plus rapide à travailler, mais il fallait un atelier, pas une allée.
Première blague (vous avez droit exactement à deux) : dRAID, c’est comme engager une équipe de déménagement — tout va plus vite, et pourtant vous passez la moitié du temps à étiqueter des cartons.
Pourquoi le resilver fait mal sur RAIDZ classique
Le resilvering est la reconstruction de la redondance par ZFS après le remplacement ou le retour d’un disque. Pour les miroirs, le resilver peut être relativement efficace : ZFS peut copier uniquement les blocs alloués (lectures « séquentielles-ish » du côté sain, écritures vers le nouveau), et il peut souvent éviter de toucher l’espace vide. Pour RAIDZ, surtout les RAIDZ larges, la vie devient plus compliquée :
La taxe du resilver RAIDZ
Dans RAIDZ, la parité d’un bloc donné est distribuée à travers le vdev, mais la reconstruction après la perte d’un périphérique exige souvent la lecture de la plupart des disques restants dans le groupe RAIDZ pour reconstituer les morceaux manquants. Cela signifie :
- Plus de disques impliqués par bloc pendant la reconstruction.
- Des schémas d’E/S plus aléatoires, selon l’allocation et la fragmentation.
- Des points chauds si un seul disque de secours effectue la majorité des écritures.
- Des fenêtres dégradées longues où une seconde défaillance peut se transformer en une mauvaise journée de récupération.
En exploitation réelle, la douleur n’est pas juste « c’est lent ». C’est « c’est lent pendant que l’entreprise continue d’écrire des données ». Si vous bridez trop le resilver, vous augmentez l’exposition au risque. Si vous ne le bridez pas, votre stockage devient générateur de latence et toutes les équipes applicatives découvrent soudainement la phrase « le stockage est lent ».
Scrub vs resilver : même mathématique, urgence différente
Les scrubs lisent les données pour vérifier les sommes de contrôle et réparer la corruption silencieuse. Le resilver lit pour reconstruire la redondance. Les deux sont coûteux, mais le resilver est urgent parce que vous êtes en mode dégradé. En production, l’urgence change le rayon d’impact acceptable.
Comment dRAID fonctionne réellement : spare distribués et groupes à largeur fixe
dRAID introduit deux grandes idées que vous devez intégrer avant même de penser à le déployer :
1) Capacité de spare distribuée (pas seulement un « disque spare chaud »)
Au lieu d’avoir un ou deux disques spare dédiés inactifs jusqu’à une panne, dRAID réserve de l’espace de spare sur tous les périphériques du vdev dRAID. Lorsqu’un disque tombe en panne, la reconstruction peut écrire les données reconstruites dans des régions de spare distribuées sur les disques survivants. Cela évite le scénario classique où le disque de remplacement unique devient le goulot.
Opérationnellement, cela signifie que les écritures de resilver peuvent être réparties, utilisant mieux l’agrégat d’IOPS et la bande passante. Cela signifie aussi que votre « spare » n’est pas une chose discrète que vous pouvez pointer et remplacer sans réfléchir ; c’est une capacité intégrée à la disposition.
2) Groupes à largeur fixe (un contrat de disposition)
dRAID utilise des groupes à largeur fixe : chaque groupe est essentiellement un petit ensemble en style RAIDZ avec données + parité + spare distribué. Ces groupes sont ensuite distribués sur les disques. C’est pourquoi le resilver dRAID peut utiliser efficacement beaucoup de disques : la reconstruction peut cibler les groupes pertinents et répartir largement le travail.
Mais un schéma à largeur fixe est aussi un contrat avec votre futur vous. Il affecte les options d’expansion, les caractéristiques de performance, et la tolérance à « ajoutons juste quelques disques plus tard ». dRAID tend à récompenser la planification et punir l’improvisation.
Ce que cela donne en cas de panne
RAIDZ traditionnel : remplacer un disque, resilver sur ce disque, votre nouveau disque est occupé, vos anciens disques sont occupés, et le pool est occupé à être occupé.
dRAID : le pool utilise de l’espace spare distribué pour la reconstruction, donc la « cible d’écriture » n’est pas un seul disque ; ce sont plusieurs. Ensuite, plus tard, vous pouvez « guérir » vers un périphérique de remplacement selon l’implémentation exacte et le workflow. L’essentiel est que la première phase — la plus risquée — peut être plus courte et plus parallèle.
Deuxième et dernière blague : si vous avez déjà regardé un resilver RAIDZ lent, vous savez que c’est la seule fois où une barre de progression peut vous vieillir.
Faits et contexte historique
Du contexte concret aide à garder dRAID en perspective. Voici quelques faits qui expliquent pourquoi il existe et pourquoi il se comporte comme il le fait :
- Le risque de reconstruction a augmenté avec la taille des disques : les disques multi-téra octets ont prolongé les fenêtres de rebuild au point où « seconde panne pendant la reconstruction » est devenu un paramètre de planification, pas un cas marginal.
- ZFS RAIDZ a été conçu d’abord pour l’intégrité : checksums de bout en bout et auto-réparation importaient plus que la vitesse de rebuild, surtout aux débuts où les disques étaient plus petits.
- Les miroirs sont restés populaires parce qu’ils échouent gracieusement : les resilvers de miroir peuvent être rapides et ciblés, mais les miroirs échangent efficacité de capacité contre comportement de récupération.
- Les RAIDZ larges sont devenus tendance pour l’économie de capacité : moins de vdevs, plus de disques par vdev, meilleure efficacité de parité — jusqu’à ce que la réalité des pannes et des performances se manifeste.
- Les contrôleurs RAID d’entreprise avaient des concepts de « spare distribué » bien avant ZFS dRAID : l’idée de répartir la capacité spare pour éviter les points chauds n’est pas nouvelle ; l’intégrer proprement aux sémantiques ZFS est la partie difficile.
- OpenZFS a amélioré progressivement le comportement de resilver : resilver séquentiel, device removal, classes d’allocation, et meilleure observabilité ont déplacé les compromis pratiques au fil du temps.
- SMR a montré que « rebuild peut être catastrophique » : les disques shingled peuvent s’effondrer face aux écritures aléatoires ; le comportement de rebuild est devenu un sujet d’achat, pas juste une note technique.
- « Scrubber régulièrement » est devenu une doctrine parce que la corruption silencieuse est réelle : ZFS a rendu les scrubs partie intégrante des opérations normales ; dRAID ne remplace pas cette discipline.
Où dRAID gagne en production
1) Grands pools où le temps de resilver est le risque principal
dRAID justifie son coût quand vous avez assez de disques pour qu’un rebuild ciblé sur « un seul disque spare » devienne un goulet. Si vous avez déjà vu un disque de remplacement saturé à 100% pendant que le reste du pool traîne à 20–30%, vous avez vu la motivation.
En mode dégradé, vous payez généralement trois factures :
- Facture risque : temps jusqu’à la restauration de la redondance.
- Facture performance : lectures supplémentaires et calculs de parité.
- Facture opérationnelle : attention humaine, alertes et contrôle des changements.
dRAID réduit principalement la facture risque en améliorant le parallélisme et en évitant une seule cible de rebuild.
2) Environnements avec matériel prévisible et répétable
Si vous achetez des disques par plateaux de modèles identiques, dans des châssis fixes, et que vous avez un plan de cycle de vie ferme, dRAID peut convenir. Il aime la symétrie. Il n’aime pas que vous mélangiez des disques 12 To et 18 To à 2 heures du matin parce que les achats ont « trouvé une bonne affaire ».
3) Endroits où la « performance dégradée » est une panne
Certaines charges tolèrent un pool dégradé. D’autres non. Dans un cluster de virtualisation très occupé ou une cible de sauvegarde avec ingestion lourde, la performance dégradée peut se transformer en échecs en cascade : retentatives, timeouts, accumulation de files d’attente, et finalement un ticket d’incident qui inclut le mot « intermittent ».
dRAID n’est pas une garantie, mais il peut réduire le temps passé dans cet état dégradé, qui est souvent la seule partie que vous pouvez améliorer raisonnablement sans réarchitecturer.
Où dRAID mord : complexité, contraintes et surprises
dRAID transforme le traitement des pannes en workflow, pas en événement
Dans un miroir, « remplacer un disque, resilver, terminé » est une narration claire. Dans RAIDZ, c’est similaire mais plus lent. Dans dRAID, vous devez comprendre ce que le système fait avec l’espace spare distribué, comment les remplacements sont incorporés, et à quoi ressemble « sain » en termes d’état de disposition. Ce n’est pas que dRAID soit fragile ; c’est qu’il a plus d’éléments mobiles, et votre on-call doit avoir un modèle mental qui tient en situation de stress.
Les erreurs de planification sont plus difficiles à annuler
Le conseil traditionnel — « ajoutez un vdev plus tard » — existe toujours, mais les propriétés de groupe à largeur fixe de dRAID rendent votre conception initiale plus contraignante. Si vous êtes le type d’organisation qui fait évoluer le stockage par achats opportunistes de disques, dRAID peut sembler une camisole.
La performance reste de l’arithmétique de vdev
dRAID n’abroge pas les fondamentaux de performance ZFS :
- Les IOPS proviennent des vdevs plus que du seul nombre brut de disques pour beaucoup de charges aléatoires.
- Recordsize et forme de la charge importent.
- Les vdevs spéciaux peuvent aider les métadonnées et petits blocs, mais peuvent aussi devenir un point unique de « pourquoi tout est lent ? » s’ils sont sous-dimensionnés.
Toutes les plateformes et drapeaux de fonctionnalités ne se valent pas
dRAID vit dans l’écosystème OpenZFS, qui couvre différents systèmes d’exploitation et cadences de sortie. Si vous exécutez ZFS dans un environnement conservateur, soyez honnête sur votre appétence pour les nouvelles fonctionnalités et votre capacité à valider les mises à jour et procédures de récupération.
Observabilité et attentes en matière d’outillage
La plupart des équipes ont déjà de la mémoire musculaire autour de zpool status, des calendriers de scrub, et du remplacement de disques défaillants. dRAID ajoute des états et comportements que vous devrez intégrer aux runbooks. Ce n’est pas rédhibitoire ; c’est une question de personnel et de discipline.
Trois mini-récits du monde de l’entreprise (avec cicatrices)
Mini-récit n°1 : Un incident causé par une fausse hypothèse
L’équipe stockage d’une entreprise SaaS de taille moyenne a migré un dépôt de sauvegarde d’un large RAIDZ2 vers dRAID. La revue de conception s’est bien passée. Le benchmark avait l’air correct. Le runbook on-call a été mis à jour avec le nouveau type de vdev. Tout le monde se sentait moderne.
Puis un disque est tombé pendant une fenêtre d’ingestion chargée. L’on-call a fait ce qu’il faisait depuis des années : insérer un disque de remplacement, lancer le même workflow zpool replace, et attendre que l’histoire familière « resilver vers nouveau disque » se déroule.
Ce qu’ils ont manqué, c’est la différence entre « remplacer un périphérique » et « restaurer la redondance via la capacité spare distribuée ». Ils regardaient la mauvaise chose. Ils s’attendaient à ce que le débit d’écriture d’un seul disque représente le progrès. Pendant ce temps, le pool distribuait les écritures de reconstruction à travers le vdev. L’on-call a vu le disque de remplacement non saturé à 100% et a supposé que quelque chose était bloqué.
Ils ont escaladé à la direction technique. La direction a escaladé au fournisseur. Le fournisseur a demandé des diagnostics, ce qui a pris du temps. Dans la confusion, quelqu’un a fortement bridé les réglages de resilver pour « stabiliser la performance », ce qui a transformé une courte fenêtre de risque en une longue.
L’incident n’était pas une perte de données. C’était une perte de coordination. La fausse hypothèse était que le traitement d’une panne par dRAID ressemblerait à celui du RAIDZ. La correction n’était pas un patch ; c’était une formation et un nouveau tableau de bord « à quoi ressemble un bon progres » pour le resilver et la charge du pool.
Mini-récit n°2 : Une optimisation qui s’est retournée contre eux
Une société de services financiers avait un cluster ZFS pour l’analytique. Ils ont déployé dRAID pour réduire les fenêtres de rebuild parce que les achats imposaient de très gros disques, et leurs resilvers RAIDZ2 prenaient « des jours, pas des heures ». dRAID a aidé — jusqu’à ce que quelqu’un veuille être malin.
L’équipe voulait maximiser la capacité utilisable. Ils ont choisi une disposition large avec un spare distribué minimal, en raisonnant « on peut toujours garder un spare froid sur l’étagère ». Ils ont aussi réglé ZFS pour le débit, poussant recordsize et profondeurs de file pour favoriser les lectures/écritures en bloc.
En charge normale, c’était excellent. En panne, ce fut le chaos. Avec une capacité spare distribuée minimale, le comportement de rebuild est devenu moins tolérant. Et le réglage orienté débit qui paraissait bon dans les benchmarks s’est transformé en pics de latence pendant la reconstruction, parce que les mêmes paramètres qui aident le streaming pénalisent sous reconstruction de parité lourde mélangée à des E/S aléatoires des jobs analytiques.
Le retour de bâton était subtil : ils avaient optimisé pour l’utilisation en état stable et les benchmarks, pas pour la réalité opérationnelle où « le mode dégradé n’est pas un laboratoire ». Ils ont dû revoir la disposition, réserver plus de spare distribué, et fixer des throttles de rebuild plus prudents pour protéger la latence de queue pendant les incidents.
Mini-récit n°3 : Une pratique ennuyeuse mais correcte qui a sauvé la journée
Une grande entreprise exploitait une archive multi-pétaoctets sur ZFS. Rien de glamour : matériel prévisible, adoption conservatrice des fonctionnalités, fenêtres de changement, et un calendrier de scrub si régulier qu’on pouvait régler sa montre sur les tickets qu’il générait.
Ils ont adopté dRAID spécifiquement pour réduire le temps passé en mode dégradé. Mais la raison pour laquelle cela a fonctionné pour eux n’était pas la nouveauté ; c’était leur discipline. Chaque trimestre, ils effectuaient un exercice de panne simulée : hors-ligner un disque (dans une fenêtre contrôlée), vérifier les alertes, valider le runbook, mesurer le temps de resilver, et confirmer que les SLA applicatifs tenaient.
Quand un vrai disque est tombé pendant un week-end férié — parce que les disques aiment les jours fériés — ils n’ont pas improvisé. Ils ont suivi le runbook, vérifié l’état du pool, surveillé les bons compteurs, et n’ont pas touché aux throttles parce qu’ils les avaient déjà réglés pour « charge production + rebuild ».
La journée a été sauvée par des pratiques ennuyeuses : scrubs réguliers qui réduisent les erreurs latentes, procédures de remplacement testées, et quelqu’un capable d’expliquer à la direction que « le pool fait exactement ce que nous avons conçu ». En stockage, l’ennui est une réussite.
Tâches pratiques : commandes + interprétation
Les tâches suivantes supposent un hôte Linux avec OpenZFS installé et des utilitaires courants disponibles. Ajustez les noms de périphériques et de pool pour votre environnement. Chaque commande ici est quelque chose que j’ai exécuté en colère ou en répétition.
Tâche 1 : Identifier votre réalité ZFS et de pool
cr0x@server:~$ uname -r
6.8.0-52-generic
cr0x@server:~$ zfs version
zfs-2.2.4-1
zfs-kmod-2.2.4-1
cr0x@server:~$ zpool get all tank | egrep 'version|feature@|ashift' | head
tank version 5000 local
tank feature@async_destroy active local
tank feature@device_removal active localInterprétation : Ne discutez pas dRAID de façon abstraite — vérifiez la version ZFS réelle et quelles fonctionnalités sont actives. Certains comportements et l’observabilité s’améliorent selon les versions.
Tâche 2 : Créer un pool dRAID (exemple de disposition)
cr0x@server:~$ sudo zpool create -o ashift=12 tank draid2:8d:24c:2s \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d0 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d1 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d2 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d3 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d4 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d5 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d6 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d7 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d8 \
/dev/disk/by-id/wwn-0x5000c500a1b2c3d9Interprétation : Ceci est un modèle, pas une recommandation universelle. La syntaxe dRAID encode le niveau de parité, la largeur de groupe, le nombre d’enfants et les spares distribués. Si vous vous trompez de disposition, vous « gagnerez » une vitesse de rebuild que vous ne pourrez pas opérationnaliser.
Tâche 3 : Vérifier la topologie et voir ce que vous avez réellement construit
cr0x@server:~$ zpool status -v tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
draid2:8d:24c:2s-0 ONLINE 0 0 0
wwn-0x5000c500a1b2c3d0 ONLINE 0 0 0
wwn-0x5000c500a1b2c3d1 ONLINE 0 0 0
...Interprétation : Confirmez la ligne du vdev dRAID. Quand l’on-call est fatigué, « je croyais que c’était RAIDZ2 » n’est pas une cause racine acceptable.
Tâche 4 : Mesurer les compteurs de performance du pool avant les ennuis
cr0x@server:~$ zpool iostat -v tank 5 3
capacity operations bandwidth
pool alloc free read write read write
tank 2.15T 19.6T 210 980 18.2M 92.7M
draid2 2.15T 19.6T 210 980 18.2M 92.7M
...Interprétation : C’est votre « normal ». Pendant un resilver, comparez à cette base. Si vous n’avez pas de base, vous discuterez des impressions.
Tâche 5 : Simuler une panne en toute sécurité (mettre un disque hors ligne)
cr0x@server:~$ sudo zpool offline tank wwn-0x5000c500a1b2c3d3
cr0x@server:~$ zpool status tank
pool: tank
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
action: Online the device using 'zpool online' or replace the device with 'zpool replace'.
scan: none requested
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
draid2:8d:24c:2s-0 DEGRADED 0 0 0
wwn-0x5000c500a1b2c3d3 OFFLINE 0 0 0Interprétation : En laboratoire ou dans une fenêtre contrôlée, ceci teste l’alerte et vérifie votre compréhension du comportement dégradé. Ne le faites pas un vendredi sauf si votre organisation aime l’art performance.
Tâche 6 : Remettre le périphérique en ligne (online) et surveiller la reconstruction
cr0x@server:~$ sudo zpool online tank wwn-0x5000c500a1b2c3d3
cr0x@server:~$ zpool status tank
pool: tank
state: ONLINE
scan: resilver in progress since Tue Dec 24 10:12:41 2025
312G scanned at 2.11G/s, 84.2G issued at 582M/s, 6.45T total
84.2G resilvered, 1.30% done, 03:05:12 to goInterprétation : Surveillez à la fois « scanned » et « issued ». Si scanned est énorme mais issued faible, vous êtes probablement limité par le CPU, les I/O ou la contention.
Tâche 7 : Remplacer un périphérique défaillant par un neuf (opération typique)
cr0x@server:~$ sudo zpool replace tank wwn-0x5000c500a1b2c3d3 /dev/disk/by-id/wwn-0x5000c500d4e5f6a7
cr0x@server:~$ zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 24 10:22:09 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
draid2:8d:24c:2s-0 DEGRADED 0 0 0
replacing-3 DEGRADED 0 0 0
wwn-0x5000c500a1b2c3d3 FAULTED 0 0 0
wwn-0x5000c500d4e5f6a7 ONLINE 0 0 0Interprétation : Le remplacement est toujours une opération de première classe, mais ne supposez pas que le travail de rebuild se fait « uniquement vers le nouveau disque ». dRAID utilise des schémas de spare distribué en dessous.
Tâche 8 : Suivre la progression du resilver avec des détails exploitables
cr0x@server:~$ watch -n 2 'zpool status tank; echo; zpool iostat -v tank 2 1'
Every 2.0s: zpool status tank; echo; zpool iostat -v tank 2 1
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 24 10:22:09 2025
1.02T scanned at 1.88G/s, 411G issued at 756M/s, 6.45T total
411G resilvered, 6.38% done, 02:23:44 to goInterprétation : Associez zpool status (progression) avec zpool iostat (distribution de la charge). Si un sous-ensemble de disques est saturé, vous avez trouvé la prochaine question.
Tâche 9 : Confirmer ashift et les hypothèses d’alignement de secteur
cr0x@server:~$ zdb -C tank | egrep 'ashift|vdev_children' | head -n 20
ashift: 12
vdev_children: 1Interprétation : Un ashift mal aligné peut vous punir silencieusement pour toujours. dRAID ne vous sauvera pas de ce type d’erreur ; il reconstruira juste plus vite dans la même mauvaise géométrie.
Tâche 10 : Inspecter les stats ARC quand le resilver paraît lié CPU/mémoire
cr0x@server:~$ arcstat 2 5
time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
10:31:02 820 92 10 20 2 70 8 2 0 64.1G 96.0G
10:31:04 790 110 13 28 3 80 10 2 0 64.2G 96.0GInterprétation : Un resilver qui se bat avec votre working set peut pousser les taux de miss du cache et rendre la latence applicative désagréable. L’ARC n’est pas juste pour la lecture ; c’est une partie de l’histoire du comportement de récupération.
Tâche 11 : Vérifier la latence pathologique au niveau bloc
cr0x@server:~$ iostat -x 2 3
avg-cpu: %user %nice %system %iowait %steal %idle
12.40 0.00 6.20 18.90 0.00 62.50
Device r/s w/s rkB/s wkB/s await svctm %util
nvme0n1 80.0 120.0 12000 34000 2.1 0.2 4.0
sdg 140.0 220.0 9800 21000 28.4 2.8 98.0
sdh 135.0 210.0 9500 20500 31.2 2.9 97.5Interprétation : Pendant un resilver, quelques périphériques peuvent atteindre 100% d’utilisation avec await élevé. S’ils sont tous sur le même chemin HBA ou expander, vous êtes peut-être limité en amont — pas par ZFS.
Tâche 12 : Confirmer que les scrubs sont sains (et ne passent pas silencieusement)
cr0x@server:~$ zpool status -x
all pools are healthy
cr0x@server:~$ zpool status tank | sed -n '/scan:/,/config:/p'
scan: scrub repaired 0B in 07:18:22 with 0 errors on Sun Dec 21 03:00:01 2025Interprétation : Des scrubs qui s’achèvent régulièrement sans erreurs ne sont pas excitants, mais ils réduisent la probabilité qu’un resilver tombe sur une erreur latente de lecture et transforme une « panne disque » en réunion « pourquoi la récupération est compliquée ? »
Tâche 13 : Vérifier les paramètres de dataset ZFS qui influencent la douleur de rebuild
cr0x@server:~$ zfs get -r recordsize,compression,atime,logbias,sync tank/data | head -n 20
NAME PROPERTY VALUE SOURCE
tank/data recordsize 128K local
tank/data compression zstd local
tank/data atime off local
tank/data logbias latency local
tank/data sync standard defaultInterprétation : Ces réglages ne changeront pas la conception fondamentale du rebuild dRAID, mais ils modifient absolument la forme des E/S en état stable, les tendances de fragmentation, et à quel point le mode dégradé est pénible.
Tâche 14 : Contrôler l’impact du resilver (brider avec précaution)
cr0x@server:~$ sudo sysctl -a | egrep 'zfs_vdev_resilver|min|max' | head
fs.zfs.vdev.raidz_deflate=1
fs.zfs.vdev.async_read_max_active=3
fs.zfs.vdev.async_write_max_active=10
cr0x@server:~$ sudo sysctl -w fs.zfs.vdev.async_read_max_active=6
fs.zfs.vdev.async_read_max_active = 6Interprétation : Le bridage dépend de la charge et du système d’exploitation. La leçon n’est pas « mettez X à Y ». La leçon est : changez une chose à la fois, mesurez la latence extrême, et rappelez-vous que vous échangez fenêtre de risque contre douleur utilisateur.
Mode d’emploi pour diagnostic rapide : trouver le goulot vite
Ceci est la séquence « 2 heures du matin, la production est dégradée, tout le monde vous regarde ». L’objectif est d’identifier si le resilver est lent à cause de la politique ZFS, de contraintes matérielles, ou de contention avec la charge.
Premier point : confirmez l’état réel dans lequel vous êtes
cr0x@server:~$ zpool status -v tank
cr0x@server:~$ zpool events -v | tail -n 50Ce que vous cherchez : Est-ce un resilver, un scrub, ou les deux ? Le pool est-il DEGRADED ou SUSPENDED ? Y a-t-il des erreurs de checksum indiquant des dégâts supplémentaires ? Quelqu’un a-t-il mis un périphérique hors ligne intentionnellement ?
Deuxième point : vérifiez si vous êtes IO-bound sur un sous-ensemble de disques ou un chemin
cr0x@server:~$ zpool iostat -v tank 2 5
cr0x@server:~$ iostat -x 2 5Ce que vous cherchez : Quelques périphériques à ~100% d’utilisation avec await élevé suggèrent un goulet (disque, HBA, expander, lien SAS). Si tous les disques sont modérément occupés mais que le progrès est lent, cherchez ailleurs.
Troisième point : vérifiez la pression CPU, mémoire et le comportement ARC
cr0x@server:~$ vmstat 2 5
cr0x@server:~$ top -b -n 1 | head -n 25Ce que vous cherchez : Un iowait élevé peut indiquer un bound disque. Un CPU système élevé avec des threads ZFS peut indiquer une surcharge de checksum/parité. La pression mémoire peut provoquer un renouvellement de cache qui ralentit tout.
Quatrième point : vérifiez si la charge est tout simplement trop bruyante
cr0x@server:~$ zfs list -o name,used,available,refer,mountpoint -r tank | head
cr0x@server:~$ zfs get -r sync,logbias,primarycache,secondarycache tank | head -n 40Ce que vous cherchez : Les workloads à écritures synchrones pendant une reconstruction peuvent ruiner votre journée. Si vous exécutez une base de données avec sync=always sur des disques rotatifs et sans SLOG, aucun type de vdev ne rendra cela joli.
Cinquième point : faites un changement, mesurez, et notez-le
Si vous ajustez la concurrence ou la planification, faites-le par étape contrôlée et observez :
cr0x@server:~$ zpool status tank | sed -n '/scan:/,/config:/p'
cr0x@server:~$ zpool iostat -v tank 5 2Ce que vous cherchez : Une augmentation de « issued at » sans pics de latence inacceptables est la victoire. Un progrès plus rapide avec un incident côté utilisateur n’est pas une victoire ; c’est une dispute que vous perdrez plus tard.
Erreurs courantes : symptômes et corrections
Erreur 1 : Traiter dRAID comme du RAIDZ dans les runbooks
Symptôme : L’on-call se focalise sur le débit du disque de remplacement ; il pense que le rebuild est « bloqué » parce que ce disque n’est pas saturé.
Correction : Mettez à jour les runbooks pour insister sur la progression au niveau du pool (zpool status) et les schémas d’I/O distribués (zpool iostat -v). Formez sur ce à quoi ressemble un comportement « normal » pendant un resilver dRAID.
Erreur 2 : Disposition choisie par feuille de calcul de capacité, pas par workflow de panne
Symptôme : Super chiffres de TB utilisables, mais en mode dégradé la latence explose, ou le comportement de rebuild devient imprévisible en charge.
Correction : Réévaluez le niveau de parité, la largeur de groupe et le nombre de spares distribués en fonction des objectifs opérationnels : cibles de temps de rebuild, performance acceptable en mode dégradé, et votre taux de panne réaliste.
Erreur 3 : Mélanger types ou tailles de disques sans précaution
Symptôme : Asymétrie de performance étrange, goulets inattendus, ou temps de rebuild qui ne correspondent pas à la planification.
Correction : Gardez les membres du vdev aussi uniformes que possible. Si vous devez mélanger, faites-le intentionnellement et modélisez l’appareil le plus lent comme facteur limitant.
Erreur 4 : Ignorer les goulets de chemin (HBA/expander)
Symptôme : Un groupe de disques montre tous un await élevé simultanément ; remplacer un disque n’améliore pas la vitesse de rebuild.
Correction : Validez la topologie SAS, le nombre de voies, les firmwares et le câblage. dRAID augmente le parallélisme ; votre matériel doit pouvoir le supporter.
Erreur 5 : Bridage agressif du rebuild pour « aider la performance »
Symptôme : Les utilisateurs sont contents, mais le pool reste dégradé beaucoup plus longtemps que prévu, augmentant l’exposition au risque.
Correction : Fixez les throttles de rebuild en fonction des budgets de latence extrême mesurés. Envisagez des politiques temporelles : plus agressif la nuit, conservateur en période de pointe.
Erreur 6 : Sous-estimer la valeur des scrubs de routine
Symptôme : Le rebuild rencontre des erreurs de checksum ou des erreurs de lecture, compliquant la récupération.
Correction : Scrubbez selon un calendrier qui correspond à votre tolérance au risque et à la classe de disques. Les scrubs ne sont pas optionnels dans les grands pools.
Erreur 7 : Surconfiance dans les vdevs spéciaux
Symptôme : Le pool « a l’air bien » mais les opérations lourdes en métadonnées rampent, surtout pendant un resilver ou un scrub.
Correction : Dimensionnez correctement les vdevs spéciaux, miroirlez-les, et surveillez leur latence. Si le vdev spécial est malade, le pool est malade.
Checklists / plan étape par étape
Checklist A : Décider si dRAID convient
- Définissez votre objectif de panne : « Restaurer la redondance sous X heures en charge typique. » Si vous ne pouvez pas dire X, vous n’êtes pas prêt à discuter dRAID ; vous basez encore le stockage sur des impressions.
- Quantifiez le SLA en mode dégradé : Quelle latence et quel débit sont acceptables lorsqu’un disque est mort et que le rebuild tourne ?
- Validez la symétrie matérielle : Même modèle de disque, même politique de firmware, HBAs cohérents, refroidissement prévisible.
- Évaluez la maturité opérationnelle : Pouvez-vous exécuter des exercices de panne trimestriels ? Pouvez-vous mettre à jour OpenZFS sans craindre ?
- Choisissez le niveau de parité selon le risque : dRAID n’élimine pas le risque de URE/erreurs latentes ; il change le comportement de récupération. Choisissez la parité comme un adulte.
Checklist B : Validation pré-déploiement (le labo qui sauve votre trimestre)
- Créez un pool à petite échelle avec les mêmes ratios de disposition (parité, largeur de groupe, spares distribués).
- Exécutez une simulation de charge en état stable (votre pattern IO, pas un benchmark générique).
- Mettez un disque hors ligne et mesurez : temps de resilver, latence extrême, CPU, profondeur des files disque.
- Remplacez un disque et confirmez que le workflow opérationnel est compris.
- Testez un scrub sous charge. Testez un scrub pendant un resilver si vous êtes courageux — mais enregistrez l’impact.
- Documentez les graphes « normaux » pour le resilver : bande passante émise, distribution d’utilisation par disque.
Checklist C : Runbook de production pour un disque défaillant en dRAID
- Confirmez l’alerte :
zpool status -v, vérifiez les erreurs au-delà du disque défaillant. - Stabilisez la situation : ne changez pas encore les réglages ; observez d’abord.
- Identifiez le disque physique : faites correspondre WWN/serial au slot avec vos outils et étiquettes plateforme.
- Remplacez le disque (hot-swap si pris en charge) et lancez
zpool replaceen utilisant des IDs de périphérique stables. - Surveillez la progression avec des métriques au niveau pool et par disque. Surveillez la latence applicative, pas seulement la vitesse de rebuild.
- Après la fin, revoyez : le temps de rebuild était-il dans la cible ? Y a-t-il eu des erreurs de checksum ? Des goulets de chemin ?
- Fermez la boucle : mettez à jour le runbook si quelque chose vous a surpris.
FAQ
1) dRAID est-il toujours plus rapide pour resilver que RAIDZ ?
Non. dRAID est conçu pour paralléliser la reconstruction et éviter le goulet d’un disque spare unique, mais la vitesse réelle dépend de la contention de charge, des chemins matériels et des choix de disposition. Si votre goulet est un lien HBA ou un expander lent, dRAID peut exposer ce goulet plutôt que le contourner.
2) dRAID remplace-t-il le besoin de spares physiques ?
Il change le concept. dRAID utilise une capacité spare distribuée pour que le travail de récupération puisse démarrer sans qu’un disque spare dédié fasse toutes les écritures. Beaucoup d’opérateurs conservent encore des spares physiques en stock pour un remplacement rapide — parce que le matériel casse toujours et que vous voulez un périphérique propre dans le châssis.
3) Dois-je choisir dRAID plutôt que des miroirs pour la performance ?
Si vous voulez une I/O aléatoire basse latence, les miroirs restent la victoire la plus simple car ils fournissent plus d’IOPS par To et des resilvers simples. dRAID concerne surtout l’amélioration du comportement de récupération des pools parité à grande échelle. Si votre charge est sensible à la latence et aléatoire, les miroirs (ou plus de vdevs) restent souvent le choix pratique.
4) Puis-je étendre un vdev dRAID plus tard ?
Planifiez comme si l’expansion était plus difficile que souhaitée. L’expansion ZFS se fait généralement en ajoutant des vdevs, pas en grossissant un vdev unique de façon transparente. Le design de groupes à largeur fixe de dRAID rend « ajouter des disques dans ce vdev » une conversation plus contrainte. Traitez la disposition initiale comme un engagement de longue durée.
5) dRAID réduit-il le risque de perte de données pendant le rebuild ?
Il réduit le temps passé en mode dégradé dans de nombreux scénarios, ce qui réduit l’exposition. Il n’élimine pas les risques tels que les pannes multiples, les secteurs latents, les bugs de firmware ou l’erreur humaine. Le niveau de parité et la discipline des scrubs restent importants.
6) dRAID rendra-t-il mes scrubs plus rapides ?
Pas automatiquement. La vitesse de scrub dépend de la bande passante de lecture, de la latence des disques et de l’activité du pool. dRAID se concentre sur le comportement du resilver, pas sur l’accélération de toutes les opérations de maintenance. Cela dit, de meilleures caractéristiques de distribution de charge peuvent parfois rendre la maintenance moins soudaine.
7) Comment savoir si mon resilver est « lent » pour une vraie raison ?
Comparez « issued at » et l’utilisation par disque avec votre baseline (zpool iostat -v). Si la progression est faible et que les disques ne sont pas occupés, suspectez du bridage ou des contraintes CPU. Si un sous-ensemble de disques est saturé, suspectez un goulet de chemin ou du matériel inégal. Si la latence applicative est terrible, suspectez la contention avec la charge et reconsidérez les throttles ou la planification.
8) Quel niveau de parité choisir avec dRAID ?
Choisissez la parité selon le nombre de disques, la classe de disques, les fenêtres de rebuild, et votre tolérance à des pannes multiples. dRAID2 (double parité) est courant dans les grands pools. Si l’impact métier d’une seconde panne est inacceptable, n’essayez pas de négocier avec la physique : ajoutez de la parité ou changez l’architecture.
9) dRAID change-t-il la manière de régler recordsize et compression ?
Il ne change pas les fondamentaux : réglez recordsize pour correspondre à la taille I/O de la charge, utilisez la compression quand elle réduit les E/S physiques, et désactivez atime dans la plupart des datasets sensibles à la performance. Mais comme dRAID vise une récupération plus rapide, testez la performance en mode dégradé avec vos réglages de dataset, pas seulement les benchmarks en état stable.
10) Quel est le « tell » opérationnel que dRAID fait son travail ?
Le tell n’est pas un disque qui s’emballe. C’est plusieurs disques participant à la reconstruction, une latence applicative stable dans votre budget défini, et un temps plus court entre la panne et la restauration de la redondance.
Conclusion
dRAID n’est ni un gadget ni un déjeuner gratuit. C’est une réponse d’ingénierie sérieuse à un problème de production très réel : le temps de resilver est devenu un facteur de risque principal à mesure que les disques ont grossi et que les pools se sont élargis. En répartissant la capacité spare et le travail de rebuild sur de nombreux disques, dRAID peut raccourcir les fenêtres dégradées et réduire les points chauds — les parties de l’histoire de panne qui font le plus mal.
Mais cela vous demande aussi de mûrir opérationnellement. Vous avez besoin d’une meilleure planification, de runbooks clairs, et d’une observabilité adaptée au nouveau comportement. Si vos pratiques de stockage sont déjà disciplinées — matériel cohérent, exercices de panne testés, SLA mesurés — dRAID peut être une amélioration pratique. Si vous vous reposez sur l’improvisation et l’espoir, dRAID ne vous sauvera pas. Il échouera juste plus vite, et avec des graphiques plus intéressants.