Aller au contenu

Scrub, SMART, alertes ZED par mail

Day 2 · ExploiterNiveau 1 · DécouvrirRunbookRédigé · à valider en lab

Objectif : vérifier que chaque nœud ZFS contrôle ses disques (scrub mensuel, SMART), et que toute anomalie arrive par mail à l'équipe d'exploitation via ZED et les notifications Proxmox VE. À faire à la mise en service, puis après chaque réinstallation de nœud. Durée : 20 minutes par nœud.

Qui fait quoi

Brique Rôle Configuration par défaut sur PVE
Scrub Relit tous les blocs du pool et répare ce qui peut l'être Mensuel : 2e dimanche du mois à 00:24 (/etc/cron.d/zfsutils-linux)
TRIM Signale aux SSD les blocs libérés Mensuel : 1er dimanche du mois, même fichier
smartd Surveille l'état SMART des disques, envoie un mail à root Service smartd actif, paquet smartmontools installé
ZED Démon d'événements ZFS : disque en défaut, erreurs, fin de resilver Service zfs-zed, mail à root (ZED_EMAIL_ADDR)
Notifications PVE Les mails à root deviennent des événements system-mail, routés vers vos cibles Datacenter → Notifications

Avant de toucher la prod

  • Adresse mail de l'équipe d'exploitation connue (liste de diffusion, pas une personne).
  • Cible de notification fonctionnelle (SMTP du client ou sendmail) : voir Notifications natives.
  • Aucun resilver en cours : zpool status sans ligne resilver in progress.

Étapes

  1. Adresse de root : Datacenter → Permissions → Users → root → Edit → E-Mail : adresse de l'équipe.
  2. Cible et test : Datacenter → Notifications → sélectionner la cible (par défaut mail-to-root) → Test. Le mail doit arriver en moins de 5 minutes.
  3. Matchers : vérifier qu'un matcher (par défaut default-matcher) envoie tous les événements, ou au moins les sévérités error et unknown, vers cette cible. Les mails système (smartd, ZED) arrivent avec la sévérité unknown.
  4. SMART : nœud → Disks, colonne S.M.A.R.T. : PASSED ou OK partout. Sélectionner un disque → Show S.M.A.R.T. values pour le détail.
  5. Dernier scrub : nœud → Disks → ZFS → double-clic sur tank : ligne Scan avec la date du dernier scrub et 0 errors.
# 1. Scrub : planification et dernier passage
cat /etc/cron.d/zfsutils-linux
zpool status tank | grep -A1 scan:
#   scan: scrub repaired 0B in 00:41:12 with 0 errors on Sun Oct 12 01:05:36 2026

# 2. Lancer un scrub hors planning (charge disque importante : de préférence hors production)
zpool scrub tank
zpool scrub -p tank        # mettre en pause ; relancer avec zpool scrub tank
zpool scrub -s tank        # arrêter

# 3. SMART
systemctl is-active smartd
grep -v '^#' /etc/smartd.conf | grep -v '^$'
smartctl -H /dev/disk/by-id/<disque>          # santé globale
smartctl -a /dev/disk/by-id/<disque>          # attributs, journal d'erreurs
smartctl -t short /dev/disk/by-id/<disque>    # autotest court (2 min environ)

# 4. ZED
systemctl is-active zfs-zed
grep -E '^ZED_(EMAIL_ADDR|NOTIFY_INTERVAL_SECS|NOTIFY_VERBOSE)' /etc/zfs/zed.d/zed.rc
#   ZED_EMAIL_ADDR="root"

Pour tester toute la chaîne ZED → mail, passer temporairement ZED_NOTIFY_VERBOSE=1 dans /etc/zfs/zed.d/zed.rc (ZED envoie alors aussi un mail en fin de scrub sain), systemctl restart zfs-zed, lancer zpool scrub rpool (petit pool), attendre le mail, puis remettre la valeur d'origine et redémarrer zfs-zed.

Attributs SMART à surveiller

Attribut / indicateur Signal Action
Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable en hausse Surface du disque qui se dégrade Planifier le remplacement (RB-05)
UDMA_CRC_Error_Count en hausse Câble ou fond de panier Reprendre la connectique (RB-07)
NVMe : Percentage Used proche de 100 %, Media and Data Integrity Errors > 0 Usure ou erreurs du SSD Remplacement planifié
SMART overall-health self-assessment test result: FAILED Panne annoncée Remplacement rapide

Vérifications

  • Mail de test reçu depuis Datacenter → Notifications → Test.
  • zpool status -x : all pools are healthy.
  • Ligne scan de zpool status datée de moins de 35 jours.
  • systemctl is-active smartd zfs-zed : active deux fois.
  • Mail ZED de fin de scrub reçu lors du test avec ZED_NOTIFY_VERBOSE=1.

Rollback

Toutes ces actions sont sans risque pour les données. Un scrub lancé en journée qui ralentit la production se met en pause (zpool scrub -p tank) ou s'arrête (zpool scrub -s tank). Restaurer zed.rc à sa valeur d'origine après le test.

Pièges vus en support

  • Adresse mail de root restée à celle saisie à l'installation (souvent celle d'un prestataire ou d'un ancien collaborateur) : les alertes partent dans le vide pendant des mois.
  • Scrub jamais terminé car interrompu par un redémarrage hebdomadaire : vérifier la date de la ligne scan.
  • Serveur derrière un contrôleur RAID : smartctl ne voit pas les disques sans option -d adaptée, et ZFS ne remonte pas les vraies erreurs.
  • Scrub lancé à la main en pleine journée sur un RAIDZ de HDD : latences fortes sur toutes les VM.
  • Mail reçu « scrub repaired 128K » ignoré : une réparation est le signe d'un disque, d'un câble ou d'une RAM à vérifier (RB-07).

Quand ouvrir un ticket iTop

Attribut SMART critique ou disque FAILED : P2 (P1 si le vdev a déjà perdu sa redondance). Scrub avec erreurs non réparées (Permanent errors) : P1. Mails de notification impossibles à faire fonctionner : P3. Joindre zpool status -v, smartctl -a du disque, journalctl -u zfs-zed -u smartd --since "-7 days".

Ouvrir un ticket iTop

Pour aller plus loin