Stratégie de hot-swap ZFS : comment remplacer des disques sans panique

novembre 10, 2025 • février 3, 2026 • Lecture : 32 min • Views: 8

Cet article vous a aidé ?

Remplacer un disque dans ZFS devrait ressembler à changer un pneu : méthodique, un peu salissant et pas un test de personnalité. Pourtant, en production cela se transforme souvent en exercice d’improvisation collective — quelqu’un fixe des LED qui clignotent, quelqu’un d’autre est connecté en SSH sur le mauvais hôte, et un troisième demande si « DEGRADED » est juste une suggestion.

Ce guide est une stratégie pratique et éprouvée sur le terrain pour hot-swap des disques dans ZFS sans inventer de nouvelles catégories d’incidents. Il est écrit pour les personnes qui exploitent de vrais systèmes : vous tenez à la disponibilité, aux traces d’audit et à ce tableau de bord exécutif qui devient rouge si la latence augmente plus de cinq minutes.

1. État d’esprit : remplacer des disques est normal

ZFS est conçu autour de l’hypothèse que le stockage échoue. Les disques tombent en panne. Les câbles lâchent. Les backplanes lâchent. Les humains échouent avec enthousiasme. ZFS n’exige pas que vous empêchiez la panne ; il exige que vous y répondiez de manière prévisible.

Une bonne stratégie de hot-swap porte moins sur « la bonne commande » et plus sur le contrôle de l’ambiguïté :

Sachez exactement quel périphérique vous retirez. « Probablement /dev/sdb » est la manière de créer un post-mortem d’incident avec danse interprétative.
Faites en sorte que ZFS voie des noms de périphériques stables. Préférez /dev/disk/by-id/ aux /dev/sdX éphémères.
Observez avant et après. Des bases, des logs et des vérifications déterministes transforment « je crois que ça marche » en « ça marche ».
Respectez le resilver. Ce n’est pas de la magie ; c’est du I/O, du CPU et parfois de la douleur.

Une vérité opérationnelle : le hot-swap est rarement la partie dangereuse. La partie dangereuse, ce sont les 45 minutes avant, quand l’équipe se convainc qu’elle a une information parfaite. Spoiler : ce n’est pas le cas. Vous créez une procédure qui fonctionne même quand vous n’avez pas toutes les informations.

Blague n°1 (courte, pertinente) : Un remplacement de disque, c’est comme un exercice d’évacuation — vous découvrez les sorties bloquées quand vous descendez déjà le serveur dans l’escalier.

2. Faits intéressants et contexte historique

Un peu de contexte aide à justifier les décisions modernes de hot-swap ZFS auprès des ingénieurs et de ceux qui demandent « pourquoi ça prend si longtemps ».

ZFS a été conçu avec des checksums de bout en bout pour détecter la corruption silencieuse que les RAID classiques servent joyeusement comme « correct ». C’est pourquoi les erreurs de checksum comptent même quand le système de fichiers « a l’air normal ».
Les rebuilds RAID étaient autrefois majoritairement séquentiels. Les disques modernes de grande capacité et des charges aléatoires ont transformé les rebuilds en événements longs et bruyants ; le comportement du resilver ZFS a évolué pour éviter la lecture d’espace non alloué dans de nombreux cas (selon le type de vdev et les flags de fonctionnalités).
Le problème du « write hole » dans les RAID5/6 traditionnels (perte de courant au milieu d’une mise à jour de stripe) a poussé vers le copy-on-write et les mises à jour transactionnelles — ZFS en a fait une hypothèse de première classe.
Le nommage des périphériques sous Unix a toujours été glissant. Les noms /dev/sdX sont des artefacts d’ordre de découverte ; aux débuts du hotplug, le « même disque » pouvait revenir avec une lettre différente après un reboot. D’où l’usage courant d’identifiants persistants.
Le support matériel du hot-swap a précédé la maturité opérationnelle commune. Backplanes et expanders SAS ont rendu le retrait de disques facile ; les playbooks opérationnels ont pris du retard, d’où le classique « on a arraché le mauvais ».
SMART n’a jamais été une garantie. Beaucoup de disques meurent sans grands préavis SMART. SMART est un système probabiliste d’alerte précoce, pas une prophétie.
« Disques plus gros, mêmes baies » a changé la logique de défaillance. Quand les rebuilds prennent plus de temps, la fenêtre d’exposition augmente. La stratégie de remplacement devient une stratégie de fiabilité, pas juste une corvée de maintenance.
L’auto-réparation de ZFS nécessite de la redondance. ZFS peut détecter la corruption seul ; il ne peut la réparer que lorsqu’il a une bonne copie (miroir/RAIDZ ou fonctionnalités de redondance spéciales).
Opérationnellement, le plus grand risque, ce sont les humains sous pression temporelle. La raison pour laquelle beaucoup d’équipes utilisent des rituels « hors-ligne + LED locate + confirmation du serial » n’est pas de la superstition ; c’est du tissu cicatriciel bien mérité.

3. Principes de base pour un hot-swap sans panique

3.1 Privilégiez l’identité sur la localisation, puis vérifiez la localisation

Votre configuration ZFS devrait suivre les disques par des IDs stables. Mais quand le pool indique « disque X est défectueux », vous devez toujours mapper cela à un emplacement physique et à un numéro de série réel.

Le schéma sûr est :

ZFS signale un membre de vdev en difficulté (par-id recommandé).
Vous mappez cet identifiant au numéro de série.
Vous mappez le numéro de série à un emplacement (outils d’enclosure ou outils du contrôleur).
Vous allumez la LED de localisation, et vous vérifiez d’une seconde manière.

3.2 N’« optimisez » pas au point de perdre des données

Les procédures de hot-swap sont volontairement ennuyeuses. Si vous êtes tenté de sauter des étapes parce que « c’est juste un miroir », rappelez-vous : les miroirs échouent aussi, et le rebuild le plus rapide est celui que vous n’êtes pas obligé de refaire.

Blague n°2 (courte, pertinente) : La seule chose plus permanente qu’un contournement temporaire est un remplacement de disque « rapide » fait sans vérifier le serial.

3.3 Traitez le resilver comme un incident, pas comme une tâche en arrière-plan

Le resilvering concurrence l’I/O de production et peut amplifier les goulots existants. Il est normal d’observer des pics de latence, surtout sur des pools HDD avec des petits writes aléatoires. Planifiez-le, surveillez-le et communiquez à ce sujet.

3.4 Utilisez les spares et les remplacements étagés intentionnellement

Les hot spares peuvent réduire le temps en état dégradé, mais ils peuvent aussi masquer un problème matériel (par ex. backplane défaillant ou chemin de contrôleur instable) en « soignant » le symptôme. Décidez si vous voulez :

Activation automatique des spares pour minimiser la fenêtre de risque, ou
Utilisation manuelle des spares pour garder les humains dans la boucle pour vérification.

4. Pré-vol : ce que vous vérifiez avant de toucher le matériel

Avant de retirer quoi que ce soit, vous voulez répondre à trois questions :

Le pool est-il suffisamment sûr pour survivre à cette opération ? Si vous êtes déjà à un disque de perdre le vdev, arrêtez et réfléchissez.
Le « disque défaillant » est-il réellement le disque ? Ça peut être un câble, un port d’expander, un HBA ou un emplacement d’enclosure.
Avez-vous un bon remplaçant et un plan de rollback ? Le média de remplacement peut être DOA. Le rollback est souvent « réinsérer l’ancien disque », ce qui demande de ne pas l’abîmer en le retirant.

4.1 Snapshot de santé et capture de preuves

Capturez suffisamment d’état pour pouvoir comparer avant/après et défendre vos choix plus tard.

cr0x@server:~$ zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:21:11 with 0 errors on Mon Dec 23 02:10:22 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABC       ONLINE       0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABD       ONLINE       0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABE       FAULTED      0     0    23  too many errors
            ata-WDC_WD101KRYZ-01..._1SGH3ABF       ONLINE       0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABG       ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        /tank/vmstore/vm-102-disk-0

Interprétation : Ce n’est pas « un disque est manquant », c’est pire : une défaillance de périphérique avec erreurs de checksum et erreurs permanentes. Vous pourriez avoir besoin d’une réparation au niveau applicatif pour les fichiers impactés. Néanmoins, remplacer le disque est la première étape.

4.2 Confirmez la marge de redondance

Connaissez ce que votre vdev peut tolérer. Un RAIDZ2 peut survivre à deux pannes de disques par vdev ; un miroir peut en survivre à une par miroir ; un RAIDZ1 vit un peu dangereusement sur de gros disques.

cr0x@server:~$ zpool status tank | sed -n '1,60p'
  pool: tank
 state: DEGRADED
  scan: scrub repaired 0B in 03:21:11 with 0 errors on Mon Dec 23 02:10:22 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ...

Interprétation : Identifiez le type de vdev et combien de membres sont déjà hors-service. Si vous êtes au bord du précipice (par ex. RAIDZ1 déjà dégradé), planifiez une fenêtre de maintenance différente.

4.3 Vérifiez les problèmes systémiques (HBA, câblage, enclosure)

Si plusieurs disques génèrent des erreurs sur le même chemin contrôleur, remplacer un seul disque revient parfois à « traiter la contusion, pas la fracture ».

cr0x@server:~$ dmesg -T | egrep -i 'ata|sas|scsi|reset|I/O error|timeout' | tail -n 30
[Mon Dec 23 11:04:18 2025] sd 3:0:12:0: [sdo] tag#71 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Mon Dec 23 11:04:18 2025] sd 3:0:12:0: [sdo] Sense Key : Medium Error [current]
[Mon Dec 23 11:04:18 2025] sd 3:0:12:0: [sdo] Add. Sense: Unrecovered read error
[Mon Dec 23 11:04:20 2025] mpt3sas_cm0: log_info(0x31111000): originator(PL), code(0x11), sub_code(0x1000)

Interprétation : « Medium Error » pointe vers la surface/média du disque. Si vous voyez plutôt des resets de lien, des resets PHY ou des timeouts sur plusieurs disques, suspectez le câblage, l’expander, le firmware du HBA ou des problèmes thermiques.

5. Identification du disque : la partie qui casse vraiment les équipes

Les échecs de hot-swap ne sont rarement dus à la syntaxe ZFS. Ils sont dus à quelqu’un qui retire le mauvais disque parce que le schéma de nommage était négligé. Les systèmes de production punissent l’ambiguïté.

5.1 Utilisez des identifiants persistants dans ZFS

Lors de la création des pools, utilisez les chemins /dev/disk/by-id. Si votre pool utilise déjà /dev/sdX, vous pouvez toujours remplacer en spécifiant l’ancien périphérique tel que ZFS le connaît, mais planifiez une migration vers un nommage stable à l’avenir.

5.2 Mappez le périphérique ZFS au périphérique OS puis à la baie physique

Commencez par ce que ZFS rapporte (souvent une chaîne by-id). Puis mappez au périphérique kernel, ensuite au numéro de série, puis à l’emplacement d’enclosure.

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep 1SGH3ABE
lrwxrwxrwx 1 root root  9 Dec 23 10:55 ata-WDC_WD101KRYZ-01W..._1SGH3ABE -> ../../sdo

Interprétation : Le by-id défaillant pointe actuellement vers /dev/sdo. « Actuellement » compte — les événements hotplug peuvent réénumérer les périphériques. C’est pourquoi nous vérifions aussi le serial via SMART.

cr0x@server:~$ sudo smartctl -a /dev/sdo | egrep -i 'Model|Serial|Capacity|Reallocated|Pending|Offline_Uncorrectable' 
Device Model:     WDC WD101KRYZ-01W
Serial Number:    1SGH3ABE
User Capacity:    10,000,831,348,736 bytes
  5 Reallocated_Sector_Ct   0x0033   001   001   140    Pre-fail  Always       -       2816
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       12
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       12

Interprétation : Ce disque n’est pas en train de débattre philosophiquement de sa retraite. Des milliers de reallocations et des secteurs en attente signifient « remplacez-moi ». Capturez le serial ; c’est votre ancre de vérité.

5.3 Allumez la bonne LED (quand vous le pouvez)

Sur des serveurs équipés de gestion d’enclosure, vous pouvez localiser la baie via des outils SAS d’enclosure. L’utilitaire exact diffère, mais le principe est : utilisez le serial pour trouver la baie, puis faites-la clignoter.

Si vous n’avez pas de LED de localisation : étiquetez vos tiroirs, maintenez une carte des baies, et ne vous fiez pas à « troisième à partir de la gauche ». Cette phrase a causé des incidents.

6. Procédures pas à pas pour hot-swap (miroir, RAIDZ, spares)

6.1 Flux général sûr (fonctionne pour la plupart des topologies)

Confirmez l’état du pool/vdev et la marge de redondance.
Confirmez l’identité du disque défaillant par serial.
Optionnellement, mettez le disque hors ligne dans ZFS (recommandé quand possible).
Retirez et remplacez physiquement le disque.
Assurez-vous que l’OS voit le nouveau disque et confirmez que son serial correspond au papier du remplacement.
Exécutez zpool replace (ou laissez autoreplace prendre le relai si vous l’avez activé délibérément).
Surveillez le resilver jusqu’à la fin ; vérifiez qu’il n’y a pas de nouvelles erreurs ; lancez un scrub si approprié.

6.2 Remplacement en miroir

Les miroirs sont tolérants et rapides à remettre en service, mais ne confondez pas « tolérant » avec « invincible ». Si vous enlevez le mauvais côté, vous pouvez tomber le miroir et provoquer un incident de service, surtout si le disque restant est déjà marginal.

Approche recommandée :

Mettre hors ligne le membre que vous comptez retirer.
Le remplacer et attacher le nouveau disque.
Privilégier des chemins de périphériques explicites by-id.

6.3 Remplacement RAIDZ

Les resilvers RAIDZ peuvent être plus pénalisants pour les performances, surtout sur des HDD et avec des petits blocs. Si la charge est sensible à la latence, planifiez le remplacement pour une fenêtre plus calme ou ralentissez le comportement du resilver (avec précaution) plutôt que d’espérer le meilleur.

6.4 Spares : hot, cold et « surprise, il s’est activé »

ZFS supporte les spares. Si un spare a pris la place, votre travail devient : remplacer le disque défaillant, puis décider de remettre le spare dans le pool de spares ou de le garder en place. Ne laissez pas un spare consommé sans l’enregistrer ; six mois plus tard quelqu’un supposera encore que vous avez un spare et vous passerez une soirée très éducative.

7. Tâches pratiques (avec commandes et interprétation)

Ci-dessous des tâches pratiques que vous pouvez intégrer à un runbook. Elles sont écrites avec un esprit Linux + OpenZFS. Ajustez les chemins pour votre distribution et votre pile matérielle.

Tâche 1 : Obtenir un état de pool net pour le ticket

cr0x@server:~$ zpool status -P -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:21:11 with 0 errors on Mon Dec 23 02:10:22 2025
config:

        NAME                                                STATE     READ WRITE CKSUM
        /tank                                               DEGRADED     0     0     0
          raidz2-0                                          DEGRADED     0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABC                 ONLINE       0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABD                 ONLINE       0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABE                 FAULTED      0     0    23  too many errors
            /dev/disk/by-id/ata-..._1SGH3ABF                 ONLINE       0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABG                 ONLINE       0     0     0

Interprétation : -P force les chemins complets ; -v inclut les détails d’erreur. Cette sortie est ce que vous voulez dans votre timeline d’incident.

Tâche 2 : Vérifier que les labels sur disque correspondent

cr0x@server:~$ sudo zdb -l /dev/sdo | sed -n '1,60p'
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'tank'
    state: 0
    txg: 12345678
    pool_guid: 1234567890123456789
    vdev_guid: 9876543210987654321
    top_guid: 1111222233334444555

Interprétation : Confirme que le disque appartient bien au pool attendu. Utile sur des hôtes multi-pools ou quand quelqu’un a « emprunté » des baies.

Tâche 3 : Mapper by-id au périphérique kernel courant

cr0x@server:~$ readlink -f /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._1SGH3ABE
/dev/sdo

Interprétation : Aide à connecter le nommage ZFS aux outils SMART et aux logs kernel.

Tâche 4 : Vérifier SMART et les compteurs d’erreur

cr0x@server:~$ sudo smartctl -H /dev/sdo
SMART overall-health self-assessment test result: FAILED!

Interprétation : Un SMART health failed n’est pas subtil. Même sans cela, des comptes élevés de pending/uncorrectable suffisent pour agir.

Tâche 5 : Vérifier si les erreurs se propagent

cr0x@server:~$ zpool events -v | tail -n 20
TIME                           CLASS
Dec 23 2025 11:03:55.123456789 ereport.fs.zfs.checksum
    vdev_path=/dev/disk/by-id/ata-..._1SGH3ABE
    vdev_guid=9876543210987654321
    pool=tank

Interprétation : Si vous voyez des erreurs de checksum sur plusieurs disques, regardez les chemins du contrôleur et le câblage, pas seulement le disque « le plus bruyant ».

Tâche 6 : Mettre le disque hors ligne proprement avant de le retirer (recommandé)

cr0x@server:~$ sudo zpool offline tank /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._1SGH3ABE
cr0x@server:~$ zpool status tank | sed -n '1,40p'
  pool: tank
 state: DEGRADED
config:

        NAME                                          STATE     READ WRITE CKSUM
        tank                                          DEGRADED     0     0     0
          raidz2-0                                    DEGRADED     0     0     0
            ...                                       ...
            ata-WDC_WD101KRYZ-01W..._1SGH3ABE         OFFLINE      0     0     0

Interprétation : L’offline réduit les comportements surprises pendant le retrait du disque. Il rend aussi le scénario « mauvais disque retiré » plus visible plus tôt.

Tâche 7 : Après le swap physique, confirmez que l’OS voit le nouveau disque

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,TYPE
NAME   SIZE MODEL           SERIAL    WWN               TYPE
sdo    9.1T WDC WD101KRYZ   2JGH7XYZ  0x50014ee2abcd123 disk
...

Interprétation : Confirmez que vous regardez le nouveau serial, pas l’ancien qui réapparaît à cause d’un tiroir lâche ou d’un rebond backplane.

Tâche 8 : Remplacer explicitement le disque dans ZFS

cr0x@server:~$ sudo zpool replace tank \
  /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._1SGH3ABE \
  /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._2JGH7XYZ

Interprétation : Un remplacement explicite old->new évite l’ambiguïté et empêche ZFS de « deviner » quel nouveau disque vous vouliez.

Tâche 9 : Surveiller la progression du resilver correctement

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Mon Dec 23 11:22:01 2025
        1.23T scanned at 1.8G/s, 412G issued at 620M/s, 9.20T total
        82.3G resilvered, 4.36% done, 03:21:44 to go
config:
        ...

Interprétation : « Scanned » et « issued » comptent. Si « issued » rampe alors que « scanned » est rapide, votre pool sert fortement de l’I/O réel ou vous êtes bouché ailleurs.

Tâche 10 : Vérifier l’I/O par vdev et repérer un goulet

cr0x@server:~$ zpool iostat -v tank 5
                                   capacity     operations     bandwidth
pool                             alloc   free   read  write   read  write
-------------------------------  -----  -----  -----  -----  -----  -----
tank                             62.3T  28.7T   420   1900  86.4M   322M
  raidz2-0                       62.3T  28.7T   420   1900  86.4M   322M
    ata-..._1SGH3ABC                -      -     80    350  16.0M  64.0M
    ata-..._1SGH3ABD                -      -     82    360  16.2M  64.5M
    ata-..._2JGH7XYZ                -      -     96    520  20.5M  88.0M
    ata-..._1SGH3ABF                -      -     80    330  16.0M  62.0M
    ata-..._1SGH3ABG                -      -     82    340  16.2M  63.5M
-------------------------------  -----  -----  -----  -----  -----  -----

Interprétation : Le disque de remplacement travaille souvent plus dur pendant le resilver. Si un disque montre une bande passante/ops beaucoup plus mauvaise, suspectez un nouveau disque défectueux, un problème de vitesse négociée du lien, ou une voie/slot/backplane en difficulté.

Tâche 11 : Confirmer TRIM / attentes ashift (surtout SSD)

cr0x@server:~$ sudo zdb -C tank | egrep -i 'ashift|autotrim' | head
                ashift: 12
        autotrim: on

Interprétation : Des hypothèses de taille de secteur non concordantes peuvent nuire aux performances. Vous ne pouvez pas « réparer ashift » sur un membre de vdev existant sans remplacer/réécrire le vdev, donc vérifiez avant d’étendre des remplacements SSD.

Tâche 12 : Valider que le pool redevient sain et le reste

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

Interprétation : La meilleure sortie d’état est ennuyeuse. Si elle ne l’est pas, continuez à creuser.

Tâche 13 : Lancer un scrub après remplacement (quand approprié)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 15:01:12 2025
        2.10T scanned at 1.5G/s, 0B issued at 0B/s, 9.20T total

Interprétation : Un scrub est une passe de confiance : il lit et vérifie. Ne le lancez pas aveuglément pendant un pic de charge si votre budget de latence est fragile, mais planifiez-le rapidement après si possible.

Tâche 14 : Si le pool rapporte des erreurs permanentes, identifiez les fichiers impactés

cr0x@server:~$ zpool status -v tank | sed -n '/errors:/,$p'
errors: Permanent errors have been detected in the following files:
        /tank/vmstore/vm-102-disk-0

Interprétation : Remplacer le disque arrête l’hémorragie, mais ne ressuscite pas des données déjà corrompues. Vous devez maintenant effectuer une récupération spécifique à la charge de travail : restaurer depuis une sauvegarde, régénérer des artefacts ou réparer des images VM.

8. Réalité du resilver : performances, durée et comment le surveiller

Le resilvering est la copie par ZFS des données nécessaires pour reconstruire la redondance sur le nouveau périphérique. Les détails varient selon la topologie et la version/features de ZFS, mais en production vous vous posez deux questions :

Combien de temps resterons-nous en état dégradé ?
Quelle douleur les utilisateurs ressentiront-ils pendant que nous sommes dégradés ?

8.1 Pourquoi le temps de resilver est si difficile à prévoir

Données allouées vs taille brute : Un disque de 10 To ne signifie pas 10 To à resilver. Ça dépend de l’occupation du pool et de la disposition des données.
Interférence de la charge : ZFS sert des lectures/écritures tout en resilverant. Vos clients font partie du benchmark.
Comportement des disques sous stress : Les HDD peuvent entrer en recovery profonde ; les SSD peuvent thermique-throttler ; les disques SMR peuvent transformer un rebuild en lettre d’excuses au ralenti.
Limites du contrôleur : expanders SAS, HBA, lanes PCIe — votre goulet peut être en amont des disques.

8.2 À quoi ressemble un bon resilver

Un resilver sain est bruyant mais stable : la progression augmente régulièrement, la latence I/O grimpe un peu, et ZFS n’accumule pas de nouveaux erreurs de checksum.

Ce qui est mauvais :

La progression du resilver stagne pendant de longues périodes.
De nouvelles erreurs de lecture apparaissent sur d’autres disques.
Le disque de remplacement montre des timeouts dans dmesg.
La latence applicative devient non linéaire (effondrement des files d’attente).

8.3 L’astuce opérationnelle : réduire les surprises

Prévenez les gens qu’un resilver est en cours. Si vous avez des SLO, considérez cela comme une période de risque connue. Si vous avez des jobs batch ou des sauvegardes, pensez à les mettre en pause. L’incident de performance le plus simple à résoudre est celui que vous ne déclenchez pas pendant votre propre maintenance.

9. Playbook de diagnostic rapide : chasse au goulet en situation de pression

Ceci est la séquence « mon pager hurle et la direction regarde ». Le but n’est pas d’obtenir la cause racine parfaite en cinq minutes. Le but est d’arrêter d’empirer la situation et de trouver rapidement le goulet dominant.

Step 1: Confirmez l’état que ZFS pense avoir

cr0x@server:~$ zpool status -v
cr0x@server:~$ zpool status -x

Regardez : DEGRADED vs FAULTED, resilver en cours, compteurs d’erreurs en augmentation, « too many errors », ou un périphérique manquant.

Step 2: Vérifiez les logs kernel pour erreurs de transport vs média

cr0x@server:~$ dmesg -T | tail -n 200

Interprétation :

Erreurs média (« Unrecovered read error ») impliquent généralement le disque.
Erreurs de transport (resets de lien, timeouts sur plusieurs périphériques) impliquent le câblage/HBA/expander/backplane/alimentation.

Step 3: Identifiez si le goulet est le disque, le CPU, la mémoire ou la mise en file

cr0x@server:~$ uptime
cr0x@server:~$ vmstat 1 5
cr0x@server:~$ iostat -x 1 5

Interprétation :

Un wa élevé (iowait) et une forte utilisation disque suggèrent un goulot stockage.
Une file d’exécution élevée avec un iowait faible suggère CPU-bound ou contention de locks.
Un await disque qui explose pendant le resilver peut être attendu — mais s’il est extrême et concentré sur un périphérique, suspectez ce membre/slot.

Step 4: Zoomez sur la distribution I/O au niveau ZFS

cr0x@server:~$ zpool iostat -v 5
cr0x@server:~$ zpool iostat -v tank 5

Regardez : un disque beaucoup plus lent que ses pairs, ou un vdev effectuant un travail disproportionné. En RAIDZ, un seul disque à la traîne peut entraîner une latence catastrophique pour tout le vdev.

Step 5: Vérifiez la pression ARC et les données sales (si la latence monte)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep 'size|c_max|c_min|memory_throttle_count' | head -n 20
cr0x@server:~$ cat /proc/spl/kstat/zfs/vdev_cache_stats 2>/dev/null | head

Interprétation : Si vous êtes en throttling mémoire ou l’ARC est sous pression, ZFS peut faire du travail supplémentaire. C’est souvent la « douleur de fond » rendue visible pendant le resilver.

Step 6: Si la corruption est signalée, décidez ce que vous sauvez en premier

Si ZFS signale des erreurs permanentes, priorisez l’intégrité :

Stabilisez le pool (terminez remplacement/resilver).
Identifiez les datasets/fichiers impactés.
Restaurez/réparez au niveau applicatif.

La performance se règle. La corruption est une échéance.

10. Erreurs courantes (symptômes et corrections)

Cette section est écrite à l’encre des incidents passés. Si vous vous reconnaissez, félicitations : vous êtes normal. Maintenant corrigez cela.

Mistake 1: Utiliser /dev/sdX dans les configs du pool

Symptôme : Après un reboot ou un hotplug, ZFS affiche des périphériques manquants ou le mauvais disque apparaît comme membre défaillant ; quelqu’un jure que « avant c’était sdc ».

Correction : Utilisez les chemins by-id pour les remplacements, et pendant une fenêtre de maintenance, migrez vers des identifiants stables. Au minimum, remplacez toujours en utilisant by-id plutôt que sdX.

Mistake 2: Retirer un disque avant de le mettre hors ligne (en environnements ambigus)

Symptôme : Le pool passe de DEGRADED à « device missing », multipath se comporte étrangement, ou le mauvais tiroir est retiré parce que l’équipe n’avait pas de signal clair « celui-ci est sûr à retirer ».

Correction : Offlinez le membre cible, confirmez qu’il apparaît OFFLINE pour ce by-id spécifique, puis retirez-le.

Mistake 3: Confondre une baie/backplane défaillant avec un disque défaillant

Symptôme : Vous remplacez le disque et les erreurs continuent — souvent sur le nouveau disque — surtout des timeouts ou des resets de lien.

Correction : Déplacez le disque sur un autre slot (si possible) pour tester la baie, inspectez les câbles SAS/SATA, vérifiez les logs d’expander/HBA et examinez l’alimentation/les températures.

Mistake 4: Remplacer plusieurs disques « puisque nous y sommes »

Symptôme : Un second disque se déconnecte en plein resilver, ou les performances s’effondrent. L’équipe est maintenant en train de faire deux opérations stressantes en même temps.

Correction : Étalez les remplacements. Terminez un resilver avant d’en démarrer un autre, sauf si vous avez un plan très contrôlé et une marge de redondance adéquate (et même là, soyez prudent).

Mistake 5: Supposer que la vitesse de resilver sera « comme la dernière fois »

Symptôme : Un resilver qui prenait des heures prend maintenant des jours ; les parties prenantes paniquent ; les ingénieurs commencent à « bidouiller » des paramètres au hasard.

Correction : Validez l’occupation du pool, l’intensité de la charge et la classe de périphérique (CMR vs SMR HDD, comportement de cache SSD, etc.). Utilisez iostat/zpool iostat pour localiser le véritable limiteur avant de changer des paramètres ZFS.

Mistake 6: Ignorer les erreurs de checksum parce que le pool est ONLINE

Symptôme : Des erreurs de checksum périodiques apparaissent ; les scrubs les « réparent » parfois ; des mois plus tard un second événement révèle une corruption latente ou un problème matériel plus large.

Correction : Traitez les erreurs de checksum comme un signal. Corrélez avec SMART, câblage, resets du contrôleur et scrubs. Remplacez proactivement les composants suspects.

Mistake 7: Autoreplace activé sans discipline d’inventaire stricte

Symptôme : Un nouveau disque inséré déclenche un remplacement automatique, mais il n’était pas destiné à ce pool/vdev ; en environnement multi-bay, il est facile de consommer le mauvais disque.

Correction : Si vous utilisez autoreplace, associez-le à un repérage strict des baies, au suivi des serials et au contrôle des changements. Sinon préférez des zpool replace explicites.

Mistake 8: Ne pas vérifier le nouveau disque avant de lui faire confiance

Symptôme : Le resilver commence, puis le nouveau disque commence à produire des erreurs ; vous êtes de nouveau en dégradé, avec moins de confiance.

Correction : Au minimum, confirmez l’identité SMART et la santé basique. Dans des environnements plus stricts, faites des tests burn-in avant de mettre les disques en production.

11. Checklists / plan pas à pas

11.1 La checklist opérationnelle « remplacer un disque »

Ouvrez un incident ou un enregistrement de changement (même si c’est « mineur »). Ajoutez hôte, pool et horaire.
Capturez l’état de base : zpool status -P -v, zpool events -v | tail, et les erreurs kernel récentes.
Confirmez la marge de redondance : identifiez le type de vdev et les membres déjà dégradés.
Identifiez le disque défaillant par serial : map by-id → sdX → SMART serial.
Vérifiez la baie physique : map d’enclosure/LED locate ; vérification par une seconde personne si disponible.
Mettre hors ligne le disque : zpool offline, confirmez qu’il apparaît OFFLINE.
Hot-swap matériel : retirez l’ancien disque, insérez le remplaçant, attendez que l’OS le détecte.
Vérifiez le serial et la taille/classe du remplaçant : lsblk, smartctl.
Exécutez le remplacement : zpool replace pool old new.
Surveillez le resilver : zpool status et zpool iostat -v.
Surveillez les dommages collatéraux : de nouvelles erreurs de checksum sur d’autres disques suggèrent un problème systémique.
Clôturez : confirmez zpool status -x, planifiez un scrub, mettez à jour l’inventaire avec les serials anciens/nouveaux.

11.2 Checklist « nous avons trouvé des erreurs permanentes »

Stabiliser le pool (compléter remplacement/resilver).
Lister les fichiers impactés : zpool status -v.
Identifier les datasets et le contexte applicatif propriétaires.
Restaurer depuis une sauvegarde ou régénérer les données.
Scrubber après la remédiation pour confirmer la propreté.

11.3 Checklist « on suspecte que ce n’est pas le disque »

Vérifier si plusieurs disques sur le même chemin contrôleur montrent des resets/timeouts.
Inspecter les câbles, reseater le HBA, revoir les firmwares et températures.
Changer de slot pour le disque (si possible) pour isoler une baie/backplane défaillante.
Considérer le remplacement du contrôleur ou des diagnostics d’expander si les erreurs persistent.

12. Trois mini-histoires du monde corporate

12.1 Incident causé par une mauvaise supposition : « la LED signifie que ce disque est safe à retirer »

L’environnement était un cluster de virtualisation assez standard : quelques hôtes à forte densité de stockage, un pool ZFS partagé par hôte, et assez de tableaux de bord pour vous faire croire que chaque métrique était facturable. Un hôte a signalé un disque dégradé. L’on-call a fait la bonne première étape : vérifier zpool status et a vu un chemin by-id familier.

Puis la mauvaise supposition est arrivée : l’équipe a traité la LED du châssis comme source de vérité. Le serveur avait deux comportements LED différents — un piloté par l’enclosure, un par la fonction « locate » du contrôleur RAID. Quelqu’un avait précédemment testé « locate » sur une autre baie et ne l’avait jamais désactivé. Donc maintenant deux baies clignotaient : le disque défaillant et un disque parfaitement sain.

L’on-call a retiré le mauvais disque. Le pool est passé de DEGRADED à un état beaucoup plus furieux, et les latences du stockage des VM de l’hôte ont grimpé dans des charts qui font découvrir des adjectifs aux dirigeants. ZFS a fait ce qu’il pouvait, mais perdre un membre supplémentaire dans le même vdev a fait passer le système de « réparable en servant du trafic » à « vous allez devoir restaurer certaines choses ».

La réparation n’a pas été héroïque ; elle a été procédurale. Ils ont réinséré le disque retiré par erreur (heureusement sain), mis hors ligne le disque correct par by-id, puis utilisé une seconde méthode de confirmation : le serial via SMART correspondait au registre d’actifs, et la carte des baies correspondait à la baie d’enclosure. Après le remplacement, ils ont mis à jour le runbook : les LED aident, elles ne sont pas autoritaires. La chaîne d’autorité est : identifiant ZFS → périphérique OS → serial SMART → baie physique.

La leçon : les humains aiment une lumière clignotante parce que ça semble certain. Les systèmes de production punissent ce raccourci émotionnel.

12.2 Optimisation qui a mal tourné : « augmentons la vitesse du resilver pour finir plus vite »

Une autre organisation avait une charge sensible à la latence — pensez à des services internes qui ne sont « pas orientés client » jusqu’à ce qu’ils tombent, moment où ils deviennent la chose la plus visible pour le client. Ils ont eu un disque qui est tombé dans un vdev RAIDZ. L’équipe voulait minimiser la fenêtre dégradée, alors quelqu’un a proposé d’augmenter l’agressivité : laissez le resilver tourner aussi vite que les disques pouvaient pousser.

Ça a fonctionné au sens strict : le débit du resilver a augmenté. Mais la charge n’était pas idle, et le pool n’était pas majoritairement séquentiel. La combinaison de lectures intensives du rebuild, des calculs de parité et de la charge normale d’écritures aléatoires a poussé le système dans un effondrement des files d’attente. La latence a explosé, des timeouts ont cascade, et les services en amont ont commencé des tempêtes de retry. L’infrastructure n’était plus simplement dégradée — c’était un incident de performance.

Ce qui a empiré les choses : pendant cet événement, un autre disque a commencé à logger des timeouts. Pas parce qu’il mourait, mais parce qu’il était affamé et la file du contrôleur était saturée. Ça a déclenché une panique « un second disque est-il en train de tomber ? », et l’équipe a failli lancer un second remplacement en plein resilver.

La stabilisation finale a été, encore une fois, ennuyeuse : ils ont réduit l’agressivité du rebuild (et réduit les I/O batch concurrentes), priorisé la stabilité du service, et accepté une fenêtre dégradée plus longue. Le resilver s’est terminé plus tard, mais le business a arrêté de remarquer le stockage à chaque clignotement.

La leçon : un resilver plus rapide n’est pas automatiquement plus sûr. Le resilver le plus sûr est celui qui ne déclenche pas un outage en tentant d’en prévenir un.

12.3 Une pratique ennuyeuse mais correcte qui a sauvé la mise : inventaire par serial et vérification à deux

Cette équipe avait la réputation d’être presque offensivement méthodique. Chaque baie avait une étiquette. Chaque disque avait son serial enregistré lors de l’installation. À chaque remplacement, ils mettaient à jour un inventaire interne et copiaient la sortie zpool status -P -v avant/après dans le ticket de changement. C’était le genre de processus qui fait lever les yeux au ciel certains ingénieurs — jusqu’à ce qu’il paie son loyer.

Un après-midi, un pool a rapporté des erreurs sur un disque physiquement situé dans une baie qui, d’après l’étiquette, ne devrait pas faire partie de ce pool. Cette incohérence a été l’alarme. Plutôt que d’arracher le disque « évident », ils ont fait une pause. Ils ont vérifié le by-id ZFS, l’ont mappé à un serial, et ont découvert que le disque avait été déplacé des mois plus tôt lors d’un swap de châssis et que la carte des baies n’avait jamais été mise à jour.

Parce qu’ils avaient un inventaire basé sur les serials, ils ont pu réconcilier la discordance sans deviner. Ils ont mis à jour la carte des baies, mis hors ligne le disque correct, et l’ont remplacé proprement. Pas de retrait accidentel, pas de seconde panne, pas de downtime inattendu. Le seul « coût » fut dix minutes supplémentaires de vérification.

Dans la revue post-incident, personne n’a célébré le processus ; ils l’ont à peine mentionné. C’est comme ça qu’on sait que ça a fonctionné. Les meilleures pratiques opérationnelles ne créent pas d’histoires. Elles les empêchent.

13. FAQ

Q1: Dois-je toujours mettre un disque hors ligne avant de le retirer physiquement ?

Dans la plupart des environnements de production, oui. L’offline rend l’intention explicite et réduit l’ambiguïté lors des événements hotplug. Les exceptions sont quand le disque est déjà disparu/inaccessible, ou que votre pile matérielle ne tolère pas bien l’offlining — mais ce sont des cas spéciaux à documenter.

Q2: Puis-je remplacer un disque par un modèle légèrement plus petit si l’étiquette indique « même taille » ?

Ne vous fiez pas aux tailles marketing. ZFS se soucie des secteurs réellement utilisables. Un remplaçant même légèrement plus petit peut ne pas réussir à s’attacher. Vérifiez les tailles avec lsblk ou blockdev --getsize64 avant de commencer.

Q3: Miroir vs RAIDZ — la procédure de hot-swap diffère-t-elle ?

Le flux de commandes est similaire, mais le profil de risque diffère. Les miroirs sont généralement plus simples et resilver plus vite ; les resilvers RAIDZ peuvent être plus lourds et plus longs. La règle « ne remplacez pas plusieurs disques à la fois » est plus critique en RAIDZ car le stress du resilver peut révéler des membres faibles.

Q4: Que faire si `zpool replace` dit que le périphérique est occupé ou ne veut pas s’attacher ?

Causes courantes : le nouveau disque a des partitions d’un usage précédent, multipath présente un nœud différent de celui attendu, ou vous spécifiez des chemins instables. Confirmez l’identité du nouveau disque, effacez les anciens labels si approprié (avec précaution), et utilisez des chemins by-id de façon cohérente.

Q5: Dois-je activer autoreplace ?

Autoreplace peut être excellent dans des environnements strictement contrôlés avec un mapping de baies constant et un inventaire discipliné. Dans des environnements mixtes (pools multiples, enclosures partagées, humains échangeant « n’importe quel disque »), cela peut entraîner des comportements surprenants. Si vous ne pouvez pas garantir la discipline opérationnelle, préférez des remplacements explicites.

Q6: Comment savoir si des erreurs de checksum signifient que j’ai perdu des données ?

Les erreurs de checksum signifient que ZFS a détecté un mismatch. Si la redondance a permis la réparation, ZFS peut l’avoir corrigé de manière transparente (vous verrez « repaired » pendant un scrub). Si ZFS rapporte des « permanent errors », cela signifie qu’il n’a pas pu réparer certains blocs ; c’est alors que vous identifiez les fichiers impactés et restaurez/réparez au niveau applicatif.

Q7: Est-il sûr d’exécuter un scrub pendant un resilver ?

Ce n’est généralement pas ce que vous voulez. Les deux sont des opérations de lecture lourdes en concurrence sur les mêmes spindles/contrôleurs. Terminez le resilver d’abord, puis lancez le scrub bientôt après (ou planifiez-le quand la charge est acceptable). Il existe des cas où vous scrubez pour confirmer un problème d’intégrité plus large, mais cela doit être une décision intentionnelle.

Q8: Pourquoi le resilver ZFS semble parfois plus lent que les rebuilds « traditionnels » ?

Parfois ce n’est pas plus lent ; c’est juste honnête sur la quantité de travail. ZFS peut faire des vérifications supplémentaires, et il partage souvent la bande passante avec l’I/O de production. De plus, les charges modernes sont aléatoires et les disques modernes sont énormes. L’inflation du temps de rebuild est une taxe physique, pas un bug logiciel.

Q9: Après le remplacement, dois-je conserver l’ancien disque pour analyse ?

Si votre environnement a des pannes récurrentes, oui — au moins assez longtemps pour confirmer si le mode de défaillance est usure média, problème de transport, ou environnemental (chaleur/vibration/alimentation). Si c’est clairement un média défaillant (pending/uncorrectable en explosion), vous pouvez généralement RMA et passer à autre chose, mais conservez suffisamment de preuves (sortie SMART, serial, horodatages) pour repérer des motifs.

14. Conclusion

Les hot-swaps ZFS n’ont pas à être des sports d’adrénaline. Le système vous donne les outils pour remplacer des disques en sécurité — si vous traitez l’identité comme sacrée, gardez le nommage des périphériques stable, et respectez le resilver comme un véritable événement opérationnel.

La stratégie gagnante est délibérément peu sexy : confirmez par serial, offline avant de retirer, remplacez explicitement, surveillez le resilver comme si ça comptait, et suivez avec des vérifications d’intégrité et des mises à jour d’inventaire. Voilà comment remplacer des disques sans panique — en éliminant la surprise du processus, une vérification ennuyeuse à la fois.