Mise à niveau OpenZFS : la checklist qui évite les pannes

Ce qui casse réellement lors des mises à niveau OpenZFS

La plupart des guides « mise à niveau ZFS » se concentrent sur la commande nommée zpool upgrade. C’est comme se focaliser sur la ceinture de sécurité d’un avion en ignorant les moteurs. Les pannes réelles se regroupent en quelques catégories :

1) Vous avez mis à jour le userland, mais pas le module kernel (ou l’inverse)

Sur Linux, OpenZFS est souvent un module kernel fourni via DKMS ou des paquets qui suivent kABI. Si votre kernel est mis à jour et que le module ne se compile pas ou ne se charge pas, vous n’avez plus ZFS. Si les outils userland sont plus récents que le module, vous obtiendrez des avertissements, des comportements étranges ou des fonctionnalités manquantes. Sur FreeBSD, ZFS est généralement intégré, mais vous pouvez toujours créer un décalage de version entre environnements de démarrage ou jails.

2) Les feature flags rendent les pools « plus récents » que certains hôtes

OpenZFS utilise des feature flags sur les pools. Une fois activés, certains flags sont « active » et ne peuvent pas être désactivés. L’implication pratique : activer un flag peut bloquer définitivement l’import du pool sur des implémentations OpenZFS plus anciennes. Cela devient problématique quand l’« implémentation plus ancienne » s’avère être votre site de DR.

3) Le pool de démarrage et le support du bootloader forment leur propre univers

Root-on-ZFS est merveilleux jusqu’à ce que vous découvriez que votre bootloader ne comprend qu’un sous-ensemble des fonctionnalités OpenZFS. Le pool peut être parfaitement sain, mais votre système ne démarre pas parce que le bootloader ne peut pas lire les structures sur disque créées par les nouvelles fonctionnalités. Si vous mettez à niveau un pool de démarrage, votre plan de retour arrière doit être infaillible.

4) La compatibilité de la réplication est un contrat opérationnel

zfs send/zfs receive est votre tuyau de données. Si vous activez des fonctionnalités ou changez des propriétés qui altèrent la compatibilité des streams, votre réplication peut échouer, ignorer silencieusement ce que vous attendez, ou vous contraindre à des reseeds complets. « Ça snapshot toujours » n’est pas équivalent à « ça réplique toujours ».

5) Les régressions de performance sont généralement des désaccords de configuration

Les mises à niveau peuvent changer des valeurs par défaut, le comportement de l’ARC, les schémas de prefetch, ou la manière dont certaines charges d’IO interagissent avec la compression, le recordsize et les vdevs spéciaux. Le code peut être correct ; votre charge de travail pourrait simplement enfin révéler que vos réglages précédents étaient inappropriés. Vous avez besoin d’un bilan de performance avant/après, sinon vous passerez une semaine à vous disputer autour de graphiques.

Une idée paraphrasée de Gene Kim, qui a passé sa carrière à traduire la douleur opérationnelle en langage compréhensible par les dirigeants : la fiabilité vient de changements rapides et sûrs avec boucles de feedback. C’est le cœur de cette checklist : rendre le changement sûr, observable et réversible.

Faits intéressants et contexte historique (la partie utile)

• ZFS a popularisé le checksumming de bout en bout pour les données et les métadonnées, ce qui change la façon de penser la « corruption silencieuse » comparé aux piles RAID traditionnelles.
• Les feature flags d’OpenZFS ont remplacé les anciens numéros de version de pool pour que les implémentations puissent évoluer sans un verrouillage linéaire unique.
• Le copy-on-write explique pourquoi les snapshots sont bon marché, mais cela signifie aussi que les motifs de fragmentation d’espace libre peuvent vous surprendre après un fort churn.
• L’ARC n’est pas juste un cache ; c’est un cache adaptatif avec un comportement d’éviction qui peut dominer les discussions sur la pression mémoire sur des charges mixtes.
• L2ARC n’est pas un cache de lecture comme on l’imagine souvent ; c’est un cache de second niveau avec des coûts de warm-up et une surcharge de métadonnées qui peut nuire si mal dimensionné ou placé sur un média fragile.
• Les vdevs spéciaux (pour métadonnées et petits blocs) peuvent être transformateurs, mais ils introduisent aussi des « petits dispositifs critiques et rapides » qui peuvent faire tomber tout le pool s’ils ne sont pas redondants.
• Les streams zfs send ont évolué pour supporter les propriétés, les grands blocs, les données embarquées et les reprises de receive ; tous les receivers ne comprennent pas toutes les variantes de stream.
• Root-on-ZFS est devenu courant sur plusieurs OS parce que les boot environments et les snapshots rendent les mises à jour réversibles — quand on respecte les limites du bootloader.

Pré-vol : définissez ce que « mise à niveau » signifie dans votre environnement

Avant de toucher aux paquets, répondez à trois questions. Si vous ne pouvez pas y répondre, vous ne faites pas une mise à niveau ; vous lancez les dés dans une salle de serveurs.

Définir la portée de la mise à niveau

• Userland seulement ? Outils comme zfs, zpool, zed (daemon d’événements).
• Module kernel ? Sur Linux : version du module ZFS, SPL, statut de build DKMS, initramfs.
• Feature flags du pool ? Si vous allez exécuter zpool upgrade ou laisser les pools tels quels.
• Changements de propriétés de datasets ? Certaines équipes « mettent à niveau » en activant aussi la compression partout. Ce n’est pas une mise à niveau. C’est une migration du comportement I/O.

Inventorier la surface de compatibilité

Listez chaque système susceptible d’importer ce pool ou de recevoir des streams de réplication :

• Hôtes primaires
• Hôtes de DR
• Cibles de sauvegarde
• Postes de travail d’analyse/récupération (oui, quelqu’un finit par essayer d’importer un pool sur un laptop)
• Capacités du bootloader si c’est un pool de démarrage

S’engager sur une stratégie de rollback

Il n’existe que deux stratégies de rollback sérieuses :

1. Rollback via boot environments (système ZFS, root-on-ZFS) : snapshot/clone du dataset root et conserver un boot environment connu-bon sélectionnable au démarrage.
2. Rollback hors-bande (ZFS non-root) : conserver les anciens paquets disponibles, garder l’ancien kernel disponible, et ne jamais activer de features irréversibles tant que vous n’êtes pas confiant.

Blague #1 : ZFS, c’est comme une cuisine professionnelle — tout est étiqueté, checksummé et organisé, et un seul stagiaire peut malgré tout mettre le feu.

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

Ce sont des tâches pour la production. Chacune inclut une commande, une sortie exemple, ce que cela signifie, et ce que vous décidez ensuite. Exécutez-les avant et après la mise à niveau. Conservez les sorties dans votre ticket de changement. Le vous du futur vous en sera reconnaissant, et le vous du futur est généralement celui qui tient le pager.

Task 1: Confirmer quelle version de ZFS vous exécutez réellement

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

Ce que cela signifie : Les versions userland et module kernel sont affichées (varie selon la distro). Si vous voyez seulement le userland, vérifiez le module séparément.

Décision : Si les versions sont désynchronisées après la mise à niveau, arrêtez et corrigez la parité paquets/module avant de toucher aux pools.

Task 2: Vérifier que le module kernel est chargé (Linux)

cr0x@server:~$ lsmod | grep -E '^zfs '
zfs                  8843264  6

Ce que cela signifie : Le module ZFS est chargé ; le dernier nombre est le « users ».

Décision : S’il n’est pas chargé, consultez les journaux de build DKMS, l’initramfs, et vérifiez si la mise à jour du kernel a cassé la compilation du module.

Task 3: Vérifier la santé du pool et les compteurs d’erreurs avant toute modification

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

Ce que cela signifie : Aucune faute connue. Si vous obtenez autre chose, vous avez du travail à faire avant la mise à niveau.

Décision : S’il y a des erreurs de checksum, un resilvering en cours, ou des vdevs dégradés : reporter la mise à niveau. Réparez le pool d’abord, puis mettez à niveau.

Task 4: Obtenir le statut complet, pas le résumé rassurant

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Determine if the device needs to be replaced, and clear the errors
  scan: scrub repaired 0B in 00:12:33 with 0 errors on Thu Dec 19 03:12:01 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda     ONLINE       0     0     2  (repairable)
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0

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

Ce que cela signifie : « Healthy » peut masquer des erreurs réparées mais réelles. Les erreurs permanentes listent les fichiers affectés.

Décision : Enquêter et remédier aux erreurs permanentes (restauration depuis un réplicat/sauvegarde) avant la mise à niveau. Évaluez aussi le disque sda pour remplacement.

Task 5: Confirmer que vous avez des scrubs récents et sans alarmes

cr0x@server:~$ zpool get -H scrub tank
tank	scrub	scrub repaired 0B in 00:12:33 with 0 errors on Thu Dec 19 03:12:01 2025	-

Ce que cela signifie : Résultat du dernier scrub et horodatage.

Décision : Si les scrubs sont anciens ou montrent des erreurs, lancez un scrub avant la mise à niveau. Vous voulez des données connues-bonnes avant de commencer à changer la pile.

Task 6: Capturer les feature flags actuellement activés et actifs

cr0x@server:~$ zpool get -H -o name,property,value all tank | grep -E '^tank	feature@'
tank	feature@async_destroy	enabled
tank	feature@empty_bpobj	active
tank	feature@spacemap_histogram	enabled
tank	feature@extensible_dataset	enabled

Ce que cela signifie : enabled signifie que le pool peut l’utiliser ; active signifie que c’est utilisé sur le disque.

Décision : Si vous voyez des features que vous ne reconnaissez pas comme supportées par vos hôtes de DR/sauvegarde, n’exécutez pas zpool upgrade pour l’instant. Construisez d’abord une matrice de compatibilité.

Task 7: Voir quelles upgrades sont disponibles (et ne pas les appliquer aveuglément)

cr0x@server:~$ zpool upgrade
This system supports ZFS pool feature flags.

The following pools are formatted with legacy version numbers and can be upgraded:
  tank

The following feature flags are supported:
  spacemap_histogram
  enabled_txg
  hole_birth
  extensible_dataset
  ...

Ce que cela signifie : Affiche les features supportées et si les pools utilisent des versions legacy.

Décision : La mise à jour du format du pool est une décision explicite de compatibilité. Si vous avez la moindre chance d’importer sur des systèmes plus anciens, différer la mise à niveau du pool jusqu’à ce que tous les systèmes soient mis à jour et testés.

Task 8: Vérifier les propriétés de datasets qui affectent la performance et la réplication

cr0x@server:~$ zfs get -r -o name,property,value -s local,received compression,recordsize,atime,xattr,acltype,encryption,keylocation tank
NAME                PROPERTY     VALUE
tank                compression  zstd
tank                recordsize   128K
tank                atime        off
tank/vmstore        recordsize   16K
tank/vmstore        compression  lz4
tank/backup         atime        on

Ce que cela signifie : Propriétés locales et reçues qui déterminent le layout sur disque, les schémas I/O et le comportement.

Décision : Geler les changements de propriétés pendant la fenêtre de mise à niveau. Si vous voulez « corriger des propriétés », faites-en un changement séparé avec sa propre pensée sur le rollback.

Task 9: Valider la posture snapshots/réplication avant la mise à niveau

cr0x@server:~$ zfs list -t snapshot -o name,creation -S creation | head
NAME                          CREATION
tank/vmstore@autosnap_2025-12-26_0000  Fri Dec 26 00:00 2025
tank/home@autosnap_2025-12-26_0000     Fri Dec 26 00:00 2025
tank@autosnap_2025-12-26_0000          Fri Dec 26 00:00 2025

Ce que cela signifie : Les snapshots existent et sont récents.

Décision : Si les snapshots ne sont pas à jour, corrigez l’automatisation avant la mise à niveau. Pas de snapshots signifie pas de rollback rapide pour les erreurs de données.

Task 10: Vérifier la compatibilité du stream de réplication en pratique (dry run avec resumable receive)

cr0x@server:~$ zfs send -nP tank/vmstore@autosnap_2025-12-26_0000 | head
size	1234567896

Ce que cela signifie : -nP estime la taille du send sans envoyer. Si ceci échoue, vous avez un problème côté envoi.

Décision : Si l’estimation échoue après la mise à niveau, vous avez probablement heurté un mismatch de feature/propriété ou un changement de stream. Enquêter avant la prochaine réplication planifiée.

Task 11: Confirmer que vous pouvez réellement importer le pool sur l’hôte mis à jour (et voir pourquoi ça pourrait échouer)

cr0x@server:~$ zpool import
   pool: tank
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          raidz1-0  ONLINE
            sda     ONLINE
            sdb     ONLINE
            sdc     ONLINE

Ce que cela signifie : Pool importable découvert. Sur un système réel vous ne lanceriez pas ceci sur l’hôte actif sauf en récupération ; c’est idéal sur un standby ou un environnement de secours.

Décision : Si l’import affiche « unsupported features », vous avez prouvé une rupture de compatibilité. N’activez pas les features du pool tant que chaque importeur n’est pas prêt.

Task 12: Valider les contraintes du pool de démarrage (environnements root-on-ZFS)

cr0x@server:~$ zpool list -o name,size,alloc,free,ashift,health
NAME   SIZE  ALLOC   FREE  ASHIFT  HEALTH
bpool  1.8G   612M  1.2G      12  ONLINE
rpool  1.8T   1.1T  724G      12  ONLINE

Ce que cela signifie : Vous avez probablement un bpool séparé (boot pool) avec des features conservatrices, plus rpool pour le filesystem root.

Décision : Traitez bpool comme un « stockage compatible bootloader ». Soyez extrêmement conservateur sur la mise à niveau ou l’activation de features dessus.

Task 13: Confirmer que ZED tourne et rapportera les problèmes

cr0x@server:~$ systemctl status zfs-zed.service --no-pager
● zfs-zed.service - ZFS Event Daemon (zed)
     Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled)
     Active: active (running) since Thu 2025-12-26 00:10:11 UTC; 2h 3min ago

Ce que cela signifie : Le daemon d’événements ZFS est actif. Sans lui, vous pouvez manquer des événements de disque et des alertes de scrub.

Décision : Si ZED n’est pas en marche, corrigez cela avant la mise à niveau. La visibilité fait partie de la sécurité.

Task 14: Vérifier le comportement de l’ARC avant/après (sanity check rapide, pas du tuning cargo-cult)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  size     c
00:00:01   912    34      3     9   1%    21   2%     4   0%  28.1G  31.9G
00:00:02   877    29      3     8   1%    17   2%     4   0%  28.1G  31.9G
00:00:03   940    35      3     9   1%    22   2%     4   0%  28.1G  31.9G

Ce que cela signifie : Taux de miss et taille ARC. Un pic soudain de miss après la mise à niveau peut indiquer un changement de comportement de prefetch ou une pression mémoire.

Décision : Si miss% bondit et que la latence augmente, commencez par vérifier la charge et la pression mémoire avant de toucher aux tunables.

Task 15: Confirmer que la mise à jour n’a pas modifié le comportement de montage ou la visibilité des datasets

cr0x@server:~$ zfs mount | head
tank                          /tank
tank/home                     /tank/home
tank/vmstore                  /tank/vmstore

Ce que cela signifie : Datasets montés et leurs mountpoints.

Décision : Si des datasets attendus ne sont pas montés après upgrade/reboot, vérifiez canmount, mountpoint, et si l’ordonnancement systemd a changé.

Task 16: Post-upgrade : assurez-vous que le pool est toujours propre et que le journal d’événements ne cache pas une catastrophe

cr0x@server:~$ zpool events -v | tail -n 12
TIME                           CLASS
Dec 26 02:11:03.123456 2025    sysevent.fs.zfs.config_sync
    pool: tank
    vdev: /dev/sdb

Dec 26 02:11:04.654321 2025    sysevent.fs.zfs.history_event
    history: zpool scrub tank

Ce que cela signifie : Événements récents ZFS. Utile après des mises à niveau pour voir si des dispositifs ont disparu, si multipath a changé, ou si un config sync est survenu.

Décision : Si vous voyez des événements répétés de retrait/ajout de device, arrêtez et enquêtez câblage, HBAs, config multipath, ou changements de nommage udev avant de faire confiance au pool.

Checklists / plan étape par étape (celui que vous pouvez exécuter à 2 h du matin)

Ce plan suppose que vous mettez à niveau OpenZFS sur un hôte de production. Adaptez selon votre plateforme, mais ne sautez pas la logique. ZFS punit l’improvisation.

Phase 0 : Planification de la compatibilité (faire avant la fenêtre de changement)

1. Notez tous les importeurs. Chaque hôte susceptible d’importer le pool, y compris DR, sauvegarde et médias de secours.
2. Notez tous les récepteurs de réplication. Chaque cible qui reçoit des streams zfs send.
3. Déterminez la plus ancienne version d’OpenZFS dans cet ensemble. Cette version est votre plancher de compatibilité.
4. Décidez si vous exécuterez zpool upgrade. Réponse par défaut dans un parc hétérogène : non. Mettez d’abord à jour le code, puis les features.
5. Pour les boot pools : identifiez les contraintes du bootloader. Si vous ne pouvez pas dire ce que votre bootloader peut lire, considérez les upgrades du boot pool comme interdits tant que ce n’est pas prouvé sûr.
6. Construisez un plan de rollback qui ne repose pas sur l’espoir. Ancien kernel disponible, anciens paquets disponibles, boot environment si root-on-ZFS, et un « comment obtenir une shell » documenté (IPMI/iLO/console).

Phase 1 : Vérifications préalables (juste avant le changement)

1. Confirmer les versions ZFS (zfs --version).
2. Confirmer le module chargé (lsmod | grep zfs sur Linux).
3. Confirmer la santé du pool (zpool status -x, puis zpool status -v).
4. Confirmer la récence du scrub (zpool get scrub).
5. Capturer les feature flags (zpool get feature@* ou sortie filtrée).
6. Capturer les propriétés clés des datasets (zfs get -r pour compression/recordsize/atime/encryption).
7. Confirmer que les snapshots existent et que la réplication a été propre récemment (vos outils + zfs list -t snapshot).
8. Confirmer la marge d’espace libre. Vous voulez un slack opérationnel pour les resilvers et la croissance des métadonnées.

Phase 2 : Exécution de la mise à niveau (code d’abord, features ensuite)

1. Mettre à jour les paquets. Conservez les notes des versions avant/après.
2. Recompiler initramfs si applicable. Sur Linux, ZFS dans l’initramfs compte pour les boot pools.
3. Redémarrer pendant la fenêtre. Si vous ne redémarrez pas, vous ne testez pas la partie la plus difficile.
4. Valider post-boot module + import du pool + montages. Vérifier zfs mount, services et I/O applicative.
5. Ne pas exécuter zpool upgrade le premier jour. Observez la stabilité d’abord.

Phase 3 : Vérification post-upgrade (immédiatement puis 24 heures après)

1. Vérifier le statut du pool et les erreurs.
2. Vérifier ZED et la pipeline d’alerting.
3. Lancer un scrub (si la fenêtre le permet) ou en programmer un rapidement.
4. Déclencher une exécution de réplication et vérifier le côté réception.
5. Comparer les baselines de performance : latence, IOPS, CPU, taux de miss ARC.
6. Revoir zpool events -v pour la rotation des devices.

Phase 4 : Mise à niveau des feature flags (seulement après préparation de la flotte)

Quand — et seulement quand — chaque importeur et récepteur est sur un OpenZFS compatible, et que vous avez testé les chemins de rollback, alors vous pouvez envisager d’activer de nouvelles features de pool.

1. Revoir les features supportées (zpool upgrade).
2. Activer les features délibérément, par petits groupes, avec un enregistrement de changement.
3. Vérifier que la réplication fonctionne encore après.
4. Mettre à jour la documentation « plancher de compatibilité ». La version minimale de votre flotte vient de bouger.

Blague #2 : La seule chose plus permanente qu’un feature flag est la mémoire de la personne qui l’a activé cinq minutes avant les vacances.

Plan de diagnostic rapide

Après une mise à niveau OpenZFS, vous recevrez typiquement un de trois signaux de douleur : ça ne démarre/importe pas, c’est lent, ou la réplication échoue. Ce playbook est ordonné pour trouver rapidement le goulot d’étranglement, pas pour philosopher.

Premièrement : le système voit-il le pool et les dispositifs ?

• Vérifier le module chargé : lsmod | grep zfs (Linux) ou vérifier que le kernel a ZFS et que le userland correspond.
• Vérifier la stabilité des noms de dispositifs : rechercher des disques manquants, WWN changés, problèmes multipath.
• Vérifier l’importabilité : zpool import (sur un environnement de secours ou standby).
• Vérifier le statut du pool : zpool status -v pour vdevs dégradés et erreurs de checksum.

Deuxièmement : est-ce un problème de compatibilité / feature flag ?

• Si le pool n’importe pas et que vous voyez « unsupported feature(s) », arrêtez. Ce n’est pas un problème de tuning.
• Comparez zpool get feature@* entre les hôtes fonctionnels et ceux en échec.
• Pour les échecs de démarrage : suspectez le support du bootloader pour les features, pas « ZFS cassé ».

Troisièmement : est-ce une régression de performance ou un problème du chemin I/O ?

• Vérifier la latence au niveau du pool : zpool iostat -v 1 10 (non montré ci-dessus, mais vous devriez le lancer).
• Vérifier les misses ARC et la pression mémoire : arcstat, et les stats mémoire de l’OS.
• Vérifier l’utilisation CPU dans les threads kernel : un CPU système élevé peut indiquer un overhead checksum/compression ou un pattern de charge pathologique.
• Vérifier le drift recordsize/compression : les mises à niveau ne changent pas les blocs existants, mais elles peuvent révéler que vos propriétés « taille unique » n’étaient pas adaptées.

Quatrièmement : est-ce la réplication/outillage ?

• Lancer un zfs send -nP manuel et inspecter les erreurs.
• Confirmer que le receiver peut accepter le stream (version/support features).
• Vérifier si votre outil de réplication parse des sorties qui ont changé subtilement.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : le pool n’importe pas après la mise à niveau ; le message mentionne des features non supportées

Cause racine : Des features du pool ont été activées sur un autre hôte (ou vous avez exécuté zpool upgrade) et maintenant vous essayez d’importer sur une implémentation OpenZFS plus ancienne.

Correction : Mettre à niveau l’environnement importateur vers une version OpenZFS compatible. Si c’est le DR et que vous ne pouvez pas, votre seul chemin est de restaurer depuis une réplication/sauvegarde ciblant un pool compatible. Vous ne pouvez pas « désactiver » la plupart des features actives.

2) Symptom : le système démarre en initramfs ou shell d’urgence ; root pool introuvable

Cause racine : Module ZFS non inclus/compilé pour le nouveau kernel, initramfs sans ZFS, ou le module a échoué à se charger.

Correction : Démarrer sur un kernel ancien depuis le bootloader (conservez-en un), rebuild DKMS/module, rebuild initramfs, et redémarrer. Valider la parité zfs --version ensuite.

3) Symptom : le bootloader ne peut pas lire le boot pool, mais le pool s’importe depuis un média de secours

Cause racine : Features du boot pool non supportées par le bootloader. Vous avez mis à jour/changé quelque chose sur bpool ou utilisé un ashift/ensemble de features incompatible pour le loader.

Correction : Restaurer le boot pool depuis un snapshot/boot environment connu-bon si disponible. Sinon, réinstaller le bootloader avec un design de boot pool compatible (souvent : garder le boot pool conservateur et séparé).

4) Symptom : la réplication commence à échouer après la mise à niveau avec des erreurs de stream

Cause racine : L’émetteur produit maintenant des streams utilisant des features que le receveur ne peut pas accepter, ou votre script de réplication suppose un ancien comportement/options de zfs send.

Correction : Mettre à niveau le côté receveur d’abord (ou garder l’émetteur compatible), et adapter l’outillage de réplication pour utiliser des flags compatibles. Vérifier avec zfs send -nP et un petit dataset de test.

5) Symptom : chute de performance ; pics CPU ; I/O wait augmente

Cause racine : Souvent pas « ZFS est devenu plus lent », mais un changement dans le kernel, l’ordonnanceur I/O, l’implémentation de la compression, ou le comportement de reclaim mémoire interagissant avec l’ARC.

Correction : Comparer les baselines avant/après. Vérifier arcstat pour les taux de miss, zpool iostat pour la latence, et si votre charge a changé. Ensuite seulement considérer un tuning ciblé. Ne touchez pas à zfs_arc_max au doigt mouillé.

6) Symptom : datasets non montés après reboot ; services échouent car chemins manquants

Cause racine : Propriétés de dataset comme canmount, mountpoint, ou l’ordonnancement systemd ont changé ; parfois une propriété reçue écrase une attente locale.

Correction : Inspecter les propriétés avec zfs get, corriger la source voulue (local vs received), et assurer que les dépendances de service attendent les montages ZFS.

7) Symptom : les commandes « zfs » fonctionnent mais les opérations de pool échouent étrangement ; les logs montrent un mismatch de version

Cause racine : Dérèglement entre userland et module kernel après une mise à jour partielle.

Correction : Aligner les versions. Sur Linux, cela signifie s’assurer que le module ZFS est compilé pour le kernel en cours et que les paquets userland correspondent à la même ligne de release.

Trois mini-histoires du monde corporatif (anonymisées, douloureusement plausibles)

Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne gérait une paire de serveurs de stockage : primaire et DR. Le primaire était mis à jour trimestriellement. Le DR était « stable » comme du vieux pain. L’hypothèse était simple : la réplication ZFS, c’est juste des snapshots sur le réseau, donc tant que les datasets existent, la compatibilité se débrouillera.

Pendant une mise à jour de routine, un ingénieur a exécuté zpool upgrade parce que la commande semblait être l’étape logique suivante. Le pool est resté en ligne, rien n’a crashé, et le ticket de changement a été fermé tôt. Dans les jours suivants, les jobs de réplication ont commencé à échouer, mais seulement sur certains datasets. Les échecs étaient assez intermittents pour être ignorés et assez bruyants pour irriter tout le monde.

Puis un incident réel a frappé le primaire — un HBA a commencé à renvoyer des resets sous charge. Ils ont basculé vers le DR et découvert que le pool ne s’importait pas. « Unsupported features » à l’import. Le DR tournait une version OpenZFS plus ancienne qui ne comprenait pas certains feature flags maintenant actifs. Le pool n’était pas endommagé. Il était simplement trop moderne pour l’environnement qui en avait le plus besoin.

La récupération a été ennuyeuse et coûteuse : reconstruire le DR avec une pile plus récente, puis restaurer les données depuis ce que la réplication avait encore de valide. La panne réelle n’était pas due à ZFS. Elle venait de l’hypothèse que les feature flags sont optionnels et réversibles. Ils ne le sont pas.

Mini-histoire n°2 : L’optimisation qui s’est retournée contre eux

Une autre organisation gérait un cluster de virtualisation avec ZFS en backend. Après avoir mis à jour OpenZFS, un ingénieur a décidé de « profiter de la nouvelle version » en changeant la compression de lz4 à zstd sur le dataset des VM. La logique semblait simple : meilleure compression = moins d’I/O = meilleures performances. C’est une bonne théorie dans un monde où le CPU est gratuit et où la latence est imaginaire.

En pratique, le cluster exécutait une charge mixte : petits writes aléatoires, opérations métadonnées en rafales, et orages de backup occasionnels. Après le changement, la latence a empiré aux heures de pointe. Le CPU a augmenté. L’on-call a commencé à voir des timeouts VM qui n’arrivaient jamais auparavant. Les graphiques de stockage au niveau disque semblaient corrects, ce qui a rendu l’incident plus amusant : tout le monde a blâmé le réseau.

Le problème n’était pas que zstd soit mauvais. C’était qu’ils ont changé une propriété définissant la charge en même temps qu’une mise à niveau OpenZFS, sans comparaisons de baseline. Les niveaux de compression et l’overhead CPU importent. De plus, les blocs existants ne sont pas re-compressés, donc le comportement de performance variait selon l’âge des données des VM. Parfait pour la confusion.

La correction a été de revenir la compression du dataset chaud des VM à lz4, garder zstd pour les datasets froids, et séparer « upgrade de la pile stockage » et « changement du comportement stockage ». L’upgrade n’était pas le vilain ; c’était l’empilement des changements.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise liée à la finance utilisait root-on-ZFS partout. Ils avaient une politique qui faisait lever les yeux aux ingénieurs : chaque mise à jour d’hôte exigeait un nouveau boot environment, plus un redémarrage post-upgrade pendant la fenêtre. Pas d’exception. La politique existait parce que quelqu’un, des années plus tôt, en avait eu assez du « on redémarrera plus tard » qui se transformait en « on découvrira pendant une panne ».

Pendant une mise à niveau OpenZFS, un hôte est revenu avec des services ZFS incapables de monter un dataset. La raison était banale : combinaison d’un ordre de services et d’une propriété de montage héritée de façon inattendue. L’hôte était techniquement up, mais les applications étaient mortes. L’ingénieur en on-call n’a pas tenté de bidouilles ingénieuses sur un système cassé sous pression.

Ils ont sélectionné le boot environment précédent dans le bootloader, sont revenus sur l’ancienne pile, et ont restauré le service. Puis, en heures diurnes, ils ont reproduit le problème en staging, corrigé l’ordre de montage, et ré-exécuté la mise à niveau. Le downtime a été minimal parce que le rollback n’était pas théorique — c’était de la routine.

C’est le type de pratique qui paraît lente jusqu’à ce qu’elle soit plus rapide que toutes les alternatives.

FAQ

1) Dois-je lancer zpool upgrade immédiatement après la mise à niveau d’OpenZFS ?

Non, pas par défaut. Mettez d’abord à jour la pile logicielle, validez la stabilité et la réplication, puis mettez à jour les features du pool quand chaque importeur/récepteur est prêt.

2) Quelle est la différence entre mettre à jour OpenZFS et mettre à jour un pool ?

Mettre à jour OpenZFS modifie le code qui lit/écrit votre pool. Mettre à jour un pool change les feature flags sur disque. La seconde opération peut être irréversible et affecte la compatibilité entre hôtes.

3) Puis-je rétrograder OpenZFS si quelque chose tourne mal ?

Vous pouvez généralement rétrograder le logiciel si vous n’avez pas activé de nouvelles features de pool et si votre distribution supporte le rollback de paquets. Si vous avez activé des features devenues actives, les anciennes implémentations peuvent ne plus pouvoir importer le pool.

4) Pourquoi mon pool indique « healthy » alors que j’ai des erreurs permanentes ?

zpool status -x est un résumé. Des erreurs permanentes peuvent exister même quand le pool est en ligne. Consultez toujours zpool status -v avant les mises à niveau.

5) Dois-je lancer un scrub avant de mettre à niveau ?

Si vous n’avez pas scrubé récemment, oui. Un scrub valide l’intégrité des données sur tout le pool. Vous voulez des données connues-bonnes avant de changer les modules kernel et le code de stockage.

6) Qu’en est-il des datasets chiffrés — des précautions spéciales lors d’une upgrade ?

Assurez-vous que la gestion des clés fonctionne au travers des redémarrages : confirmez keylocation, testez les procédures de déverrouillage, et validez que le démarrage précoce peut accéder aux clés si le dataset root est chiffré.

7) Ma cible de réplication est plus ancienne. Puis-je quand même mettre à jour l’émetteur ?

Souvent oui, si vous évitez d’activer des features incompatibles et que vous gardez les streams de réplication compatibles. Mais vous devez tester : exécutez zfs send -nP et validez un receive sur la cible plus ancienne.

8) Pourquoi séparer bpool (boot pool) de rpool ?

Les bootloaders supportent souvent moins de features ZFS que l’OS. Un boot pool conservateur réduit le risque qu’une mise à jour de feature rende le système non bootable.

9) Si la performance a changé après la mise à niveau, quelle est la première métrique fiable ?

La latence au niveau du pool et des vdevs, ainsi que les taux de miss ARC sous la même charge. Les graphiques de débit seul peuvent masquer des régressions de latence qui cassent les applis.

10) L2ARC est-il une bonne idée après une mise à niveau ?

Seulement si vous pouvez démontrer que cela aide. L2ARC ajoute de la complexité et peut voler de la mémoire pour les métadonnées. Mesurez avant et après ; ne le considérez pas comme un passage obligé.

Conclusion : prochaines étapes à entreprendre réellement

Voici le chemin pratique qui évite la plupart des douleurs liées aux mises à niveau OpenZFS :

1. Inventoriez importeurs et récepteurs. La compatibilité est une propriété de flotte, pas d’hôte isolé.
2. Mettre à jour le code d’abord, redémarrer, valider. Si vous ne redémarrez pas, vous remettez le vrai test à plus tard, dans un pire moment.
3. Différer zpool upgrade jusqu’à ce que tout l’écosystème soit prêt. Traitez les feature flags comme des migrations de schéma : planifiées, revues et programmées.
4. Capturer des preuves. Sauvegardez les sorties pré/post pour versions, statut de pool, feature flags, propriétés et tests de réplication.
5. Effectuer un test de réplication contrôlé. Si vous ne pouvez pas prouver que send/receive fonctionne encore, vous n’avez pas de DR — vous avez une histoire.

Mettre à niveau OpenZFS peut être ennuyeux. C’est l’objectif. La checklist n’est pas une cérémonie ; c’est la façon d’éviter que la garde d’astreinte devienne une expérience de développement de carrière.