ZFS : Remplacer plusieurs disques — l’ordre sûr qui évite la panne

Le modèle mental : ce que signifie vraiment « ordre sûr »

Remplacer plusieurs disques dans ZFS en toute sécurité relève moins de la baie que vous ouvrez en premier que du budget de redondance que vous dépensez pendant l’opération.

Dans un miroir, votre redondance est simple : un disque peut mourir et vous continuez. Pendant un remplacement, vous sortez intentionnellement un disque et demandez au disque survivant de gérer toutes les lectures tout en alimentant le resilver. Vous n’avez pas seulement réduit la redondance ; vous avez augmenté la charge sur les membres restants. C’est là que « l’autre disque allait bien hier » devient « l’autre disque renvoie maintenant des erreurs de lecture ». Ce n’est pas ZFS qui fait une scène. C’est la physique et la probabilité.

Dans RAIDZ (RAIDZ1/2/3), le budget de redondance est distribué. Vous pouvez perdre 1, 2 ou 3 dispositifs dans un vdev et continuer à lire les données (selon le niveau). Mais vous ne pouvez pas dépenser ce budget à la légère : chaque dispositif dégradé supplémentaire augmente à la fois le risque d’une erreur de lecture irrécupérable et le temps passé sans marge. Et si vous remplacez plusieurs disques, il est facile d’exécuter accidentellement deux opérations qui se chevauchent dans le même vdev. C’est la classique erreur « je ne pensais pas que ces remplacements se chevaucheraient ».

Donc, « ordre sûr » signifie :

• Un vdev à la fois autant que possible, et jamais plusieurs dispositifs dégradés dans le même vdev sauf si vous êtes déjà en mode urgence.
• Attendre la fin et la stabilisation du resilver avant de poursuivre avec le disque suivant dans ce vdev.
• Utiliser des identifiants de périphérique persistants (by-id/by-path) afin de remplacer le disque que vous pensez remplacer.
• Valider la redondance et la santé avant et après chaque étape avec des commandes qui disent la vérité.

Une citation pour rester honnête : « L’espoir n’est pas une stratégie », couramment attribuée aux ingénieurs et opérateurs ; considérez-la comme une idée paraphrasée issue de la culture de la fiabilité.

Blague n°1 : Un resilver, c’est comme un abonnement à la salle de sport — facile à commencer, difficile à finir, et ça devient très coûteux si vous l’ignorez.

Faits intéressants et contexte historique (court, utile)

1. ZFS est né chez Sun Microsystems au milieu des années 2000 pour mettre fin à la séparation « système de fichiers vs gestionnaire de volumes » et rendre le stockage plus cohérent.
2. Le copy-on-write (CoW) signifie que ZFS ne réécrit jamais les blocs vivants ; il écrit de nouveaux blocs et bascule les pointeurs. C’est pourquoi une perte de courant en plein écriture ne corrompt pas les structures existantes comme le faisaient d’anciennes piles.
3. « Resilver » est le terme ZFS pour la reconstruction après un remplacement de périphérique ; ce n’est pas toujours un rebuild complet parce que ZFS peut souvent reconstruire uniquement les données allouées (surtout avec le comportement séquentiel du resilver plus récent).
4. RAIDZ n’est pas « juste RAID-5/6 » ; ZFS utilise une largeur de stripe variable et intègre checksums et auto-réparation, changeant le comportement en cas d’erreurs de lecture.
5. La réalité des secteurs 4K a pénalisé de nombreuses premières déploiements ZFS ; des mauvais réglages d’ashift ont causé de l’amplification d’écriture et des resilvers lents qui semblaient indiquer « ZFS est lent ». Ce n’était pas ZFS. C’était la configuration.
6. Le « recordsize 1 Mo » par défaut (pour certaines charges) est un compromis de performance ; les gros enregistrements sont excellents pour le flux IO mais peuvent augmenter les coûts read/modify/write pour des mises à jour aléatoires petites sur RAIDZ.
7. La croissance des capacités de disque a changé le risque de rebuild ; des disques plus grands signifient des resilvers plus longs, ce qui augmente la fenêtre d’exposition pendant la dégradation. C’est un risque opérationnel, pas théorique.
8. Les noms de périphériques persistants sont devenus une compétence de survie ; le renumérotage /dev/sdX après redémarrage a causé assez d’incidents pour que « toujours utiliser /dev/disk/by-id » devienne une loi tribale.

Pré-vol : décidez si vous devez vraiment commencer aujourd’hui

Le remplacement de disque n’est pas une « maintenance rapide » si l’un des cas suivants est vrai :

• Le pool est déjà dégradé et sert du trafic critique.
• La vitesse de resilver est historiquement lente sur ce système (pool occupé, disques SMR, ou HBA saturé).
• Vous êtes proche de la capacité (forte fragmentation et manque d’espace libre aggravent tout).
• Vous ne pouvez pas identifier les disques de manière fiable (pas de correspondance série ↔ baie).
• Vous n’avez pas un scrub récent avec des résultats propres.

Soyez ennuyeux. Planifiez une fenêtre. Assurez-vous d’avoir un accès console. En production, vous voulez un moyen de sortie : charge réduite, mode maintenance, ou la capacité de basculer le trafic ailleurs.

Principes de base : règles à suivre même sous pression

1) Remplacez les disques séquentiellement au sein d’un vdev

Ne « parallélisez » pas les remplacements dans le même vdev RAIDZ ou miroir. ZFS peut le gérer dans certains cas, mais vous transformez une opération contrôlée en course entre la fin du resilver et la prochaine panne.

2) Préférez explicitement zpool replace au « retirer et prier »

Remplacer physiquement un disque en espérant que ZFS « comprenne » est une méthode. Ce n’est juste pas une bonne méthode. Utilisez zpool replace avec des identifiants stables. Validez.

3) Ne supprimez pas les erreurs pour vous rassurer

zpool clear sert à effacer une erreur connue et transitoire après correction de la cause. L’utiliser comme support émotionnel masque des preuves dont vous avez besoin pour prendre de bonnes décisions.

4) Chaque étape est : observer → agir → observer

Avant chaque disque : vérifiez la santé. Après chaque commande : vérifiez l’état. Après chaque resilver : contrôlez les erreurs et lancez un scrub si approprié.

5) Comprenez ce que « sûr » signifie pour votre topologie

Un miroir 2 voies tolère une panne. Un vdev RAIDZ2 tolère deux pertes de périphériques mais peut quand même mourir à cause d’erreurs de lecture pendant le resilver si les disques survivants ne peuvent pas restituer correctement les données pour la reconstruction.

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

Voici des actions d’opérateur réelles : commande, sortie exemple, ce que ça signifie et ce que vous faites ensuite. Supposez le nom de pool tank. Adaptez aux noms de votre environnement.

Task 1: Confirm current pool health and locate the damaged device

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device or use 'zpool clear' to clear the error.
  scan: scrub repaired 0B in 03:12:10 with 0 errors on Wed Dec 18 02:12:11 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  FAULTED     12     0     0  too many errors
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/data/dbfile.dat

Ce que cela signifie : Le pool est dégradé ; un périphérique identifié par son by-id est faulted avec des erreurs de lecture. Il y a des erreurs permanentes, ce qui signifie que des données ont été corrompues ou n’ont pas pu être reconstruites à un moment donné.

Décision : Arrêtez-vous et évaluez l’impact. Si vous voyez des erreurs permanentes, décidez s’il faut restaurer les fichiers affectés depuis une sauvegarde avant de poursuivre. Remplacer le disque ne réparera pas magiquement des données applicatives déjà corrompues.

Task 2: Confirm the topology and redundancy level

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: scrub repaired 0B in 03:12:10 with 0 errors on Wed Dec 18 02:12:11 2025
config:

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

Ce que cela signifie : Il s’agit d’un vdev RAIDZ2. Vous pouvez survivre à une panne supplémentaire dans ce vdev, mais vous ne devez pas être négligent.

Décision : Remplacez un disque, attendez la fin complète du resilver, vérifiez, puis continuez. Pas de traitement par lot.

Task 3: Map the by-id device to a physical bay/serial

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep S3ZABC123456 | head
lrwxrwxrwx 1 root root  9 Dec 26 08:11 ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456 -> ../../sdf
lrwxrwxrwx 1 root root 10 Dec 26 08:11 ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456-part1 -> ../../sdf1

Ce que cela signifie : Le disque défaillant est actuellement /dev/sdf. Cela peut changer après des redémarrages ; le nom by-id est votre ancre.

Décision : Utilisez les identifiants by-id dans toutes les commandes ZFS. Utilisez le numéro de série pour localiser la baie (LEDs du châssis, gestion HBA, ou votre runbook DC).

Task 4: Check SMART health before you touch anything

cr0x@server:~$ sudo smartctl -a /dev/sdf | egrep "SMART overall-health|Reallocated_Sector_Ct|Media_Wearout_Indicator|UDMA_CRC_Error_Count"
SMART overall-health self-assessment test result: FAILED!
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always       -       9812
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0

Ce que cela signifie : Le disque est effectivement en train de faillir (réallocations massives). Les erreurs CRC sont à zéro, donc ce n’est pas juste un problème de câblage.

Décision : Remplacez le disque. Si ce n’étaient que des erreurs CRC, vérifiez d’abord le câblage/le backplane avant d’engendrer des remplacements inutiles.

Task 5: Verify pool free space and fragmentation risk

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint -r tank | head
NAME         USED  AVAIL  REFER  MOUNTPOINT
tank         68.1T  3.2T   128K  /tank
tank/data    66.9T  3.2T  66.9T  /tank/data
tank/logs    1.2T   3.2T  1.2T   /tank/logs

Ce que cela signifie : Seulement ~3.2T libres sur un pool ~71T. C’est serré. Les performances de resilver et de scrub peuvent se dégrader ; l’allocation devient plus complexe.

Décision : Si possible, libérez de l’espace avant de commencer. Sinon, acceptez que le resilver prendra plus de temps et que la fenêtre d’exposition s’agrandit.

Task 6: Verify the last scrub and decide whether to scrub first

cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
  scan: scrub repaired 0B in 03:12:10 with 0 errors on Wed Dec 18 02:12:11 2025

Ce que cela signifie : Un scrub a été exécuté récemment et n’a trouvé aucune erreur. Bien : vous avez une preuve récente que la redondance fonctionnait.

Décision : Procédez au remplacement. Si le dernier scrub est ancien ou a eu des erreurs, vous pouvez lancer un scrub d’abord (si le pool n’est pas trop fragile) pour faire remonter les problèmes latents avant de le stresser avec un resilver.

Task 7: Offline the device (when you want a controlled removal)

cr0x@server:~$ sudo zpool offline tank ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456
cr0x@server:~$ sudo zpool status tank | grep -A2 S3ZABC123456
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456  OFFLINE      0     0     0

Ce que cela signifie : Vous avez dit à ZFS « ce disque est volontairement hors ligne ». Cela évite la confusion si le disque disparaît en plein IO.

Décision : Offline avant le retrait physique sauf si vous êtes en hot-swap forcé et que le disque est déjà parti.

Task 8: Replace the disk using persistent identifiers

cr0x@server:~$ sudo zpool replace tank ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456 ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654
cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Fri Dec 26 08:33:02 2025
        2.11T scanned at 1.35G/s, 410G issued at 262M/s, 68.1T total
        410G resilvered, 0.59% done, 3 days 02:11:22 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ...
            replacing-2                           DEGRADED     0     0     0
              ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456  OFFLINE      0     0     0
              ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654  ONLINE       0     0     0  (resilvering)

Ce que cela signifie : ZFS a créé un vdev replacing et a démarré le resilver vers le nouveau périphérique. L’ETA est longue : c’est le temps d’exposition.

Décision : Ne touchez pas un autre disque dans ce vdev tant que ce resilver n’est pas terminé et que le pool n’est pas revenu à ONLINE (ou au moins que le vdev n’ait pas retrouvé sa redondance complète).

Task 9: Monitor resilver progress and watch for read errors

cr0x@server:~$ watch -n 10 sudo zpool status tank
Every 10.0s: sudo zpool status tank

  pool: tank
 state: DEGRADED
  scan: resilver in progress since Fri Dec 26 08:33:02 2025
        9.82T scanned at 1.12G/s, 1.84T issued at 214M/s, 68.1T total
        1.84T resilvered, 2.70% done, 2 days 20:05:13 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ...
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZOLD111222  ONLINE      18     0     0

Ce que cela signifie : Un des disques restants montre maintenant des erreurs de lecture. C’est votre alerte précoce que la charge du resilver révèle des faiblesses.

Décision : Mettez en pause les charges non essentielles, réduisez l’IO, et envisagez un remplacement proactif. Si les erreurs augmentent ou si un autre disque se dégrade, arrêtez-vous et passez en réponse d’urgence (sauvegardes, réplication, préparation à la restauration).

Task 10: Check kernel logs for link resets and transport errors

cr0x@server:~$ sudo dmesg -T | egrep -i "ata[0-9]+:|link reset|I/O error|blk_update_request" | tail -n 12
[Fri Dec 26 09:01:12 2025] ata9.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
[Fri Dec 26 09:01:12 2025] ata9.00: failed command: READ FPDMA QUEUED
[Fri Dec 26 09:01:13 2025] ata9: hard resetting link
[Fri Dec 26 09:01:18 2025] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Fri Dec 26 09:01:19 2025] blk_update_request: I/O error, dev sdi, sector 1293849216 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0

Ce que cela signifie : L’OS voit des réinitialisations de lien et des erreurs IO de lecture sur un disque spécifique. Cela peut être un disque qui lâche, ou un problème de câblage/backplane/HBA.

Décision : Si les compteurs CRC augmentent dans SMART et que les logs montrent des resets de lien, vérifiez la connectivité physique avant de déclarer le disque mort.

Task 11: Confirm the new disk’s ashift / sector alignment expectations (sanity check)

cr0x@server:~$ sudo zdb -C tank | egrep -n "ashift|vdev_tree" | head -n 8
40: vdev_tree:
56:         ashift: 12
57:         asize:  12003003719680

Ce que cela signifie : ashift: 12 implique des secteurs 4K (2^12). Bien pour les disques modernes. Si vous aviez ashift: 9 avec des disques 4K, les performances seraient pénibles et les resilvers plus lents.

Décision : Si ashift est incorrect, ne « corrigez » pas cela en remplaçant des disques ; ashift est défini par vdev à la création. La correction nécessite recréation/migration du vdev. Planifiez-le, n’improvisez pas.

Task 12: When resilver finishes, verify pool is healthy and error-free

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: resilvered 68.1T in 2 days 21:44:02 with 0 errors on Mon Dec 29 06:17:04 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          raidz2-0                                ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654  ONLINE       0     0     0
            ...

Ce que cela signifie : Le pool est ONLINE, le resilver est terminé et les erreurs sont à zéro. C’est l’état que vous voulez avant de passer au disque suivant.

Décision : Ce n’est qu’à ce moment que vous procédez au périphérique suivant. Si vous faites tourner un lot, remplacez le disque suivant dans le même vdev un par un en attendant la fin complète entre chaque.

Task 13: Start a scrub after a replacement cycle (validation step)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | sed -n '1,10p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 29 06:22:11 2025
        1.14T scanned at 992M/s, 12.3G issued at 10.7M/s, 68.1T total
        0B repaired, 0.01% done, 19:05:41 to go

Ce que cela signifie : Le scrub est en cours. Notez la différence entre le taux de scan et le taux émis ; le taux émis reflète l’IO réel effectué.

Décision : Laissez-le se terminer. Si le scrub fait remonter des erreurs, traitez-les comme la preuve d’un problème plus large (autre disque faible, contrôleur, câblage, ou corruption latente).

Task 14: Use zpool events to see what actually happened

cr0x@server:~$ sudo zpool events -v | tail -n 20
TIME                           CLASS
Dec 29 2025 06:17:04.123456789  resilver.finish
    pool = tank
    vdev_path = /dev/disk/by-id/ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654
    resilvered_bytes = 74882345013248
Dec 29 2025 06:22:11.987654321  scrub.start
    pool = tank

Ce que cela signifie : Vous avez une timeline auditable. Cela compte quand quelqu’un demande « quand avons-nous commencé à stresser le pool ? »

Décision : Enregistrez cette sortie dans votre ticket de changement. Le vous du futur aime les preuves.

Ordre sûr selon la topologie des vdev

Mirrors (2-way, 3-way)

Règle d’ordre : remplacez une feuille à la fois, attendez la fin du resilver, puis passez au miroir suivant. Si vous avez de nombreux mirrors (fréquent dans les « striped mirrors »), vous pouvez remplacer un disque par miroir séquentiellement, mais ne dégradez pas plusieurs mirrors simultanément à moins que vous ne puissiez tolérer une redondance réduite sur l’ensemble du pool.

Pourquoi : Quand un membre de miroir manque, le disque restant est votre point de défaillance unique pour les données de ce miroir. De plus, ce disque survivant gère maintenant toutes les lectures et alimente la reconstruction. C’est le moment où les erreurs de lecture cachées apparaissent.

Ordre recommandé :

1. Choisissez un vdev mirror.
2. Remplacez le disque le pire (SMART en échec, erreurs, ou lot le plus ancien).
3. Attendez la fin du resilver, vérifiez ONLINE, contrôlez les erreurs.
4. Eventuellement lancez un scrub après un lot de remplacements.
5. Passez au miroir suivant.

RAIDZ1

Règle d’ordre : ne laissez jamais deux remplacements concurrents dans le même vdev RAIDZ1. RAIDZ1 a une marge de sécurité mince : un disque manquant passe, un second échec est fatal.

Réalité opérationnelle : RAIDZ1 sur des disques volumineux est un pari. Si vous remplacez plusieurs disques sur RAIDZ1, votre « ordre sûr » revient à « un disque, resilver complet, vérification, répéter » — et vous devriez rester un peu nerveux. C’est sain.

RAIDZ2 / RAIDZ3

Règle d’ordre : remplacez toujours séquentiellement au sein d’un vdev. Oui, RAIDZ2 tolère deux pannes, mais le resilver est le moment où les disques faibles se révèlent et où le temps moyen avant une deuxième panne diminue.

Ordre recommandé :

1. Remplacez d’abord les disques faulted ou qui renvoient des erreurs de lecture/écriture.
2. Ensuite remplacez les disques avec des indicateurs SMART croissants (réallocations, secteurs en attente, usure media).
3. Laissez les disques « sains mais vieux » pour la fin, et arrêtez-vous si vous observez de nouvelles erreurs sur les survivants pendant le resilver.

Vdevs spéciaux : SLOG, L2ARC, classe d’allocation spéciale

Ce ne sont pas des vdevs de données de la même manière, mais ils peuvent quand même vous gâcher la journée.

• SLOG (separate intent log) : le perdre ne détruit pas les données engagées, mais peut provoquer une chute de performance et des timeouts clients. Remplacez-le avec précaution, validez le comportement des workloads sync.
• L2ARC : sûr à retirer/remplacer du point de vue intégrité des données. Mais le retirer sous charge peut déclencher une amplification de lectures quand les données chaudes retombent sur les disques tournants.
• Vdev spécial : traitez-le comme un vdev de données. Le perdre peut être catastrophique selon la configuration, car la metadata et les petits blocs peuvent y résider. L’ordre de remplacement est « ne jamais le dégrader au-delà de sa redondance », comme pour les mirrors/RAIDZ.

Blague n°2 : Hot-swapper le mauvais disque est une excellente façon d’apprendre à quel point vous faites confiance à vos sauvegardes.

Checklists / plan étape par étape

Checklist A : avant de remplacer un disque (la liste « ne soyez pas malin »)

• Confirmer la topologie du pool et la redondance par vdev (zpool status).
• Confirmer les résultats et la date du dernier scrub (zpool status).
• Vérifier l’espace libre (zfs list) et planifier un resilver plus long si l’espace est serré.
• Collecter les métriques de base et les compteurs d’erreurs (SMART, dmesg pour erreurs de lien).
• Mapper le périphérique by-id à la baie/au numéro de série et étiquetez physiquement le disque que vous retirerez.
• Confirmer que vous avez un accès console/remote hands si l’hôte redémarre ou se bloque.
• Assurez-vous d’avoir un plan de rollback : réduire la charge, basculer, ou suspendre l’ingestion.

Checklist B : cycle de remplacement d’un disque (répétable, sûr)

1. Observer : zpool status -v et identifier exactement le nom de la feuille vdev à remplacer.
2. Offline (optionnel mais recommandé) : zpool offline cette feuille.
3. Swap physique : retirer/insérer le disque ; confirmer que l’OS voit la nouvelle entrée by-id.
4. Remplacer : zpool replace pool old-by-id new-by-id.
5. Surveiller : suivre zpool status pour la progression et les erreurs.
6. Valider : après la fin, assurer que le pool revient à ONLINE et que les erreurs restent nulles.
7. Enregistrer : capturer des extraits de zpool events -v et SMART pour le nouveau disque (baseline).

Checklist C : remplacer un lot complet (lorsque plusieurs disques sont suspects)

C’est là où les gens deviennent trop confiants et ZFS leur rappelle que c’est un système de fichiers, pas un thérapeute.

1. Triez les disques par urgence : faulted > erreurs lecture/écriture > SMART pre-fail > lot ancien.
2. Remplacez un disque à la fois par vdev.
3. Après chaque resilver, revérifiez les SMART et les compteurs ZFS des autres disques ; la charge change la vérité.
4. Après 2–3 remplacements (ou après tout incident), lancez un scrub dans une fenêtre contrôlée.
5. Si vous observez de nouvelles erreurs de lecture sur les survivants, arrêtez le lot et réévaluez. « Terminer le planning » n’est pas un principe SRE.

Plaidoyer de diagnostic rapide

Quand un remplacement de disque tourne mal, vous devez répondre rapidement à une question : sommes-nous limités par les disques, le contrôleur/les liaisons, ou la charge ? Voici l’ordre qui vous conduit vite à une réponse utile.

1er : la vérité côté ZFS (état du pool, erreurs, scan/resilver)

• Vérifier : zpool status -v
• Chercher : DEGRADED/FAULTED, compteurs READ/WRITE/CKSUM croissants, « too many errors », et ETA de resilver qui explose au lieu de se stabiliser.
• Décision : Si les erreurs augmentent sur plusieurs périphériques du même vdev, cessez les changements et réduisez l’IO. Préparez-vous à restaurer/réplication.

2e : signaux OS transport et contrôleur (dmesg)

• Vérifier : dmesg -T pour réinitialisations de lien, timeouts, « frozen », « I/O error ».
• Chercher : resets répétés sur le même port/périphérique, qui impliquent souvent le câblage/backplane/firmware HBA plutôt que le disque lui-même.
• Décision : Si plusieurs disques sur le même HBA montrent des resets, mettez les remplacements en pause et corrigez la couche transport d’abord.

3e : santé par disque et types d’erreurs (SMART)

• Vérifier : smartctl -a pour réallocations, secteurs en attente, compteurs CRC, usure media.
• Chercher : CRC en hausse (câblage), realloc/pending en hausse (media), ou « FAILED » overall health.
• Décision : Remplacez les disques avec des problèmes media. Corrigez le câblage/backplane pour les problèmes CRC.

4e : pression de la charge (le pool est-il surchargé ?)

• Vérifier : modèles IO actifs : grandes lectures séquentielles, petites écritures aléatoires, écritures sync lourdes.
• Chercher : taux émis du resilver qui s’effondre tandis que le taux de scan reste élevé ; applications en timeout ; pics de latence.
• Décision : throttlez ou mettez en pause les IO non essentielles. Dans les cas extrêmes, stoppez l’ingestion, replanifiez les remplacements, ou basculez le trafic.

Erreurs courantes : symptôme → cause → correctif

Mistake 1: “We replaced disk A, so now we can replace disk B immediately.”

Symptôme : le pool passe de DEGRADED à UNAVAIL pendant le second remplacement ; le resilver ne finit jamais.

Cause racine : chevauchement d’états dégradés dans le même vdev (mirror/RAIDZ) réduisant la redondance au-dessous de ce que le vdev peut tolérer.

Correctif : remplacez un disque par vdev à la fois ; attendez la fin du resilver et l’état ONLINE avant de poursuivre.

Mistake 2: Resilver is painfully slow and ETA keeps growing

Symptôme : « 3 days remaining » devient « 9 days remaining », le débit émis est faible, les workloads timeout.

Cause racine : pool presque plein, forte fragmentation, IO concurrent élevé, disques SMR, ou contrôleur saturé.

Correctif : réduisez la charge, libérez de l’espace, planifiez les remplacements en période de faible IO, et vérifiez que vous ne mélangez pas des disques SMR dans un environnement de rebuild intensif.

Mistake 3: New disk shows up as ONLINE but the pool still reports errors

Symptôme : zpool status montre des compteurs READ/CKSUM non nuls sur les disques survivants après le resilver.

Cause racine : erreurs de lecture latentes pendant le resilver ; problèmes de transport ; ou corruption existante découverte pendant la reconstruction.

Correctif : examinez zpool status -v pour erreurs permanentes, lancez un scrub, contrôlez SMART et dmesg. Si des erreurs permanentes existent, restaurez les données affectées depuis la sauvegarde.

Mistake 4: “We used /dev/sdX because it was obvious.”

Symptôme : mauvais disque remplacé ; le disque intended reste dans le pool ; un disque sain est maintenant manquant.

Cause racine : renumérotation des périphériques ; /dev/sdX n’est pas stable après redémarrages et hotplug.

Correctif : utilisez toujours /dev/disk/by-id ou /dev/disk/by-path dans les commandes ZFS ; confirmez que le serial correspond au disque physique.

Mistake 5: Clearing errors early to make dashboards green

Symptôme : les erreurs disparaissent, puis réapparaissent plus tard ; vous ne pouvez pas prouver quand l’incident a commencé.

Cause racine : zpool clear a effacé les compteurs sans corriger le périphérique ou le lien sous-jacent.

Correctif : n’effacez les erreurs qu’après action corrective et après avoir capturé des preuves (statut, SMART, logs).

Mistake 6: Replacing disks while a scrub is running

Symptôme : saturation IO ; resilver ralenti à un point d’arrêt ; timeouts accrus ; impact client.

Cause racine : scrub et resilver se concurrencent ; tous deux sont lecteurs intensifs et stressent des disques déjà vieillissants.

Correctif : ne pas chevaucher sauf si vous avez une raison explicite (rare). Mettez le scrub en pause si possible ; planifiez le scrub après le resilver.

Mistake 7: Assuming a “checksum error” means the disk is bad

Symptôme : CKSUM en hausse ; les disques semblent sains dans SMART.

Cause racine : corruption au niveau du câblage/backplane/contrôleur ; erreurs DMA ; problèmes intermittents de transport.

Correctif : inspectez et reseatez les câbles, changez de port, mettez à jour le firmware HBA, et surveillez les compteurs CRC dans SMART.

Trois mini-histoires du monde de l’entreprise

Mini-story 1: The incident caused by a wrong assumption

Ils avaient un pool striped-mirror alimentant une ferme de build et un dépôt d’artefacts. Rien d’exotique, beaucoup d’IO et une bonne dose de « on nettoiera plus tard ». Un disque a commencé à flapper. Quelqu’un a fait la bonne chose et l’a marqué pour remplacement.

L’hypothèse erronée était simple : « Tous les mirrors sont indépendants, donc on peut remplacer un disque dans le mirror A et un autre dans le mirror B en même temps. » Ce qui semble raisonnable jusqu’à ce que vous constatiez que la charge n’est pas indépendante. Le dépôt d’artefacts martelait le pool, et les deux membres restants des mirrors faisaient maintenant un double travail : servir les lectures et alimenter les resilvers.

En quelques heures, un second disque dans un des mirrors a commencé à signaler des erreurs de lecture. Il n’était pas tout neuf, et il n’appréciait pas d’être la dernière source de vérité pour la moitié des données en plein pic CI. Le pool n’est pas mort instantanément ; il s’est dégradé en mode ralenti, ce qui est pire car tout le monde pense pouvoir « finir le rebuild ».

La correction n’était pas ingénieuse : ils ont mis CI en pause, vidé les files, et terminé un resilver à la fois. Puis ils ont ajouté une règle dans leur processus de changement : « Un seul mirror dégradé à la fois sauf en cas de basculement. » La leçon n’était pas que ZFS est fragile. La leçon était que le couplage des charges fait des « vdevs indépendants » un mensonge quand vous saturez les mêmes plateaux.

Mini-story 2: The optimization that backfired

Une équipe voulait des resilvers plus rapides, alors elle a poussé la configuration à fond. Plus de concurrence, plus de threads, et ils ont laissé les remplacements tourner en heures ouvrées parce que « le pool peut le gérer ». Les métriques allaient bien le jour 1. Le jour 2, les alarmes de latence DB ont commencé. Le jour 3, l’équipe applicative est venue avec des graphes et des fourches.

Le retour de bâton n’était pas mystérieux : resilver est lourd en lectures, et ces lectures concurrencent tout le reste. En « optimisant » la vitesse du resilver sans contrôler la charge, ils ont créé la tempête parfaite : lectures aléatoires des applis + lectures séquentielles du resilver + écritures sync d’une charge journaling. Le pool vivait à de hauts depths de queue, et la latence est devenue instable et imprévisible.

Puis l’effet secondaire est arrivé : un disque marginal a commencé à timeouter, que ZFS a interprété comme des erreurs. Le pool n’était pas seulement lent — il était dégradé. Ce qui les a sauvés, c’est l’abandon de l’« optimisation ». Ils ont planifié les resilvers la nuit, réduit l’IO de jour, et utilisé des contrôles opérationnels (limitation de débit via gestion des workloads) plutôt que d’essayer de duper le stockage. Plus rapide c’est bien. Rapide au mauvais moment, c’est ainsi qu’on fabrique des incidents.

Mini-story 3: The boring but correct practice that saved the day

Un autre environnement : une boîte compliance-heavy avec un contrôle des changements strict. C’était le genre d’endroit où on lève les yeux au ciel devant la paperasse jusqu’à ce que quelque chose casse. Ils avaient un pool RAIDZ2 avec un lot de disques vieillissants identifiés, et ils ont planifié un remplacement en rolling sur plusieurs semaines.

La pratique ennuyeuse : chaque disque avait son serial mappé à une baie, consigné, et vérifié par des mains distantes avec une seconde personne lisant le serial sur l’étiquette. Pas de « probablement la slot 7 ». Ils ont aussi capturé zpool status, résumés SMART, et sorties zpool events avant et après chaque remplacement.

À mi-parcours du lot, un disque a lâché sévèrement. Pas celui en cours de remplacement — un autre. Dans beaucoup d’équipes, c’est là que la panique commence. Ici, ils ont regardé leurs enregistrements et ont vu que les scrubs avaient été propres, le dernier resilver sans erreur, et les nouveaux disques avec des baselines SMART propres. Ces preuves leur ont permis de prendre une décision calme : faire un remplacement d’urgence unique, mettre en pause le reste du lot, et programmer un scrub une fois la redondance rétablie.

Ils n’ont jamais eu d’incident visible client. La paperasse n’a pas empêché la panne. Elle a empêché l’erreur humaine qui transforme une panne en outage. L’ennuyeux est une fonctionnalité.

FAQ

1) Can I replace multiple disks at once if I have RAIDZ2?

Vous pouvez, mais vous ne devriez pas. RAIDZ2 tolère deux périphériques manquants, mais les resilvers qui se chevauchent multiplient le risque et le temps d’exposition. Remplacez un disque par vdev, attendez la fin.

2) Should I offline a disk before pulling it?

Oui, quand vous le pouvez. Offliner rend le retrait intentionnel et réduit les comportements surprises. Si le disque est déjà parti, procédez avec zpool replace en utilisant l’identifiant du périphérique manquant.

3) What’s the difference between scrub and resilver?

Un scrub valide les données en lisant et vérifiant les checksums à travers le pool. Un resilver reconstruit des données sur un périphérique de remplacement. Les deux stressent les disques ; ne les chevauchez pas à la légère.

4) Why does ZFS show “permanent errors” even after I replaced the disk?

Parce que certaines données étaient illisibles ou corrompues au moment où elles étaient nécessaires. Remplacer le disque rétablit la redondance ; cela ne corrige pas rétroactivement des fichiers applicatifs corrompus. Restaurez ces fichiers depuis sauvegarde ou répliques.

5) Should I use /dev/sdX in zpool replace?

Non. Utilisez /dev/disk/by-id ou le nom exact de la feuille vdev montré par zpool status. /dev/sdX peut et va changer.

6) Resilver is slow. Is that a sign something is wrong?

Parfois. Un resilver lent peut être normal sous charge, sur des pools presque pleins, ou avec des médias plus lents. C’est suspect quand il devient progressivement plus lent ou que des erreurs commencent à s’accumuler pendant le processus.

7) Do I need to run a scrub after every single disk replacement?

Pas nécessairement après chaque disque, mais vous devriez en lancer un après un lot de remplacements ou après tout événement avec des erreurs. L’objectif est la validation, pas le rituel.

8) What if the new disk is larger than the old disk?

ZFS utilisera généralement la plus petite taille jusqu’à ce que tous les membres du vdev soient mis à niveau et que vous étendiez (selon les fonctionnalités et la configuration). N’attendez pas des gains de capacité instantanés.

9) What if the new disk is smaller than the old one?

Ne le faites pas. Même de petites différences de taille peuvent empêcher le remplacement. Égaler ou dépasser la capacité, et préférez la même classe/modèle quand possible pour éviter des déséquilibres de performances.

10) Can I replace disks in different vdevs concurrently?

Parfois, mais c’est toujours risqué car le budget IO du pool est partagé. Si vous devez le faire, ne le faites que lorsque vous pouvez réduire la charge et que vous avez une forte visibilité opérationnelle.

Prochaines étapes concrètes

• Consignez votre cartographie de périphériques : by-id ↔ baie ↔ serial. Faites-le avant le prochain incident qui forcera l’improvisation.
• Décidez de votre politique de remplacement : un à la fois par vdev, avec des « conditions d’arrêt » explicites (nouvelles erreurs sur les survivants, resets de lien, effondrement des performances).
• Automatisez la capture d’évidence : enregistrez zpool status -v, résumés SMART, et zpool events -v dans votre dossier de changement.
• Entraînez-vous sur un pool non critique : réalisez un remplacement contrôlé pour que la première fois ne soit pas en pleine alerte.
• Après un lot, scrubpez et révisez : considérez le rapport de scrub comme votre certificat « nous sommes de nouveau stables ».

Remplacer plusieurs disques dans ZFS est sûr quand vous respectez le budget de redondance et la dimension temporelle. Remplacez un disque, terminez le resilver, vérifiez la santé, puis passez au suivant. L’ordre n’est pas une superstition. C’est la façon d’empêcher la maintenance de devenir une réponse d’incident.