Aller au contenu

Sizing ZFS : capacité utile, padding RAIDZ, volblocksize, 80 % max

Day 0 · ConcevoirNiveau 3 · MaîtriserCours + calculateurRédigé · à valider en lab

La capacité réellement exploitable pour des disques de VM se calcule en quatre étages : capacité brute, moins la parité ou les copies, moins le padding RAIDZ des zvols et la réserve interne de ZFS (1/32), puis 80 % de ce résultat. Ces formules sont exactement celles du calculateur ZFS ; faites vos essais avec lui.

Les quatre étages de capacité

flowchart LR
    B["Brut<br/>disques × taille"] --> A["Affiché<br/>après parité/copies<br/>et réserve 1/32"]
    A --> Z["Zvols<br/>après padding RAIDZ"]
    Z --> E["Exploitable<br/>80 % des zvols"]
Étage Ce que c'est Où le voir
Brut Somme des tailles fabricant Fiche technique
Affiché Après parité ou copies, moins la réserve ZFS de 1/32 zfs list tank (USED + AVAIL), GUI
Zvols Ce que les disques de VM consomment vraiment, padding compris zfs get used,logicalused tank/vm-101-disk-0
Exploitable 80 % des zvols : au-delà, les performances chutent Votre supervision

Les formules

Reprises à l'identique de Comment on calcule (capacités en To fabricant ; 1 To = 0,9095 Tio) :

vdevs          = partie entière (disques / largeur de vdev)
mirror         : affiché = vdevs × taille disque
RAIDZp         : affiché = vdevs × (largeur - p) × taille disque
réserve ZFS    : affiché × (1 - 1/32)

padding RAIDZ (allocation d'un bloc de zvol) :
  N       = volblocksize / taille de secteur (2^ashift)       secteurs de données
  parité  = p × arrondi supérieur (N / (largeur - p))
  total   = N + parité, arrondi au multiple supérieur de (p + 1)
  efficacité zvol = N / total

zvols          = vdevs × largeur × taille disque × efficacité zvol × (1 - 1/32)
exploitable    = zvols × 0,80
IOPS aléatoires : mirror ≈ vdevs (écriture), vdevs × largeur (lecture) ; RAIDZ ≈ vdevs

Pour un mirror, l'efficacité zvol vaut simplement 1 / largeur (pas de padding).

Pourquoi le padding RAIDZ ?

Un zvol découpe le disque de VM en blocs de taille fixe, le volblocksize. Chaque bloc est écrit sur le vdev RAIDZ avec sa propre parité, et l'allocation est arrondie à un multiple de (p + 1) secteurs pour ne pas laisser de trous inutilisables. Plus le bloc est petit par rapport à la largeur du vdev, plus la part perdue est grande.

Exemple 1 : 8 SSD de 1,92 To en RAIDZ2 (un vdev de 8), ashift 12, volblocksize 16 K

affiché    = 1 × (8 - 2) × 1,92 = 11,52 To × (1 - 1/32) = 11,16 To
N          = 16 Kio / 4 Kio = 4 secteurs
parité     = 2 × arrondi sup (4 / 6) = 2
total      = 6 → déjà multiple de 3 → 6
efficacité = 4 / 6 = 66,7 %   (au lieu des 6/8 = 75 % attendus)
zvols      = 1 × 8 × 1,92 × 0,667 × (1 - 1/32) = 9,92 To
exploitable= 9,92 × 0,80 = 7,94 To (7,2 Tio)

Exemple 2 : les mêmes 8 SSD en 4 mirrors de 2

affiché    = 4 × 1,92 × (1 - 1/32) = 7,44 To
zvols      = 4 × 2 × 1,92 × 0,5 × (1 - 1/32) = 7,44 To
exploitable= 5,95 To, avec environ 4 fois les IOPS en écriture du RAIDZ2

L'écart réel entre RAIDZ2 et mirrors est donc de 7,94 To contre 5,95 To, et non de 75 % contre 50 % du brut.

Efficacité zvol selon le volblocksize (RAIDZ2 de 8 disques, ashift 12)

volblocksize N Parité Total arrondi Efficacité
8 K 2 2 6 33 %
16 K 4 2 6 67 %
32 K 8 4 12 67 %
64 K 16 6 24 67 %
128 K 32 12 45 71 %

Avec 8 K, un RAIDZ2 consomme trois fois l'espace des données : c'est le piège classique des pools créés avant que le défaut ne passe à 16 K.

volblocksize sur Proxmox VE

  • Le défaut d'OpenZFS est de 16 Kio depuis OpenZFS 2.2 (PVE 8.1 et suivants ; PVE 9 embarque OpenZFS 2.3). Ce défaut s'applique quand le champ Block Size du stockage est vide. Certaines pages de la documentation Proxmox mentionnent encore 8 Kio : vérifiez sur vos zvols.
  • Le réglage se fait par stockage : Datacenter → Storage → tank → Edit → Block Size, ou ligne blocksize dans /etc/pve/storage.cfg.
  • Il ne s'applique qu'aux nouveaux disques : le volblocksize d'un zvol est fixé à sa création. Pour changer celui d'un disque existant, il faut le déplacer (Disk Action → Move Storage) vers un stockage configuré avec la nouvelle valeur.
  • Un bloc plus grand améliore l'efficacité RAIDZ et la compression, mais augmente l'amplification d'écriture pour les petites écritures du système invité (bases de données à pages de 8 Kio).
zfs get volblocksize tank/vm-101-disk-0
grep -A5 "zfspool: tank" /etc/pve/storage.cfg
zfs list -o name,used,logicalused,refreservation -t volume

Pourquoi 80 % maximum ?

ZFS écrit toujours dans de l'espace libre (copy-on-write). Plus le pool est rempli, plus il est fragmenté et plus l'allocateur cherche longtemps un emplacement : les latences d'écriture montent nettement au-delà de 80 %. Les snapshots de réplication et de sauvegarde ont aussi besoin de place. Le portail retient donc 80 % de la capacité zvols comme capacité exploitable.

Recommandations MSP

  • Faites le calcul avec le calculateur et collez son résumé dans le ticket d'avant-vente.
  • Alertez à 75 % de remplissage (zpool list, colonne CAP) et planifiez l'extension avant 80 %.
  • Le Thin provision (sparse 1) permet de surallouer les disques de VM : suivez alors l'occupation réelle du pool, pas la somme des tailles de disques.
  • Ajoutez la croissance sur 3 ans et la place des snapshots de réplication (environ le volume modifié entre deux synchronisations).

Pièges vus en support

  • Capacité vendue d'après zpool list : cette commande affiche la taille brute pour un RAIDZ (parité incluse). Utilisez zfs list ou le calculateur.
  • Stockage avec blocksize 8k hérité d'une ancienne installation sur un RAIDZ2 : la moitié de l'espace part en parité et en padding.
  • Pool à 95 % : la suppression d'un snapshot ou d'un disque devient elle-même lente ; la réplication échoue faute d'espace (RB-11).
  • Volblocksize de 128 K choisi pour gagner de l'espace sur un serveur SQL : performances d'écriture effondrées.

Testez-vous

  1. RAIDZ1 de 4 disques, ashift 12, volblocksize 16 K : quelle est l'efficacité zvol ?

    Réponse

    N = 4 ; parité = 1 × arrondi sup (4/3) = 2 ; total = 6, multiple de 2 → 6. Efficacité = 4/6 = 67 %, au lieu des 75 % attendus.

  2. Un pool affiche 10 To dans zfs list en mirror. Quelle capacité exploitable retenez-vous pour des VM ?

    Réponse

    En mirror, pas de padding : zvols ≈ affiché. Exploitable = 10 × 0,80 = 8 To.

  3. Vous changez Block Size de 8k à 16k sur le stockage tank. Que se passe-t-il pour la VM 101 existante ?

    Réponse

    Rien : son zvol garde 8 K. Seuls les nouveaux disques prennent 16 K. Pour la VM 101, il faut déplacer le disque vers un stockage configuré en 16 K.

  4. Pourquoi la colonne CAP de zpool list sur un RAIDZ2 n'indique-t-elle pas l'espace utilisable ?

    Réponse

    zpool list raisonne en capacité brute, parité incluse. L'espace disponible pour les données se lit avec zfs list, et le padding des zvols réduit encore ce chiffre.

Pour aller plus loin