Tableau de santé ZFS : métriques indispensables à suivre (ou vous êtes aveugle)

Ce que signifie « sain » pour ZFS (et ce que ça ne signifie pas)

« La santé » ZFS n’est pas juste « pool est ONLINE. » C’est comme déclarer un patient en bonne santé parce qu’il est techniquement debout.
La vraie santé, c’est : les données sont correctes, la redondance est préservée, le temps de récupération est borné, et les performances sont prévisibles sous charge.

Un tableau utile répond continuellement à cinq questions :

1. Mes données sont-elles toujours protégées ? (redondance intacte ; pas de corruption silencieuse qui s’accumule ; pas de tendance inquiétante des checksums.)
2. Suis-je sur le point de perdre la protection ? (scrub qui trouve de plus en plus d’erreurs ; reallocations SMART qui augmentent ; risque de resilver qui monte.)
3. Le pool est-il assez rapide pour la charge ? (distribution de la latence ; files d’attente ; comportement des écritures sync ; équilibre des vdev.)
4. Le pool ralentit-il avec le temps ? (fragmentation, pool plein, pression sur les métadonnées, thrash de l’ARC, saturation des special vdev.)
5. Puis-je récupérer rapidement ? (temps de resilver ; disponibilité des spares ; latence de réplication ; respect du calendrier des scrubs.)

Ce que cela ne signifie pas : « CPU faible », « le réseau a l’air OK », ou « personne ne m’a encore appelé. » ZFS peut cacher beaucoup de douleur derrière
le buffering et les écritures asynchrones jusqu’à ce qu’une charge syncvienne demander la vérité.

Faits et contexte historique (pourquoi ces métriques existent)

• ZFS est né chez Sun au milieu des années 2000 avec l’objectif explicite d’intégrité de bout en bout—des checksums sur tout, pas seulement sur les métadonnées.
• « Scrub » n’est pas un nom mignon : il existe parce que la corruption silencieuse est réelle, et les disques mentent de façon convaincante tant que vous ne lisez pas chaque bloc.
• ARC (Adaptive Replacement Cache) est central pour les performances ZFS ; ce n’est pas un ajout. ZFS est conçu en supposant un cache grand et intelligent.
• L2ARC est arrivé plus tard comme cache de lecture de second niveau sur des périphériques rapides, mais ce n’est pas magique : il a besoin de RAM pour les métadonnées et peut consommer du CPU.
• ZIL et SLOG sont souvent mal compris : le ZIL est toujours présent ; un SLOG est simplement un dispositif séparé pour stocker le ZIL de manière plus sûre/rapide.
• Copy-on-write (CoW) échange la simplicité du réécriture en place contre la cohérence. Le prix est la fragmentation et la nécessité de surveiller l’espace libre.
• « RAIDZ n’est pas RAID » en comportement opérationnel : la reconstruction (resilver) ne lit que les blocs alloués, ce qui peut être plus rapide, mais punit quand même les disques lents.
• OpenZFS a élargi l’écosystème à illumos, FreeBSD, Linux et d’autres ; c’est pourquoi certaines commandes et kstats diffèrent selon la plateforme.
• Les special vdevs (métadonnées/petits blocs) sont puissants mais tranchants en exploitation : perdre le special vdev peut vous faire perdre le pool.

Ce ne sont pas des anecdotes de quiz. Elles expliquent pourquoi le tableau doit être orienté vers l’intégrité et la latence, pas seulement le débit.

Les métriques à suivre absolument (et comment les interpréter)

1) État du pool et compteurs d’erreurs (intégrité d’abord)

Votre bandeau supérieur doit être brutalement simple : état du pool et compteurs d’erreurs par vdev et par périphérique :
erreurs de lecture, erreurs d’écriture, erreurs de checksum. Les erreurs de checksum sont celles qui doivent vous faire vous redresser.
Les lectures et écritures peuvent échouer de façon transitoire ; les erreurs de checksum signifient que les données ne correspondaient pas à ce que ZFS avait écrit.

Suivez :

• État du pool : ONLINE/DEGRADED/FAULTED
• Compteurs d’erreurs par périphérique feuille
• Événements « errors: Permanent errors have been detected… »
• Nombre de périphériques dégradés/manquants

Règle de décision : tout trend non nul d’erreurs de checksum est un incident jusqu’à preuve du contraire. Pas un ticket. Un incident.

2) Métriques de scrub : dernier scrub, durée, erreurs trouvées

Les scrubs sont votre sérum de vérité périodique. Si vous ne scrubez pas, vous misez l’entreprise sur le fait que les disques se comporteront lorsque cela comptera.
Un tableau doit afficher :

• Temps depuis le dernier scrub terminé
• Durée du scrub (et son évolution)
• Erreurs trouvées pendant le scrub
• Taux de scrub (MB/s), surtout sur les grands pools

Schéma à surveiller : des scrubs qui prennent de plus en plus chaque mois corrèlent souvent avec un pool qui se remplit, plus fragmenté, ou un disque qui se dégrade silencieusement.

3) Métriques de resilver : heure de début, progression, estimation de fin

Le temps de resilver est un risque opérationnel. Pendant un resilver, vous avez une redondance réduite et une exposition accrue à une seconde défaillance.
Suivez :

• Resilver en cours
• Taux de scan et ETA
• Nombre de resilvers lors des N derniers jours (des resilvers fréquents suggèrent du matériel marginal)

Décision : si le temps de resilver est « des jours », vous ne gérez pas un système de stockage ; vous gérez un kiosque à loterie. Ajustez le design : plus de vdevs, miroirs,
moins de grands groupes RAIDZ, ou disques plus rapides, selon les contraintes.

4) Pression de capacité : % utilisé, % libre et, crucialement, fragmentation de l’espace libre

ZFS a une falaise de performance. Ce n’est pas un mythe. Au-delà d’un certain remplissage, les allocations deviennent plus difficiles, la fragmentation augmente, et la latence explose sous charge.
Suivez :

• Pourcentage d’allocation du pool
• Quotas/réservations des datasets (ils peuvent masquer une vraie pénurie)
• Fragmentation de l’espace libre (niveau pool)

Seuil opinionné : considérez 80% d’utilisation du pool comme « jaune », 90% comme « rouge ».
Certains pools survivent au-delà, mais vous le payez en latence.

5) Latence : pas seulement la moyenne, mais la distribution et la latence des écritures sync

Les graphiques de débit rassurent. Les graphiques de latence gardent les systèmes en vie. Vous voulez :

• Latence lecture p50/p95/p99 par pool et par vdev
• Latence écriture p50/p95/p99
• Latence des écritures sync (surtout si vous servez des bases de données, NFS ou disques de VM)
• Profondeur de file d’attente (périphérique et pipeline ZFS)

Si le p99 est moche, les utilisateurs parleront de « lenteur aléatoire ». Vous appellerez ça « un mardi. »

6) IOPS et bande passante par vdev (le déséquilibre vous montre où le feu est)

Les pools ZFS sont des agrégats. Le goulot est généralement un vdev, un disque, ou une classe de périphérique (p. ex. special vdev, SLOG).
Suivez :

• IOPS et bande passante par vdev de premier niveau
• Latence par vdev
• Pourcentage d’occupation du disque

Décision : si un vdev est constamment plus chaud, corrigez le layout ou le placement de la charge. Ne « tweakez » pas autour d’un problème structurel.

7) Métriques ARC : taille, ratio de hit, évictions, et « l’ARC se bat-il avec l’OS ? »

L’ARC peut cacher des péchés. Ou les exposer. Vous avez besoin de :

• Taille ARC vs target
• Ratio de hit (global, et par données vs métadonnées si disponible)
• Taux d’éviction
• Signaux de pression mémoire (activité de swap, risque OOM)

Attention : un fort ratio de hit ARC peut être sans signification si votre charge est en streaming. Le vrai signal est : atteignez-vous vos SLO de latence ?

8) Métriques L2ARC (si utilisé) : ratio de hit, taux d’alimentation, et amplification d’écriture

L2ARC aide les charges lecture-intensive et cache-friendly. Il peut aussi simplement user des SSD sans rien accomplir.
Suivez :

• Taille L2ARC et ratio de hit
• Taux de « feed » (combien vous y écrivez)
• Indicateurs d’usure SSD (depuis SMART)

Décision : si le ratio de hit L2ARC est faible et que le taux de feed est élevé, c’est probablement un placebo coûteux.

9) Métriques ZIL/SLOG : taux d’écritures sync, latence SLOG, et santé du périphérique

Si vous exportez NFS en sync, exécutez des bases de données ou hébergez des disques de VM, le comportement du ZIL définira votre pire journée.
Suivez :

• IOPS d’écritures sync
• Latence et erreurs du périphérique SLOG
• Utilisation et contention du SLOG

Un SLOG qui est « ok » jusqu’à atteindre la throttling thermique est une recette classique d’incident.

10) Paramètres au niveau dataset qui changent la réalité : recordsize, volblocksize, compression, atime, sync

Les datasets ZFS sont des frontières de politique. Votre tableau doit pouvoir corréler les performances avec les réglages que vous appliquez :

• recordsize (systèmes de fichiers) et volblocksize (zvols)
• algorithme et ratio de compression
• atime (souvent des écritures gaspillées)
• sync (standard/always/disabled)

Le ratio de compression n’est pas seulement « espace économisé ». C’est aussi « moins d’IO requis » si le CPU est disponible. Surveillez les deux.

11) SMART et santé des périphériques : sectors réalloués, erreurs média, température, et événements de perte d’alimentation

ZFS peut corriger certaines erreurs. Il ne peut pas corriger un disque qui meurt lentement pendant que vous l’ignorez.
Suivez :

• Nombre de secteurs réalloués / erreurs média
• UDMA CRC errors (les câbles/backplanes comptent)
• Température et flags de throttling thermique
• NVMe percent used / niveau d’usure

Décision : remplacez les disques sur tendance, pas sur héroïsme. Attendre « FAILED » est la façon dont on finit par resilver pendant un week-end férié.

12) Signaux de réplication et sauvegarde : lag, dernière réussite, et « avons-nous vraiment testé la restauration ? »

Un tableau de santé sans statut réplication/sauvegarde est du théâtre. Suivez :

• Heure de la dernière snapshot et respect de la rétention
• Lag de réplication (temps et octets)
• Dernier send/receive réussi
• Récence d’un test de restauration (oui, ça appartient au tableau)

Une idée paraphrasée de W. Edwards Deming convient bien aux opérations : Sans données, vous n’êtes qu’une autre personne avec une opinion. (idée paraphrasée, attribuée à W. Edwards Deming)

Blague n°1 : ZFS est comme un bon comptable—tout est checksummed, et il se souviendra absolument de ce que vous avez essayé de « juste ignorer ».

Tâches pratiques : commandes, sens de la sortie et décisions (12+)

Ce sont des tâches que vous pouvez exécuter aujourd’hui. L’important n’est pas la commande. L’important est ce que vous faites après avoir lu la sortie.
Les exemples supposent OpenZFS sur Linux ; ajustez les chemins pour votre plateforme si nécessaire.

Task 1: Confirm pool health and error counters

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:12:33 with 0 errors on Sun Dec 22 02:18:10 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 cela signifie : « ONLINE » est nécessaire mais pas suffisant. Les compteurs comptent. Tout CKSUM non nul est un drapeau rouge ; READ/WRITE aussi, mais CKSUM est plus effrayant.

Décision : Si les erreurs sont non nulles, ouvrez un incident : identifiez le périphérique, vérifiez le câblage/backplane, exécutez SMART, et planifiez le remplacement. Si des erreurs CKSUM répétées apparaissent, n’attendez pas.

Task 2: Watch for slow or stalled scrub/resilver

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 02:10:03 2025
        4.12T scanned at 610M/s, 2.01T issued at 298M/s, 18.3T total
        0B repaired, 10.97% done, 0 days 15:22:10 to go
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 cela signifie : « scanned » vs « issued » peuvent diverger ; «issued» reflète l’IO réel. Des ETA longues peuvent indiquer des disques lents, de la contention, ou du throttling.

Décision : Si l’ETA du scrub explose ou si le taux «issued» s’effondre sous charge normale, investiguez la latence par disque et les erreurs. Envisagez de planifier les scrubs hors-peak et vérifiez les throttles de scrub.

Task 3: Check pool capacity and fragmentation risk

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME              USED  AVAIL  REFER  MOUNTPOINT
tank             72.4T  9.63T   128K  /tank
tank/vm          41.1T  9.63T  40.9T  /tank/vm
tank/backups     28.7T  9.63T  28.7T  /tank/backups
tank/home        2.58T  9.63T  2.58T  /tank/home

Ce que cela signifie : « AVAIL » est partagé entre les datasets sauf si des réservations sont en place. Un pool avec ~88% utilisé est déjà dans la zone « falaise de latence » pour de nombreuses charges.

Décision : Si vous êtes en tendance vers 85–90% utilisé, arrêtez d’ajouter des données. Gagnez du temps en expirant des snapshots, déplaçant des données froides, ajoutant des vdevs, ou augmentant la capacité. Ne « tweakez » pas pour vous en sortir.

Task 4: Surface dataset policies that change write behavior

cr0x@server:~$ zfs get -o name,property,value -s local,received recordsize,compression,atime,sync tank/vm
NAME     PROPERTY     VALUE
tank/vm  recordsize   128K
tank/vm  compression  lz4
tank/vm  atime        off
tank/vm  sync         standard

Ce que cela signifie : Ces propriétés influencent directement la taille d’IO et la sémantique de durabilité. «sync=always» peut écraser la latence sur un SLOG faible ; «sync=disabled» peut fausser les performances en risquant la perte de données.

Décision : Validez que les propriétés correspondent à la charge. Si vous avez mis sync sur «disabled» pour «résoudre» des performances, vous n’avez pas résolu les performances—vous avez changé les règles de la physique.

Task 5: Measure real-time IO load and latency by vdev

cr0x@server:~$ sudo zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        72.4T  9.63T  3.12K  1.88K  612M  241M
  raidz2-0                  72.4T  9.63T  3.12K  1.88K  612M  241M
    sda                         -      -    520    310   98M   41M
    sdb                         -      -    510    305   96M   40M
    sdc                         -      -    540    312  101M   41M
    sdd                         -      -    105    328   22M   39M
    sde                         -      -    525    309   99M   40M
    sdf                         -      -    520    316   98M   40M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Un disque (sdd) fait beaucoup moins de lectures mais des écritures similaires : cela peut indiquer des erreurs de lecture, des lectures lentes, ou un problème de chemin provoquant des répétitions ailleurs.

Décision : Creusez ce périphérique : SMART, câblage, contrôleur, et logs du noyau. Si le vdev est déséquilibré, les temps de resilver et de scrub souffrent, tout comme votre p99.

Task 6: Check ARC behavior (Linux)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|c_min|hits|misses|demand_data_hits|demand_data_misses) '
size                            4    17179869184
c_min                           4     4294967296
c_max                           4    34359738368
hits                            4    9140284432
misses                          4     821739122
demand_data_hits                4    6021139981
demand_data_misses              4     611229880

Ce que cela signifie : La taille ARC, la cible max, et les compteurs hit/miss vous donnent l’efficacité du cache. Un faible ratio de hit sous une charge de lectures aléatoires suggère que vous avez besoin de plus de RAM ou d’un autre layout.

Décision : Si les misses sont élevés et la latence aussi, envisagez d’ajouter de la RAM avant d’ajouter des caches SSD « fantaisie ». Si votre charge est en streaming, ne réagissez pas excessivement aux misses ; concentrez-vous sur le débit et le comportement d’écriture.

Task 7: Confirm there’s no memory pressure hiding behind ARC

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           256Gi       118Gi        12Gi       2.0Gi       126Gi       136Gi
Swap:            0B          0B          0B

Ce que cela signifie : La mémoire «available» compte. Si l’available s’effondre et que le swap commence à tourner, l’ARC va réduire et votre stockage deviendra soudainement «lent» partout.

Décision : Si l’hôte swappe, traitez cela comme un incident de performance. Corrigez la pression mémoire, réduisez les workloads co-localisés, ou limitez l’ARC intentionnellement.

Task 8: Check per-disk latency and queueing (OS-level)

cr0x@server:~$ iostat -x 2 2
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.42    0.00    5.18    8.70    0.00   75.70

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  %util
sda             85.0    51.0    98.0    41.0    1680.0     7.2    42.0     48.0     32.0   96.0
sdb             82.0    49.0    96.0    40.0    1676.0     6.8    39.0     44.0     31.0   94.0
sdc             88.0    52.0   101.0    41.0    1672.0     6.9    40.0     46.0     31.0   95.0
sdd             18.0    55.0    22.0    39.0    1490.0    18.5   210.0    420.0     26.0   99.0

Ce que cela signifie : sdd a un énorme r_await et une file profonde. C’est votre fragment de disque problématique. ZFS attendra parce que la parité/miroir en a besoin.

Décision : Remplacez le disque, réparez le chemin, ou migrez le vdev vers du matériel plus sain. Tuner ZFS ne fera pas arrêter un disque en train de mourir.

Task 9: Pull SMART/NVMe health and decide on proactive replacement

cr0x@server:~$ sudo smartctl -a /dev/sdd | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count|Temperature_Celsius'
  5 Reallocated_Sector_Ct   0x0033   097   097   010    Pre-fail  Always       -       48
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       6
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       6
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   041   053   000    Old_age   Always       -       59

Ce que cela signifie : Pending et uncorrectable sectors plus une température élevée : ce disque n’est pas « ok ». Il négocie avec l’entropie.

Décision : Remplacez-le. Si il est chaud, corrigez la circulation d’air aussi. Si plusieurs disques montrent des tendances similaires, suspectez le refroidissement du châssis, le backplane, ou un lot défectueux.

Task 10: Check ZFS events for silent warnings

cr0x@server:~$ sudo zpool events -v | tail -n 20
TIME                           CLASS
Dec 24 2025 14:18:03.512410000  ereport.fs.zfs.io
        vdev_path: /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_9JH2ABCD
        vdev_guid: 1234567890123456789
        zio_err: 5
        zio_offset: 8723412992
        zio_size: 131072
        zio_flags: 180880
        parent_guid: 9876543210987654321

Ce que cela signifie : ZFS vous parle d’erreurs IO avec du contexte. Ces événements précèdent souvent un statut « DEGRADED » complet.

Décision : Corrélez les événements avec SMART et les logs du noyau. Escaladez si le taux d’événements augmente. Quelques erreurs IO peuvent vite mener à un resilver.

Task 11: Validate ashift (the performance foot-gun you don’t notice until it hurts)

cr0x@server:~$ sudo zdb -C tank | egrep 'ashift|vdev_tree' -n | head
34:        vdev_tree:
57:            ashift: 12

Ce que cela signifie : ashift=12 implique des secteurs 4K. Si vous avez créé un pool avec ashift=9 sur des disques 4K, vous obtenez une amplification read-modify-write et de la latence triste.

Décision : Si ashift est incorrect, planifiez une migration. Vous ne pouvez pas le corriger sur place. C’est pourquoi la création de pool doit être traitée comme la conception d’un schéma.

Task 12: Confirm special vdev usage (if present) and whether it’s saturating

cr0x@server:~$ sudo zpool status 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
          special
            nvme0n1                  ONLINE       0     0     0

Ce que cela signifie : Un special vdev existe. Cela signifie que les métadonnées (et possiblement les petits blocs) vivent là. S’il est surchargé ou tombe en panne, vous pouvez être dans un monde de douleur.

Décision : Assurez-vous que le special vdev a de la redondance (miroir) et surveillez sa latence et son usure. Si c’est un périphérique unique, corrigez ce design avant qu’il ne vous corrige.

Task 13: Check snapshot load and retention creep

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,creation | head -n 8
NAME                               USED  REFER  CREATION
tank/vm@auto-2025-12-25-0000        0B    40.9T  Thu Dec 25 00:00 2025
tank/vm@auto-2025-12-24-0000        0B    40.9T  Wed Dec 24 00:00 2025
tank/vm@auto-2025-12-23-0000       12.4G  40.9T  Tue Dec 23 00:00 2025
tank/vm@auto-2025-12-22-0000       10.1G  40.9T  Mon Dec 22 00:00 2025
tank/vm@auto-2025-12-21-0000       11.7G  40.9T  Sun Dec 21 00:00 2025
tank/vm@auto-2025-12-20-0000        9.8G  40.9T  Sat Dec 20 00:00 2025
tank/vm@auto-2025-12-19-0000       10.9G  40.9T  Fri Dec 19 00:00 2025

Ce que cela signifie : «USED» des snapshots n’est pas zéro une fois que les blocs divergent. La prolifération de snapshots consomme silencieusement de l’espace et peut dégrader les performances.

Décision : Si les snapshots mangent le pool, corrigez la rétention. Si la conformité exige une longue rétention, budgétez la capacité en conséquence et évitez de stocker des datasets très volatils dans le même pool.

Task 14: Spot replication lag via recent snapshot times (simple but effective)

cr0x@server:~$ zfs get -H -o value creation tank/vm@auto-2025-12-25-0000
Thu Dec 25 00:00 2025

Ce que cela signifie : Si la dernière snapshot est ancienne, la réplication ne peut pas être à jour non plus (sauf si vous répliquez sans snapshots, ce qui est un autre risque).

Décision : Si le calendrier des snapshots dérive, considérez le lag de réplication comme un incident RPO. Réparez la pipeline, pas seulement l’exécution ratée.

Cahier de diagnostic rapide : trouver le goulot en minutes

Le but n’est pas de devenir un magicien. Le but est d’éviter de passer deux heures à débattre si c’est « le réseau » tandis que le pool est à 92% plein.
Voici l’ordre qui gagne en production.

Step 1: Confirm you’re not already in a data-risk event

• Vérifier : zpool status -v (erreurs, DEGRADED, scrub/resilver en cours)
• Vérifier : zpool events -v | tail (nouvelles erreurs IO)
• Vérifier : SMART pour les périphériques suspects (pending/uncorrectable sectors)

Si des erreurs de checksum apparaissent, arrêtez de chasser la performance. Vous êtes en mode intégrité maintenant.

Step 2: Identify whether the pain is latency, throughput, or sync semantics

• Vérifier : zpool iostat -v 1 (qui est chaud ? quel vdev ?)
• Vérifier : iostat -x 1 (await, %util, profondeur de file par disque)
• Demander : La charge est-elle sync-heavy (NFS sync, bases de données, écritures VM) ?

Symptomatique classique : le débit semble « ok », mais la latence p99 est horrible et les utilisateurs se plaignent. C’est de la mise en file, de la contention, ou un périphérique lent.

Step 3: Check capacity and fragmentation pressure

• Vérifier : zfs list et tendances d’utilisation du pool
• Vérifier : nombre et croissance des snapshots

Si le pool est très plein, vous pouvez perdre des jours à « tuner » alors que l’allocateur continue de lutter. Achetez d’abord de l’espace.

Step 4: Check cache effectiveness and memory pressure

• Vérifier : stats ARC (hit/miss, taille vs c_max)
• Vérifier : free -h et activité swap

Le thrash ARC transforme des lectures aléatoires petites en seeks disque. Votre tableau doit vous laisser voir ce basculement sur des semaines, pas seulement après le pager.

Step 5: Check “policy knobs” and recent changes

• Vérifier : propriétés dataset (sync, recordsize, compression)
• Vérifier : déploiements récents : mises à jour du kernel, firmware contrôleur, nouvelles charges, nouvelles options de montage NFS

La plupart des incidents ne sont pas mystérieux. Ils sont juste non corrélés. Corrélez-les.

Trois mini-récits d’entreprise (ce qui arrive vraiment)

Mini-story #1: The incident caused by a wrong assumption (“ONLINE means healthy”)

Une société SaaS de taille moyenne faisait tourner des bases clients sur des disques VM stockés sur ZFS. Le tableau du pool avait une grande tuile verte :
«tank: ONLINE.» Tout le monde se sentait bien. Quand les plaintes de performance sont arrivées, l’équipe stockage montrait cette tuile et disait,
«C’est le stockage, c’est OK. Ça doit être les hyperviseurs.»

Le premier indice réel fut une augmentation lente des temps de requête qui ne corrélait pas avec le CPU ou le réseau. Puis la fenêtre de sauvegarde a commencé
à déborder sur les heures ouvrables. Rien de dramatique—juste une impression croissante que tout était plus lourd qu’avant.
L’équipe a finalement lancé zpool status -v et a trouvé un compteur de checksum non nul sur un disque qui était «stable» depuis des semaines.
Les scrubs passaient, mais prenaient plus de temps, et personne ne suivait la durée.

L’hypothèse erronée était que ZFS «gèrerait» et qu’on serait appelé quand ça compterait. Mais ZFS est prudent : il réessaie,
corrige, et continue de servir. Cette gentillesse est précisément la raison pour laquelle vous devez le surveiller. Ces compteurs de checksum racontaient l’histoire :
un chemin de disque corrompait des lectures de façon intermittente, corrigées par la redondance—jusqu’à ce que ce ne soit plus le cas.

La correction fut ennuyeuse : remplacer le disque, inspecter le slot backplane, et ajouter des alertes sur les deltas de checksum (pas seulement le compte absolu),
plus un panneau «durée de scrub». Le résultat fut tout aussi ennuyeux : la fois suivante qu’un chemin est devenu instable, ils l’ont remplacé avant des symptômes visibles clients.
C’est à ça que ressemble le succès en stockage : rien ne se passe.

Mini-story #2: The optimization that backfired (“sync=disabled is free performance”)

Une équipe plateforme interne avait un système CI reposant sur NFS. Il était «lent» aux heures de pointe. Quelqu’un a trouvé un article de blog et a basculé
sync=disabled sur le dataset, parce que la charge était «de simples artefacts de build temporaires». Le tableau a immédiatement paru meilleur.
La latence a chuté. Tout le monde a célébré. Quelqu’un a même suggéré de généraliser le changement sur d’autres datasets.

Une semaine plus tard, un événement d’alimentation a touché le rack. Pas une panne complète du datacenter ; juste un transfert UPS et quelques hôtes qui n’ont pas aimé.
Le système CI est revenu… puis des jobs ont commencé à échouer avec des artefacts corrompus et des fichiers manquants. La nature «temporaire» des artefacts
s’est avérée être un mensonge : le système mettait aussi en cache des blobs de dépendances et des sorties de build réutilisées en aval.

ZFS a fait exactement ce qu’on lui avait demandé : avec sync désactivé, il a acquitté les écritures avant qu’elles ne soient sur un stockage stable.
L’équipe avait troqué la durabilité pour la vitesse sans décision de risque formelle. La panne n’était pas l’événement d’alimentation. La panne était le choix de politique.

La correction fut double : remettre sync=standard, et construire une vraie solution :
un SLOG NVMe miroir avec protection contre la perte d’alimentation, plus de l’instrumentation pour la latence des écritures sync.
Après cela, le tableau a montré la vérité : le goulot était les écritures sync, pas une magie aléatoire des performances.

Mini-story #3: The boring practice that saved the day (“scrub schedule + SMART trend alerts”)

Une équipe de services financiers exploitait un grand pool d’archivage. Rien de flashy. Majoritairement des lectures séquentielles, des écritures périodiques, et une rétention stricte.
L’équipe avait une habitude que tout le monde trouvait un peu agaçante : des scrubs mensuels, avec alertes non seulement pour les erreurs mais aussi pour «durée de scrub augmentée de 30%».
Ils suivaient aussi les tendances SMART pour les secteurs pending et la température.

Un mois, la durée du scrub a bondi. Pas d’erreurs, juste plus lent. Le tableau a montré la latence lecture p95 d’un vdev qui augmentait régulièrement,
alors que les autres restaient stables. SMART n’indiquait pas une défaillance catastrophique, mais montrait l’augmentation de «Current_Pending_Sector» sur un seul disque.
Pas assez pour déclencher un remplacement fournisseur, mais suffisant pour déclencher la politique interne de l’équipe.

Ils ont remplacé le disque pendant les heures ouvrables sans drame. Une semaine plus tard, l’ancien disque a échoué complètement sur le banc de test.
L’équipe n’a pas gagné de prix. Ils n’ont pas non plus reçu d’appel à 03:00 avec un pool dégradé et un CEO qui se met soudain à s’intéresser à la parité.

La pratique n’était pas astucieuse. Elle était cohérente. Le stockage récompense la cohérence comme un animal dressé : nourrissez-le de scrubs et d’alertes de tendance, et il se comporte.

Erreurs courantes : symptôme → cause racine → correction

1) “Pool is ONLINE but users report random stalls”

Symptôme : Gel court, pics de latence p99, surtout sous charge mixte.

Cause racine : Un disque lent, des accrochages du contrôleur, ou un déséquilibre de vdev causant de la mise en file. Souvent visible avec iostat -x comme un await/%util élevé sur un seul périphérique.

Correction : Identifiez le disque chaud/lent, vérifiez SMART et les logs, réinsérez/remplacez le matériel. Ajoutez des panneaux de latence par disque, pas seulement le débit du pool.

2) “Everything got slower after we added more data”

Symptôme : Dégradation graduelle des performances, scrubs plus longs, erreurs d’allocation apparaissant en fin de capacité.

Cause racine : Pool trop plein et/ou fortement fragmenté ; snapshots consommant de l’espace ; petits segments libres.

Correction : Ramenez le pool à une utilisation raisonnable. Supprimez/expirez les snapshots de façon responsable, ajoutez de la capacité, rééquilibrez les données. Mettez «pool used %» en page d’accueil avec alertes strictes.

3) “Sync writes are painfully slow”

Symptôme : Bases de données/NFS/VMs montrent une latence de commit élevée ; le débit semble correct pour les workloads asynchrones.

Cause racine : Pas de SLOG, SLOG faible, ou SLOG sans protection contre la perte d’alimentation ; possible aussi : sync=always sur un dataset qui n’en a pas besoin.

Correction : Utilisez un SLOG miroir capable de PLP pour les charges sync sérieuses. Surveillez la latence et les erreurs du SLOG. Ne mettez pas sync=disabled pour «corriger» cela.

4) “We’re seeing checksum errors but SMART looks okay”

Symptôme : CKSUM non nul dans zpool status, souvent en augmentation lente.

Cause racine : Câblage/backplane/contrôleur défaillant, pas forcément le média du disque. Des UDMA CRC errors peuvent apparaître, mais pas toujours.

Correction : Changez câbles/ports, mettez à jour le firmware, déplacez le disque vers une autre baie/contrôleur, puis re-scrub. Traitez les deltas de checksum comme des signaux critiques.

5) “L2ARC didn’t help; SSD wear is high”

Symptôme : Peu ou pas d’amélioration de la latence de lecture ; gros volume d’écritures SSD.

Cause racine : Le working set ne tient pas en RAM ou n’est pas cache-friendly ; L2ARC est alimenté agressivement ; les métadonnées brûlent de la RAM.

Correction : Vérifiez le ratio de hit et le taux de feed. Si ça n’aide pas, retirez-le. Investissez plutôt dans la RAM ou le layout vdev avant d’acheter des SSD placebo.

6) “Resilver takes forever and we feel exposed”

Symptôme : Reconstructions mesurées en jours ; performances dégradées pendant le resilver.

Cause racine : Grands vdevs sur disques lents, pool surchargé, ou trop peu de vdevs (pas assez de parallélisme).

Correction : Redessinez : plus de vdevs, vdevs miroir pour les charges IO aléatoires, ou groupes RAIDZ plus petits. Gardez des spares à portée de main et testez les procédures de remplacement.

Blague n°2 : Si votre seule alerte stockage est «pool FAULTED», votre monitoring est essentiellement un détecteur de fumée qui ne bippe qu’après que la maison ait déménagé.

Listes de contrôle / plan pas-à-pas

Checklist pour le tableau : les panneaux qui comptent

• Panneau intégrité : état du pool, compte DEGRADED/FAULTED, erreurs checksum/lecture/écriture (absolues et delta), événements ZFS récents.
• Panneau scrub & resilver : dernière date de scrub, tendance de durée, erreurs trouvées ; flag resilver actif, taux, ETA.
• Panneau capacité : % utilisé du pool, % libre, usage des datasets, espace utilisé par les snapshots, quotas/réservations anormaux.
• Panneau latence : lecture/écriture p50/p95/p99 par pool et par vdev ; await périphérique ; %util ; profondeur de file.
• Panneau charge : IOPS et bande passante par vdev ; taux d’écriture sync si mesurable ; principaux datasets consommateurs si vous avez de la comptabilité par dataset.
• Panneau cache : taille ARC, ratio de hit, taux d’éviction ; ratio de hit L2ARC et taux de feed (si utilisé).
• Panneau santé périphérique : tendances SMART : pending/uncorrectable/reallocated, erreurs CRC, température, usure NVMe.
• Panneau protection des données : fraîcheur des snapshots, lag de réplication, dernier backup/réplication réussi, date du dernier test de restauration.

Checklist opérations : routines hebdomadaires et mensuelles

1. Hebdomadaire : revoir les deltas de checksum et les logs d’événements ZFS ; investiguer tout mouvement.
2. Hebdomadaire : revoir la tendance de latence p99 par vdev ; identifier les points chauds émergents.
3. Hebdomadaire : revoir la réserve de capacité ; confirmer que vous ne dérivez pas vers 90%.
4. Mensuel : lancer un scrub (ou vérifier qu’il a eu lieu) ; enregistrer la durée et la comparer au baseline.
5. Mensuel : revoir le rapport SMART et les températures ; corriger l’aération avant de remplacer la moitié de la flotte.
6. Trimestriel : tester une restauration (fichiers et dataset), documenter le temps de restauration, et mettre à jour les runbooks.
7. Après tout changement matériel : vérifier les identifiants de périphérique, ashift, et que les alertes pointent toujours vers les bons disques.

Étapes pas-à-pas : quand vous créez un nouveau pool (faire ceci à chaque fois)

1. Décidez du layout vdev selon la charge : miroirs pour IO aléatoire, RAIDZ pour capacité et patterns plutôt séquentiels.
2. Confirmez les attentes ashift avant création. Traitez cela comme irréversible.
3. Définissez les politiques dataset à l’avance : compression activée (lz4), atime off pour la plupart, recordsize/volblocksize raisonnables, sync standard.
4. Programmez le scrub et les alertes avant que des données de production n’arrivent.
5. Mettez en place le monitoring SMART avec alertes basées sur tendances, pas seulement «FAILED».
6. Baselinez les performances (latence sous charge représentative) et conservez-le pour comparaison.

FAQ

1) What’s the single most important ZFS metric?

Les deltas d’erreurs de checksum (et les événements qui les entourent). Les problèmes de performance font mal ; les problèmes d’intégrité ruinent des carrières.
Suivez les comptes absolus et les variations dans le temps par périphérique.

2) How often should I scrub?

Pour la plupart des pools de production : un scrub mensuel est une valeur par défaut raisonnable. Les très grands ou très actifs peuvent nécessiter un réglage, mais «jamais» n’est pas une stratégie.
Si les scrubs sont trop perturbateurs, corrigez la planification et investiguez pourquoi le pool ne tolère pas les lectures séquentielles.

3) Why does ZFS get slow when the pool is nearly full?

Les allocations CoW ont besoin d’espace libre suffisamment contigu. À mesure que l’espace libre diminue et se fragmente, ZFS travaille plus dur pour allouer des blocs, et l’IO devient plus aléatoire.
Des pics de latence apparaissent avant d’atteindre 100%. C’est pourquoi vous alertez tôt.

4) Is ARC hit ratio a reliable KPI?

C’est un outil de diagnostic, pas un KPI. Un faible ratio de hit peut être normal pour des lectures en streaming. Utilisez-le pour expliquer un comportement de latence, pas pour «optimiser un chiffre».

5) When should I use L2ARC?

Quand votre working set est plus grand que la RAM mais reste cacheable, et que vous avez du CPU et de la RAM disponibles pour l’overhead métadonnées.
Si vous pouvez acheter plus de RAM, faites-le d’abord dans de nombreux cas.

6) Do I need a SLOG?

Seulement si vous avez des écritures sync significatives et que vous tenez à la latence (bases de données, NFS en sync, stockage VM).
Si vous en ajoutez un, utilisez des dispositifs avec protection contre la perte d’alimentation et mettez-les en miroir pour la fiabilité.

7) Are checksum errors always a dying disk?

Non. Elles sont souvent causées par le câblage, un HBA défaillant, des problèmes de firmware, ou un slot backplane instable. Mais la correction reste urgente : identifiez le chemin et éliminez la corruption.

8) Should I alert on “pool ONLINE” changing only?

C’est le minimum, et c’est trop tard pour être rassurant. Alertez sur les deltas de checksum, les anomalies de durée de scrub, les tendances SMART, et les pics de latence vdev.
«ONLINE» est le titre ; l’histoire se trouve dans les notes de bas de page.

9) How do I tell if one vdev is the bottleneck?

Utilisez zpool iostat -v et au niveau OS iostat -x pour comparer await/%util par périphérique. Un périphérique de premier niveau saturé avec un await élevé est un coupable classique.
Si un seul vdev top-level est chaud, vous manquez peut-être de nombre de vdevs (pas de taille de disque).

10) What’s a reasonable alert threshold for disk temperature?

Cela dépend de la classe de disque, mais des températures soutenues dans les hauts 50 °C sont un mauvais signe pour la longévité.
Surveillez la tendance : si la température monte sur des semaines, vous avez probablement modifié l’aération ou la densité.

Conclusion : prochaines étapes réalisables cette semaine

Un tableau de santé ZFS n’est pas un seul graphique. C’est un ensemble d’opinions encodées en alertes : intégrité d’abord, puis latence, puis capacité, puis optimisation.
Si vous ne suivez que le débit et «ONLINE», vous apprendrez les problèmes quand les utilisateurs vous l’apprendront—bruyamment.

1. Ajoutez des panneaux en page d’accueil pour : deltas de checksum, durée de scrub, % utilisé du pool, et p99 latence par vdev.
2. Transformez SMART en alertes de tendance : pending/uncorrectable, réalloué, température, et usure NVMe.
3. Rédigez une page de runbook : que faire lorsque les erreurs de checksum augmentent, et que faire lorsque la latence p99 grimpe.
4. Choisissez un calendrier de scrub et rendez-le non optionnel ; alertez lorsqu’il ne s’exécute pas.
5. Arrêtez les «correctifs performance» qui sont en réalité des compromis de durabilité sauf si vous avez pris une décision de risque formelle.

Faites cela, et vous n’êtes plus aveugle. Vous aurez toujours des problèmes—c’est le stockage—mais ce seront des problèmes que vous pouvez voir venir, quantifier, et corriger selon vos conditions.