ZFS dRAID Sparing : Comment les spares distribués modifient la récupération

décembre 23, 2025 • février 3, 2026 • Lecture : 32 min • Views: 10

Cet article vous a aidé ?

Les pannes RAIDZ traditionnelles ont un rythme familier : un disque meurt, vous insérez un spare, et vous attendez pendant que le pool cloue ce disque de remplacement pendant des heures (ou des jours) comme s’il était responsable de la panne.
Pendant ce temps, la latence augmente, les responsables applicatifs froncent les sourcils, et l’équipe stockage commence à négocier avec la physique.

dRAID change ce rythme. Les spares distribués font de la récupération une opération parallèle sur de nombreux disques, pas un événement d’endurance ciblé sur un seul disque.
C’est important — si on le comprend et qu’on l’exploite correctement. Sinon, vous pouvez vous retrouver « récupéré » sur le papier alors que la performance chute silencieusement.

Ce que change (et ce que ne change pas) le sparing dRAID

L’essentiel : dRAID remplace le modèle « hot spare comme disque entier » par un espace de spare distribué à l’intérieur du vdev dRAID.
Lorsqu’un disque tombe en panne, la reconstruction écrit dans des slices de spare réparties sur les disques restants, permettant aux E/S de récupération de s’exécuter en parallèle.
La reconstruction est moins « un disque se fait gaver de parité » et plus « toute la classe passe le même test ensemble ».

Mais dRAID ne réécrit pas magiquement les lois du stockage. Vous devez toujours :

Survivre au domaine de défaillance que vous avez conçu (dRAID1 vs dRAID2 vs dRAID3).
Payer le travail de parité en CPU et en I/O disque.
Vivre avec le fait qu’un pool en reconstruction est un pool sous contrainte.

Deux modèles mentaux : resilver RAIDZ vs reconstruction dRAID

Le resilver RAIDZ rejoue traditionnellement la métadonnée et copie les blocs encore référencés, mais il a tendance à cibler fortement le périphérique de remplacement.
Le remplacement devient le goulot d’étranglement — surtout s’il s’agit d’un HDD parmi des HDD, ou pire, d’un disque plus petit avec un comportement SMR que vous n’avez pas remarqué.

dRAID est conçu pour éviter le goulot d’un seul périphérique en utilisant de l’espace de spare distribué. Cela change les modes de défaillance en récupération :

Bon : vous pouvez retrouver la redondance plus vite (souvent de façon spectaculaire) parce que les écritures ne passent pas en série par un seul disque.
Différent : les écritures de reconstruction sont réparties sur de nombreux disques, donc tout le vdev peut devenir « chaud » durant la reconstruction.
Plus subtil : vous pouvez « terminer » la reconstruction dans des spares distribués et devoir plus tard effectuer un remplacement physique pour restaurer la capacité de spare d’origine.

Ce qui doit vous importer en exploitation

En termes opérationnels, le sparing dRAID déplace la fenêtre de risque :

Le temps passé en redondance réduite peut diminuer, ce qui est le but principal.
L’impact performance sur l’ensemble du pool pendant la reconstruction peut être plus large car plus de disques participent.
Le travail de suivi (remplacer le disque défaillant et évacuer les slices de spare vers lui) devient une phase distincte à planifier.

Les spares distribués expliqués façon SRE

Voici la manière la plus claire d’y penser : dans dRAID, chaque disque physique contribue non seulement des slices de données et de parité, mais aussi (optionnellement) des slices de spare.
Ces slices de spare sont réparties sur tout le vdev. Quand un disque meurt, ZFS reconstruit les slices manquantes et les écrit dans les slices de spare des disques restants.

Cela signifie que le « spare » n’est pas un disque solitaire et inactif attendant le drame. C’est une capacité réservée saupoudrée partout, prête à être utilisée immédiatement.

Pourquoi cela aide : parallélisme et éviter le goulot du « disque de remplacement unique »

Le comportement classique d’un hot spare a souvent une propriété brutale : le périphérique de remplacement doit absorber un énorme flux d’écritures essentiellement séquentielles tout en participant aux lectures et au calcul de la parité.
Le participant le plus lent devient votre métronome de rebuild.

Avec des spares distribués, les écritures de reconstruction peuvent être envoyées vers de nombreux disques en parallèle.
Cela tend à :

Réduire le temps de récupération pour de grands pools HDD.
Rendre le temps de rebuild moins sensible à un seul spare lent.
Mieux utiliser de larges JBOD où vous avez déjà acheté les plateaux — vous les utilisez réellement pendant la récupération.

Ce qui change au sujet de « remplacer le disque »

Dans dRAID, « un disque est tombé en panne » et « un nouveau disque est inséré » sont des événements liés mais pas identiques.
Vous pouvez reconstruire dans les spares distribués avant d’avoir physiquement le remplaçant sous la main. C’est puissant en sites distants, en labo, ou quand la chaîne d’approvisionnement est lente.
Mais c’est aussi un piège si vous traitez « reconstruit » comme « terminé ».

Le vdev a consommé ses slices de spare. Vous fonctionnez maintenant avec moins (ou zéro) capacité de spare jusqu’à ce que vous remplaciez physiquement le disque et rééquilibriez les données hors des spares distribués.
Cette phase de suivi est importante. L’ignorer, c’est rouler en dépannage avec une roue de secours en faisant comme si tout allait bien.

Blague #1 : Les spares distribués, c’est comme avoir des extincteurs dans chaque pièce au lieu d’un seul dans le hall — ça n’empêche pas de mettre le feu en premier lieu.

Parcours de récupération : de la panne à l’état stable

Parcourons la timeline d’une panne dans un pool dRAID, en nous concentrant sur ce qui change opérationnellement.
Je resterai neutre vis-à-vis des vendeurs mais précis sur les commandes, parce que personne n’a été appelé pour un séminaire de philosophie.

Phase 0 : pool sain, slices de spare réservées

En état stable, les slices de spare dRAID sont réservées mais inutilisées.
Vous payez en capacité brute pour cette disponibilité, comme pour un spare traditionnel, mais vous payez aussi en complexité de layout.
Donc surveillez-le comme si vous y teniez.

Phase 1 : un disque échoue (ou est faulted)

Le pool détecte un taux d’erreurs du périphérique, des timeouts, ou un chemin mort. ZFS marque le périphérique comme FAULTED ou OFFLINE.
À ce moment, le pool est dégradé. Votre première question : Sommes-nous toujours dans la tolérance de parité ?

Phase 2 : reconstruction dans les spares distribués

L’objectif de conception de dRAID est de reconstruire rapidement en parallélisant les E/S de reconstruction sur les disques restants.
Pendant cette phase, vous pouvez observer :

Augmentation des lectures sur de nombreux membres (pour reconstruire données/parité manquantes).
Augmentation des écritures sur de nombreux membres (écriture dans les slices de spare).
Impact sur la latence à l’échelle du pool même si le débit paraît correct, car les files s’allongent partout.

Votre travail : confirmer que ça progresse, confirmer que le goulot correspond à l’attendu (généralement les disques), et confirmer qu’aucun autre élément ne flanche.

Phase 3 : stable mais « sur les slices de spare »

Après la reconstruction, la redondance peut être restaurée au sens logique : les slices manquantes sont maintenant présentes ailleurs.
Mais vous avez consommé de l’espace de spare. Opérationnellement, vous n’êtes pas revenu à la situation initiale.

Point de décision :

Si vous pouvez remplacer le disque rapidement, faites-le et terminez la guérison.
Si vous ne le pouvez pas, soyez honnête sur le risque : une seconde défaillance pourrait vous faire dépasser la tolérance de parité, et vous pourriez ne plus avoir de slices de spare disponibles.

Phase 4 : remplacement physique et évacuation

Quand vous insérez un nouveau disque et l’attachez, ZFS peut redistribuer les données depuis les slices de spare vers le nouveau périphérique, restaurant ainsi la capacité de spare distribuée.
C’est là que certaines équipes sont surprises : elles fêtent la fin de la reconstruction, puis oublient d’achever la dernière étape, et six mois plus tard elles manquent « mystérieusement » de marge de spare.

Faits et histoire : pourquoi dRAID existe

Les fonctionnalités de stockage n’apparaissent pas souvent parce que les ingénieurs s’ennuyaient. dRAID répond à une douleur précise : le temps de rebuild et le risque de rebuild dans de larges groupes RAID avec de gros HDD.

Fait 1 : Quand les capacités HDD ont augmenté plus vite que le débit de rebuild par disque, le temps passé en état dégradé est devenu un enjeu majeur de fiabilité pour les arrays RAID.
Fait 2 : Les designs traditionnels de « hot spare global » peuvent limiter la vitesse de rebuild sur le spare unique, même quand des dizaines d’autres disques sont majoritairement inactifs.
Fait 3 : Les fournisseurs RAID ont introduit il y a des années le « distributed sparing » dans les arrays matériels pour réduire le temps de rebuild et éviter qu’un seul spare soit surchargé.
Fait 4 : ZFS a historiquement mis l’accent sur la correction et le checksum bout-en-bout ; la vitesse de rebuild dans de très larges vdevs est devenue une pression opérationnelle croissante.
Fait 5 : Le terme « resilver » est spécifique à ZFS et reflète que ZFS reconstruit typiquement seulement les données vivantes référencées par les métadonnées, pas l’intégralité du périphérique brut (même si le comportement dépend de la topologie et des fonctionnalités).
Fait 6 : Les groupes de parité larges peuvent subir une « amplification de rebuild » : il faut lire plus de disques pour reconstruire des données perdues, augmentant la charge et la probabilité d’erreurs supplémentaires pendant la récupération.
Fait 7 : Les déploiements JBOD modernes (beaucoup de disques derrière des HBA) ont rendu le parallélisme pendant la récupération non seulement possible mais nécessaire — autrement, vous aviez acheté des plateaux que vous n’utilisez pas quand vous en avez le plus besoin.
Fait 8 : Opérationnellement, les plus grosses interruptions de stockage ne sont souvent pas la première panne disque ; ce sont la seconde panne pendant une fenêtre de rebuild prolongée.
Fait 9 : dRAID vise aussi à réduire les effets de « falaise de performance » en distribuant la charge de reconstruction ; cela rend l’impact plus large mais souvent moins profond.

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a migré une couche de logs de RAIDZ2 vers dRAID2 parce qu’elle voulait une récupération plus rapide et moins de marathons de rebuild nocturnes.
Le pilote s’est bien passé. Les tableaux de bord semblaient plus calmes. La direction a déclaré victoire, ce qui est toujours un moment dangereux.

Quelques mois plus tard, un disque est tombé en panne en production. L’astreinte a vu le pool se reconstruire rapidement et a marqué l’incident « résolu ».
Ils n’ont pas remplacé le disque immédiatement car les achats avaient du retard et le système semblait stable.
Le pool a fonctionné pendant des semaines avec des slices de spare distribués consommées.

Puis un second disque dans le même châssis a commencé à générer des timeouts intermittents. Pas mort, juste suffisamment instable pour provoquer de longs stalls d’I/O.
ZFS a fait ce qu’il devait : il a retenté, journalisé des erreurs, et a continué. L’application a fait ce qu’elle fait toujours sous stall : elle a accumulé des files.
La latence a explosé, le pipeline de logs a pris du retard, et soudain la « couche de logs non critique » retardait l’investigation d’un autre incident.

La mauvaise hypothèse était simple : « reconstruction terminée » a été traité comme « redondance et capacité de spare entièrement restaurées ».
En termes dRAID, ils avaient la stabilité mais pas de marge. La correction fut banale : formaliser la phase de remplacement avec un SLO.
Remplacez le disque défaillant dans une fenêtre définie, et suivez « distributed spare consommé » comme métrique de risque de premier plan.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une société d’analytique financière exécutait une charge lourde de lectures aléatoires sur un pool HDD alimenté par un grand ARC et un L2ARC modeste.
Ils sont passés à dRAID parce que leurs vdevs étaient larges et que le temps de rebuild devenait une histoire de fiabilité gênante pour les auditeurs.

Un ingénieur — intelligent, bien intentionné et allergique aux ressources inactives — a décidé de « booster » la performance de récupération en augmentant l’agressivité du rebuild pendant la reconstruction.
Le pool s’est reconstruit vite, certes. Il a aussi transformé la latence normale des requêtes en incident quotidien.
L’activité métier a commencé à subir des timeouts en heures de pointe parce que les disques dépensaient leur budget d’IOPS à reconstruire au lieu de servir.

Le postmortem fut clair : ils ont optimisé pour le temps de complétion et ignoré le temps de service.
Dans des pools larges, la reconstruction parallèle peut saturer l’ensemble des plateaux. Ce n’est pas de la « vitesse gratuite », c’est une autre façon de dépenser la même monnaie I/O.

La correction fut opérationnelle, pas héroïque : limiter l’agressivité de reconstruction pendant les heures de production, puis accélérer hors pointe.
Ils ont aussi déplacé des jeux de données « chauds » vers des pools SSD où le comportement de rebuild importait moins et où la latence de service comptait davantage.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise de santé gérait des archives d’imagerie sur de grands pools dRAID. Les données étaient écrites une fois, lues rarement, et absolument imperméables à la perte.
Leur équipe stockage était discrètement conservatrice : ils testaient les procédures de remplacement trimestriellement, gardaient les firmwares cohérents, et faisaient tourner l’astreinte sur des exercices pratiques.
Personne n’a fait la fête pour ça. C’est comme ça qu’on sait que c’était le bon travail.

Un weekend, un backplane d’un châssis a commencé à faire rebondir deux disques — déconnexions brèves, puis reconnexions.
ZFS a signalé un périphérique dégradé, a lancé l’activité de reconstruction, puis s’est stabilisé quand le chemin est revenu.
L’astreinte a suivi le playbook : confirmé que ce n’était pas un disque isolé, vérifié les logs HBA, et placé le châssis en fenêtre de maintenance.

Ils ont remplacé le backplane, resserré le câblage, et n’ont remplacé les disques suspects qu’après.
Parce qu’ils avaient une procédure rodée, ils n’ont pas paniqué et remplacé la moitié du châssis en introduisant involontairement plus de risque.
La reconstruction s’est terminée sans drame.

Le « sauvetage » n’était pas un réglage astucieux. C’était l’habitude de vérifier la couche matérielle en premier, de valider les domaines de panne, et d’effectuer une maintenance contrôlée.
L’ennuyeux a gagné. Encore une fois.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici des actions concrètes d’opérateur. Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision à prendre.
Les noms d’hôtes et de pools sont des exemples ; ne copiez-collez pas aveuglément en prod sauf si vous aimez rédiger des rapports d’incident.

Tâche 1 : Confirmer la santé du pool et si une reconstruction/resilver est active

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Dec 26 02:01:11 2025
        1.23T scanned at 1.8G/s, 620G issued at 900M/s, 14.2T total
        620G resilvered, 4.25% done, 04:18:33 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          draid2:8d:24c:1s-0                      DEGRADED     0     0     0
            sda                                    ONLINE       0     0     0
            sdb                                    ONLINE       0     0     0
            sdc                                    FAULTED      0     0     0  too many errors
            sdd                                    ONLINE       0     0     0
            ...
errors: No known data errors

Signification : Le pool est dégradé et un resilver est en cours. « errors: No known data errors » est ce que vous voulez voir.
La ligne scan vous donne le débit, le pourcentage terminé et l’ETA. Le nombre « issued » aide à détecter un throttling ou une contention.

Décision : Si l’ETA est raisonnable et que les erreurs sont stables, vous surveillez. Si l’ETA explose ou que les erreurs augmentent, passez à la plaquette de diagnostic rapide.

Tâche 2 : Identifier si l’espace de spare est consommé (vue générale)

cr0x@server:~$ sudo zpool list -v tank
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank    218T   141T    77T        -         -     18%    64%  1.00x  DEGRADED  -
  draid2:8d:24c:1s-0  218T   141T    77T        -         -     18%    64%      -      -

Signification : Ceci n’affiche pas directement « spare consommé », mais confirme que vous êtes sur un vdev dRAID et l’état du pool.
La capacité et la fragmentation comptent car une forte fragmentation peut ralentir la reconstruction.

Décision : Si CAP est élevé et FRAG est élevé, attendez-vous à une récupération plus lente et planifiez une fenêtre de risque plus longue.

Tâche 3 : Confirmer la topologie exacte du vdev (paramètres dRAID)

cr0x@server:~$ sudo zpool status tank | sed -n '1,80p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 02:01:11 2025
config:

        NAME                     STATE     READ WRITE CKSUM
        tank                     DEGRADED     0     0     0
          draid2:8d:24c:1s-0     DEGRADED     0     0     0
            sda                  ONLINE       0     0     0
            sdb                  ONLINE       0     0     0
            sdc                  FAULTED      0     0     0  too many errors
            sdd                  ONLINE       0     0     0

Signification : La chaîne dRAID encode data/parity/enfants/spares. Les formats diffèrent légèrement selon les plateformes, mais l’essentiel :
vous pouvez voir le niveau de parité (draid2) et qu’il y a de la capacité de spare (1s).

Décision : Vérifiez que le niveau de parité correspond à votre appétit pour le risque. Si vous avez construit dRAID1 pour « capacité pas chère », acceptez que les opérations seront corsées.

Tâche 4 : Vérifier erreurs silencieuses de données vs erreurs de périphérique

cr0x@server:~$ sudo zpool status -xv tank
pool 'tank' is degraded
status: One or more devices is currently being resilvered.
errors: No known data errors

Signification : « No known data errors » signifie que ZFS n’a pas détecté de perte d’intégrité checksum des blocs stockés.
Les erreurs de périphérique ne sont pas la même chose que des données corrompues, mais elles peuvent devenir des données corrompues si vous manquez de parité.

Décision : S’il y a des erreurs de données connues, cessez les débats ; escaladez. Vous pourriez devoir restaurer depuis une sauvegarde pour les objets affectés.

Tâche 5 : Trouver le périphérique défaillant par identifiant persistant (pas /dev/sdX)

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sdc|ata|wwn' | head
lrwxrwxrwx 1 root root  9 Dec 26 01:58 ata-WDC_WD140EDGZ-11B2DA0_9KJ3ABCD -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 01:58 wwn-0x5000cca2b3c4d5e6 -> ../../sdc

Signification : /dev/sdc peut changer après un reboot. by-id et wwn sont stables et devraient être ce que votre zpool utilise.

Décision : Si votre pool a été construit avec des chemins /dev/sdX, planifiez une correction. Ce n’est pas « si » ça vous posera problème, c’est « quand ».

Tâche 6 : Inspecter les logs noyau pour resets de lien et problèmes d’enclosure

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata|sas|scsi|reset|timeout|I/O error' | tail -n 15
[Thu Dec 26 01:56:09 2025] sd 4:0:12:0: [sdc] tag#198 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Thu Dec 26 01:56:09 2025] ata12: hard resetting link
[Thu Dec 26 01:56:10 2025] ata12: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Thu Dec 26 01:56:12 2025] blk_update_request: I/O error, dev sdc, sector 1827342336 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Signification : Les timeouts et resets de lien impliquent souvent le câblage, le backplane, le HBA ou l’expander — pas seulement le disque.

Décision : Si plusieurs disques sur le même chemin montrent des resets, suspendez le réflexe « remplacer le disque » et investiguez le chemin d’enclosure.

Tâche 7 : Mesurer la pression I/O en temps réel pendant la reconstruction

cr0x@server:~$ iostat -x 2 5
Linux 6.6.0 (server)   12/26/2025  _x86_64_  (64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    6.92    9.40    0.00   71.58

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda              85.0    42.0   160.0    52.0     254.0      9.2   78.0     62.0    110.0   4.1   98.0
sdb              81.0    39.0   158.0    49.0     255.0      8.8   74.0     60.0    105.0   4.0   97.0
sdd              83.0    40.0   159.0    50.0     253.0      8.9   76.0     61.0    108.0   4.0   98.0

Signification : Les disques sont proches de 100% d’utilisation avec un await élevé. C’est attendu pendant une récupération agressive, mais cela dégradera la latence.

Décision : Si c’est un niveau sensible à la latence, vous limitez la reconstruction (voir tâches ci-dessous) ou déplacez la charge.

Tâche 8 : Surveiller les I/O par vdev ZFS et le comportement du resilver

cr0x@server:~$ sudo zpool iostat -v tank 2 3
                                   capacity     operations     bandwidth
pool                             alloc   free   read  write   read  write
-------------------------------  -----  -----  -----  -----  -----  -----
tank                              141T    77T  3.10K  1.20K  1.45G   620M
  draid2:8d:24c:1s-0              141T    77T  3.10K  1.20K  1.45G   620M
    sda                               -      -    130     55    62M    27M
    sdb                               -      -    128     54    61M    26M
    sdd                               -      -    129     55    61M    27M
-------------------------------  -----  -----  -----  -----  -----  -----

Signification : Vous pouvez voir la reconstruction répartir les E/S sur les membres. C’est la signature opérationnelle du sparing distribué : plusieurs périphériques travaillent.

Décision : Si un disque est loin derrière les autres, suspectez un périphérique lent, un chemin dégradé ou un comportement SMR. Investiguer avant qu’il ne devienne le nouveau goulot.

Tâche 9 : Confirmer la compression et recordsize au niveau dataset (impacts sur la récupération)

cr0x@server:~$ sudo zfs get -o name,property,value -s local,received compression,recordsize tank/data
NAME       PROPERTY     VALUE
tank/data  compression  zstd
tank/data  recordsize   1M

Signification : Un recordsize large et la compression peuvent affecter la quantité d’I/O physique que la reconstruction doit toucher, ainsi que le coût CPU de l’interaction parité/compression.

Décision : Si le CPU est saturé durant la récupération, considérez si un niveau de compression trop agressif rend la reconstruction liée au CPU.

Tâche 10 : Vérifier le chevauchement scrub/resilver (douleur auto-infligée)

cr0x@server:~$ sudo zpool status tank | egrep -i 'scan:|scrub|resilver'
  scan: resilver in progress since Thu Dec 26 02:01:11 2025
        1.23T scanned at 1.8G/s, 620G issued at 900M/s, 14.2T total

Signification : Si un scrub tourne pendant un resilver/reconstruction, vous exécutez deux opérations d’intégrité coûteuses en même temps.

Décision : Ne pas chevaucher sauf raison ; si un scrub a démarré automatiquement, suspendez-le (tâche 11).

Tâche 11 : Mettre en pause un scrub pour réduire la contention (quand approprié)

cr0x@server:~$ sudo zpool scrub -p tank

Signification : Cela met en pause un scrub en cours sur de nombreuses plateformes. Le comportement dépend de la version d’OpenZFS et de l’intégration OS.

Décision : Si vous êtes en reconstruction suite à une panne, priorisez l’opération qui restaure la redondance d’abord. Reprenez le scrub après.

Tâche 12 : Mettre un périphérique en OFFLINE pour arrêter l’aggravation du problème

cr0x@server:~$ sudo zpool offline tank sdc

Signification : OFFLINE indique à ZFS d’arrêter d’essayer ce périphérique. Pour un chemin qui flappe, cela peut stabiliser le pool et permettre à la reconstruction d’avancer de façon prévisible.

Décision : Si le périphérique timeoute de façon intermittente, l’offliner peut prévenir des retries répétés et des tempêtes de latence. Mais assurez-vous que la tolérance de parité suffit.

Tâche 13 : Remettre un périphérique en ONLINE après correction du chemin

cr0x@server:~$ sudo zpool online tank sdc

Signification : ONLINE permet à ZFS de réutiliser le périphérique. S’il était en réalité sain et que le problème venait du câblage, cela peut réduire la charge de récupération.

Décision : Ne le faites qu’après avoir corrigé le problème sous-jacent du chemin, sinon vous réintroduirez du flapping et perdrez du temps.

Tâche 14 : Remplacer un disque défaillant en utilisant un chemin by-id stable

cr0x@server:~$ sudo zpool replace tank sdc /dev/disk/by-id/wwn-0x5000cca2b3c4d5ff

Signification : Cela indique à ZFS d’attacher le nouveau périphérique comme remplaçant de l’ancien. Le pool va resilver/rééquilibrer selon les besoins.

Décision : Si vous n’utilisez pas by-id/wwn, vous êtes à un reboot de remplacer le mauvais disque. Utilisez des identifiants stables. Toujours.

Tâche 15 : Vérifier que ZFS n’est pas bloqué sur le CPU (coûts parité/checksum)

cr0x@server:~$ mpstat -P ALL 2 2 | head -n 15
Linux 6.6.0 (server)  12/26/2025  _x86_64_  (64 CPU)

12:14:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
12:14:03 PM  all  28.10   0.00  14.90    6.50  0.00   1.20    0.00  49.30
12:14:03 PM    0  92.00   0.00   6.00    0.00  0.00   0.00    0.00   2.00
12:14:03 PM    1  88.50   0.00  10.00    0.00  0.00   0.00    0.00   1.50

Signification : Si quelques CPU sont saturés tandis que les disques ne le sont pas, vous pourriez être lié au CPU (checksum, parité, compression).

Décision : Si CPU-bound durant la récupération, réduisez temporairement les charges concurrentes et révisez les réglages de compression pour le futur design.

Tâche 16 : Vérifier la pression mémoire (thrash ARC change la latence)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           512Gi       396Gi        22Gi       5.2Gi        94Gi       105Gi
Swap:           16Gi       0.5Gi        15Gi

Signification : Si « available » s’effondre et que le swap augmente, votre système peut thrash, transformant la reconstruction en carnaval de latence.

Décision : Si swap utilisé, stoppez les consommateurs mémoire non essentiels et considérez des limites ARC (avec prudence) sur les systèmes où ZFS concurrence les applications.

Tâche 17 : Valider que le disque de remplacement est sain avant de lui faire confiance

cr0x@server:~$ sudo smartctl -a /dev/disk/by-id/wwn-0x5000cca2b3c4d5ff | egrep -i 'Model|Serial|Reallocated|Pending|Offline_Uncorrectable|SMART overall'
Device Model:     WDC WD140EDGZ-11B2DA0
Serial Number:    9KJ3WXYZ
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct     0
Current_Pending_Sector    0
Offline_Uncorrectable     0

Signification : Vous vérifiez les signaux évidents de panne précoce. Un disque « neuf » avec des secteurs pending n’est pas « neuf », c’est « incident futur ».

Décision : Si les attributs SMART sont mauvais, RMAez-le maintenant. Ne laissez pas le resilver être votre test de burn-in.

Tâche 18 : Confirmer que vous n’êtes pas discrètement à court de marge de spare (contrôle opérationnel)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
status: One or more distributed spares have been consumed.
action: Replace the failed device and allow the pool to heal to restore spare space.
  scan: resilvered 14.2T in 05:01:22 with 0 errors on Thu Dec 26 07:02:33 2025
config:

        NAME                     STATE     READ WRITE CKSUM
        tank                     ONLINE       0     0     0
          draid2:8d:24c:1s-0     ONLINE       0     0     0
            sda                  ONLINE       0     0     0
            sdb                  ONLINE       0     0     0
            sdd                  ONLINE       0     0     0
            ...

Signification : C’est le message spécifique dRAID « n’oubliez pas la dernière mile » que vous devriez traiter comme un ticket, pas comme une suggestion.

Décision : Planifiez le remplacement physique si cela n’a pas encore été fait, et suivez cet état jusqu’à ce qu’il disparaisse. Fonctionner en permanence avec des spares consommés, c’est s’exposer à une suite.

Plaquette de diagnostic rapide

Quand la reconstruction est lente ou que la performance est terrible, il faut trouver le vrai goulot vite. Pas « éventuellement ».
Voici l’ordre qui gagne en général.

1) Commencez par la vérité : que pense ZFS qu’il se passe ?

zpool status -v tank : Y a-t-il un resilver/reconstruction ? Progresse-t-il ? Des erreurs de données ?
zpool iostat -v tank 2 : Tous les disques participent-ils équitablement ? Un laggard évident ?

Si ZFS montre des erreurs en hausse, arrêtez les optimisations et stabilisez. Une défaillance rapide reste une défaillance.

2) Décidez si vous êtes lié disque, chemin ou CPU

iostat -x 2 : Si %util proche de 100% avec await élevé partout, vous êtes disk-bound (attendu, mais peut nécessiter throttling).
dmesg -T : Si vous voyez resets/timeouts, vous êtes path-bound. Corrigez câblage/backplane/HBA avant de toucher aux réglages ZFS.
mpstat : Si les CPU sont saturés tandis que les disques ne le sont pas, vous êtes CPU-bound (parité/checksum/compression).

3) Cherchez la contention auto-infligée

Scrub chevauchant un resilver.
Sauvegardes qui martèlent le pool pendant la récupération.
Concurrence applicative non bornée (restaurations parallèles, réindexations, etc.).

Si votre organisation ne peut pas réduire la charge pendant la récupération, concevez pour cette réalité : plus de parité, domaines de panne plus petits, ou une tier différente pour le trafic critique en latence.

4) Validez l’hypothèse « un disque lent »

dRAID parallélise le travail, mais il peut toujours être tenu en otage par un disque qui se fige périodiquement.
Dans de larges vdevs, un lecteur ayant des stalls de 30 secondes peut créer une latence de queue à l’échelle du pool.

Vérifiez smartctl pour erreurs médias.
Vérifiez les logs pour resets de lien.
Comparez les débits par disque dans zpool iostat -v.

5) Ensuite seulement, envisagez le tuning

Le tuning est en dernier parce que c’est la manière la plus facile de se sentir productif tout en rendant le système moins prévisible.
Si vous touchez aux réglages, faites-le avec un plan de rollback et une métrique de succès claire (ETA, SLO de latence, ou les deux).

Erreurs courantes : symptôme → cause → correction

Erreur 1 : « Resilver terminé, donc on est hors de danger »

Symptôme : Le pool est ONLINE, mais le statut mentionne des spares distribués consommés ; des semaines plus tard, une autre panne disque devient une crise.

Cause : Traiter la reconstruction dans des spares distribués comme l’état final, au lieu d’un filet de sécurité temporaire.

Correction : Remplacez rapidement le disque défaillant et vérifiez que l’avertissement « distributed spares consumed » disparaît. Suivez-le comme élément de risque.

Erreur 2 : Rebuild lent imputé à ZFS, alors que c’est l’enclosure

Symptôme : Le débit de récupération varie fortement ; dmesg montre des resets ; plusieurs disques affichent des timeouts.

Cause : Câble SAS défectueux, expander, backplane, ou firmware HBA marginal. La récupération met à nu le chemin.

Correction : Corrigez d’abord le transport. Changez les câbles, vérifiez l’état de l’expander, assurez la cohérence des firmwares, puis relancez la reconstruction.

Erreur 3 : Reconstruction trop agressive en période de charge

Symptôme : Le rebuild se termine vite mais la latence applicative est terrible ; timeouts côté utilisateur.

Cause : Ne viser que le temps de rebuild. La reconstruction parallèle peut consommer l’ensemble des spindles.

Correction : Throttlez la récupération pendant les heures d’activité et accélérez hors-pointe. Si possible, ajustez la priorité scan/resilver prudemment.

Erreur 4 : Utiliser /dev/sdX dans les pools de production

Symptôme : Après reboot ou maintenance, les périphériques sont permutés ; le remplacement cible le mauvais disque.

Cause : Noms de périphériques non persistants.

Correction : Utilisez /dev/disk/by-id ou les chemins WWN pour les membres de vdev et les remplacements. Documentez la cartographie vers les baies.

Erreur 5 : Choisir la largeur dRAID pour la capacité brute, pas pour le comportement de récupération

Symptôme : La reconstruction martèle l’ensemble du pool ; l’impact performance est inacceptable ; la fenêtre de risque reste effrayante.

Cause : Groupes dRAID trop larges pour la charge et le hardware. Plus large n’est pas toujours mieux.

Correction : Réduisez la largeur du domaine de panne (plus de vdevs, moins de disques par groupe dRAID), ou déplacez les charges sensibles à la latence vers des tiers SSD/NVMe.

Erreur 6 : Oublier qu’un disque instable peut imiter un « rebuild lent »

Symptôme : L’ETA augmente ; le taux de scan baisse ; un périphérique montre des erreurs intermittentes mais reste ONLINE.

Cause : Disque marginal qui n’est pas encore complètement mort ; ZFS retente, ce qui tue le débit.

Correction : Remplacez proactivement le disque marginal. Ne l’attendez pas pour échouer proprement.

Erreur 7 : Laisser les scrubs se chevaucher avec la récupération

Symptôme : Scrub et resilver apparaissent ensemble ; la bande passante est divisée ; tout est plus lent.

Cause : Le planning automatique de scrub ne tient pas compte des fenêtres de récupération.

Correction : Mettez le scrub en pause pendant la récupération, puis reprenez-le. Ajustez l’automatisation pour détecter et différer quand un resilver est en cours.

Blague #2 : La seule chose plus rapide qu’un rebuild dRAID est l’email de la finance demandant pourquoi vous avez besoin « d’autant de disques ».

Listes de vérification / plan pas-à-pas

Checklist A : Quand un disque tombe en panne dans un pool dRAID

Confirmer la tolérance de parité et l’état du pool.
Lancez zpool status -v. Si vous êtes au-delà de la tolérance de parité, arrêtez-vous : vous êtes en zone de perte de données.
Vérifier les erreurs de données.
Utilisez zpool status -xv. S’il existe des erreurs de données connues, ouvrez un incident et planifiez une restauration.
Valider que ce n’est pas un problème de chemin.
Consultez dmesg -T pour resets/timeouts. Si plusieurs disques sur le même chemin montrent ça, investiguez l’enclosure/HBA d’abord.
Stabiliser les périphériques qui flappent.
Si un périphérique timeoute de façon intermittente, envisagez zpool offline pour arrêter le thrash, si la parité le permet.
Surveiller la progression et l’impact.
Utilisez zpool iostat -v 2 et iostat -x 2. Décidez s’il faut throttler ou déplacer la charge.
Remplacer le matériel de façon délibérée.
Remplacez le disque défaillant en utilisant by-id/WWN. Évitez de remplacer plusieurs disques en même temps sauf si vous aimez les probabilités.
Confirmer la restauration des spares.
Après la reconstruction, assurez-vous que l’avertissement « distributed spares consumed » disparaît après remplacement et guérison.

Checklist B : Décisions en phase de conception qui rendent la récupération dRAID ennuyeuse

Choisissez la parité selon votre réalité de défaillance. dRAID2 est le baseline pragmatique pour les grands pools HDD. dRAID1 est pour ceux qui aiment les cas limites.
Ne rendez pas les domaines de panne trop larges. Les groupes larges se reconstruisent vite mais peuvent créer une contention à l’échelle du pool. Équilibrez vitesse de récupération et latence de service.
Standardisez le hardware. Mélanger modèles de disques et révisions de firmware transforme des disques « identiques » en éléments très dissemblables sous charge.
Cartographiez baie → WWN. Gardez un mapping pour remplacer le bon disque physique sans danse interprétative.
Automatisez la détection. Alertez sur DEGRADED, sur spares distribués consommés, et sur la croissance de l’ETA de reconstruction (bon prédicteur d’un problème).
Entraînez-vous aux remplacements. La première fois que vous exécutez zpool replace ne devrait pas être pendant une panne.

Checklist C : Vérification post-récupération

Exécutez zpool status -v et confirmez que le scan montre « with 0 errors ».
Assurez-vous qu’il ne reste plus d’avertissement « distributed spares consumed » après le remplacement physique et la guérison.
Vérifiez SMART sur le nouveau disque et au moins un disque « voisin » ; les pannes ont souvent tendance à se regrouper.
Revoir les logs dmesg depuis l’incident pour les erreurs de chemin ; corrigez les problèmes de transport avant que la prochaine panne ne les teste à nouveau.
Reprenez le scrub si vous l’aviez mis en pause, mais faites-le pendant une fenêtre calme.

FAQ

1) Est-ce que dRAID élimine le besoin de disques hot spare ?

Il réduit la dépendance à un spare dédié unique pour la récupération immédiate, car l’espace de spare est distribué.
Vous avez toujours besoin d’un plan de remplacement physique. Les spares distribués sont une marge temporaire, pas un substitut permanent au matériel de remplacement.

2) La récupération dRAID est-elle toujours plus rapide que RAIDZ ?

Souvent plus rapide en temps écoulé pour de grands pools HDD car les écritures de reconstruction sont parallélisées. Pas toujours « moins impactante ».
Vous pouvez passer de « un disque saturé » à « tous les disques occupés », ce qui peut être pire pour les charges sensibles à la latence.

3) Que signifie vraiment « distributed spares consumed » ?

Cela signifie que la reconstruction a utilisé des slices de spare réservées dans le vdev dRAID pour reconstituer les données/parité manquantes.
Vous avez récupéré la redondance mais dépensé de la capacité de spare. Remplacez le disque défaillant pour restaurer la marge de spare.

4) Puis-je faire tourner un pool indéfiniment avec des spares distribués consommés ?

Vous le pouvez, comme on peut faire tourner un serveur indéfiniment avec un RAID dégradé : jusqu’au moment où vous ne le pouvez plus.
La posture opérationnelle correcte est de le traiter comme un risque limité dans le temps et de planifier le remplacement.

5) Si un disque flappe, dois-je l’offliner immédiatement ?

Si vous êtes dans la tolérance de parité et que le flapping cause des timeouts répétés, l’offliner peut réduire le chaos et accélérer la récupération.
Si l’offline dépasserait la tolérance de parité, stabilisez d’abord la couche transport et évitez d’empirer la situation.

6) Pourquoi la reconstruction dégrade-t-elle la performance même si elle est « distribuée » ?

Parce que vous effectuez des lectures supplémentaires (pour reconstruire) et des écritures supplémentaires (pour stocker les slices reconstruites), plus le calcul de parité.
La distribution augmente le parallélisme ; elle n’enlève pas le travail. Elle le répartit juste.

7) Dois-je limiter la récupération pour protéger la latence applicative ?

Oui, si le niveau a des SLOs de latence. Restaurez la redondance, mais pas en sacrifiant le service en production via la latence queue.
Limitez pendant les heures de pointe et accélérez hors-pointe. L’objectif est un service sûr, pas seulement un bel ETA.

8) Quelle est la première chose à vérifier quand la récupération est plus lente que prévu ?

Vérifiez les erreurs de transport dans les logs noyau et cherchez un disque lent dans zpool iostat -v.
En pratique, « ZFS est lent » signifie souvent « un chemin SAS est malade » ou « un disque se fige ».

9) Est-ce que dRAID change la manière de dimensionner la parité (dRAID1/2/3) ?

Il change la dynamique de récupération, pas la mathématique de la tolérance de défaillance.
Les grands pools avec de gros disques bénéficient de plus de parité car la probabilité d’une seconde défaillance pendant la fenêtre de reconstruction n’est pas négligeable.

10) Comment expliquer le sparing dRAID à la direction ?

« Nous dépensons un peu de capacité à l’avance pour réduire le temps pendant lequel nous sommes vulnérables après une panne. »
Si vous voulez une phrase courte : c’est une assurance qui se paie en moins d’heures de risque dégradé.

Conclusion : prochaines étapes rentables

Les spares distribués de dRAID ne sont pas un argument marketing ; ce sont une réponse pratique aux réalités modernes du disque.
Ils peuvent réduire la fenêtre dangereuse après une panne en parallélisant la reconstruction.
Ils changent aussi ce que signifie « terminé » : la reconstruction peut se finir sans disque de remplacement, mais vous opérez sur une marge de spare dépensée jusqu’à ce que vous remplaciez le matériel et laissiez le vdev guérir.

Trois prochaines étapes qui rendent la récupération dRAID ennuyeuse — dans le meilleur sens :

Operationalisez la récupération en deux phases. Suivez « distributed spares consumed » comme ticket avec un SLA, pas comme une note de bas de page.
Bâtissez l’habitude du diagnostic rapide. Vue ZFS, puis disques/chemin, puis CPU/mémoire, puis tuning. Dans cet ordre.
Entraînez-vous aux remplacements. Le meilleur moment pour apprendre votre mapping by-id n’est pas à 3h du matin avec un pool dégradé.

Une idée paraphrasée qui mérite un post-it, attribuée à Gene Kim (auteur DevOps/ops) : améliorez le travail quotidien pour que les incidents deviennent plus rares et que les récupérations deviennent routinières.