Planification de capacité ZFS : concevoir la croissance sans reconstruction

Ce que « planification de capacité » signifie vraiment dans ZFS

Dans un monde de contrôleurs RAID traditionnels, la planification de capacité se résume principalement à « combien de disques faut-il »
et « combien de temps avant d’en acheter d’autres ». Dans ZFS, la planification de capacité inclut aussi :

• Irreversibilité de la topologie : la largeur et la redondance des vdev forment le squelette. Les changer plus tard est généralement une reconstruction.
• Couplage performance : espace, IOPS et latence sont liés via l’espace libre, la fragmentation et les metaslabs.
• Marges de sécurité opérationnelle : temps de resilver, risque de URE, fenêtres de scrub et rétention des snapshots sont des sujets de capacité.
• Domaines de panne : « plus d’espace » peut silencieusement signifier « plus grande surface d’impact ».

La planification de capacité est donc un problème de conception système. C’est choisir des contraintes avec lesquelles vous vivrez des années, pas des trimestres.
Votre futur vous jugera sur deux choses : si l’extension a été ennuyeuse, et si les pannes ont été rares.

Faits et contexte qui changent les décisions

Quelques points concrets — certains historiques, d’autres pratiques — qui corrigent souvent les modèles mentaux :

1. ZFS a été construit chez Sun pour éviter la « corruption silencieuse des données », pas seulement pour agréger des disques. Les checksums bout en bout et l’auto-réparation sont fondamentaux.
2. Le Copy-on-Write (CoW) explique pourquoi les pools « pleins » deviennent moches : vous avez besoin d’espace libre pour écrire de nouveaux blocs avant de libérer les anciens.
3. Les premières déployations ZFS évitaient le RAID matériel parce que masquer les erreurs disque brisait le modèle checksum+réparation. C’est toujours vrai : ZFS veut la visibilité directe des disques.
4. RAIDZ a été conçu pour éviter le write hole qui peut affecter RAID5/6 ; ZFS maintient la cohérence via des transactions et CoW.
5. « Ashift » est devenu une histoire de guerre quand les secteurs 4K sont arrivés et que des gens ont gardé un alignement 512 bytes. Vous ne pouvez pas changer ashift plus tard sans reconstruire.
6. La capacité des disques a augmenté plus vite que la vitesse de reconstruction. Le temps de resilver est maintenant une donnée d’entrée de la planification, pas un détail post-mortem.
7. ZFS a un « slop space » (une marge réservée) précisément parce que les administrateurs sont optimistes et les applications impitoyables.
8. Les snapshots sont bon marché jusqu’à ce qu’ils ne le soient plus : ils coûtent de l’espace seulement quand les blocs divergent, mais les politiques de rétention peuvent transformer un « oups » en « plus d’espace ».
9. Les vdevs spéciaux (métadonnées/classe) ont modifié l’économie de la performance en vous permettant d’acheter de l’espace rapide pour les métadonnées au lieu de tout accélérer.

Une idée paraphrasée à garder en tête, attribuée à John Allspaw : La fiabilité est une fonctionnalité que vous intégrez aux systèmes, pas un état que vous déclarez après le lancement.
La planification de capacité est de l’ingénierie de fiabilité avec une calculatrice et l’humilité de laisser du slack.

Modélisez la croissance d’abord : charges, amplification d’écriture et temps

Commencez par le « quoi », pas par les disques

Avant de choisir les largeurs RAIDZ ou le nombre de miroirs, décidez ce que vous stockez et comment ça se comporte :

• Profil de taille de bloc : bases de données et images VM génèrent de petites écritures aléatoires ; archives média font de gros flux séquentiels.
• Taux de churn : la fréquence de réécriture des données compte plus que leur volume. Le CoW signifie que le churn crée de la fragmentation.
• Rétention et cycle de vie : snapshots, sauvegardes et obligations légales peuvent doubler l’espace « effectif » utilisé.
• SLOs de performance : objectifs de latence p95 et budgets de temps de rebuild doivent orienter la redondance et le nombre de vdevs.

Pensez en « utilisable maintenant » vs « utilisable plus tard »

Les achats aiment les To bruts. Les opérations vivent en To utilisables à latence acceptable. Vous voulez deux chiffres dans votre plan :

• Utilisable jour 0 : ce que vous pouvez allouer en toute sécurité le premier jour tout en respectant les objectifs d’espace libre.
• Utilisable jour N : ce que vous pouvez atteindre en ajoutant des vdevs, en remplaçant des disques, ou les deux, sans reposer le pool.

L’amplification d’écriture ne concerne pas que les SSD

ZFS amplifie les écritures de manières qui comptent pour la capacité :

• Surcharge de parité (RAIDZ) : les petites écritures aléatoires peuvent devenir des patterns read-modify-write si recordsize et charge de travail sont décalés.
• Croissance des métadonnées : beaucoup de petits fichiers, ACLs, xattrs et snapshots gonflent les métadonnées.
• Copies et réplication : copies=2, cibles send/receive et staging de sauvegarde doublent rapidement le compte.

Planifiez avec un facteur de sécurité. Si vous ne connaissez pas le churn, supposez qu’il est élevé. Si vous ne connaissez pas la rétention, supposez que quelqu’un
demandera « gardez juste un peu plus longtemps » deux semaines après avoir atteint 85 % d’utilisation.

Blague n°1 : La seule chose qui grandit plus vite que les données, c’est le nombre d’équipes prétendant qu’elles « n’écrivent presque rien ». C’est adorable.

Choix de vdev qui déterminent votre futur

Mirrors : le choix ennuyeux qui gagne plus souvent qu’il ne perd

Les miroirs sont coûteux en capacité mais indulgents opérationnellement. Ils :

• Augmentent les IOPS en ajoutant des vdevs miroir (chaque vdev miroir ajoute des têtes indépendantes).
• Resilvent plus vite, car seuls les blocs alloués sont copiés et il y a moins de calculs de parité et de coordination multi-disques.
• Gèrent mieux les situations où « un disque est bizarre ». La variance de latence est plus faible car les lectures peuvent venir de chaque côté.

Si votre charge est lourde en I/O aléatoire (VMs, bases de données, conteneurs mixtes), les miroirs sont généralement la bonne réponse à moins que le coût en capacité ne soit la seule chose que votre organisation entend.

RAIDZ : efficace en capacité, mais la largeur est un engagement à long terme

RAIDZ (parité simple, double, triple) échange IOPS et caractéristiques de resilver contre espace utilisable. Il peut être fantastique pour
des charges orientées débit ou majoritairement séquentielles. Mais le piège clé est la largeur du vdev.

Historiquement, vous ne pouviez pas étendre un vdev RAIDZ en ajoutant des disques ; vous ajoutiez un nouveau vdev entier. OpenZFS moderne
propose un support d’expansion RAIDZ, mais la disponibilité et la maturité dépendent de la plateforme et de la version, et vous devez toujours penser
à la complexité opérationnelle et à la performance pendant le reshape. Traitez-le comme « possible » mais pas « inévitable ». Si votre plateforme ne le
supporte pas, planifiez comme si ça n’existait pas.

Niveau RAIDZ : ne soyez pas radin sur la parité avec de gros disques

Les gros disques ont changé les calculs. Les fenêtres de reconstruction sont plus longues, et la probabilité d’une seconde défaillance pendant le resilver n’est pas théorique.
RAIDZ1 est encore utilisé, mais il devrait être réservé aux cas où :

• Vous pouvez tolérer un risque plus élevé,
• Les rebuilds sont rapides (petits disques, faible utilisation),
• Et vous avez d’excellentes sauvegardes et une récupération testée.

Pour le « stockage d’entreprise », RAIDZ2 est la recommandation par défaut. RAIDZ3 est défendable pour des vdevs très larges, des disques très gros,
ou des environnements où la corrélation de défaillance des disques est quelque chose que vous avez déjà observée.

Nombre de vdevs : la capacité est poolée, la performance ne l’est pas

ZFS stripe across vdevs, pas au niveau des disques individuels comme un contrôleur RAID pourrait le faire. Un pool avec un seul vdev RAIDZ large
reste un vdev. Il a la concurrence d’un seul vdev pour beaucoup d’opérations. Ajoutez des vdevs pour ajouter du parallélisme.

C’est pourquoi « un RAIDZ2 de 12 disques » et « deux RAIDZ2 de 6 disques » peuvent se comporter de façon très différente sous charge. La deuxième option a deux
vdevs, plus de concurrence, et souvent une meilleure latence à la queue. La première option a un seul domaine de panne et une seule enveloppe de performance.
Votre monitoring vous dira ce que vous avez construit.

Ashift et alignement des secteurs : le tatouage que vous obtenez une fois

Choisissez ashift=12 (secteurs 4K) comme base sauf raison très spécifique de faire autrement. Beaucoup de disques « 512e » mentent poliment.
Un ashift incorrect peut coûter performance et espace pour toujours.

Règles d’espace libre : pourquoi 80 % n’est pas une superstition

ZFS a besoin d’espace libre pour rester rapide et sûr

L’ancienne recommandation « ne pas dépasser 80 % » survit parce qu’elle fonctionne. À mesure que les pools se remplissent :

• L’allocation devient plus difficile ; ZFS a moins de grands extents libres à choisir.
• La fragmentation augmente ; les écritures séquentielles deviennent moins séquentielles.
• Le Copy-on-Write nécessite plus d’espace temporaire, donc métadonnées et réécritures de blocs coûtent plus.
• Resilver et scrub deviennent plus lents car il y a plus de données et moins de slack I/O.

Traitez « 80 % » comme un déclencheur de planification par défaut, pas comme une source de panique. « 90 % » est le point où vous commencez à annuler des réunions.

Slop space : la marge qu’on oublie jusqu’au jour où elle vous sauve

ZFS réserve un peu d’espace (le « slop ») pour éviter un comportement catastrophique d’un pool plein. Ce n’est pas là pour votre commodité ; c’est là
pour que le pool continue de fonctionner quand les humains font des choses humaines. Les plans de capacité doivent supposer que le slop est intouchable.

La stratégie quotas et réservations fait partie de la planification de capacité

Les quotas et réservations ne sont pas des « politiques de système de fichiers ». Ce sont des garde-fous qui empêchent un dataset de manger le pool
et de transformer tous les autres workloads en victimes.

• Utilisez des quotas pour limiter le rayon d’impact.
• Utilisez des réservations (et refreservation) uniquement quand vous devez garantir de l’espace pour des datasets critiques.
• Privilégiez les project quotas dans les environnements avec beaucoup de sous-arbres et un turnover d’équipes fréquent.

Snapshots, clones et rétention : la taxe de capacité furtive

Les snapshots ne sont pas gratuits ; c’est une facturation différée

Les snapshots conservent d’anciens blocs. Plus vos données changent, plus les snapshots épinglent de l’espace. Pour les images VM et bases de données à churn constant,
les snapshots peuvent devenir une seconde copie avec le temps. Le piège est que le pool semble correct… jusqu’à ce que vous supprimiez des données et que rien ne se libère parce que les snapshots y font toujours référence.

La rétention doit être explicite et appliquée

« Conserver des snapshots quotidiens pendant 30 jours » semble inoffensif jusqu’à ce que vous ayez 50 datasets et 10 équipes et que l’une d’elles décide de
snapshotter toutes les 5 minutes. Vous avez besoin de :

• d’un schéma de nommage,
• d’une politique de rétention par classe de dataset,
• et d’un pruning automatisé traité comme critique en production.

Les clones : pratiques, mais ils embrouillent la comptabilité

Les clones partagent des blocs. C’est le but. Cela signifie aussi que « utilisé » devient une question avec plusieurs réponses (used logique, referenced,
écrit, usage par snapshot). Si vous ne formez pas les équipes là-dessus, quelqu’un supprimera « l’original » et sera confus que l’espace ne revienne pas, ou supprimera le « clone »
et sera surpris par ce qui disparaît.

Vdevs spéciaux, SLOG, L2ARC : capacité et domaines de panne

Vdevs spéciaux : le levier de performance qui peut aussi briquer votre pool

Les classes d’allocation spéciales peuvent stocker les métadonnées (et optionnellement les petits blocs) sur des périphériques rapides. Bien faits, ils donnent à des pools HDD
l’impression de ne pas être restés en 2009. Mal faits, ils créent un nouveau domaine de panne qui peut faire tomber tout le pool.

Règles qui vous gardent employé :

• Miroirez les vdevs spéciaux. Traitez-les comme des métadonnées critiques (parce que c’en sont).
• Dimensionnez-les avec la croissance en tête. S’ils se remplissent, la performance chute et le comportement d’allocation change.
• Suivez l’usage spécial séparément. C’est facile à manquer jusqu’à ce qu’il soit trop tard.

SLOG : pas un cache d’écriture, et pas pour la plupart des gens

Un périphérique de log séparé (SLOG) n’aide que les écritures synchrones. Si votre charge est majoritairement asynchrone, un SLOG est un placebo sophistiqué.
Si votre charge est synchrone et sensible à la latence (NFS pour VMs, bases de données avec fsync), un bon SLOG peut stabiliser la latence aux extrêmes.

Lien avec la planification de capacité : la taille du SLOG est généralement faible, mais l’endurance du périphérique, la protection contre la perte de puissance et le mirroring comptent.
Un périphérique SLOG mort dans une mauvaise configuration est une manière rapide d’apprendre à quoi ressemblent les « écritures sync bloquées ».

L2ARC : cache de lecture qui peut voler de la RAM et vous décevoir

L2ARC n’est pas « ajoutez un SSD, obtenez la vitesse ». C’est « ajoutez un SSD, puis payez les coûts de métadonnées en RAM ». Planifiez la RAM avant de planifier L2ARC. Si votre ARC
est déjà sous pression, L2ARC peut aggraver les choses en augmentant le churn d’éviction.

Blague n°2 : L2ARC ressemble à un abonnement à une salle de sport — l’acheter donne l’impression d’agir, mais les résultats dépendent de ce que vous faites réellement.

Voies d’extension sans reconstruction (et ce qui force quand même une reconstruction)

Méthode d’extension n°1 : ajouter des vdevs (le classique)

Ajouter un nouveau vdev est le chemin de croissance le plus établi. Cela préserve la géométrie des vdevs existants et augmente la performance en
ajoutant plus de parallélisme. Cela augmente aussi le nombre de domaines de panne : plus de disques signifie plus de pannes au fil du temps, donc la politique de redondance
et le monitoring comptent.

Implication de planification : concevez les vdevs initiaux pour que les vdevs futurs puissent leur correspondre. Mélanger des tailles et profils de performance très différents
peut provoquer des allocations inégales et un comportement imprévisible.

Méthode d’extension n°2 : remplacer les disques par des disques plus grands (grow-in-place)

Remplacer chaque disque d’un vdev par un plus grand et laisser ZFS étendre est courant pour les miroirs et RAIDZ. Ça marche, mais :

• C’est lent : vous resilvez chaque disque, un à la fois.
• C’est risqué si votre vdev est déjà stressé ou fortement utilisé.
• Vous n’obtenez l’espace que lorsque le dernier disque est remplacé (pour RAIDZ).

Implication de planification : si vous allez faire du grow-in-place, assurez-vous que vos fenêtres de resilver et stratégie de spares sont réalistes. « On remplacera les disques le weekend »
est la façon dont vous finissez par reconstruire un mardi.

Méthode d’extension n°3 : expansion RAIDZ (là où supportée)

Si votre plateforme supporte l’expansion de vdev RAIDZ, traitez-la comme un outil, pas comme une stratégie. Elle peut être utile pour une croissance incrémentale
quand ajouter des vdevs entiers n’est pas faisable. Mais vous devez quand même demander :

• Quel est l’impact de performance pendant le reshape ?
• Comment cela interagit-il avec votre calendrier de scrub ?
• Quelle est la procédure de rollback si quelque chose tourne mal ?
• Le monitoring et la maturité opérationnelle correspondent-ils à la complexité ?

Ce qui force généralement quand même une reconstruction

Certaines décisions sont difficiles à annuler :

• Mauvais ashift (alignement taille secteur).
• Mauvaise géométrie de vdev pour la charge (par ex. un énorme RAIDZ pour des workloads I/O aléatoires lourds).
• Changement de politique de redondance (par ex. passer de RAIDZ1 à RAIDZ2 sans chemins de conversion supportés).
• Stratégie de vdev spécial fondamentalement décalée (périphériques métadonnées sous-dimensionnés ou non miroirés).
• Erreurs de dedup qui nécessitent une refonte pour récupérer la performance et la sanity de capacité.

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

C’est la partie que vous pouvez copier dans un runbook ops. Chaque tâche inclut : commande, ce que signifie la sortie, et la décision qu’elle entraîne.
Les commandes supposent OpenZFS sur Linux ; adaptez les noms de périphériques pour votre plateforme.

Task 1: Get the real pool capacity and health

cr0x@server:~$ zpool list -o name,size,alloc,free,capacity,health
NAME   SIZE   ALLOC   FREE  CAPACITY  HEALTH
tank  109T   71.2T  37.8T       65%  ONLINE

Signification : « capacity » est l’utilisation au niveau du pool. Elle n’inclut pas la croissance future des snapshots ni les réservations de dataset.

Décision : Si la capacité tend vers 80 %, commencez la planification d’extension ; si elle dépasse 85 %, commencez l’exécution.

Task 2: See vdev layout (the “future regrets” view)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 12:41:03 with 0 errors on Sun Dec 22 03:10:32 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0

errors: No known data errors

Signification : Vous avez un vdev RAIDZ2. Un seul vdev signifie une concurrence limitée comparée à plusieurs vdevs.

Décision : Si vous avez besoin de plus d’IOPS, prévoyez d’ajouter un autre vdev plutôt que d’élargir celui-ci.

Task 3: Confirm ashift (alignment) before you buy more disks

cr0x@server:~$ zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
37:        vdev_tree:
58:            ashift: 12
59:            asize:  14000519643136

Signification : ashift: 12 indique un alignement en 4K. Bon défaut pour les disques modernes.

Décision : Si ashift est 9 sur des disques 4K, envisagez planifier une reconstruction ou une migration plutôt que d’empirer l’erreur.

Task 4: Identify top datasets by space (including snapshots)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -S used | head -n 12
NAME                 USED  AVAIL  REFER  MOUNTPOINT
tank/vm              28.1T  38.0T  6.2T   /tank/vm
tank/backups         17.4T  38.0T  1.1T   /tank/backups
tank/home            8.6T   38.0T  8.2T   /tank/home
tank                 71.2T  38.0T  216K   /tank

Signification : USED inclut l’utilisation par snapshot. REFER est les données référencées en live.

Décision : Si USED est bien plus grand que REFER, les snapshots épinglent de l’espace ; traitez la rétention avant d’acheter des disques.

Task 5: Quantify snapshot space burn

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,creation -S used | head -n 8
NAME                              USED  REFER  CREATION
tank/vm@auto-2025-12-25-1200       1.2T  6.1T   Thu Dec 25 12:00 2025
tank/vm@auto-2025-12-24-1200       1.1T  5.9T   Wed Dec 24 12:00 2025
tank/backups@daily-2025-12-25      640G  1.1T   Thu Dec 25 01:00 2025
tank/vm@auto-2025-12-23-1200       980G  5.7T   Tue Dec 23 12:00 2025

Signification : Le USED d’un snapshot est l’espace détenu uniquement par ce snapshot (estimé par ZFS).

Décision : Si quelques snapshots dominent, taillez ou ajustez le planning ; si tous sont gros, le churn est élevé — prévoyez plus d’espace.

Task 6: Check for reservations and refreservations (hidden “missing space”)

cr0x@server:~$ zfs get -r -H -o name,property,value reservation,refreservation tank | egrep -v '\t0$' | head
tank/db	reservation	2T
tank/vm	refreservation	5T

Signification : Les réservations consomment de l’espace même si le dataset est vide ; refreservation est liée à l’espace référencé, souvent utilisée avec des volumes.

Décision : Si le pool est serré, remettez en question les réservations : ne les conservez que pour les workloads qui ont réellement besoin d’espace garanti.

Task 7: Inspect compression effectiveness (capacity multiplier or disappointment)

cr0x@server:~$ zfs get -o name,property,value -s local,received compression,compressratio tank | head -n 12
NAME        PROPERTY       VALUE
tank/home   compression    zstd
tank/home   compressratio  1.62x
tank/vm     compression    zstd
tank/vm     compressratio  1.08x
tank/db     compression    zstd
tank/db     compressratio  1.01x

Signification : compressratio montre les économies réelles. Les VM et DB compressent souvent mal.

Décision : Si votre plan suppose des gains de compression, vérifiez la réalité. Ne budgétez pas des téraoctets imaginaires.

Task 8: Check recordsize/volblocksize alignment (performance and space behavior)

cr0x@server:~$ zfs get -o name,property,value recordsize tank/home tank/backups
NAME         PROPERTY    VALUE
tank/home    recordsize  128K
tank/backups recordsize  1M

Signification : Un grand recordsize améliore le débit pour les workloads séquentiels ; il peut nuire aux petites écritures aléatoires.

Décision : Définissez recordsize par classe de dataset. Ne faites pas tourner des images VM avec 1M de recordsize à moins d’aimer les graphiques de latence.

Task 9: Check sync settings (and whether you’re masking a problem)

cr0x@server:~$ zfs get -o name,property,value sync tank
NAME  PROPERTY  VALUE
tank  sync      standard

Signification : standard respecte la sémantique de sync des applications. disabled est un compromis perte-de-données.

Décision : Si quelqu’un a mis sync=disabled pour « améliorer la perf », remettez-le et concevez un SLOG approprié ou isolez la charge.

Task 10: Measure fragmentation and allocation pressure

cr0x@server:~$ zpool list -o name,capacity,fragmentation,free,allocated
NAME  CAPACITY  FRAG  FREE   ALLOCATED
tank      65%    29%  37.8T      71.2T

Signification : La fragmentation n’est pas toujours mauvaise, mais frag élevé + capacité élevée corrèle souvent avec des pics de latence.

Décision : Si FRAG monte et que vous êtes au-dessus d’environ ~80% de capacité, priorisez l’ajout d’espace (nouveau vdev) plutôt que des micro-optimisations.

Task 11: Watch I/O latency by vdev (find the actual limiter)

cr0x@server:~$ zpool iostat -v tank 5 3
                                            capacity     operations     bandwidth
pool                                        alloc   free   read  write   read  write
------------------------------------------  -----  -----  -----  -----  -----  -----
tank                                         71.2T  37.8T    820  1.40K  92.1M  141M
  raidz2-0                                   71.2T  37.8T    820  1.40K  92.1M  141M
    ata-WDC_WD140EDGZ-...                        -      -    140    240  15.3M  25.0M
    ata-WDC_WD140EDGZ-...                        -      -    135    230  15.0M  24.6M
    ata-WDC_WD140EDGZ-...                        -      -    138    235  15.2M  24.8M
------------------------------------------  -----  -----  -----  -----  -----  -----

Signification : Un vdev supporte toute la charge. Si le débit est correct mais la latence mauvaise, vous êtes probablement limité en IOPS.

Décision : Ajoutez des vdevs pour la concurrence ; n’attendez pas que le tuning invente de nouveaux plateaux tournants.

Task 12: Confirm scrub behavior and error trend

cr0x@server:~$ zpool status tank | sed -n '1,12p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 12:41:03 with 0 errors on Sun Dec 22 03:10:32 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0

Signification : Les scrubs sont votre système d’alerte précoce. Des temps de scrub longs peuvent indiquer croissance de taille, contention, ou disques faibles.

Décision : Si le temps de scrub augmente, prévoyez des fenêtres de maintenance plus longues ou plus de vdevs ; examinez aussi la santé des disques.

Task 13: Check per-disk SMART indicators (predict the next failure, not the last one)

cr0x@server:~$ sudo smartctl -a /dev/sdb | 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       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1

Signification : Les secteurs pending et uncorrectable sont un signal « ce disque négocie avec la réalité ».

Décision : Remplacez proactivement les disques montrant des counts pending/uncorrectable croissants, surtout avant un cycle d’extension/resilver prévu.

Task 14: Validate special vdev usage (if present)

cr0x@server:~$ zpool list -v tank
NAME         SIZE   ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
tank         109T   71.2T  37.8T        -         -    29%    65%  1.00x  ONLINE
  raidz2-0   109T   71.2T  37.8T        -         -    29%    65%
special         -      -      -        -         -      -      -

Signification : Si vous avez une classe spéciale, vous devez la surveiller comme un pool dans le pool (allocation, erreurs, usure).

Décision : Si les périphériques spéciaux approchent une forte utilisation, étendez-les (avec précaution) avant que la pression d’allocation métadonnées n’atteigne un point critique.

Task 15: See what’s actually writing now (tie capacity to offenders)

cr0x@server:~$ sudo arcstat 5 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:00:05  2.1K   320     13   120    5    40    2   160    7  98.4G  110G
12:00:10  2.3K   410     15   180    6    50    2   180    7  98.1G  110G
12:00:15  2.2K   360     14   140    6    45    2   175    7  98.2G  110G

Signification : Des taux de miss élevés impliquent plus de lectures disque ; si couplé à un pool presque plein, la latence explose.

Décision : Si l’ARC est sous-dimensionné pour le working set, prévoyez des montées en RAM avant d’accuser les disques. Les plans de capacité doivent inclure la RAM pour le cache.

Manuel de diagnostic rapide

Quand quelqu’un dit « le stockage est lent », vous n’avez pas le temps de débats philosophiques sur CoW. Vous avez besoin d’une séquence de triage qui
trouve rapidement le goulot et indique l’action suivante.

Première étape : êtes-vous à court d’espace (ou effectivement à court) ?

• Exécutez zpool list et regardez CAPACITY et FREE.
• Exécutez zfs list et cherchez des datasets dont USED inclut une énorme utilisation par snapshots.
• Vérifiez les reservations/refreservations qui « cachent » de l’espace libre.

Si l’utilisation du pool est élevée (surtout >85%), traitez cela comme la cause probable des pics de latence jusqu’à preuve du contraire.
La solution est généralement « ajouter de l’espace » ou « supprimer des snapshots », pas du tuning noyau.

Deuxième étape : est-ce IOPS/latence, bande passante, ou CPU ?

• zpool iostat -v 5 pour voir si la charge est concentrée sur un vdev et si les disques sont saturés.
• Niveau système : iostat -x 5 et vmstat 5 pour voir les profondeurs de queue, await times, et CPU steal/saturation.
• Si RAIDZ et écritures petites lourdes : vérifiez l’utilisation CPU et la charge d’interruptions ; le travail de parité n’est pas gratuit.

Troisième étape : êtes-vous en mode maintenance ou en mode défaillance ?

• zpool status pour resilver/scrub en cours, erreurs, ou périphériques lents.
• Vérifications SMART pour les disques avec secteurs pendants.
• Vérifiez les changements récents de config : compression, sync, recordsize, propriétés de vdev spécial.

Quatrième étape : l’ARC est-il sous pression ou le working set est-il mal assorti ?

• arcstat pour les tendances de miss rate et la taille de l’ARC.
• Cherchez des changements soudains de pattern de charge (par ex. un nouveau job d’analytics lisant tout une fois).

Cette séquence évite l’échec classique : passer des heures à tuner alors que le pool est simplement trop plein, ou courir après des « problèmes disque »
alors que c’est un goulot ARC/RAM.

Trois mini-récits d’entreprise issus du terrain

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

Une société SaaS de taille moyenne avait un cluster NFS backé par ZFS pour des images VM. L’équipe stockage avait dimensionné la capacité sur « utilisé actuel
plus 30 % ». Ils étaient fiers du tableur. Il avait du formatage conditionnel et tout.

La mauvaise hypothèse : la rétention des snapshots était « stable ». En réalité, l’équipe de virtualisation avait augmenté la fréquence des snapshots
pour des rollbacks plus rapides pendant une migration. Les snapshots sont passés d’horaires à toutes les 10 minutes pour un sous-ensemble de datasets. Personne n’a prévenu
le stockage ; techniquement, ils « n’avaient pas changé la taille des données ». Techniquement vrai. Opérationnellement sans rapport.

Des semaines plus tard, l’utilisation du pool est entrée en zone dangereuse. Les écritures sont devenues de plus en plus fragmentées. La latence p95 a monté, puis p99 est devenue une falaise.
Les clients NFS ont commencé à expirer sous ce qui semblait être une charge « normale ». Les applications ont accusé le réseau, le réseau a accusé les hyperviseurs, et le stockage a été appelé en dernier,
comme le veut la tradition.

La correction post-incident n’a pas été héroïque. Ils ont audité les plannings de snapshot, appliqué la rétention par classe de dataset, et implémenté des quotas pour qu’« une expérience »
ne puisse pas manger le pool. La planification de capacité a été mise à jour pour inclure la croissance des snapshots comme terme de première classe, pas comme note de bas de page.

La leçon : dans ZFS, « taille des données » est un concept trompeur. Vous devez modéliser le churn et la rétention, sinon vous planifiez pour un monde dans lequel vous ne vivez pas.

Mini-récit 2 : l’optimisation qui a mal tourné

Une organisation financière exploita un mix de bases de données et partages de fichiers. Ils étaient sensibles à la latence I/O en fin de mois. Quelqu’un a remarqué que
la latence d’écriture synchrone était le point douloureux et a décidé de « réparer » rapidement : sync=disabled sur les datasets chauds.

Ça a marché — de façon spectaculaire. Les graphiques de latence se sont aplatis. L’équipe a déclaré victoire et a passé à autre chose. Quelques semaines plus tard, un événement de
coupure d’alimentation a mis hors tension un rack assez longtemps pour hard-resetter un nœud de stockage. Le hardware est revenu. Le pool s’est importé. L’application est revenue.
Puis les bugs d’intégrité ont commencé : incohérences de base de données, transactions récentes manquantes, et le pire type d’incident — perte de données qui ne se révèle pas immédiatement.

La récupération a été douloureuse et politique. Ils ont restauré depuis les sauvegardes, rejoué ce qu’ils pouvaient, et passé des jours à prouver ce qui avait été perdu.
L’ « optimisation » initiale n’était pas malveillante ; elle résultait du fait de traiter les sémantiques de stockage comme un interrupteur de performance.

La correction ennuyeuse était aussi la bonne : ils sont revenus à sync=standard, ont ajouté des périphériques SLOG miroirs avec protection perte de puissance pour les datasets qui en avaient vraiment besoin,
et ont séparé les workloads pour que les bases de données ne combattent pas les partages de fichiers pendant les pics. La planification de capacité a aussi changé — l’endurance et les domaines de panne du SLOG sont
devenus des éléments de conception, pas un ajout en urgence.

La leçon : certaines optimisations sont juste des incidents différés avec de meilleurs graphiques.

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

Une société média avait des pétaoctets d’archive nearline et une petite couche hot pour les projets actifs. Leur ingénieur stockage avait une habitude qui semblait ennuyeuse en réunion : des « exercices de feu »
trimestriels de capacité. Pas de panique, pas de drame. Juste tester les procédures d’extension, valider les sauvegardes, et revoir les courbes de tendance.

Ils maintenaient une règle simple : l’extension commence à 75 % d’utilisation projetée (basée sur un taux de croissance roulant), pas quand le pool atteint 80 % en réalité. Ils avaient aussi une politique de snapshot stricte :
agressive sur les datasets actifs, conservatrice sur les archives, et toujours avec du pruning automatisé. Personne n’a eu le droit de conserver des snapshots infinis parce que « c’est plus sûr ».

Pendant un projet majeur, une équipe interne a commencé à générer soudainement de gros fichiers intermédiaires à churn élevé sur la couche hot. Le taux de croissance a doublé. Le monitoring a flaggé la tendance en quelques jours.
Parce que l’organisation avait déjà testé la procédure, ajouter un nouveau vdev a été opérationnellement sans événement. Ils ont étendu tôt, réaligné les attentes avec les parties prenantes, et évité la spirale familière « on réparera après la deadline ».

L’incident qui n’est pas arrivé est difficile à célébrer. Mais la pratique ennuyeuse — déclencheurs basés sur la tendance, extensions répétées, et application de politiques — a gardé le système stable quand le comportement humain a changé.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: latency spikes as pool hits ~85–95%

Cause racine : pression d’allocation + fragmentation + overhead CoW dans un pool presque plein.

Correction : ajoutez de la capacité (de préférence de nouveaux vdevs), taillez les snapshots, et arrêtez les écritures non critiques. Ne « tunez » pas pour contourner la physique.

2) Symptom: “deleted data but space didn’t return”

Cause racine : les snapshots (ou clones) référencent encore des blocs.

Correction : identifiez l’usage des snapshots (zfs list -t snapshot), réduisez la rétention, évitez les clones longue durée pour les datasets à fort churn.

3) Symptom: pool shows free space, but datasets report low available

Cause racine : quotas/réservations, refreservations, ou effets du slop space.

Correction : auditez zfs get reservation,refreservation,quota ; supprimez ou redimensionnez. Éduquez les équipes : pool free ≠ dataset free.

4) Symptom: “we added faster disks, still slow”

Cause racine : conception à vdev unique limite la concurrence ; ou la charge est IOPS-limited et vous avez ajouté du débit séquentiel.

Correction : ajoutez des vdevs (plus de concurrence), envisagez des miroirs pour l’I/O aléatoire, séparez les workloads par dataset et classe de vdev.

5) Symptom: scrubs/resilvers take forever now

Cause racine : plus de données allouées, disques plus lents, contention, ou pool presque plein causant des patterns d’allocation inefficaces.

Correction : étendez la capacité plus tôt ; planifiez les scrubs en période de faible charge ; enquêtez sur les disques faibles ; évitez de pousser les pools en zones de haute utilisation.

6) Symptom: special vdev fills up, performance falls off a cliff

Cause racine : périphériques spéciaux sous-dimensionnés pour la croissance métadonnées/petits-blocs ; petits blocs redirigés de façon inattendue.

Correction : dimensionnez les vdevs spéciaux de manière conservative ; miroirez-les ; surveillez l’allocation ; ajustez special_small_blocks avec précaution.

7) Symptom: random write performance is awful on RAIDZ

Cause racine : surcharge de parité + patterns read-modify-write + parallélisme vdev insuffisant.

Correction : utilisez des miroirs pour les datasets à écritures aléatoires, ajoutez plus de vdevs RAIDZ plutôt que d’élargir un seul, ajustez recordsize par dataset.

8) Symptom: you can’t expand the pool “the way you planned”

Cause racine : la conception supposait une fonctionnalité ou une procédure non supportée sur votre plateforme/version ; ou contraintes de baies/backplane.

Correction : validez les méthodes d’extension sur la plateforme exacte tôt ; documentez les chemins de croissance supportés ; gardez un plan de migration.

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

Checklist de planification de capacité (nouveau pool)

1. Classifiez les datasets : VM, DB, home, backups, archive — chacun a ses attentes.
2. Définissez les SLO : objectifs de latence, fenêtres de rebuild acceptables, et tolérance au downtime.
3. Choisissez la redondance : miroirs pour I/O mixte/aléatoire ; RAIDZ2/3 pour capacité + débit quand approprié.
4. Choisissez la largeur des vdevs : évitez « un vdev géant » sauf si la charge est vraiment séquentielle et tolérante.
5. Réglez ashift correctement dès le jour zéro.
6. Planifiez l’espace libre : considérez 80 % comme frontière de planification ; gardez un espace d’urgence au-delà.
7. Concevez la politique de snapshot : nommage, fréquence, rétention, et pruning automatisé.
8. Décidez des vdevs spéciaux uniquement si vous allez les miroirer et les surveiller ; dimensionnez pour la croissance.
9. Planifiez la voie d’extension : ajouter des vdevs, remplacer des disques, ou les deux — validez selon les contraintes de la plateforme.
10. Opérationnalisez : monitoring, calendrier de scrub, vérifications SMART, et procédures d’extension répétées.

Plan d’exécution de croissance (pool existant approchant des limites)

1. Mesurez la réalité : utilisation du pool, fragmentation, top datasets, usage snapshots, réservations.
2. Arrêtez l’hémorragie : taillez les snapshots, cappez les datasets hors de contrôle avec des quotas, déplacez les workloads temporaires hors du pool.
3. Choisissez la méthode d’extension :
   • Ajoutez des vdevs quand vous avez besoin de performance et d’un pas de croissance propre.
   • Remplacez les disques quand le châssis est fixe et que vous pouvez supporter de longues fenêtres de resilver.
   • Utilisez l’expansion RAIDZ seulement si votre plateforme la supporte et que vous l’avez testée.
4. Répétez : effectuez une dry run sur un lab ou système de staging ; confirmez le nommage des périphériques et la gestion des pannes.
5. Exécutez avec observabilité : surveillez zpool status, zpool iostat, I/O système et latence applicative.
6. Validation post-extension : vérifiez le nouvel espace, confirmez le calendrier de scrub, confirmez les alertes, et revérifiez les déclencheurs d’espace libre.

Checklist politique qui prévient les reconstructions surprises

• Standardisez la géométrie des vdevs pour chaque tier de stockage.
• Appliquez la rétention des snapshots et taillez automatiquement.
• Exigez une revue d’impact capacité pour les nouveaux projets générant du churn (artifacts CI, scratch analytics, prolifération de templates VM).
• Conservez des procédures d’extension documentées avec notes spécifiques aux versions.
• Organisez périodiquement des « exercices de feu » de capacité : simulez l’extension, vérifiez les sauvegardes, et testez la restauration.

FAQ

1) Quel objectif d’utilisation devrais-je viser sur ZFS ?

Prévoyez d’opérer en dessous d’environ ~80 % pour les pools généraux. Pour les workloads à fort churn (VMs/DBs), visez plus bas si vous tenez à la latence tail.
Traitez 85 % comme « exécuter l’extension », pas « commencer à réfléchir ».

2) Les miroirs sont-ils toujours meilleurs que RAIDZ ?

Non. Les miroirs sont généralement meilleurs pour l’I/O aléatoire et une latence prévisible. RAIDZ est souvent meilleur pour l’efficacité en capacité et le débit séquentiel.
L’erreur est de choisir RAIDZ pour économiser de l’espace puis d’attendre des IOPS de type miroir sous des charges VM.

3) Puis-je changer le niveau RAIDZ plus tard (RAIDZ1 vers RAIDZ2) ?

Dans de nombreux environnements, non sans reconstruction ou migration complexe. Traitez le niveau de redondance comme une décision jour-0. Si vous hésitez,
choisissez plus de parité, pas moins.

4) Pourquoi la suppression de fichiers ne libère-t-elle pas d’espace ?

Les snapshots (ou clones) conservent les anciens blocs référencés. Supprimer le fichier live ne retire qu’une référence. L’espace revient quand toutes
les références sont parties — souvent après le pruning des snapshots.

5) Comment planifier la capacité pour les snapshots ?

Estimez en fonction du churn : données modifiées par jour × fenêtre de rétention. Pour les datasets à fort churn, les snapshots peuvent approcher une seconde copie entière au fil du temps.
Mesurez avec zfs list -t snapshot et suivez la tendance.

6) Dois-je activer la déduplication pour économiser de l’espace ?

Habituellement non, sauf si vous avez un workload prouvé favorable à la déduplication et suffisamment de RAM (ou une conception spécialisée) pour la supporter en sécurité.
Les erreurs de dedup peuvent transformer les plans de capacité en incidents de performance.

7) Quand les vdevs spéciaux ont-ils du sens ?

Quand vous avez des pools HDD souffrant de workloads lourds en métadonnées (beaucoup de petits fichiers, répertoires, snapshots) et que vous pouvez miroirer des périphériques rapides et bien
les surveiller. Ils sont puissants — et impitoyables.

8) Ajouter un SLOG est-il la même chose qu’ajouter un cache ?

Non. SLOG améliore la latence des écritures synchrones. Si votre workload n’effectue pas d’écritures sync, vous ne verrez pas beaucoup d’avantage. N’achetez pas un SLOG pour régler une lenteur générale.

9) Quelle est la façon la plus sûre d’étendre la capacité sans interruption ?

Ajouter un nouveau vdev est communément le chemin le moins perturbant si vous avez des baies libres et un design cohérent. Remplacer les disques en place peut aussi se faire en ligne,
mais ça étire le risque sur une plus longue fenêtre.

10) Combien de disques par vdev RAIDZ devrais-je utiliser ?

Cela dépend de la charge et de la tolérance au rebuild. Les vdevs très larges augmentent la complexité de rebuild et peuvent nuire au comportement I/O aléatoire.
Beaucoup d’équipes préfèrent plusieurs vdevs de taille modérée plutôt qu’un très large pour mieux gérer la concurrence et la flexibilité opérationnelle.

Conclusion : prochaines étapes à exécuter cette semaine

La planification de capacité ZFS est l’art de choisir le futur que vous voulez : extensions ennuyeuses, latence prévisible et pannes récupérables.
La mauvaise conception n’explose pas toujours immédiatement. Elle accumule simplement des intérêts jusqu’à ce que le pool soit plein et que le graphe devienne vertical.

1. Exécutez les commandes d’audit ci‑dessus et notez : utilisation du pool, fragmentation, top datasets, usage snapshots, réservations et temps de scrub.
2. Définissez un déclencheur d’espace libre lié à la tendance (pas aux sentiments) : commencez l’extension à 75 % projeté, exécutez avant 85 % réel.
3. Standardisez les politiques de dataset : recordsize, compression, quotas et rétention de snapshots par classe.
4. Décidez de votre voie de croissance et répétez-la : ajout de vdevs, remplacement de disques, ou (si supporté) expansion RAIDZ — avec une procédure de rollback.
5. Faites une amélioration structurelle : plus de concurrence vdev pour les workloads IOPS, ou vdevs spéciaux miroir pour les pools riches en métadonnées.

Faites cela, et vous passerez moins de temps à négocier des urgences de stockage et plus de temps à exploiter des systèmes qui se comportent comme s’ils avaient été conçus intentionnellement.