Aller au contenu

Special vdev, SLOG, L2ARC : quand ils servent (et quand non)

Day 0 · ConcevoirNiveau 3 · MaîtriserCoursRédigé · à valider en lab

Sur un pool 100 % SSD ou NVMe, aucun de ces trois périphériques n'est utile. Ils servent sur des pools de HDD : le special vdev accélère les métadonnées (cas typique : datastore PBS), le SLOG accélère uniquement les écritures synchrones, le L2ARC ne vaut qu'après avoir maximisé la RAM.

Les trois rôles

flowchart LR
    W["Écriture synchrone<br/>(fsync, O_SYNC)"] --> ZIL["ZIL : sur le SLOG s'il existe,<br/>sinon dans le pool"]
    ZIL --> P["Vdevs de données<br/>(HDD)"]
    W2["Écriture asynchrone"] --> RAM["RAM (transaction group)"] --> P
    META["Métadonnées,<br/>petits blocs"] --> SP["Special vdev<br/>(SSD en mirror)"]
    R["Lecture"] --> ARC["ARC (RAM)"]
    ARC -- "absent" --> L2["L2ARC (SSD)"]
    L2 -- "absent" --> P
Périphérique Mot-clé zpool Contient Perte du périphérique Redondance exigée Retrait possible
Special vdev special Métadonnées, tables de dédup, petits blocs si special_small_blocks Perte du pool entier Oui, au moins celle du pool Seulement si le pool ne contient aucun vdev RAIDZ
SLOG log Journal des écritures synchrones (ZIL) Retour au ZIL dans le pool ; perte des dernières écritures seulement si le SLOG meurt en même temps qu'une coupure Mirror conseillé Oui (zpool remove)
L2ARC cache Copie de blocs lus ; persistant au redémarrage depuis OpenZFS 2.0 Aucune : lectures redirigées vers le pool Non (pas de mirror possible) Oui (zpool remove)

Special vdev

Quand il sert. Pool de HDD qui manipule énormément de métadonnées : datastore PBS (millions de chunks, garbage collection et verify), serveur de fichiers. Gain fréquent : un GC passe de plusieurs heures à quelques minutes.

Quand non. Pool déjà en SSD. Pool de zvols de VM sur HDD : les blocs de données restent sur HDD, le gain est faible.

# À la création : RAIDZ2 de 6 HDD + special en mirror de 2 SSD
zpool create -o ashift=12 tank raidz2 <hdd1> <hdd2> <hdd3> <hdd4> <hdd5> <hdd6> \
    special mirror <ssd1> <ssd2>
# Sur un pool existant (irréversible avec RAIDZ)
zpool add tank special mirror <ssd1> <ssd2>
# Optionnel : placer aussi les petits blocs de fichiers sur le special
zfs set special_small_blocks=4K tank/datastore

Seules les métadonnées écrites après l'ajout vont sur le special vdev. Si special_small_blocks est supérieur ou égal au recordsize du dataset, toutes les données y partent et le remplissent. Quand il est plein, ZFS se rabat sur les vdevs normaux. Taille indicative : quelques pour cent de la capacité du pool ; surveillez-le avec zpool list -v.

SLOG (log device)

Quand il sert. Écritures synchrones nombreuses sur HDD : bases de données qui font fsync, NFS en mode sync, VM configurées en cache writethrough ou directsync. Le SLOG réduit la latence de ces écritures ; il n'augmente pas le débit et ne sert jamais pour les lectures.

Quand non. Pool SSD/NVMe entreprise (le ZIL dans le pool est déjà rapide), charge majoritairement asynchrone.

Exigences. SSD avec protection contre les coupures de courant (PLP) et forte endurance. Quelques Go suffisent : la doc Proxmox précise qu'au-delà de la moitié de la RAM il n'y a plus de bénéfice.

zpool add tank log mirror <nvme1-part1> <nvme2-part1>
zpool iostat -v tank 5        # activité de la ligne "logs"

L2ARC (cache device)

Quand il sert. Données « tièdes » qui ne tiennent pas dans l'ARC, relues souvent, sur pool HDD, avec une RAM déjà au maximum du serveur.

Quand non. Dans presque tous les autres cas. Chaque bloc en L2ARC consomme un en-tête dans l'ARC : un gros L2ARC sur un hôte avec peu de RAM peut dégrader les performances.

zpool add tank cache <nvme-part2>
arc_summary -s l2arc           # taux de hit du L2ARC

Recommandations MSP

Cas Recommandation
Pool de VM sur SSD/NVMe (cas standard) Rien de tout cela
PBS local sur HDD Special vdev SSD en mirror (miroir 3 voies si le pool est en RAIDZ2), prévu dès la création
Pool HDD avec base de données sync SLOG mirror de SSD PLP, après mesure
Manque de cache en lecture Plus de RAM d'abord, L2ARC ensuite, après analyse de arc_summary

L'ajout d'un special vdev ou d'un SLOG en production est réalisé par le MSP (N2/N3) ou validé par ticket (N1) : une erreur de mot-clé est irréversible.

Pièges vus en support

  • Special vdev sur un seul SSD : sa panne détruit tout le pool, sauvegardes PBS comprises.
  • zpool add tank <ssd> oublié du mot-clé special, log ou cache : le SSD devient un vdev de données sans redondance, impossible à retirer d'un pool RAIDZ.
  • SLOG sur SSD grand public sans PLP : latences pires qu'avant et risque sur les dernières écritures en cas de coupure.
  • Special vdev ajouté à un datastore existant sans effet visible : seules les nouvelles métadonnées y sont écrites.
  • L2ARC de 2 To sur un hôte de 32 Gio : l'ARC se remplit d'en-têtes, le hit ratio baisse.

Testez-vous

  1. Pourquoi un special vdev doit-il être redondant, alors qu'un L2ARC n'a pas besoin de l'être ?

    Réponse

    Le special vdev contient les seules copies des métadonnées : sa perte rend le pool illisible. Le L2ARC ne contient que des copies de blocs déjà présents dans le pool.

  2. Un SLOG accélère-t-il la restauration d'une VM depuis PBS ?

    Réponse

    Non, sauf si l'écriture est synchrone. Une restauration écrit surtout en asynchrone, et le SLOG n'intervient jamais en lecture.

  3. Pool de 4 NVMe en mirrors pour des VM : faut-il un SLOG ?

    Réponse

    Non. Le ZIL intégré au pool est déjà sur NVMe. Un SLOG n'apporterait qu'un point de complexité.

  4. Peut-on retirer un special vdev d'un pool RAIDZ2 ?

    Réponse

    Non. Le retrait de vdevs de premier niveau (données ou special) n'est pas possible quand le pool contient un vdev RAIDZ. Seuls les vdevs log et cache se retirent toujours.

Pour aller plus loin