Deuxième addendum : ZED surveille la santé de mon pool, pas son tour de taille

🌐 Aussi en: English · Deutsch · Español

Un article court, conséquence directe de l’article sur les snapshots. En ajoutant des snapshots quotidiens, j’ai introduit sur ce NAS quelque chose qui n’y existait pas avant : un truc qui grossit tout seul, en silence, pour toujours, sans que personne ne lui ait rien demandé. Je suis donc allé chercher ce qui me préviendrait quand le pool commencerait à se remplir. La réponse était légèrement embarrassante.

Table of Contents

🔍 ZED a des avis sur tout, sauf là-dessus

ZED tourne. Il est configuré. C’est exactement ce que j’ai corrigé dans le dernier addendum, et la correction tient :

$ systemctl is-active zed
active

$ grep ZED_EMAIL_ADDR /etc/zfs/zed.d/zed.rc
ZED_EMAIL_ADDR="you@example.com"

Le problème, c’est ce à quoi ZED sert. Il réagit à des événements – un disque qui lâche, des erreurs de checksum, un scrub qui se termine, un vdev qui passe en mode dégradé. Des choses qui arrivent à un instant précis et qui ont un avant et un après évidents. Un pool qui se remplit lentement n’est rien de tout cela. Il n’y a pas d’événement. Aucune écriture isolée ne franchit un seuil que ZFS jugerait digne d’être signalé. L’occupation grimpe simplement, et ZED – à juste titre, conformément à sa propre conception – ne dit absolument rien. La dernière fois, l’alarme existait mais ne pouvait joindre personne. Cette fois, il n’y a carrément pas d’alarme.

🧊 Pourquoi « il suffit de supprimer un truc » n’est plus l’issue de secours d’autrefois

Sous ext4, un disque plein est agaçant. Sous ZFS, c’est pire, pour deux raisons qui s’aggravent mutuellement. D’abord, les performances en écriture se dégradent nettement au-delà d’environ 80 % – l’allocateur doit travailler plus dur pour trouver de l’espace contigu, et ça se voit. Ensuite, et c’est celle qui piège les gens : supprimer des fichiers peut échouer sur un pool complètement plein, parce que supprimer est en soi une écriture. Effacer un fichier implique de mettre à jour des métadonnées, et avec le copy-on-write, mettre à jour des métadonnées implique d’allouer un bloc. Pas de bloc libre, pas de suppression. Ajoutez maintenant les snapshots par-dessus. Comme expliqué dans l’article sur les snapshots, supprimer un fichier encore référencé par un snapshot ne libère strictement rien :

storage/demo   USED: 200M   REFER: 128K

REFER, c’est ce qui se trouve dans le répertoire actif : pratiquement rien. USED, c’est ce que le dataset occupe réellement, parce qu’un snapshot retient les blocs. Le réflexe de secours instinctif – libérer de la place en supprimant des choses – ne mène donc nulle part sur un dataset avec snapshots, et risque même de ne pas s’exécuter sur un pool vraiment plein. Une combinaison qu’il vaut mieux ne pas découvrir en production.

🛠️ Cinq lignes et un timer

Le check en lui-même n’a rien de remarquable, et c’est tout l’intérêt :

#!/bin/bash
# /usr/local/sbin/zfs-capacity-check.sh
set -euo pipefail
WARN="${1:-80}"

RECIPIENT="$(grep -hE '^ZED_EMAIL_ADDR=' /etc/zfs/zed.d/zed.rc 2>/dev/null 
\
    | head -1 | cut -d= -f2- | tr -d '"' | xargs)"
[ -n "$RECIPIENT" ] || exit 0

problems=""
while read -r pool cap; do
    num="${cap%\%}"
    [ "$num" -ge "$WARN" ] || continue
    problems="${problems}Pool '${pool}' is ${cap} full (threshold: ${WARN}%).
"
done < <(zpool list -H -o name,capacity)

[ -n "$problems" ] || exit 0
# ... assemble report, pipe into mail ...

Deux petites décisions qui méritent d’être mentionnées. Le destinataire est lu depuis zed.rc au lieu d’être codé en dur. Il existe déjà sur cette machine exactement un endroit où l’on configure « qui est prévenu quand le stockage fait des siennes », et en ajouter un second, c’est la recette pour que les deux divergent discrètement d’ici six mois. Et le mail ne se contente pas de dire « le pool est plein ». Il liste les plus gros snapshots, car sur une machine ZFS avec snapshots automatiques, c’est de très loin la réponse à « où est passé mon espace ? » – et le message qui arrive à 3 h du matin doit contenir la réponse, pas seulement la question. Le timer a la même forme que ceux des snapshots : quotidien, Persistent=true, délai aléatoire.

✅ Tester le truc censé me prévenir

Le dernier addendum s’est terminé sur un composant dont le seul travail était de donner l’alerte, et qui échouait en silence. Je ne tomberai pas deux fois dans le même piège. Alors plutôt que de faire confiance à un check qui signale correctement « rien à signaler » sur un pool à 49 %, j’ai abaissé le seuil jusqu’à ce qu’il soit obligé de se déclencher :

$ /usr/local/sbin/zfs-capacity-check.sh 40
$ tail -2 /var/log/msmtp.log
Sep 02 21:19:09 host=smtp.strato.de ... recipients=you@example.com
                smtpstatus=250 exitcode=EX_OK
Sep 11 14:47:14 host=smtp.strato.de ... recipients=you@example.com
                mailsize=861 smtpstatus=250 exitcode=EX_OK

Mail accepté, 250, EX_OK. Toute la chaîne fonctionne : script, mail, msmtp, Strato, livré. Et regardez la ligne juste au-dessus. 2 septembre – c’est le message de test de ZED de l’addendum précédent, là, dans le même log. Deux chemins d’alerte, à neuf jours d’intervalle, tous deux vérifiés de la même façon, pour la même raison.

Ce qu’il faut en retenir

Un outil de supervision vous parle des pannes qu’on a imaginées en le concevant. ZED imagine des disques qui meurent, et il excelle dans ce domaine. Il n’imagine pas votre pool qui se remplit tranquillement pendant dix-huit mois, parce que ce n’est pas un événement – c’est l’absence d’événement. C’est d’ailleurs le côté gênant de la supervision en général : ce qu’elle couvre est décidé par celui qui l’a écrite, et ce qu’elle ne couvre pas produit exactement la même sortie que « tout va bien ». Le silence. Il vaut la peine de se demander de temps en temps ce que votre supervision est structurellement incapable de vous dire. Pas ce qu’elle omet de signaler – ce qu’elle n’a jamais été conçue pour remarquer.