Expansion RAIDZ de ZFS : Ce qui est possible aujourd’hui et meilleurs contournements

décembre 18, 2025 • février 3, 2026 • Lecture : 32 min • Views: 8

Cet article vous a aidé ?

Vous avez acheté « juste assez » de disques pour un RAIDZ. Six mois plus tard, le pool est à 83%, les snapshots se multiplient comme des lapins, et l’entreprise veut encore un quart de capacité pour hier.

C’est là que l’on découvre que ZFS n’est pas magique — c’est de l’ingénierie. RAIDZ offre une excellente densité et une bonne tolérance aux pannes. Il rend aussi l’extension de capacité aussi agréable qu’une discussion avec la physique. La bonne nouvelle : OpenZFS moderne a enfin gagné une nouvelle fonctionnalité ici. La mauvaise nouvelle : vous devez toujours savoir ce qu’elle fait, ce qu’elle ne fait pas, et quels contournements sont sûrs en production.

Ce qui est possible aujourd’hui (et ce qui ne l’est pas)

Séparons trois concepts qui sont souvent confondus dans les discussions Slack et les appels d’incident :

Étendre un pool : ajouter des vdevs de niveau supérieur (par ex., ajouter un autre groupe RAIDZ). Facile. A des conséquences.
Agrandir un vdev : élargir un vdev existant (par ex., RAIDZ1 de 5 disques à 6 disques). Historiquement « non », maintenant « parfois oui » selon le support des fonctionnalités.
Agrandir chaque disque : remplacer les disques par des modèles plus grands et laisser le vdev croître après le dernier remplacement. Classique, sûr, lent.

1) Ajouter un disque à un vdev RAIDZ existant

Aujourd’hui : C’est possible sur des builds OpenZFS récents quand la fonctionnalité RAIDZ expansion est supportée et activée. Vous pouvez attacher un disque supplémentaire à un vdev RAIDZ et le vdev va subir un processus d’expansion.

Le hic : Ce n’est pas instantané, et ce n’est pas gratuit. Les données existantes doivent être réécrites pour tirer parti de la nouvelle géométrie (plus de colonnes). Cela signifie un long processus d’arrière-plan qui ressemble beaucoup à une réécriture complète du pool. Attendez-vous à des I/O lourdes, beaucoup de temps et une variabilité de performance.

2) Remplacer tous les disques par des modèles plus grands

Aujourd’hui : Toujours la méthode la plus ennuyeuse et correcte pour augmenter la capacité RAIDZ. Vous remplacez les disques un par un, resilver après chaque remplacement, puis le vdev s’étend une fois que le dernier périphérique est plus grand et que autoexpand est pris en compte.

Le hic : Vous avez besoin de patience et de bons disques. Le resilvering sur de gros disques est un choix de vie.

3) Ajouter un nouveau vdev de niveau supérieur (un autre groupe RAIDZ, ou des miroirs)

Aujourd’hui : Marche toujours. C’est ainsi que ZFS est conçu pour faire évoluer les pools : en les stripeant sur plusieurs vdevs.

Le hic : Vous modifiez définitivement votre profil de redondance et les mathématiques du domaine de panne. ZFS stripe à travers les vdevs de niveau supérieur ; perdre n’importe quel vdev de niveau supérieur fait perdre le pool. Donc si vous « ajoutez juste un disque » (un vdev d’un seul disque), vous créez un pool qui peut mourir à cause d’une seule panne de disque. Ce n’est pas une expansion, c’est un pistolet à un coup chargé.

Conseil orienté : Si vous pouvez utiliser RAIDZ expansion en toute sécurité (fonctionnalité supportée, fenêtre de maintenance tolérable, marge I/O), c’est un outil légitime maintenant. Si vous ne le pouvez pas, ne faites pas d’improvisation : remplacez les disques par des modèles plus grands ou migrez vers un nouveau pool/layout de vdev. Les vdevs « temporaires » d’un seul disque ont la fâcheuse habitude de devenir permanents jusqu’à ce qu’ils deviennent catastrophiques.

Blague n°1 : L’expansion RAIDZ, c’est comme un abonnement à la salle de sport — techniquement on peut progresser, mais ça demandera du temps et de l’inconfort soutenu.

Comment fonctionne l’expansion RAIDZ en interne (suffisant pour décider)

RAIDZ écrit les données en « stripes » à travers les disques, avec parité. Le nombre de disques participant à une stripe est la « largeur » du vdev. Quand vous ajoutez un disque à un vdev RAIDZ (avec la fonctionnalité d’expansion), vous changez cette largeur.

Voici pourquoi c’est difficile : les anciens blocs sont disposés selon l’ancienne largeur. Les nouveaux blocs pourraient être écrits avec la nouvelle largeur, mais alors vous vous retrouveriez avec un vdev contenant un mélange de dispositions. C’est possible, mais cela signifie :

Le calcul de capacité devient compliqué — l’espace n’est pas libéré automatiquement tant qu’assez de données n’a pas été réécrites.
Les caractéristiques de performance varient selon la proportion de données en « ancien format » vs « nouveau format ».
La mathématique de la parité, les classes d’allocation et la sélection des metaslabs doivent coopérer sans casser la compatibilité sur disque.

Donc l’expansion implique une réécriture contrôlée des blocs pour qu’ils puissent être redistribués selon la nouvelle géométrie. Pensez-y comme : « le pool apprend une nouvelle façon de marcher, puis il enseigne lentement à ses données existantes à marcher de la même manière. »

À quoi s’attendre opérationnellement

Un long processus en arrière-plan qui concurrence les charges normales (lecture, écriture, métadonnées).
Amplification d’écriture plus élevée parce que les blocs sont réécrits, plus l’overhead parité.
Interaction avec les snapshots : les blocs référencés par des snapshots ne disparaissent pas ; la réécriture peut être contrainte par les politiques de rétention. Vous ne « rééquilibrez » pas autour d’une montagne d’historique snapshot immuable sans en payer le prix.
Stress thermique et SMART sur l’ensemble du vdev. Si vos disques sont déjà limites, vous êtes sur le point de le découvrir de la pire façon.

Ce que l’expansion ne corrige pas

Mauvaises valeurs d’ashift (par ex., disques 4K avec ashift=9). C’est définitif.
Topologie fondamentalement inadaptée à votre charge (par ex., RAIDZ pour des écritures aléatoires sync lourdes dans une base de données sensible à la latence). Un RAIDZ plus large peut améliorer le débit, mais il ne le transformera pas en miroir.
Forte fragmentation et explosion de snapshots causées par les patterns de workload. L’expansion peut réduire la pression mais pas le comportement sous-jacent.

Faits et histoire qui expliquent les bizarreries

Quelques points de contexte qui expliquent pourquoi « ajouter juste un disque » a mis si longtemps à devenir réaliste dans l’écosystème ZFS :

ZFS est né à l’époque des disques gros et chers où on supposait planifier la topologie vdev à l’avance. La culture venait avec : « Choisissez judicieusement ; changer plus tard est dur. »
Le striping des vdevs de niveau supérieur est fondamental : les pools ZFS sont un stripe à travers des vdevs. Cela facilite la mise à l’échelle mais rend les pools à redondance mixte risqués quand on improvise.
La parité RAIDZ n’est pas un RAID5/6 collé dessus ; elle est intégrée à l’allocation et aux pointeurs de blocs. Cette intégration profonde est excellente pour l’intégrité et terrible pour retoucher la disposition après coup.
La méthode « remplacer par des disques plus grands » est antérieure à la plupart des forks ZFS modernes et est devenue l’histoire canonique d’extension parce qu’elle ne nécessitait pas de réécrire tout en une fois.
Le resilvering est souvent basé sur les blocs, pas sur le disque entier. C’est un avantage ZFS — mais les resilvers RAIDZ peuvent quand même être longs parce que la reconstruction de la parité touche beaucoup de données.
La consolidation d’OpenZFS a compté : le développement ZFS a divergé entre descendants de Solaris, puis s’est reconvergé. Les gros travaux de fonctionnalité sur le format disque avancent à la « vitesse prudente des systèmes de fichiers. »
Les snapshots sont une priorité, ce qui change tout : « supprimer et réécrire » n’est pas simple si d’anciens blocs sont encore référencés.
Les checksums de bout en bout ont changé les attentes : vous ne voulez pas seulement de la capacité ; vous voulez des données correctes. Toute fonctionnalité d’expansion doit préserver l’intégrité face aux pannes, aux pertes de courant et aux progrès partiels.
Les capacités des disques ont explosé plus vite que les fenêtres de rebuild n’ont réduit : cela a élargi la douleur — les gens voulaient l’expansion parce que remplacer par des disques plus grands impliquait des resilvers de plusieurs jours.

Tâches pratiques : commandes, sorties et décisions

Voici les tâches réelles que j’exécute avant de toucher un pool en production. Chacune inclut une commande, une sortie d’exemple, ce que signifie la sortie, et la décision que vous prenez.

Tâche 1 : Identifier vos versions ZFS et noyau/userspace

cr0x@server:~$ zfs version
zfs-2.2.4-1
zfs-kmod-2.2.4-1

Ce que ça signifie : Vous êtes sur OpenZFS 2.2.x userspace et module noyau. La disponibilité des fonctionnalités varie selon la version et le packaging de la distribution.

Décision : Si vous êtes sur une version plus ancienne, ne supposez pas que RAIDZ expansion existe. Planifiez d’abord une fenêtre de mise à jour, ou utilisez les contournements plus anciens.

Tâche 2 : Vérifier la santé du pool et tout dommage latent

cr0x@server:~$ zpool status -xv
all pools are healthy

Ce que ça signifie : Pas d’erreurs connues pour le moment.

Décision : Si cela montre des erreurs, n’expandez pas. Corrigez d’abord les problèmes périphériques sous-jacents. L’expansion multiplie les I/O et fera ressortir les disques faibles.

Tâche 3 : Obtenir la topologie exacte des vdevs (cela dicte vos options)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0

errors: No known data errors

Ce que ça signifie : Vdev RAIDZ2 unique, largeur 6. Perdre plus de 2 disques dans ce vdev rend le pool inutilisable.

Décision : Vous pouvez (a) étendre la largeur de ce vdev (si supporté), (b) remplacer les disques par des modèles plus grands, ou (c) ajouter un autre vdev RAIDZ2. N’ajoutez pas de disques simples.

Tâche 4 : Confirmer ashift et alignement de secteur (vous ne pouvez pas le « réparer » plus tard)

cr0x@server:~$ zdb -C tank | grep ashift -n
56:                ashift: 12
57:                asize:  599998545920

Ce que ça signifie : ashift=12 (secteurs 4K) est généralement raisonnable pour les disques modernes.

Décision : Si ashift est incorrect (commune valeur 9 sur des disques 4K), ne perdez pas plus de temps sur l’expansion. La migration est généralement la seule correction correcte.

Tâche 5 : Vérifier les flags de fonctionnalités et si le pool peut supporter des fonctionnalités plus récentes

cr0x@server:~$ zpool get -H all tank | egrep 'feature@|compatibility'
tank	compatibility	off	local

Ce que ça signifie : Le mode compatibility est off ; les feature flags peuvent être activés individuellement.

Décision : Dans des environnements qui bootent sur des médias de récupération plus anciens ou qui répliquent vers des hôtes plus anciens, activer de nouvelles fonctionnalités peut casser la compatibilité. Confirmez que votre flotte le supporte avant de tourner ces boutons.

Tâche 6 : Vérifier la capacité du pool et la fragmentation (l’expansion n’aime pas les pools pleins)

cr0x@server:~$ zpool list -o name,size,alloc,free,cap,frag,health tank
NAME  SIZE  ALLOC   FREE  CAP  FRAG  HEALTH
tank  21.8T  19.1T  2.7T  87%   61%  ONLINE

Ce que ça signifie : 87% plein et 61% fragmenté. Vous êtes dans la zone « tout devient plus dur maintenant ».

Décision : Si CAP > 80%, priorisez la libération d’espace avant expansion ou remplacements. Les performances et le comportement d’allocation de ZFS se dégradent fortement quand le pool est plein.

Tâche 7 : Identifier les plus gros consommateurs d’espace, y compris les snapshots

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -S used | head
NAME                 USED   AVAIL  REFER  MOUNTPOINT
tank                 19.1T  2.7T   256K   /tank
tank/backups         11.2T  2.7T   4.1T   /tank/backups
tank/backups@snap-1  2.8T      -   4.0T   -
tank/vm              5.6T   2.7T   5.6T   /tank/vm
tank/home            1.9T   2.7T   1.9T   /tank/home

Ce que ça signifie : Les snapshots peuvent représenter une quantité choquante de « USED », et ils épinglent les anciens blocs.

Décision : Si l’expansion dépend de la réécriture des blocs mais que les snapshots les maintiennent, réduisez d’abord la rétention des snapshots (avec l’accord des parties prenantes).

Tâche 8 : Mesurer les flags de rappel d’écriture et le comportement sync (les idées reçues sur SLOG vivent ici)

cr0x@server:~$ zfs get -o name,property,value -s local,default sync,logbias,recordsize tank/vm
NAME     PROPERTY    VALUE
tank/vm  sync        standard
tank/vm  logbias     latency
tank/vm  recordsize  128K

Ce que ça signifie : Le dataset VM a le comportement sync par défaut, logbias latency, recordsize 128K.

Décision : Si vous voyez des douleurs de latence, ne supposez pas qu’« expansion va résoudre ça ». Vous pouvez avoir un goulot d’écritures sync qui nécessite un tuning SLOG ou des changements de workload.

Tâche 9 : Vérifier autotrim, compression et atime — tueurs discrets et sauveurs discrets

cr0x@server:~$ zfs get -o name,property,value compression,atime,relatime,autotrim tank
NAME  PROPERTY     VALUE
tank  compression  lz4
tank  atime        off
tank  relatime     off
tank  autotrim     off

Ce que ça signifie : La compression est activée (bon). atime off (souvent bon). autotrim off (peut être correct pour HDD ; sur SSD c’est à discuter).

Décision : L’expansion augmente les écritures ; la compression peut les réduire. Si votre pool est SSD, considérez autotrim avec attention — mais testez d’abord.

Tâche 10 : Établir une base I/O et latence avant toute intervention

cr0x@server:~$ zpool iostat -v tank 5 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        19.1T  2.7T      85    210  1.20G  2.45G
  raidz2-0                  19.1T  2.7T      85    210  1.20G  2.45G
    sda                         -      -      12     35   180M   420M
    sdb                         -      -      14     36   190M   410M
    sdc                         -      -      13     34   200M   430M
    sdd                         -      -      15     35   210M   400M
    sde                         -      -      16     35   210M   410M
    sdf                         -      -      15     35   210M   380M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que ça signifie : Cela montre la bande passante/ops par vdev et par disque. Vous cherchez des anomalies et de la marge.

Décision : Si les disques sont déjà proches de la saturation, l’expansion fera du tort. Planifiez une fenêtre calme ou limitez le processus d’expansion (là où c’est supporté) via la gestion de charge.

Tâche 11 : Vérifier l’historique d’erreurs récent et le rythme des resilver/scrub

cr0x@server:~$ zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 12:44:02 with 0 errors on Mon Dec  2 03:21:08 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0

errors: No known data errors

Ce que ça signifie : Un scrub s’est terminé proprement récemment. Bonne base.

Décision : Si vous n’avez pas scrubbé depuis des mois, scrubez avant expansion/remplacements. Trouvez les erreurs latentes quand vous avez encore de la marge.

Tâche 12 : Valider que le « nouveau » disque est bien celui que vous croyez

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE
NAME   SIZE MODEL            SERIAL          TYPE
sda   3.64T ST4000NM0035     ZC1A1ABC        disk
sdb   3.64T ST4000NM0035     ZC1A1ABD        disk
sdc   3.64T ST4000NM0035     ZC1A1ABE        disk
sdd   3.64T ST4000NM0035     ZC1A1ABF        disk
sde   3.64T ST4000NM0035     ZC1A1ABG        disk
sdf   3.64T ST4000NM0035     ZC1A1ABH        disk
sdg   3.64T ST4000NM0035     ZC1A1ABJ        disk

Ce que ça signifie : Vous avez un disque candidat (sdg) présent. Vous pouvez recouper les numéros de série avec votre ticket mains en DC.

Décision : N’opérez jamais sur /dev/sdX à l’aveugle. Préférez des identifiants stables comme /dev/disk/by-id dans les configs de pool réelles.

Tâche 13 : Vérifier la santé SMART avant d’intégrer un disque dans vos mathématiques de redondance

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep 'SMART overall-health|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0

Ce que ça signifie : Pas de reallocations/pending sectors. Pas une garantie, mais ce n’est pas alarmant non plus.

Décision : Si des secteurs en attente ou des reallocations en croissance existent, n’ajoutez pas ce disque. Les disques tombent en panne sous stress ; ne les invitez pas.

Tâche 14 : Simuler le changement de topologie envisagé (dans votre tête, avec des calculs)

cr0x@server:~$ zpool list -o name,ashift,autoexpand,size,alloc,free,cap tank
NAME  ASHIFT  AUTOEXPAND  SIZE   ALLOC   FREE  CAP
tank     12   off         21.8T  19.1T   2.7T  87%

Ce que ça signifie : autoexpand off. Pour la méthode « remplacer les disques par des plus grands », vous voudrez normalement activer autoexpand au bon moment.

Décision : Décidez votre voie :

Chemin expansion RAIDZ : assurer le support de la fonctionnalité, des baies libres, accepter le temps de réécriture.
Chemin remplacement disque : activer autoexpand au bon moment ; s’attendre à des resilvers en série.
Nouveau vdev : assurer redondance et caractéristiques de performance similaires.

Tâche 15 : Préparez la partie ennuyeuse — vérifiez que vous pouvez restaurer

cr0x@server:~$ zfs get -o name,property,value -s local,default copies,encryption,keylocation tank/backups
NAME         PROPERTY     VALUE
tank/backups copies       1
tank/backups encryption   off
tank/backups keylocation  none

Ce que ça signifie : Ce dataset n’est pas chiffré et a une copie. C’est acceptable si votre système de sauvegarde est ailleurs ; terrible si vous prétendez que c’est la sauvegarde.

Décision : Avant de gros changements de layout, validez les sauvegardes et testez des restaurations. L’expansion n’est pas censée être destructive, mais les systèmes de production apprécient l’ironie.

Tâche 16 : Si vous choisissez la voie « remplacer les disques », confirmez le nommage device-by-id

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'sd[abc]$' | head -n 3
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-ST4000NM0035_ZC1A1ABC -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-ST4000NM0035_ZC1A1ABD -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-ST4000NM0035_ZC1A1ABE -> ../../sdc

Ce que ça signifie : Des identifiants stables existent. Bien.

Décision : Utilisez ces chemins dans zpool replace pour éviter les incidents de « mauvais disque ».

Méthode de diagnostic rapide : trouver le goulot vite

Quand quelqu’un dit « nous avons besoin d’une expansion RAIDZ parce que le stockage est lent/plein », vous devez diagnostiquer le vrai goulot avant de commencer à déplacer des disques. Voici l’ordre de triage que j’utilise.

Première étape : pression de capacité et fragmentation

Vérifiez CAP et FRAG via zpool list.
Si CAP > 80% et FRAG > ~50%, attendez-vous à des douleurs de l’allocation et à une amplification d’écriture.

Action : Supprimez ou déplacez des données d’abord ; resserrez la rétention des snapshots ; ajoutez de l’espace avec la méthode la moins risquée disponible. Étendre un pool presque plein, c’est comme réparer un moteur alors que la voiture est encore en course.

Deuxième étape : latence vs débit (ce ne sont pas les mêmes problèmes)

Utilisez zpool iostat -v pour repérer des disques surchargés ou un seul périphérique lent.
Corrélez avec les symptômes applicatifs : se plaignent-ils de latence IOPS ou de temps de transfert en masse ?

Action : Pour des écritures aléatoires sensibles à la latence, les changements de largeur RAIDZ peuvent peu aider. Les miroirs ou des dispositifs spéciaux peuvent être plus adaptés.

Troisième étape : écritures sync et comportement du journal d’intention

Vérifiez les propriétés des datasets : sync, logbias.
Recherchez les types de workload : NFS avec sémantique sync, bases de données, hyperviseurs VM.

Action : Si la latence sync est le goulot, un SLOG approprié sur média protégé contre la perte de puissance peut aider plus que l’expansion. Ou adaptez les sémantiques applicatives si possible.

Quatrième étape : taux d’erreurs et santé des disques

Vérifiez zpool status pour read/write/cksum errors.
Vérifiez les stats SMART sur les anomalies.

Action : Remplacez les disques défaillants avant d’essayer une expansion/rebuild. Un disque marginal soumis à une réécriture lourde devient un générateur d’indisponibilité.

Cinquième étape : recordsize, volblocksize et inadéquation workload

Pour les bases de données : un recordsize trop grand augmente l’amplification de lecture.
Pour les zvols VM : vérifiez les choix de volblocksize ; les changer plus tard peut nécessiter une migration.

Action : Corrigez le désaccord workload/dataset si possible ; l’expansion ne corrige pas des datasets mal paramétrés.

Meilleurs contournements quand vous ne pouvez pas (ou ne devriez pas) étendre RAIDZ

Même avec RAIDZ expansion disponible, il existe des cas où vous devriez choisir une approche différente : le pool est trop plein, la charge ne tolère pas une réécriture soutenue, votre plate-forme ne peut pas activer de nouveaux feature flags, ou vous ne faites pas confiance à la fenêtre de maintenance.

Contournement 1 : Remplacer les disques par des modèles plus grands (la méthode « lente mais saine »)

C’est le classique : remplacez un disque à la fois, laissez resilver, répétez. Une fois le dernier périphérique remplacé, le vdev s’étend (autoexpand, taille des partitions).

Ce que ça apporte : profil de risque prévisible, pas de nouvelle topologie, compatible.

Ce que ça coûte : du temps. De plus, des resilvers répétés stressent le vdev plusieurs fois, ce qui n’est pas négligeable sur des flottes anciennes.

Conseil opérationnel : gardez au moins une spare froide sur site. Traitez le remplacement de disques comme une campagne, pas une série d’héroïsmes ponctuels.

Contournement 2 : Ajouter un nouveau vdev de niveau supérieur (mais faites-le sérieusement)

Ajoutez un autre vdev RAIDZ avec le même niveau de parité et des performances similaires. Cela augmente la capacité immédiatement. Dans bien des cas, cela augmente aussi les performances agrégées parce qu’il y a plus de spindles et de metaslabs.

Règles :

Assortissez la redondance. RAIDZ2 + RAIDZ2 est raisonnable ; RAIDZ2 + disque unique est de la négligence.
Essayez de faire correspondre la largeur et la classe de disques. Mélanger un RAIDZ HDD large avec un RAIDZ SSD étroit crée des falaises de performance.
Planifiez les domaines de panne : plus de vdevs signifie plus de surfaces « n’importe quel vdev qui échoue tue le pool ». Ne confondez pas « plus de redondance par vdev » avec « pool invincible ».

Contournement 3 : Migrer vers des miroirs pour la croissance future

Si vous êtes dans un environnement où la capacité doit croître par petites étapes et où la performance veut des IOPS, les miroirs sont votre ami. Les miroirs permettent d’ajouter de la capacité par paires et d’obtenir une latence prévisible.

Le compromis : vous payez en capacité brute. Parfois c’est acceptable. Parfois la finance va discuter. La finance discute toujours ; c’est leur RAIDZ.

Contournement 4 : Construire un nouveau pool et répliquer (la coupure propre)

Si votre layout est mauvais (ashift, mauvais niveau de parité, mauvaise largeur, mauvais type de vdev), arrêtez de colmater et migrez. Construisez un nouveau pool avec la bonne géométrie et répliquez les datasets avec zfs send | zfs receive.

Pourquoi c’est souvent le meilleur choix : cela vous permet de corriger plusieurs erreurs structurelles à la fois et vous donne un plan de rollback. La migration est du travail, mais c’est le genre de travail qui finit par un système en lequel vous avez vraiment confiance.

Contournement 5 : Ajouter des special vdevs avec précaution (accélération des métadonnées/petits blocs)

Les special vdevs peuvent déplacer les métadonnées (et éventuellement les petits blocs) vers des supports plus rapides. Cela peut rendre un pool RAIDZ beaucoup plus réactif, surtout pour des workloads lourds en métadonnées.

Avertissement : les special vdevs ne sont pas un cache. Si vous perdez un special vdev et qu’il contient des métadonnées, vous pouvez perdre le pool. Mettez-les en miroir. Traitez-les comme du stockage de première classe, pas comme une décoration.

Trois mini-récits d’entreprise venus des tranchées

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

Ils avaient un vdev RAIDZ2 unique et manquaient d’espace. Un ingénieur bien intentionné a dit : « ZFS peut faire du striping à travers les vdevs, donc on peut ajouter un disque temporairement et déplacer les données plus tard. » Ça sonnait plausible, comme beaucoup d’idées dangereuses.

L’équipe a lancé zpool add avec un disque unique. La pression de capacité a diminué instantanément. Le ticket a été clos. Tout le monde est rentré chez soi et a apprécié la rare sensation de « on a réparé le stockage rapidement ».

Deux mois plus tard, ce disque « temporaire » a commencé à produire des erreurs. Pas une panne totale — pire. Des timeouts intermittents et des erreurs d’écriture occasionnelles. ZFS a commencé à marquer le périphérique comme dégradé, puis en erreur. Le pool est mort parce qu’un vdev de niveau supérieur est tombé. Pas de parité, pas de miroir. Un disque unique était devenu un point de défaillance pour tout le pool.

Le post-mortem a été douloureux parce que le système s’est comporté exactement comme prévu. La mauvaise hypothèse n’était pas que ZFS était peu fiable ; c’était la mauvaise compréhension de ce que « striped across vdevs » implique vraiment. Ils n’avaient pas ajouté de capacité — ils avaient ajouté un pilier fragile sous tout le bâtiment.

La réparation a été une restauration depuis les backups et une reconstruction de la topologie du pool. Ils ont aussi ajouté un garde-fou : un wrapper qui refusait zpool add à moins que le vdev ajouté respecte une règle minimale de redondance.

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

Une autre entreprise avait un pool RAIDZ1 pour une ferme de VM. Tout allait « bien » jusqu’à ce que non : pics de latence, invités saccadés, équipes applicatives en colère. L’équipe storage a décidé « d’optimiser » en rendant le RAIDZ plus large pendant une expansion pour augmenter le débit, supposant que plus de disques = plus rapide.

Ils ont étendu la capacité en ajoutant un autre vdev RAIDZ large, et ils ont aussi ajusté les paramètres des datasets : recordsize plus grand, cache plus agressif, et un planning de snapshots plus lourd « pour la sécurité ». Le système a bien benchmarké en séquentiel. La charge production n’était ni séquentielle ni polie.

Une fois sous charge réelle, les écritures sync et le churn des métadonnées ont dominé. Un RAIDZ plus large a rendu les petites écritures aléatoires plus coûteuses. Le planning de snapshots a épinglé des blocs et amplifié la fragmentation. Les scrubs ont duré plus longtemps, les resilvers ont duré plus longtemps, et la latence tail s’est empirée.

Ils n’ont pas causé de perte de données, mais ils ont créé un système qui respectait les objectifs de capacité tout en manquant les SLOs de performance. Le rollback a été une migration vers des vdevs en miroir pour les datasets VM, en laissant RAIDZ pour les backups et le stockage en masse.

La leçon n’était pas « RAIDZ est mauvais ». C’était : optimiser pour le mauvais indicateur est indiscernable d’un sabotage, sauf que les tickets sont plus jolis au début.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise média gérait un pool d’archive toujours proche du plein car quelqu’un considérait « l’espace libre » comme un luxe optionnel. L’ingénieur storage — discret, peu glamour, constamment dans le vrai — insistait sur trois pratiques : scrubs mensuels, nommage stable des périphériques, et remplacement graduel des disques avec un runbook testé.

Une semaine, un disque a commencé à montrer des secteurs en attente. Le pool était toujours en ligne. Aucune alarme applicative encore. Mais le rapport de scrub et la tendance SMART étaient clairs : le disque devenait un incident futur.

Ils ont remplacé le disque pendant les heures de bureau avec un resilver contrôlé. Parce qu’ils avaient une cartographie by-id stable, le risque de remplacer le mauvais disque était faible. Parce qu’ils faisaient des scrubs régulièrement, il n’y avait pas d’erreurs latentes désagréables découvertes pendant le resilver. Parce qu’ils gardaient 20% d’espace libre comme politique, les allocations sont restées saines et le resilver s’est achevé sans devenir un désastre de performance.

Deux jours plus tard, un autre disque dans le même vdev a échoué complètement. Ils ont respiré, regardé ZFS faire son travail de parité, et ont continué leur semaine. La deuxième panne aurait pu être une perte de pool si le premier disque avait été laissé pourrir.

La pratique « ennuyeuse » n’a pas reçu d’applaudissements. Elle a fait quelque chose de mieux : elle a évité l’appel à 3 h du matin.

Erreurs courantes : symptômes → cause racine → correctif

Erreur 1 : « On a ajouté un disque et maintenant la performance est pire »

Symptômes : Latence plus élevée, scrubs plus lents, débit imprévisible après l’activité d’expansion.

Cause racine : L’expansion/réécriture concurrence l’I/O de production ; le pool est aussi fragmenté et proche du plein.

Correctif : Créez de la marge (supprimez/migrez des données), réduisez la rétention des snapshots, planifiez la réécriture lourde en fenêtres à faible trafic, et basez-vous sur zpool iostat -v pour confirmer la contention.

Erreur 2 : « On peut juste ajouter un disque temporairement »

Symptômes : Le pool devient dépendant d’un vdev de niveau supérieur non redondant ; plus tard, une seule panne de disque fait tomber tout le pool.

Cause racine : Mauvaise compréhension du striping des vdevs de niveau supérieur et des domaines de panne.

Correctif : N’ajoutez jamais un vdev d’un seul disque à un pool important. Si vous l’avez déjà fait, migrez immédiatement ou remplacez-le en lui attachant de la redondance (miroir) si possible.

Erreur 3 : « Nous avons remplacé tous les disques mais nous n’avons pas obtenu plus d’espace »

Symptômes : Après le remplacement final, zpool list affiche toujours l’ancienne taille.

Cause racine : autoexpand désactivé, partitions non agrandies, ou taille du périphérique sous-jacente non exposée.

Correctif : Activez autoexpand, confirmez la taille des partitions, export/import si nécessaire, et vérifiez avec zpool get autoexpand et lsblk.

Erreur 4 : « Le resilver a pris une éternité puis un autre disque a lâché »

Symptômes : Resilver sur plusieurs jours, erreurs croissantes, seconde panne durant la reconstruction.

Cause racine : Pas de scrubs proactifs ; erreurs latentes découvertes pendant le rebuild ; disques anciens sous stress ; pool trop plein.

Correctif : Scrubez régulièrement, gardez de l’espace libre, remplacez les disques sur tendances SMART, et envisagez plus de parité (RAIDZ2/3) pour de grands pools HDD.

Erreur 5 : « On a activé un nouveau feature flag et maintenant la réplication/le média de boot a cassé »

Symptômes : Un autre hôte ne peut pas importer le pool ; l’image de récupération ne peut pas monter ; la cible de réplication refuse les streams.

Cause racine : Mismatch de feature flags/compatibilité entre systèmes.

Correctif : Standardisez les versions OpenZFS sur la flotte avant d’activer des fonctionnalités ; utilisez les propriétés de compatibilité quand approprié ; gardez les outils de récupération à jour.

Erreur 6 : « Nous avons étendu mais la capacité n’est pas apparue immédiatement »

Symptômes : Le disque ajouté apparaît dans la config, mais l’espace utilisable augmente lentement ou pas du tout.

Cause racine : Les blocs existants sont toujours disposés selon l’ancienne géométrie ; les snapshots épinglent les blocs ; le processus de réécriture/expansion prend du temps.

Correctif : Gérez les attentes, surveillez la progression, réduisez la rétention des snapshots, et évitez d’étendre un pool presque plein.

Listes de contrôle / plan étape par étape

Plan A : Utiliser RAIDZ expansion (quand supporté et que vous tolérez la réécriture)

Confirmer le support plateforme : version OpenZFS sur tous les importeurs (nœuds prod, DR, médias de secours).
Confirmer la santé du pool : zpool status propre, scrub récent, pas de signaux SMART rouges.
Créer de la marge : ramener CAP sous ~80% si possible.
Geler les changements risqués : pas de mises à jour noyau simultanées, pas de roulette firmware, pas d’expérimentations « tant qu’on y est ».
Valider les backups : tester un chemin de restauration pour au moins un dataset représentatif.
Identifier le disque cible par-id : confirmer numéro de série, emplacement, WWN.
Programmer la fenêtre : l’expansion est disruptive ; prévoyez une dégradation de la perf et des jobs plus longs.
Surveiller en continu : surveillez zpool status, zpool iostat, SMART, et la latence applicative.
Scrub post-changement : une fois le système stabilisé, lancez un scrub pour vérifier l’intégrité sous la nouvelle configuration.

Plan B : Remplacer les disques par des plus grands (compatible production, coûteux en temps)

Lancer un scrub d’abord ; corriger toute erreur avant de commencer.
Remplacer un disque à la fois. Laisser le resilver se terminer complètement.
Ne remplacez pas plusieurs disques « pour gagner du temps » à moins d’aimer jouer au casino avec la parité.
Après le remplacement final, assurez-vous que le vdev s’étend (autoexpand, taille des partitions).
Validez les performances et la capacité ; puis ajustez la rétention des snapshots si le vrai objectif était « libérer de l’espace ».

Plan C : Ajouter un nouveau vdev (capacité rapide, changement de topologie permanent)

Choisir une redondance égale ou supérieure aux vdevs existants.
Assortir la classe de disques et la largeur approximative pour des performances prévisibles.
Documenter le nouveau domaine de panne pour les astreintes.
Après ajout, surveiller la distribution : les nouvelles écritures iront sur le nouveau vdev ; les anciennes données restent où elles sont sauf réécriture.
Si vous avez besoin de rééquilibrage, planifiez-le explicitement (send/receive ou réécriture contrôlée), pas en espérant que ça se fasse par magie.

FAQ

1) Puis-je ajouter un disque à mon vdev RAIDZ et obtenir plus d’espace instantanément ?

Pas instantanément comme les gens l’espèrent. Avec le support RAIDZ expansion, vous pouvez ajouter un disque et démarrer un processus d’expansion, mais l’espace utilisable peut se matérialiser progressivement au fur et à mesure que les données sont réécrites.

2) Est-il plus sûr d’ajouter un nouveau vdev RAIDZ que d’étendre un existant ?

« Plus sûr » dépend de ce que vous entendez. Ajouter un nouveau vdev redondant est une opération bien comprise avec des domaines de panne prévisibles. L’expansion réécrit beaucoup de données et stresse les disques. Si vos disques sont vieux ou si votre pool est très plein, ajouter un nouveau vdev (correctement redondant) peut être l’option à moindre risque.

3) Pourquoi ZFS ne rééquilibre-t-il pas automatiquement les données après que j’ai ajouté de la capacité ?

ZFS ne déplace pas les anciens blocs juste parce que vous avez ajouté de l’espace ; il alloue de nouveaux blocs sur de nouveaux metaslabs. Un rééquilibrage automatique impliquerait d’énormes I/O en arrière-plan et des décisions de politique complexes (quelles données, quand, avec quelle agressivité, à quelle priorité).

4) Si j’ajoute un nouveau vdev, les lectures vont-elles s’accélérer ?

Souvent oui pour des workloads parallèles, car vous avez plus de vdevs pour servir les lectures. Mais les données chaudes déjà écrites sur l’ancien vdev y restent ; « plus de vdevs » ne téléporte pas votre working set.

5) Dois-je passer de RAIDZ à des miroirs pour la croissance future ?

Si vous avez besoin d’une expansion incrémentale et d’une latence IOPS prévisible, les miroirs sont généralement la bonne réponse. Si vous avez besoin de capacité utile maximale par disque et que le workload est plutôt séquentiel/en masse, RAIDZ reste pertinent. Ne choisissez pas par religion ; choisissez selon le domaine de panne et les exigences de latence.

6) Ajouter un SLOG aide-t-il pour l’expansion ou la capacité ?

Non pour la capacité. Pour la performance : il aide uniquement pour les écritures synchrones, et seulement si le dispositif SLOG est rapide et sûr contre la perte de puissance. Les mythes SLOG sont éternels ; tout comme les caches d’écriture qui mentent.

7) L’expansion RAIDZ résoudra-t-elle mon problème « pool à 90% » ?

Elle peut fournir plus d’espace, mais étendre un pool presque plein est risqué et peut être très lent. Priorité numéro un : réduire l’utilisation, élaguer les snapshots, ou ajouter de la capacité d’une façon qui n’exige pas une réécriture massive sous pression.

8) Comment savoir si les snapshots bloquent ma récupération d’espace ?

Regardez la sortie de zfs list incluant les snapshots, et comparez REFER vs USED des datasets. De grandes valeurs USED pour des snapshots signifient que d’anciens blocs sont épinglés. Si vous supprimez des données et que l’espace ne revient pas, les snapshots sont un suspect majeur.

9) Puis-je « annuler » un mauvais choix d’expansion ?

Vous ne pouvez pas retirer un vdev de niveau supérieur d’un pool dans le cas général. Vous pouvez parfois évacuer et détruire un pool, ou migrer des datasets vers un nouveau pool avec un meilleur layout. C’est pourquoi les décisions de topologie demandent de la paranoïa.

10) Quelle est la meilleure habitude pour éviter le drame lié à l’expansion ?

Garder de la marge. Sous ~70–80% d’utilisation, ZFS se comporte comme un système de fichiers compétent. Au-delà, il devient une comédie opérationnelle et de performance avec une distribution de coûts très chère.

Prochaines étapes pratiques

Voici ce que je ferais un lundi matin si je récupérais votre situation « nous avons besoin de plus de capacité RAIDZ » :

Mesurer la réalité : exécutez zpool list, zpool iostat -v, et zfs list -t snapshot. Décidez si le problème est de capacité, de latence, ou les deux.
Gagner du temps en sécurité : élaguer les snapshots et les données froides d’abord. Si vous avez besoin de capacité immédiate, ajoutez un nouveau vdev redondant — jamais un disque unique.
Choisir une stratégie d’expansion :
- Si vous pouvez tolérer une longue réécriture en arrière-plan et que votre plateforme le supporte, RAIDZ expansion est désormais une option légitime.
- Si vous avez besoin d’un risque fonctionnel minimal et d’opérations prévisibles, remplacez les disques par des plus grands.
- Si votre topologie est mauvaise (ashift, mauvaise classe de disques, mauvaise redondance), migrez vers un nouveau pool.
Appliquer les garde-fous ennuyeux : scrub d’abord, vérifier SMART, valider les backups, et documenter le rollback.

Une idée paraphrasée de Richard Cook (chercheur en sécurité et opérations) : Le succès dans les systèmes complexes vient souvent d’équipes qui s’adaptent en permanence, pas de l’absence de problèmes.

Blague n°2 : La façon la plus rapide d’apprendre que la topologie de votre pool est mauvaise est d’essayer de la « réparer temporairement » pendant un gel des changements de vacances.