Il y a une raison pour laquelle RAIDZ2 revient souvent dans les discussions sur « l’infrastructure ennuyeuse qui survive ». Ce n’est pas à la mode, ce n’est pas tape-à-l’œil, et ça ne gagnera pas les courses de benchmarks opposant des mirrors pour des I/O aléatoires de petite taille. Ce que ça fait — quand vous le dimensionnez raisonnablement et que vous l’exploitez sérieusement — c’est garder vos données debout quand un disque meurt un mardi et qu’un autre commence à montrer des signes la veille suivante.
Ceci est un guide de terrain du point de vue de quelqu’un qui a vu des pools se dégrader en temps réel, qui s’est disputé avec les achats à propos de « achetez juste des disques plus gros », et qui a appris que la différence entre une nuit d’astreinte calme et un incident marquant la carrière est souvent une seule hypothèse émise des mois plus tôt.
Ce qu’est réellement RAIDZ2 (et ce qu’il n’est pas)
RAIDZ2 est le RAID à double parité de ZFS. En termes simples : au sein d’un unique vdev RAIDZ, vous pouvez perdre deux disques et le vdev peut toujours reconstruire les données. ZFS répartit les données sur tous les disques de ce vdev, avec la parité distribuée. Quand vous construisez un pool à partir d’un ou plusieurs vdevs RAIDZ2, la disponibilité du pool est celle de ses vdevs : perdre un vdev, c’est perdre le pool.
RAIDZ2 n’est pas « deux disques de sécurité quoi qu’il arrive ». C’est une protection contre la perte de périphérique et les secteurs illisibles pendant la reconstruction — jusqu’à un certain point. Il ne vous protège pas contre :
- la suppression accidentelle (utilisez des snapshots, de la réplication, des sauvegardes)
- la corruption au niveau applicatif (utilisez des checksums, et encore des snapshots/réplication)
- les mensonges du contrôleur ou le chaos de câblage (surveillez, testez et gardez le firmware cohérent)
- l’erreur humaine (malheureusement, toujours un mode de défaillance majeur)
En exploitation, les gens confondent « niveau RAID » et « sécurité des données ». RAIDZ2 est une couche. C’est une couche solide, mais ce n’est pas toute l’histoire. Si vous ne retenez qu’une chose : RAIDZ2 vous garde en ligne pendant certains incidents matériels ; il ne vous garde pas intact dans toutes les situations.
Blague n°1 (courte, pertinente) : RAIDZ2, c’est comme emporter une roue de secours et une bombe anti-crevaison — utile. Ça n’aide pas si vous roulez dans un lac.
Pourquoi RAIDZ2 est le compromis idéal (généralement)
La plupart des conceptions de stockage sont une négociation entre quatre parties qui ne s’aiment pas : capacité, performance, résilience et budget. Les mirrors l’emportent sur les IOPS et le comportement de reconstruction, mais vous coûtent 50 % de capacité brute. RAIDZ1 est tentant jusqu’à ce que vous l’exploitiez avec des tailles de disque modernes et des taux URE réels ; vous ne voulez pas apprendre cette leçon pendant une fenêtre de resilver. RAIDZ3 est robuste mais commence à ressembler à une taxe que votre profil de risque ne justifie peut-être pas (sauf si vous gérez de très gros vdevs ou des disques très volumineux dans des charges intensives).
RAIDZ2 se situe souvent au milieu : vous « consommez » deux disques par vdev pour la parité, ce qui est un overhead relativement fixe à mesure que vous augmentez la largeur du vdev. Dans un RAIDZ2 à 8 disques, vous êtes à 75 % d’utilisable (avant overhead ZFS). Dans un RAIDZ2 à 10 disques, 80 %. Voilà l’histoire de la capacité.
L’histoire de la survie est plus subtile. Les disques modernes sont grands, et la reconstruction/resilver est une longue marche, pas un sprint. Pendant cette période, vous êtes exposé : chaque lecture supplémentaire est une chance de découvrir une erreur latente ; chaque vibration ou événement thermique est une chance qu’un autre disque devienne bizarre. RAIDZ2 est souvent le point où vous pouvez tolérer une seconde surprise sans convertir une simple contrariété en catastrophe.
La performance surprend souvent. RAIDZ2 peut fournir un excellent débit séquentiel — streaming, sauvegardes, stockages d’objets volumineux, workflows médias, scans analytiques — parce que vous utilisez beaucoup de spindles. Mais les petits writes aléatoires sont plus complexes : la parité implique un comportement read-modify-write au niveau du vdev. ZFS a des atténuations (largeur variable des bandes, transaction groups, cache), mais la physique se présente toujours à la réunion.
Ainsi, « compromis idéal » signifie généralement : efficacité de capacité correcte, tolérance à des pannes réalistes, performance acceptable pour des charges mixtes si bien configuré, et pas si cher que les achats commencent à inventer de nouveaux adjectifs.
Faits et contexte historique importants
L’ingénierie du stockage a une longue mémoire, surtout parce que nous répétons les mêmes erreurs avec des nombres plus grands. Quelques faits et points de contexte qui façonnent les décisions sur RAIDZ2 :
- ZFS a été conçu en supposant que les disques mentent. Les checksums bout en bout sont une réponse à la corruption silencieuse suffisamment fréquente pour compter dans les arrays d’entreprise et le matériel grand public.
- RAIDZ existe en partie pour éviter le « write hole RAID-5 ». Le copy-on-write et la sémantique transactionnelle de ZFS changent les modes de défaillance par rapport aux implémentations RAID hardware classiques.
- Les capacités des disques ont crû plus vite que la vitesse de rebuild. Vous pouvez acheter beaucoup de téraoctets à bas prix ; vous ne pouvez pas racheter du temps pendant une reconstruction où vous lisez presque tout le vdev.
- Les mathématiques des URE (unrecoverable read error) sont passées de la théorie aux rapports d’incidents. Ce qui était « peu probable » devient « inévitable » quand vous lisez des dizaines de téraoctets sous contrainte.
- Ashift est devenu un piège professionnel. Les disques Advanced Format (secteur 4K) ont rendu l’alignement 512e/4Kn une chute de performance réelle. ZFS l’enregistre à la création du vdev ; vous ne le changez pas à la légère ensuite.
- La compression LZ4 est devenue la valeur par défaut pour une raison. Sur de nombreuses charges, elle améliore le débit effectif parce que le CPU est plus rapide que vos disques, et vous déplacez moins d’octets.
- Les scrubs étaient autrefois « agréables à avoir ». Avec des pools volumineux, les scrubs sont une découverte proactive des défaillances : vous voulez trouver les mauvais secteurs à VOTRE rythme, pas pendant un resilver.
- Le débat sur la RAM ECC ne meurt jamais. ZFS ne « requiert » pas ECC pour fonctionner, mais les opérateurs en production ont vu des corruptions mémoire provoquer des catastrophes. Le risque dépend de la charge et de la plateforme, mais le nier conduit aux postmortems.
- NVMe a changé l’architecture. Les special vdevs, SLOG et L2ARC peuvent faire grandement évoluer le comportement d’un RAIDZ2, en mieux ou en pire, selon le déploiement.
Décisions de conception qui décident de votre sort
1) Largeur du vdev : combien de disques par RAIDZ2 ?
Le surcoût RAIDZ2 est « deux disques », donc des vdevs plus larges améliorent l’efficacité de capacité. C’est la tentation. Le contrepoids est le domaine de défaillance et le temps de rebuild : un vdev plus large signifie plus de données à lire et plus de disques participants, ce qui augmente à la fois le potentiel de performance et la surface d’erreurs pendant le resilver et le scrub.
En pratique, beaucoup de déploiements en production se situent autour de 6–10 disques par vdev RAIDZ2 pour du stockage à usage général. Des vdevs plus étroits (6–8) sont souvent plus amicaux pour le temps de resilver et la prévisibilité des IOPS ; plus larges (10–12+) sont courants dans les systèmes axés sur le débit où l’on peut tolérer des fenêtres de maintenance plus longues et où la posture de monitoring et de pièces de rechange est mature.
Une règle moins incorrecte qu’elle n’en a l’air : choisissez une largeur que vous pouvez reconstruire dans votre patience opérationnelle, pas celle des slides marketing du vendeur. Si votre rotation d’astreinte panique à un resilver de trois jours, construisez pour un resilver d’un jour. Si vous ne pouvez pas reconstruire rapidement, il vous faut plus de redondance, de meilleurs spares, ou des vdevs plus petits — ou les trois.
2) Combien de vdevs par pool ?
La performance ZFS évolue davantage avec le nombre de vdevs qu’avec le nombre de disques à l’intérieur d’un seul vdev pour beaucoup de patterns d’I/O aléatoires. Deux vdevs RAIDZ2 de 8 disques se comportent généralement mieux pour des charges concurrentes qu’un vdev RAIDZ2 de 16 disques, parce que vous avez deux files d’allocation et d’I/O indépendantes au niveau vdev.
Opérationnellement, plus de vdevs signifie aussi plus de composants et plus d’opportunités de défaillances individuelles — mais ce n’est pas automatiquement pire. Si chaque vdev est plus petit, les resilvers peuvent être plus courts et les domaines de défaillance plus simples à raisonner. L’important est de garder une conception cohérente : vdevs identiques, même ashift, même classe de disques, même firmware, même topologie.
3) Recordsize, volblocksize et forme de la charge
ZFS n’est pas du stockage bloc comme un contrôleur RAID classique ; c’est un système de fichiers et un gestionnaire de volumes avec beaucoup de réglages. Le réglage critique pour les datasets fichiers est recordsize. Un recordsize plus grand peut améliorer le débit en streaming et réduire l’overhead métadonnées ; un recordsize plus petit peut réduire l’amplification de lecture pour les petits reads aléatoires.
Pour les zvols (iSCSI, disques VM), vous vous souciez de volblocksize. Se tromper ici peut créer une amplification d’écriture qui donne l’impression que RAIDZ2 travaille dans la mélasse. Pour le stockage VM, 8K–16K volblocksize est courant ; pour les bases de données, on s’aligne sur la taille de page et les patterns d’accès. La bonne réponse dépend de la charge ; la mauvaise dépend des hypothèses.
4) Compression et checksums : pas optionnels, seulement gérés
La compression (souvent LZ4) est souvent un gain net même quand vous n’avez pas « besoin » d’espace. Elle peut réduire la charge I/O, ce qui réduit la latence et accélère resilver/scrub. Les checksums sont la raison d’être de ZFS ; ne les désactivez pas. Si vous vous inquiétez du CPU, profilez — ne devinez pas.
5) Special vdevs, SLOG et L2ARC : outils puissants, pas décorations
Ajouter un special vdev (métadonnées et petits blocs sur SSD) peut transformer des pools RAIDZ2 servant beaucoup de petits fichiers ou des charges riches en métadonnées. Il peut aussi devenir un point unique de défaillance du pool si vous le construisez sans redondance. Autrement dit : ça peut être un sauveur de performance ou un générateur de panne très coûteuse.
SLOG (dispositif de log séparé) aide les écritures synchrones seulement si vous avez réellement des écritures synchrones. Si votre charge est async (commun pour beaucoup de partages de fichiers), un SLOG ne fait rien. Un L2ARC peut aider les charges de lecture avec un working set plus grand que la RAM, mais ce n’est pas magique ; c’est un cache avec son propre overhead.
Blague n°2 (courte, pertinente) : Un SLOG pour une charge async, c’est comme installer un turbo sur un caddie — impressionnant, mais vous le poussez toujours à la main.
Réalité des performances : débit, IOPS, latence
RAIDZ2 est souvent jugé injustement par un benchmark qui ne correspond pas à la production. Il est aussi parfois déployé dans des charges où les mirrors auraient été le bon choix. Séparons les modes.
Lectures et écritures séquentielles
Si vous poussez des blocs larges — sauvegardes, médias, archives, flux de réplication — RAIDZ2 peut être excellent. Vous obtenez un débit agrégé de plusieurs disques, et l’overhead parité devient une fraction plus petite du travail parce que vous écrivez plus souvent des stripes complets.
Où il trébuche, c’est quand votre charge « séquentielle » n’est pas vraiment séquentielle : petits writes synchrones, datasets fragmentés, ou beaucoup d’écrivains concurrents peuvent transformer le pattern en quelque chose de plus proche d’un I/O aléatoire. Le comportement des transaction groups de ZFS peut masquer une partie de ça, jusqu’à ce qu’il ne puisse plus.
Lectures aléatoires
Les lectures aléatoires peuvent bien se passer si elles sont cachées. L’ARC (dans la RAM) est votre première ligne de défense. Si votre working set tient en cache, la performance RAIDZ2 dépend essentiellement de la vitesse du CPU et de la RAM, et les disques restent majoritairement au repos.
Si ce n’est pas le cas, vous êtes à la merci de la latence des spindles. Plus de vdevs aide parce que vous avez plus de chemins I/O indépendants. Des vdevs RAIDZ plus larges ne vous donnent pas plus d’IOPS comme le ferait l’ajout de vdevs ; ils vous donnent surtout plus de débit par vdev et plus d’efficacité de capacité.
Écritures aléatoires et taxe de parité
Les écritures aléatoires sur RAIDZ2 peuvent être coûteuses parce que la parité doit être mise à jour. ZFS réalise des stripes de largeur variable et peut éviter le pire comportement du RAID classique, mais il y a toujours du travail. Les petits writes peuvent nécessiter de lire l’ancien data/parity puis d’écrire le nouveau data/parity. C’est des I/O supplémentaires et de la latence en plus.
En pratique, les charges lourdes en écritures aléatoires (fermes de VM avec guests actifs, logs de base de données, petits writes synchrones) préfèrent souvent des mirrors, ou RAIDZ2 plus un special vdev et un tuning soigné, ou une approche hybride : mirrors pour les données chaudes, RAIDZ2 pour les tiers de capacité.
Latence : la métrique qui coûte des carrières
Le débit se vend facilement ; la latence, c’est ce que les utilisateurs remarquent. Les pools RAIDZ2 sous pression peuvent présenter des « cliffs de latence » durant les scrubs, resilvers, ou quand le pool est trop plein. ZFS fait de son mieux, mais si vos disques sont saturés et vos files d’attente montent, la latence suit.
Le travail de l’opérateur est de garder suffisamment de marge pour que les événements de maintenance ne deviennent pas des incidents visibles par les clients. Cela signifie : ne pas exploiter des pools à 95 % puis être surpris quand les performances chutent. ZFS n’est pas unique ici ; il est simplement honnête à ce sujet.
Opérations qui maintiennent RAIDZ2 en bonne santé
La conception RAIDZ2 vous amène à « survivable ». Les opérations vous amènent à « boring reliable ». La différence, c’est la routine.
Scrubs : la douleur contrôlée bat la douleur surprise
Les scrubs lisent toutes les données et vérifient les checksums. Ils font remonter les erreurs de secteurs latentes alors que vous avez encore de la redondance. Si vous sautez les scrubs, vous pariez que votre première découverte de mauvais secteurs se fera pendant un resilver — quand vous êtes déjà stressé et qu’un disque manque déjà.
Planifiez les scrubs selon la taille du pool et la charge. Mensuel est courant ; les pools plus grands et plus froids scrubbent parfois moins souvent ; les pools critiques scrubbent plus souvent. Le bon calendrier est celui qui se termine de façon fiable et qui ne foule pas votre budget de latence.
Comportement de resilver : les reconstructions séquentielles sont un mythe
Les rebuilds RAID classiques consistaient essentiellement à « lire le disque entier ». Le resilver ZFS est plus chirurgical : il reconstruit seulement les blocs alloués. C’est génial pour des pools peu remplis. Mais dans beaucoup de réalités d’entreprise, les pools sont… pleins. Et « blocs alloués » devient « la majeure partie du disque ».
Préparez-vous comme si les resilvers allaient être longs. Assurez-vous de pouvoir détecter et remplacer rapidement les disques défaillants. Gardez des spares ou du moins des chemins d’approvisionnement rapides. En exploitation, le temps de remplacement est une métrique de fiabilité.
Ne considérez pas SMART comme un voyant magique
Les données SMART sont utiles, mais ce n’est pas une garantie. Certains disques échouent bruyamment ; d’autres renvoient simplement des lectures lentes, des timeouts, et des bizarreries qui apparaissent sous forme de messages kernel et d’erreurs de checksum ZFS. Surveillez les compteurs d’erreurs dans zpool status et les logs système. Ce sont les symptômes qui importent pour ZFS.
Gardez les pools en dessous de la zone dangereuse
À mesure que les pools se remplissent, l’allocation devient plus difficile, la fragmentation augmente, et l’amplification d’écriture monte. Le résultat est des performances plus lentes et des resilvers/scrubs plus longs. Une cible opérationnelle courante est de garder les pools en dessous d’environ 80 % pour des charges mixtes, parfois moins si vous tenez à une latence cohérente.
Ce n’est pas de la superstition. C’est de la géométrie et de la planification. Quand l’espace libre devient fragmenté, ZFS a moins de bons choix, donc il fait plus souvent des choix moins bons.
Trois mini-récits du monde de l’entreprise
Mini-récit 1 : un incident causé par une mauvaise hypothèse
L’hypothèse : « RAIDZ2 signifie qu’on peut perdre deux disques, donc on est en sécurité pendant la maintenance. » La configuration était un cluster de virtualisation de taille moyenne stockant des disques VM sur un pool RAIDZ2. L’équipe a planifié une mise à jour firmware en rolling pour le HBA et le backplane des disques. Ils l’avaient déjà fait sur des systèmes plus petits sans incident notable.
Ils ont mis à jour un hôte, redémarré, et le pool est revenu dégradé : un disque ne s’est pas répertorié. Pas de panique. « On peut perdre deux disques », a dit quelqu’un, et la fenêtre de maintenance a continué. Puis le deuxième hôte a redémarré, et un chemin différent vers un disque a commencé à flapper. Le pool est passé de dégradé à très malheureux — timeouts, puis une seconde défaillance de périphérique.
À ce stade, les probabilités ont changé. RAIDZ2 peut perdre deux périphériques, mais il ne peut pas en perdre deux tout en survivant à un troisième périphérique qui n’est « pas mort, juste lent et qui timeoute », plus un contrôleur qui renégocie des liens. Le pool n’est pas mort instantanément, mais les workloads VM ont fait ce que font les workloads VM sous latence stockage : ils ont inondé la file d’I/O, puis le cluster a commencé à isoler des nœuds pour « stockage non réactif ».
Le postmortem ne portait pas sur ZFS en tant que mauvais outil. Il portait sur la mauvaise hypothèse : « la perte disque est binaire ». Dans les systèmes réels, les défaillances sont sales : connectivité partielle, tempêtes de timeouts, et comportements « ça marche après reboot ». La correction opérationnelle n’a pas été d’abandonner RAIDZ2 ; c’a été d’arrêter de faire une maintenance multi-hôtes sans plan de validation par étapes, et de traiter « dégradé » comme « nous sommes à un mauvais jour d’une très longue semaine ».
Mini-récit 2 : une optimisation qui s’est retournée contre eux
L’objectif : rendre un pool RAIDZ2 « plus rapide » pour de petits fichiers sur une ferme de build. L’équipe disposait d’un pool de HDD et a décidé d’ajouter un special vdev sur un seul NVMe très rapide. Les benchmarks étaient impressionnants. Les opérations metadata ont décollé. Les développeurs ont applaudi. Quelqu’un a écrit « problème résolu » dans le ticket et l’a clôturé en confiance.
Puis est venu le moment discret : quelques mois plus tard, le NVMe a commencé à générer des erreurs media. Pas catastrophiques au début — juste quelques-unes. Mais le special vdev n’était pas mirroré. Dans ZFS, si un special vdev contient les métadonnées et les petits blocs, il n’est pas optionnel : le perdre peut vous faire perdre le pool, car vous ne pouvez pas retrouver vos données sans les métadonnées. Le pool est passé de « rapide » à « crise existentielle » en une seule astreinte.
La récupération a été douloureuse : ils avaient de la réplication, mais pas assez récente pour satisfaire tout le monde. Certains artefacts ont été reconstruits ; d’autres ont été retéléchargés ; d’autres recréés. La cause racine n’était pas « NVMe est peu fiable ». La cause racine était de traiter un special vdev comme un cache. Ce n’en est pas un ; c’est un niveau de stockage.
La correction a été simple et ennuyeuse : mirrorer le special vdev, le surveiller comme un citoyen de première classe, et le dimensionner correctement. La performance est revenue, et le sommeil aussi. La leçon : quand vous ajoutez un outil puissant au RAIDZ2, lisez l’étiquette de sécurité.
Mini-récit 3 : une pratique ennuyeuse mais correcte qui a sauvé la journée
La pratique : scrubs mensuels et alertes sur les erreurs de checksum, plus une règle permanente que « toute erreur de checksum ouvre un ticket ». Ce n’était pas glamour. Ça n’a pas eu d’applaudissements dans la planification trimestrielle. C’était le genre de discipline que les gens appellent « paranoïaque » jusqu’à ce qu’ils l’appellent « leadership ».
Une semaine, une alerte s’est déclenchée : une poignée d’erreurs de checksum sur un disque pendant un scrub. Le pool était autrement sain. Personne ne hurlait. Les graphiques de stockage ne montraient rien de dramatique. Mais le ticket a eu de l’attention parce que c’était la norme. L’astreinte a remplacé le disque le lendemain en heures ouvrées. Le resilver s’est terminé proprement.
Deux semaines plus tard, un autre disque dans le même vdev a lâché complètement. Dans une autre timeline — celle où les scrubs étaient « on le fera plus tard » — le premier disque serait encore en service avec des erreurs latentes. La seconde défaillance aurait transformé le resilver en roulette russe : erreurs de lecture pendant la reconstruction, perte de données, et une réunion exécutive où tout le monde prétend qu’il voulait toujours de meilleures sauvegardes.
Au lieu de cela, RAIDZ2 a fait ce pour quoi il est conçu : absorber une défaillance sans drame. La journée a été sauvée non par des exploits, mais par un rappel calendarisé et une habitude culturelle de traiter les signaux « petits » comme réels.
Tâches pratiques (commandes + interprétation)
Voici des tâches pratiques que vous pouvez exécuter sur un système ZFS-on-Linux ou illumos/FreeBSD typique. Ajustez les noms de périphériques et de pool. Les exemples de sortie sont illustratifs ; votre système diffèrera.
Tâche 1 : Inspecter la santé du pool et les compteurs d’erreurs
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 05:12:44 with 0 errors on Sun Dec 15 03:12:44 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
ata-WDC_WD120...-part1 ONLINE 0 0 0
errors: No known data.errorsInterprétation : Vous vous souciez des compteurs READ/WRITE/CKSUM et de la ligne scan. Toute valeur CKSUM non nulle mérite une investigation ; elles indiquent souvent des problèmes de câblage/HBA autant que des disques.
Tâche 2 : Voir la disposition des vdev et ashift
cr0x@server:~$ sudo zdb -C tank | sed -n '1,120p'
MOS Configuration:
vdev_children: 1
version: 5000
pool_guid: 1234567890123456789
vdev_tree:
type: 'root'
id: 0
guid: 1111111111111111111
children[0]:
type: 'raidz'
id: 0
guid: 2222222222222222222
nparity: 2
ashift: 12Interprétation : nparity: 2 confirme RAIDZ2. ashift: 12 signifie secteurs 4K. Si vous avez accidentellement créé ashift: 9 sur des disques modernes, vous traînez une pénalité de performance et d’usure que vous ne pouvez pas « tuner » ensuite.
Tâche 3 : Vérifier les propriétés de dataset qui affectent le comportement RAIDZ2
cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,compression,atime,sync,primarycache tank
NAME PROPERTY VALUE SOURCE
tank recordsize 128K default
tank compression lz4 local
tank atime off local
tank sync standard default
tank primarycache all defaultInterprétation : compression=lz4 est généralement bon. atime=off évite des écritures supplémentaires pour les datasets majoritairement en lecture. Ne mettez pas sync=disabled à la légère ; ce n’est pas du tuning, c’est jouer aux dés avec les pannes de courant.
Tâche 4 : Mesurer les I/O en temps réel du pool et repérer l’impact d’un scrub/resilver
cr0x@server:~$ sudo zpool iostat -v tank 1 5
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 72.1T 14.2T 210 480 48.2M 96.1M
raidz2-0 72.1T 14.2T 210 480 48.2M 96.1M
ata-WDC_WD120... - - 28 60 6.3M 12.1M
ata-WDC_WD120... - - 25 58 6.0M 11.5M
ata-WDC_WD120... - - 31 61 6.8M 12.4M
-------------------------- ----- ----- ----- ----- ----- -----Interprétation : Cherchez un disque faisant significativement moins/plus de travail, ou affichant une latence élevée ailleurs (voir iostat/smartctl). Pendant un scrub, les lectures montent ; si les écritures grimpent aussi, vous souffrez peut‑être de thrashing métadonnées ou d’une charge importante.
Tâche 5 : Lancer un scrub et vérifier qu’il progresse
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
pool: tank
state: ONLINE
scan: scrub in progress since Tue Dec 23 01:05:11 2025
9.34T scanned at 1.12G/s, 3.02T issued at 371M/s, 72.1T total
0B repaired, 4.19% done, 2 days 03:14:00 to goInterprétation : Si la bande passante « issued » est bien en dessous de « scanned », l’ARC sert des données (bon signe). Si les deux sont lents, les disques sont le goulot. Si l’ETA est absurde, investiguez la santé des disques et la contention du pool.
Tâche 6 : Limiter l’impact d’un resilver/scrub (paramètres Linux/OpenZFS)
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_resilver_delay
2
cr0x@server:~$ echo 4 | sudo tee /sys/module/zfs/parameters/zfs_resilver_delay
4
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_scrub_delay
4Interprétation : Augmenter ces delays peut réduire l’impact sur la latence de production au prix de resilver/scrubs plus longs. Faites-le délibérément : si vous prolongez trop la fenêtre d’exposition, vous pouvez échanger performance contre risque.
Tâche 7 : Trouver les datasets consommant de l’espace et détecter le risque « pool plein »
cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint -S used | head
NAME USED AVAIL REFER MOUNTPOINT
tank/vm 38.2T 14.2T 38.2T /tank/vm
tank/backups 19.4T 14.2T 19.4T /tank/backups
tank/home 7.9T 14.2T 7.9T /tank/home
tank 65.5T 14.2T 112K /tankInterprétation : Quand AVAIL devient critique, les performances et la maintenance souffrent. Pensez quotas, réservations, ou extension de capacité avant d’atteindre la phase « tout est lent ».
Tâche 8 : Vérifier la fragmentation et pourquoi « c’est plus lent qu’avant » peut être vrai
cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag,health tank
NAME SIZE ALLOC FREE CAP FRAG HEALTH
tank 86.3T 72.1T 14.2T 83% 52% ONLINEInterprétation : Une fragmentation élevée associée à une capacité élevée est une mauvaise combinaison pour la latence. C’est là que « restez sous 80 % » cesse d’être du folklore.
Tâche 9 : Remplacer un disque défaillant de façon sûre (offline/replace)
cr0x@server:~$ sudo zpool offline tank ata-WDC_WD120...-part1
cr0x@server:~$ sudo zpool replace tank ata-WDC_WD120...-part1 /dev/disk/by-id/ata-WDC_WD120_NEWDRIVE-part1
cr0x@server:~$ sudo zpool status tank | sed -n '1,20p'
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 23 02:21:02 2025
1.18T scanned at 622M/s, 140G issued at 74.1M/s, 72.1T total
0B resilvered, 0.19% done, 5 days 06:10:00 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
replacing-0 DEGRADED 0 0 0
ata-WDC_WD120...-part1 OFFLINE 0 0 0
ata-WDC_WD120_NEWDRIVE-part1 ONLINE 0 0 0Interprétation : Surveillez la progression du resilver et les compteurs d’erreurs. Si l’ETA est énorme, confirmez que le pool n’est pas saturé par la charge et que le nouveau disque est sain et performant.
Tâche 10 : Identifier les disques lents et les problèmes de transport avec SMART
cr0x@server:~$ sudo smartctl -a /dev/sdc | sed -n '1,60p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model: WDC WD120...
Serial Number: XXXXX
User Capacity: 12,000,000,000,000 bytes
...
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
...
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 2
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 18Interprétation : Les pending sectors et les CRC errors importent. Les CRC errors indiquent souvent des problèmes de câblage/backplane, pas « le disque qui meurt ». Dans les incidents RAIDZ2, la moitié du combat est de distinguer une défaillance media d’un problème de transport.
Tâche 11 : Vérifier l’efficacité de l’ARC et si « ajouter de la RAM » est la bonne réponse
cr0x@server:~$ sudo arcstat 1 3
time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
02:10:01 812 122 15 92 75 30 25 0 0 124G 128G
02:10:02 790 118 14 88 75 30 25 0 0 124G 128G
02:10:03 835 140 17 101 72 39 28 0 0 124G 128GInterprétation : Un miss% faible suggère que le cache marche. Un miss% élevé pendant une charge lecture‑intensive indique que les disques sont sollicités. Si l’ARC est plafonné (arcsz proche de c) et que les misses sont élevés, plus de RAM peut aider — si le working set est cachable.
Tâche 12 : Confirmer si vous avez vraiment des écritures synchrones
cr0x@server:~$ sudo zfs get -o name,property,value sync tank/vm
NAME PROPERTY VALUE
tank/vm sync standardInterprétation : standard signifie « honorer les requêtes applicatives ». Si votre charge est NFS avec sémantique sync ou des bases de données avec fsync, un SLOG peut compter. Si votre workload émet rarement des writes sync, un SLOG est surtout décoratif.
Tâche 13 : Utiliser fio pour valider le comportement (prudemment, hors‑pic)
cr0x@server:~$ sudo fio --name=randwrite --directory=/tank/test --size=8G --bs=4k --rw=randwrite --iodepth=16 --numjobs=4 --direct=1 --runtime=60 --time_based
...
write: IOPS=820, BW=3.2MiB/s (3.4MB/s)(192MiB/60001msec)
lat (usec): min=420, max=120000, avg=18500.12, stdev=9200.55Interprétation : Les writes aléatoires 4K sur un RAIDZ2 HDD peuvent paraître affreux ; ce n’est pas nécessairement une mauvaise configuration. Utilisez‑le pour valider les attentes, pas pour gagner des discussions sur Internet.
Tâche 14 : Vérifier le statut autoexpand et la posture d’expansion des périphériques
cr0x@server:~$ sudo zpool get autoexpand tank
NAME PROPERTY VALUE SOURCE
tank autoexpand off defaultInterprétation : autoexpand détermine si un pool grandit automatiquement quand les dispositifs sous‑jacents grandissent. Ça ne vous sauvera pas d’une mauvaise planification, mais ça évite le « on a remplacé tous les disques et le pool n’a pas grossi ».
Mode d’emploi pour un diagnostic rapide
Quand la performance RAIDZ2 chute ou que des erreurs apparaissent, vous n’avez pas le temps pour un débat philosophique. Il vous faut une boucle serrée : confirmer les symptômes, isoler la couche, et décider si vous êtes en mode « fix now » ou « monitor ».
Première étape : établir s’il s’agit d’un événement de santé ou de performance
- Vérifier la santé du pool :
zpool status -v. Tout état DEGRADED/FAULTED, resilver en cours, ou erreurs de checksum change immédiatement les priorités. - Vérifier la présence d’un scrub/resilver actif : la ligne scan dans
zpool status. Si oui, attendez‑vous à une dégradation de performance ; décidez s’il faut limiter ou replanifier. - Vérifier l’espace et la fragmentation :
zpool list -o cap,fragetzfs list. Un pool plein peut se faire passer pour un « matériel devenu plus lent ».
Deuxième étape : identifier la couche goulot (CPU, RAM, disques ou réseau)
- Pression disque/vdev :
zpool iostat -v 1. Cherchez une bande passante disque inégale ou un vdev coincé près de sa limite. - Attente I/O système et files :
iostat -x 1etvmstat 1. Un await élevé et une util proche de 100 % suggèrent que les disques sont saturés ou qu’un disque est lent. - Comportement ARC/cache :
arcstat(ou équivalent). Des misses élevés pendant une charge lecture signifient que les disques travaillent. - Réseau (si applicable) :
nfsstat,ss -s, compteurs NIC. La « lenteur » stockage est parfois des retransmissions et du bufferbloat déguisés en problème disque.
Troisième étape : déterminer s’il y a un acteur isolé
- Regarder les erreurs checksum/read/write par périphérique :
zpool status. - Vérifier SMART pour secteurs pending ou CRC errors :
smartctl -a. Les CRC errors crient « câble/backplane ». Les pending sectors crient « media ». - Vérifier les logs kernel :
dmesg -Toujournalctl -kpour resets de liens, timeouts et erreurs SCSI.
Point de décision : que faire tout de suite
- Si la santé du pool est compromise : arrêtez les changements risqués, réduisez la charge si possible, et planifiez un remplacement de disque ou une correction de transport. Le tuning de performance n’est pas la priorité.
- Si le pool est plein/fragmenté : libérez de l’espace, ajoutez de la capacité, ou migrez des données. Vous ne pouvez pas tuner votre sortie de la géométrie.
- Si un disque est lent : traitez‑le comme une défaillance en cours. RAIDZ2 gère mieux les disques morts que les mi‑morts.
- Si c’est un décalage workload : envisagez des mirrors pour les tiers chauds ou ajoutez des vdevs pour augmenter le parallélisme.
Erreurs courantes : symptômes et corrections
Erreur 1 : vdevs RAIDZ2 surdimensionnés pour « l’efficacité de capacité »
Symptômes : les resilvers prennent une éternité ; les scrubs empiètent sur les heures de bureau ; les performances s’effondrent pendant la maintenance ; des événements de stress multi‑disques deviennent plus fréquents.
Correction : préférez plusieurs vdevs de largeur modérée plutôt qu’un seul vdev très large ; gardez de la capacité de secours ; planifiez l’extension en ajoutant un autre vdev RAIDZ2 plutôt que d’élargir l’existant (sauf si vous avez une fonctionnalité d’expansion testée).
Erreur 2 : traiter le special vdev comme cache et le laisser non mirroré
Symptômes : tout va vite jusqu’au jour où tout s’arrête ; une erreur sur le special device menace le pool ; comportement d’import effrayant après des soucis SSD.
Correction : mirrorer les devices du special vdev ; les surveiller ; les dimensionner pour la croissance des métadonnées ; les traiter comme du stockage critique, pas une accélération optionnelle.
Erreur 3 : tourner trop près de 100 % et appeler ça « efficace »
Symptômes : latence qui augmente, suppressions lentes, temps de sync de transaction groups longs, scrubs/resilvers qui ralentissent dramatiquement.
Correction : appliquer des quotas, archiver les vieux snapshots, ajouter de la capacité plus tôt, et garder une marge opérationnelle. Si vous avez besoin de 90 %+ d’utilisation, concevez un tier pour ça et acceptez la performance dégradée.
Erreur 4 : mauvais ashift, découvert après mise en production
Symptômes : performances d’écriture inexplicablement basses ; utilisation élevée des disques ; inquiétude sur l’usure SSD ; « c’était plus rapide en staging ».
Correction : ashift ne peut pas être changé en place pour des vdevs existants. La vraie correction est rebuild/migrate : répliquer vers un pool créé correctement et basculer.
Erreur 5 : désactiver sync pour « corriger » la latence
Symptômes : la latence d’écriture s’améliore ; plus tard, après un crash ou une coupure, les applis rapportent corruption, transactions manquantes ou disques VM incohérents.
Correction : laissez sync=standard sauf si vous comprenez et acceptez totalement le compromis de durabilité. Si les writes sync sont le goulot, envisagez un SLOG sur SSD avec protection contre la perte de puissance, ou déplacez les workloads sync‑lourds sur des mirrors.
Erreur 6 : ignorer les erreurs de checksum parce que « c’est toujours ONLINE »
Symptômes : incréments occasionnels de CKSUM ; erreurs clients intermittentes ; plus tard, cascade de faults device pendant un scrub/resilver.
Correction : investiguez tôt. Vérifiez câblage, firmware HBA, backplane, et SMART. Remplacez les composants suspects avant que le pool ne soit sous contrainte de reconstruction.
Listes de contrôle / plan étape par étape
Checklist de planification : choisir la géométrie RAIDZ2
- Définir la charge : surtout séquentielle, surtout aléatoire, sync‑heavy, metadata‑heavy, mixte ?
- Choisir un plafond d’utilisation cible (ex. 75–80 % pour des workloads mixtes sensibles à la latence).
- Choisir la largeur du vdev selon la tolérance au rebuild et la posture de risque (souvent 6–10 disques par vdev RAIDZ2).
- Choisir le nombre de vdevs pour atteindre les besoins en IOPS/parallélisme.
- Décider d’un special vdev (mirroré) si métadonnées/petits fichiers dominants ; décider d’un SLOG seulement si les écritures synchrones sont réelles.
- Définir ashift correctement à la création selon les médias réels (partir de 4K minimum ; considérer 8K/16K pour certains SSD).
- Mettre des valeurs par défaut sensées :
compression=lz4,atime=offsi approprié, réglerrecordsize/volblocksize. - Planifier scrubs, alerting, et un runbook testé de remplacement de disque.
Plan de construction : créer un pool RAIDZ2 (exemple)
Exemple seulement — vérifiez les IDs de périphériques et le partitionnement. Utilisez des chemins by-id stables.
cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ata-|nvme-' | head
cr0x@server:~$ sudo zpool create -o ashift=12 tank raidz2 \
/dev/disk/by-id/ata-DISK1-part1 \
/dev/disk/by-id/ata-DISK2-part1 \
/dev/disk/by-id/ata-DISK3-part1 \
/dev/disk/by-id/ata-DISK4-part1 \
/dev/disk/by-id/ata-DISK5-part1 \
/dev/disk/by-id/ata-DISK6-part1 \
/dev/disk/by-id/ata-DISK7-part1 \
/dev/disk/by-id/ata-DISK8-part1Interprétation : Ceci crée un vdev RAIDZ2 à 8 éléments. Pour plus de performance, on ajoute typiquement un autre vdev similaire plus tard, plutôt que d’élargir celui‑ci.
Plan opérationnel : scrub mensuel et workflow d’alerte
- Planification : lancer
zpool scrubhors‑pic. - Surveillance : alerter dès tout changement non nul de
READ/WRITE/CKSUMet sur la fin de scrub avec erreurs. - En cas d’erreur : ouvrir un ticket, capturer
zpool status -v, logs kernel, et SMART. - Remédiation : corriger le transport en premier (CRC/resets de lien), puis remplacer les disques avec pending/reallocated sectors ou timeouts répétés.
- Vérifier : re‑scrubber si nécessaire et confirmer la stabilisation des compteurs d’erreurs.
Plan d’extension de capacité : ajouter un nouveau vdev RAIDZ2
Le schéma de croissance normal ZFS est l’ajout de vdevs. Vous conservez la géométrie des vdevs existants et ajoutez du parallélisme.
cr0x@server:~$ sudo zpool add tank raidz2 \
/dev/disk/by-id/ata-NEWDISK1-part1 \
/dev/disk/by-id/ata-NEWDISK2-part1 \
/dev/disk/by-id/ata-NEWDISK3-part1 \
/dev/disk/by-id/ata-NEWDISK4-part1 \
/dev/disk/by-id/ata-NEWDISK5-part1 \
/dev/disk/by-id/ata-NEWDISK6-part1 \
/dev/disk/by-id/ata-NEWDISK7-part1 \
/dev/disk/by-id/ata-NEWDISK8-part1
cr0x@server:~$ sudo zpool status tankInterprétation : Vous avez maintenant deux vdevs RAIDZ2. L’I/O aléatoire s’améliore généralement car les allocations peuvent se répartir sur les vdevs.
FAQ
1) RAIDZ2 est‑il « suffisant » pour de très gros disques (16–24 To) ?
Souvent oui — si vous gardez des largeurs de vdev raisonnables, scrubez régulièrement, et remplacez rapidement les disques suspects. Avec des disques très grands et des vdevs très larges, RAIDZ3 devient plus attractif. La vraie question est opérationnelle : quelle est votre fenêtre d’exposition pendant un resilver, et quelle est votre confiance à éviter une troisième défaillance (timeouts, URE, resets de transport) pendant cette fenêtre ?
2) RAIDZ2 vs mirrors pour le stockage VM : que choisir ?
Si la charge VM est très écriture‑aléatoire et sensible à la latence, les mirrors gagnent généralement. RAIDZ2 peut fonctionner pour des VMs, mais il est moins indulgent et peut nécessiter plus de vdevs, un special vdev SSD, un tuning soigné de volblocksize, et assez de RAM. Si vous voulez une réponse simple et prévisible : mirrors pour les tiers chauds VM ; RAIDZ2 pour la capacité ou les tiers froids.
3) Quelle est une bonne largeur RAIDZ2 ?
Pour des workloads mixtes sur HDD, 6–10 disques par vdev RAIDZ2 est une plage pratique courante. Plus étroit reconstruit plus vite et se comporte mieux sous I/O aléatoire ; plus large améliore l’efficacité de capacité et le débit séquentiel. Si vous ne connaissez pas bien votre charge, ne construisez pas un RAIDZ2 à 14 disques en espérant que le monitoring vous sauvera.
4) Ai‑je besoin d’un SLOG avec RAIDZ2 ?
Seulement si vous avez des écritures synchrones significatives. Beaucoup de charges de partage de fichiers sont majoritairement async ; un SLOG n’aidera pas. Pour NFS en mode sync, des bases de données avec fsync, ou du stockage VM effectuant des writes sync, un SLOG SSD avec protection contre la perte de puissance peut réduire la latence. Mais il doit être de la bonne classe ; des SSD grand public sans PLP peuvent empirer la situation.
5) La compression LZ4 ralentit‑t‑elle les choses ?
Généralement non, et souvent elle accélère. LZ4 est rapide, et en écrivant moins d’octets vous réduisez le travail disque — particulièrement utile sur des RAIDZ2 HDD. Il y a des cas limites (médias déjà compressés, systèmes CPU‑contraints), mais la posture par défaut en production est « activer LZ4 sauf raison mesurée de ne pas le faire ».
6) Pourquoi je vois des erreurs de checksum alors que SMART dit PASSED ?
Parce que SMART « PASSED » est une auto‑évaluation grossière, pas une garantie. Les erreurs de checksum pointent souvent vers des problèmes de transport (mauvais câbles, backplane instable, HBA) autant que vers le media. Traitez les erreurs de checksum répétées comme réelles : capturez zpool status, vérifiez UDMA_CRC_Error_Count, et lisez les logs kernel pour des resets de lien.
7) Puis‑je étendre un vdev RAIDZ2 existant en ajoutant un disque ?
Historiquement, l’expansion RAIDZ n’était pas disponible dans beaucoup de déploiements ; OpenZFS plus récent a introduit des fonctionnalités d’expansion RAIDZ, mais la maturité opérationnelle varie selon la plateforme et la version. Dans de nombreux environnements production, la méthode conservatrice et largement utilisée reste : ajouter un nouveau vdev (un autre groupe RAIDZ2) au pool. Si vous prévoyez d’utiliser l’expansion, testez‑la en staging qui ressemble à la production et prévoyez une procédure de rollback.
8) Jusqu’où est‑ce « trop plein » pour un pool RAIDZ2 ?
Ça dépend, mais pour des workloads mixtes où la latence compte, considérez ~80 % comme une ligne jaune, pas une cible. Si vous opérez plus haut, attendez‑vous à davantage de fragmentation et une pire latence en queue, plus des scrubs/resilvers plus lents. Pour des pools d’archivage froid principalement séquentiels, vous pouvez pousser plus haut, mais vous échangez le confort opérationnel contre l’utilisation de capacité.
9) Quel est le plus grand risque opérationnel avec RAIDZ2 ?
Ce n’est pas la seconde défaillance de disque — c’est celle que vous aviez prévue. Les plus grands risques sont les fenêtres d’exposition prolongées pendant le resilver, les « mi‑défaillances » (timeouts et resets de transport), et l’exploitation trop proche de la pleine capacité en supposant que la parité vous sauvera de tout. RAIDZ2 vous achète du temps ; il n’achète pas l’immunité.
Conclusion
RAIDZ2 est populaire en production pour la même raison qu’une bonne rotation d’astreinte : il reconnaît la réalité. Les disques meurent. Ils se comportent aussi mal, ralentissent, et occasionnellement manipulent vos métriques jusqu’au pire moment. RAIDZ2 n’empêche pas le drame, mais il vous donne de la marge pour répondre sans transformer un disque défectueux en une une perte de données à la une.
Le « compromis idéal » vient avec des conditions. Gardez des largeurs de vdev sensées. Ajoutez des vdevs pour monter en performance. Scrubbez selon le calendrier. Traitez les erreurs de checksum comme des signaux, pas des trivia. Ne remplissez pas le pool jusqu’à la limite et ne blâmez pas ZFS pour la physique. Faites cela, et RAIDZ2 devient ce qu’il doit être : du stockage sans histoire qui continue de venir travailler.