Le ticket dit « le stockage est lent. » Le graphique dit « la latence a explosé. » L’équipe applicative dit « hier tout fonctionnait. »
Et vous regardez un pool ZFS fonctionnant dans une VM, soutenu par « quelques disques », présentés par « quelque contrôleur », à travers « un peu de magie hyperviseur ».
C’est là que ZFS ressemble soit à un système de fichiers miraculeux — soit à une énigme criminelle avec trop de suspects.
Le chemin contrôleur que vous choisissez (pass-through HBA vs disques virtuels) détermine ce que ZFS peut voir, ce qu’il peut réparer et ce qu’il ne peut qu’estimer.
Deviner n’est pas une stratégie de stockage.
La vraie décision : ce dont ZFS a besoin vs ce que proposent les hyperviseurs
ZFS n’est pas timide. Il veut un accès relativement direct aux disques, des identités stables, une sémantique correcte des flushs, une latence prévisible et une visibilité des erreurs.
Les hyperviseurs, par conception, abstraient le matériel. Parfois magnifiquement. Parfois de façon catastrophique.
Votre choix de contrôleur est en réalité trois choix groupés :
- Visibilité : ZFS peut-il voir SMART, les compteurs d’erreurs et le comportement réel du périphérique — ou seulement un périphérique bloc virtuel ?
- Ordonnancement et garanties de flush : quand ZFS dit « synchronize ceci », la pile s’assure-t-elle réellement que c’est durable sur un support non volatile ?
- Rayon d’impact en cas de panne : la « mise en cache utile » d’un niveau transforme-t-elle un plantage d’hôte en corruption du pool ?
Si vous retenez une phrase, que ce soit celle-ci : ZFS peut tolérer des disques lents ; il ne tolère pas les mensonges.
« Mensonges » signifie ici des acquittements d’écriture non durables, ou des rapports d’erreur qui sont engloutis, altérés ou retardés jusqu’à ce qu’il soit trop tard.
Alors… Proxmox ou ESXi ?
Si vous voulez ZFS comme pile de stockage principale sur l’hôte : Proxmox est l’option la plus simple car c’est du Linux, et ZFS-on-Linux y est une composante normale.
Si vous voulez ESXi pour son écosystème de virtualisation mais souhaitez quand même les fonctionnalités ZFS : vous parlez généralement de ZFS dans une VM (TrueNAS, OmniOS, Debian+ZFS, etc.).
C’est viable, mais le chemin contrôleur devient toute la partie décisive.
Conseils avec opinion :
- Meilleure pratique pour ZFS-dans-VM : pass-through PCIe d’un HBA en mode IT vers la VM ZFS.
- Acceptable pour faible charge / labo : disques virtuels (VMDK/virtio-blk) seulement si vous comprenez ce que vous perdez.
- Ce que j’évite en production : poser ZFS sur un contrôleur RAID présentant des volumes logiques, ou empiler ZFS sur des disques virtuels thin-provisioned sans garde-fous.
Faits intéressants et contexte historique (qui mord encore aujourd’hui)
- ZFS est né chez Sun Microsystems et a été livré sous Solaris (mi-2000s), construit autour des checksums bout en bout et du copy-on-write pour éviter la corruption silencieuse.
- Le copy-on-write explique pourquoi ZFS déteste les caches « menteurs » : il s’appuie sur des groupes de transactions et une durabilité ordonnée ; des acquittements non durables peuvent empoisonner la cohérence après un crash.
- Les datastores VMFS de VMware ont été conçus pour la virtualisation blok partagée, pas pour exposer des sémantiques de disque brut à un système de fichiers invité doté de sa propre logique RAID.
- Les HBA en « IT mode » sont devenus populaires largement parce que ZFS (et plus tard Ceph) souhaitaient un comportement JBOD simple : pas de métadonnées RAID, pas de surprises de cache contrôleur.
- Les cartes LSI SAS2008/SAS2308 (et leurs nombreuses rebrandings OEM) sont devenues le standard homelab/PME car elles étaient bon marché et supportaient bien le passthrough.
- Les disques 4K ont forcé la main de l’industrie : les mauvais réglages d’ashift peuvent gaspiller définitivement des IOPS et de l’espace ; les couches de virtualisation cachent parfois la taille réelle des secteurs.
- Les politiques de cache d’écriture ont causé de vraies pannes pendant des décennies — bien avant ZFS — car « cache activé » plus « pas de batterie/flash de secours » équivaut à « perte de données plus tard ».
- Le passthrough de SMART n’est pas acquis : beaucoup de chemins de disque virtuel ne fournissent pas les détails d’état du disque à l’invité, ce qui casse les workflows d’exploitation proactifs.
Chemins de présentation des disques : pass-through HBA, RDM, VMDK, et « ça dépend »
Chemin A : pass-through PCIe HBA (mode IT) vers la VM ZFS
C’est l’approche « cessez d’être mignon ». La VM ZFS possède l’HBA, énumère les disques directement, voit SMART, voit les numéros de série et obtient le comportement réel des périphériques.
C’est le plus proche du bare metal tout en virtualisant le calcul autour.
Avantages
- Meilleure visibilité disque : SMART, températures, compteurs d’erreurs, identifiants réels.
- Meilleure adéquation avec les hypothèses ZFS sur les flushs et le traitement des erreurs.
- Caractéristiques de performance prévisibles : l’ordonnancement et la latence sont moins mystérieux.
- Réponse aux incidents plus simple : quand un disque meurt, ZFS vous dit lequel, pas « naa.600…quelque chose ».
Inconvénients
- Perte de certaines commodités de l’hyperviseur (vMotion pour cette VM, snapshots dans le sens habituel).
- Le pass-through peut compliquer les mises à jour d’hôte et les changements matériels.
- Certaines cartes mères grand public / groupements IOMMU rendent cela pénible.
Chemin B : ESXi RDM (Raw Device Mapping) vers une VM ZFS
RDM est le mapping « à moitié brut » de VMware. En pratique, c’est quand même médiatisé.
Selon le mode (virtual vs physical compatibility), il peut ou non transmettre ce que ZFS attend.
Ça peut marcher, mais rarement la meilleure option quand le passthrough est disponible.
Avantages
- Mieux qu’un VMDK générique pour certains cas d’usage.
- Peut permettre une certaine intégration d’outils avec ESXi.
Inconvénients
- Visibilité SMART et des erreurs souvent limitée ou inconsistante.
- Plus de couches où la sémantique cache/flush peut devenir étrange.
- Ambiguïté opérationnelle : « Est-ce que l’invité voit vraiment le disque ? » devient une question récurrente.
Chemin C : disques virtuels (VMDK sur VMFS ; virtio sur Proxmox)
C’est la façon la plus courante dont les gens essaient ZFS dans une VM parce que c’est pratique et propre dans l’UI.
C’est aussi l’endroit où ZFS reçoit le moins de vérité sur le média sous-jacent.
Si vous faites ça pour quelque chose qui compte, considérez-le comme une décision produit : définissez les exigences de fiabilité, testez le comportement en cas de crash et acceptez les angles morts du monitoring.
Avantages
- Opérations du cycle de vie faciles : migration, snapshot, clonage.
- Indépendant du matériel : pas besoin d’un HBA spécial.
- Parfait pour dev/test, CI, environnements jetables.
Inconvénients
- ZFS perd l’accès direct à SMART et à certaines sémantiques d’erreur.
- Taille de secteur mal alignée et caches volatiles peuvent créer problèmes de performance et d’intégrité.
- Double mise en cache et double ordonnancement (invité + hôte) peuvent produire des pics de latence ressemblant à des « freezes » applicatifs aléatoires.
Blague n°1 : Les disques virtuels pour ZFS en production, c’est comme mettre des pneus slicks sur un chariot élévateur — techniquement ça roule, mais ce n’est pas la vitesse que vous attendiez.
Chemin D : volumes logiques présentés par un contrôleur RAID matériel
Ne le faites pas. ZFS est déjà la couche RAID. Le mettre au-dessus d’une autre couche RAID est une excellente façon d’obtenir :
gestion de défaillance inadéquate, erreurs masquées, comportement de write hole et jeu du blâme avec le support.
Il existe des exceptions de niche (un RAID0 par disque sur le contrôleur pour émuler un pass-through),
mais c’est généralement un bricolage quand vous avez acheté le mauvais contrôleur.
Pour les constructions neuves : achetez le bon matériel.
Proxmox : ZFS est de première classe, mais le matériel compte toujours
Sur Proxmox, ZFS tourne généralement sur l’hôte. C’est l’architecture la plus propre : le noyau voit les disques directement,
ZFS les gère directement, et vos VMs voient le stockage via des zvols, datasets ou partages réseau.
La « décision contrôleur » existe toujours, mais elle est plus simple : vous attachez les disques à l’hôte Proxmox via un HBA approprié (ou SATA onboard en AHCI),
ou vous compliquez la vie avec des contrôleurs RAID et des politiques de cache.
Que acheter (et comment le configurer)
- HBA en mode IT (famille LSI/Broadcom) est la réponse classique pour les backplanes SAS/SATA et les expanders.
- SATA onboard en mode AHCI convient pour de petites configurations SATA directes, si le chipset et le câblage sont raisonnables.
- Évitez le mode RAID sauf si vous pouvez forcer un vrai comportement HBA/JBOD avec cache désactivé et identifiants stables — c’est toujours second meilleur.
Réalité des performances
Proxmox avec ZFS n’est pas « lent ». Il est honnête. Si votre pool est constitué de six disques mécaniques faisant des écritures sync, la latence reflétera la physique.
ZFS vous montrera la facture de vos décisions d’architecture.
ESXi : excellent hyperviseur, histoire gênante pour ZFS en invité
ESXi est excellent pour ce pour quoi il a été conçu : exécuter des VMs, les gérer à l’échelle, abstraire le matériel et fournir des outils d’exploitation stables.
La friction apparaît lorsque vous voulez qu’un système de fichiers invité (ZFS) se comporte comme sur du bare metal alors qu’ESXi fait ce que font les hyperviseurs.
Que faire sur ESXi si vous voulez les fonctionnalités ZFS
- Le meilleur : dédier un HBA et utiliser le pass-through PCIe vers une VM de stockage (TrueNAS, etc.). Présenter le stockage à ESXi via NFS/iSCSI.
- Acceptable : RDM en mode physical pour chaque disque, si le passthrough est impossible. Valider la visibilité SMART et le comportement des flushs.
- Risqué : ZFS sur VMDKs sur VMFS, surtout thin-provisioned, avec snapshots, et sans surveillance de la pression du datastore sous-jacent.
Le problème philosophique : qui est responsable de l’intégrité ?
Dans un monde ESXi + VMFS, la pile VMware est responsable de l’intégrité du datastore, de la redondance et de la récupération.
Dans un monde ZFS, ZFS veut posséder ce travail de bout en bout.
Si vous laissez les deux piles « aider », vous pouvez finir sans que l’une ou l’autre soit pleinement responsable.
Une citation à garder sur un post-it :
L’espoir n’est pas une stratégie.
— James Cameron
Pourquoi le choix du contrôleur change les modes de défaillance (et votre pager)
1) ZFS a besoin d’une identité disque stable
ZFS étiquette les disques et s’attend à ce qu’ils restent le même périphérique.
Les disques virtuels sont stables à leur manière, mais ils masquent la topologie réelle.
Si un disque physique commence à produire des erreurs, ZFS dans l’invité peut ne voir qu’« erreur de lecture disque virtuel », pas « Seagate SN1234 meurt en baie 7 ».
2) SMART et signaux prédictifs de défaillance
SMART n’est pas parfait, mais c’est ce qu’on a. Secteurs réalloués, secteurs en attente, erreurs CRC — ce sont des avertissements précoces.
Avec le pass-through, vous pouvez les surveiller dans le système ZFS et remplacer les disques avant qu’un resilver ne devienne un drame d’une semaine.
Avec des VMDK, vous êtes souvent aveugle à moins de surveiller depuis l’hôte avec des outils séparés et de corréler manuellement.
3) Sémantique des flushs et écritures sync
ZFS se soucie profondément de ce que signifie « sync ». Les bases de données aussi.
Si l’hyperviseur ou le contrôleur acquitte des écritures avant qu’elles ne soient durables, une coupure électrique peut laisser ZFS croire que les données sont en sécurité alors qu’elles ne le sont pas.
ZFS est robuste, mais il ne peut pas checksummer des données qui n’ont jamais été écrites.
4) Profondeur de queue et variance de latence
Beaucoup de rapports « ZFS est lent dans une VM » signifient en réalité « votre chemin IO a trois files, deux caches et un goulot minuscule ».
Les HBA en pass-through laissent l’invité gérer la mise en file directement.
Avec des disques virtuels, vous pouvez obtenir des pics de latence imprévisibles dus à la contention de l’hôte, aux opérations de métadonnées du datastore ou aux chaînes de snapshots.
5) Récupérabilité quand l’hôte est malade
Avec un HBA en pass-through, la VM ZFS est plus autonome : déplacez l’HBA + disques vers un autre hôte, importez le pool, continuez.
Avec des VMDK, votre pool est emmêlé avec les datastores VMFS, la configuration de l’hôte ESXi, et parfois l’état des snapshots.
La récupération devient une fouille archéologique multi-couches.
Blague n°2 : Les couches de stockage sont comme les lasagnes — trop de couches et vous passerez la nuit à regretter vos choix.
Tâches pratiques : commandes, interprétation des sorties, décisions
Le but des commandes n’est pas de se sentir occupé. C’est de réduire l’incertitude jusqu’à ce que la bonne décision soit évidente.
Ci‑dessous des tâches réelles que j’utilise en triage production et en revue d’architecture. Chacune indique ce qu’il faut regarder et la décision suivante.
Task 1: Confirm ZFS sees real disks (not a single giant virtual blob)
cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,SIZE,ROTA,TYPE
NAME MODEL SERIAL SIZE ROTA TYPE
sda ST12000NM0008 ZHZ1ABC1 10.9T 1 disk
sdb ST12000NM0008 ZHZ1ABC2 10.9T 1 disk
sdc ST12000NM0008 ZHZ1ABC3 10.9T 1 disk
nvme0n1 Samsung SSD 980 S64DNF0R1234 931G 0 disk
Ce que cela signifie : Vous avez un modèle et un numéro de série par disque. Cela indique généralement une attache directe ou un HBA en passthrough.
Si vous voyez « VMware Virtual disk » (ou des modèles/numéros de série identiques), vous êtes sur des disques virtuels.
Décision : Si c’est une VM ZFS et que la visibilité opérationnelle vous importe, orientez-vous vers un pass-through HBA.
Task 2: Check whether the controller is a real HBA and in a sane mode
cr0x@server:~$ lspci -nn | egrep -i 'sas|sata|raid|lsi|broadcom'
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2308 PCI-Express Fusion-MPT SAS-2 [1000:0087]
Ce que cela signifie : Le périphérique LSI SAS2308 est un HBA courant adapté au mode IT.
Si vous voyez un modèle de contrôleur RAID, vérifiez qu’il n’applique pas de cache d’écriture ou de présentation RAID.
Décision : Préférez un HBA en mode IT pour ZFS ; évitez les volumes RAID matériel comme vdevs ZFS.
Task 3: Verify passthrough from the guest perspective (ZFS VM)
cr0x@server:~$ dmesg | egrep -i 'mpt2sas|mpt3sas|scsi host' | tail -n 8
[ 2.114012] mpt2sas_cm0: LSISAS2308: FWVersion(20.00.07.00), ChipRevision(0x05), BiosVersion(07.39.02.00)
[ 2.116842] scsi host0: ioc0
[ 2.116904] scsi host1: ioc1
Ce que cela signifie : L’invité a chargé le pilote HBA et voit le contrôleur directement.
Décision : Procédez avec des vdevs par disque ; activez la surveillance SMART dans l’invité.
Task 4: Confirm ZFS pool topology (and spot accidental single points of failure)
cr0x@server:~$ zpool status -v
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
errors: No known data errors
Ce que cela signifie : RAIDZ2 sur six disques, pas d’erreurs. Si vous voyez des identifiants scsi- qui changent souvent, vous avez peut-être un nommage de périphérique instable.
Décision : Si les noms de périphériques sont instables, utilisez /dev/disk/by-id lors de la création/remplacement des disques.
Task 5: Check ashift (4K alignment) to avoid permanent performance sadness
cr0x@server:~$ zdb -C tank | egrep 'ashift|vdev_tree' -n | head
41: vdev_tree:
57: ashift: 12
Ce que cela signifie : ashift: 12 implique des secteurs 4K. Si c’est 9 (512B) sur des disques 4K, vous pouvez subir de l’amplification d’écriture et moins d’IOPS.
Décision : Si ashift est incorrect, vous devez reconstruire le pool. Il n’existe pas de bouton magique « fix ashift ».
Task 6: Measure sync write penalty (tells you whether SLOG matters)
cr0x@server:~$ zfs get -o name,property,value -s local,default sync tank
NAME PROPERTY VALUE
tank sync standard
cr0x@server:~$ dd if=/dev/zero of=/tank/testfile bs=1M count=1024 oflag=dsync status=progress
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6 s, 43.6 MB/s
Ce que cela signifie : oflag=dsync approximates le comportement d’écriture sync. 43 MB/s sur disques mécaniques peut être normal ; 3 MB/s suggère un problème de flush/queue.
Décision : Si les écritures sync sont un goulot et que vous avez de vrais workloads sync (bases de données, NFS en sync), ajoutez un SLOG adapté avec protection contre la perte d’alimentation.
Task 7: Verify SLOG presence and what it’s doing
cr0x@server:~$ zpool status tank | egrep -A3 'logs|cache|special'
logs
nvme0n1p2 ONLINE 0 0 0
Ce que cela signifie : Un dispositif journal dédié existe. Si c’est un NVMe grand public sans PLP, il peut accélérer jusqu’au moment où il ne le pourra plus.
Décision : Utilisez des SSD/NVMe entreprise avec PLP pour SLOG. Si vous ne pouvez pas, ne faites pas semblant que c’est suffisant.
Task 8: Check ZFS compression and recordsize (common “free performance” lever)
cr0x@server:~$ zfs get -o name,property,value compression,recordsize tank
NAME PROPERTY VALUE
tank compression lz4
tank recordsize 128K
Ce que cela signifie : lz4 est généralement bénéfique ; recordsize 128K est un défaut polyvalent.
Décision : Pour des images de VM, envisagez un dataset avec recordsize=16K ou 32K. Pour sauvegardes/médias, conservez 128K ou plus.
Task 9: Look for checksum errors (they tell you about the path, not just the disk)
cr0x@server:~$ zpool status -v tank
pool: tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 12
sdb ONLINE 0 0 0
errors: No known data errors
Ce que cela signifie : Un CKSUM non nul peut indiquer un câblage, un backplane, un contrôleur, un expander, un firmware ou le disque lui-même.
ZFS l’a corrigé grâce à la redondance, mais le chemin est bruyant.
Décision : Vérifiez SMART, échangez les câbles, rebranchez, mettez à jour le firmware HBA. Si les erreurs persistent sur un disque, remplacez-le.
Task 10: Pull SMART data (only works well with real disk access)
cr0x@server:~$ smartctl -a /dev/sda | egrep -i 'model|serial|reallocated|pending|crc|temperature'
Device Model: ST12000NM0008
Serial Number: ZHZ1ABC1
Reallocated_Sector_Ct 0
Current_Pending_Sector 0
UDMA_CRC_Error_Count 18
Temperature_Celsius 41
Ce que cela signifie : Les erreurs CRC crient souvent « câble/backplane », pas « média disque ».
Décision : Réparez le transport avant de blâmer ZFS. Remplacez les câbles SATA/SAS ; vérifiez l’emplacement du backplane et la santé des expanders.
Task 11: Identify whether the hypervisor path is adding latency (guest view)
cr0x@server:~$ iostat -x 1 5
Device r/s w/s rkB/s wkB/s await svctm %util
sda 5.0 42.0 320.0 8192.0 38.21 2.11 98.7
sdb 4.0 40.0 256.0 8064.0 41.02 2.03 97.9
Ce que cela signifie : Un await élevé avec un svctm modéré peut indiquer une mise en file au-dessus du périphérique (contention contrôleur/hyperviseur).
Décision : Si c’est une VM avec disques virtuels, investigatez la contention du datastore hôte ou les réglages de profondeur de file ; envisagez de passer au pass-through HBA.
Task 12: Check TRIM/discard behavior (important for SSD pools and virtual disks)
cr0x@server:~$ zpool get autotrim tank
NAME PROPERTY VALUE SOURCE
tank autotrim off default
cr0x@server:~$ zpool set autotrim=on tank
Ce que cela signifie : Si vous êtes sur SSD, autotrim aide la performance sur le long terme. Dans certains setups de disques virtuels, discard peut être non supporté ou lent.
Décision : Activez autotrim pour les pools SSD si supporté ; faites des benchmarks en environnement virtualisé pour vérifier que les trims ne provoquent pas de pics de latence.
Task 13: Confirm whether you’re accidentally double-caching
cr0x@server:~$ zfs get -o name,property,value primarycache,secondarycache tank
NAME PROPERTY VALUE
tank primarycache all
tank secondarycache all
Ce que cela signifie : ZFS utilisera la RAM (ARC) et éventuellement L2ARC. Dans une VM, l’hôte peut aussi cacher agressivement.
Décision : Si la mémoire VM est contrainte ou sujette au ballooning, réduisez la taille de l’ARC ZFS ou ajustez les caches ; évitez d’exécuter ZFS là où l’hyperviseur peut lui retirer la mémoire de façon imprévisible.
Task 14: Validate scrub behavior and time-to-detect problems
cr0x@server:~$ zpool scrub tank
cr0x@server:~$ zpool status tank | egrep -i 'scan|scrub'
scan: scrub in progress since Sun Dec 28 01:10:11 2025
1.23T scanned at 1.05G/s, 220G issued at 187M/s, 10.8T total
0B repaired, 2.04% done, 0:58:12 to go
Ce que cela signifie : Le débit de scrub vous indique la performance de lecture bout en bout et la contention.
Décision : Si les scrubs sont terriblement lents dans une VM, vérifiez la contention hôte, l’ordonnancement contrôleur, et si les disques virtuels sont limités par des quotas de datastore.
Trois mini-récits de la vie en entreprise
1) L’incident causé par une mauvaise hypothèse : « L’hyperviseur flush les écritures, évidemment »
Une entreprise de taille moyenne exécutait un cluster ESXi avec une VM de stockage fournissant NFS à ESXi. La VM de stockage utilisait ZFS.
Quelqu’un l’a montée rapidement pendant une fenêtre de refresh matériel. Ils ont utilisé des VMDK sur un datastore VMFS parce que ça rendait la construction « portable ».
Ça a passé des tests basiques : copies de fichiers, quelques boot de VM, un benchmark synthétique qui a fait se sentir productifs.
Des semaines plus tard, un redémarrage d’hôte est survenu pendant un événement d’alimentation. L’UPS a fonctionné, en grande partie. Mais un hôte a chuté brutalement.
Après le retour de l’alimentation, la VM de stockage est montée et ZFS a importé le pool. Les applications ont démarré, tout avait l’air normal — jusqu’à ce qu’une base de données commence à générer des erreurs de corruption logique.
Pas « disque défaillant », pas « pool en panne ». Données incorrectes silencieuses à un endroit critique.
L’enquête a été dégueulasse parce que chaque couche avait une dénégation plausible. ESXi disait que le datastore était sain.
ZFS disait que le pool était en ligne. La base de données disait, essentiellement, « on m’a promis la durabilité et je ne l’ai pas eue. »
L’hypothèse centrale — que les écritures sync de l’invité étaient fidèlement durables sur le média physique — n’a jamais été validée sous conditions de crash.
La correction n’était pas un réglage magique ZFS. Ils ont reconstruit : pass-through HBA vers la VM de stockage, validation de la visibilité SMART, désactivation des caches d’écriture non sûrs sur le contrôleur, et retests avec simulations de crash délibérées.
La leçon n’était pas « ESXi est mauvais ». C’était que l’abstraction sans validation transforme le « devrait » en « probablement ».
La production ne tourne pas sur du « probablement ».
2) L’optimisation qui a mal tourné : « Ajoutons un L2ARC et poussons la compression »
Une autre organisation avait Proxmox avec ZFS sur l’hôte, principalement des SSD plus quelques miroirs HDD pour le bulk.
Ils avaient une plainte de performance : des vagues de boot de VM pendant les fenêtres de patch provoquaient des pics de latence.
Quelqu’un a proposé d’ajouter un SSD L2ARC et de retoucher les réglages : plus grand ARC, plus grand L2ARC, et quelques tweaks copiés depuis un forum comme un sortilège.
Pendant une semaine, tout semblait amélioré. Les ratios de hit-cache montaient. Les graphiques viraient au vert.
Puis un autre symptôme est apparu : des blocages imprévisibles en journée. Pas une lenteur constante — juste des pauses brusques qui faisaient timeout des applications bavardes.
Les scrubs ont aussi ralenti et débordé dans les heures ouvrables.
Cause racine : ils ont ajouté un SSD grand public comme L2ARC sans protection perte d’alimentation et ont sous-estimé la charge d’écriture et le churn de métadonnées supplémentaires.
Pire, la pression mémoire due à un ARC surdimensionné plus la demande mémoire des VM a poussé l’hôte en comportement de reclamation.
Le système n’était pas à court de RAM ; il était à court de RAM stable. L’efficacité du cache ZFS s’effondrait chaque fois que l’hôte devait jongler.
Ils ont retiré le L2ARC, limité l’ARC raisonnablement, et ciblé le vrai goulot : le comportement des écritures sync et l’ordonnancement pendant les pics.
Ils ont ajouté un SLOG adapté et réparti les IO des VM.
L’« optimisation » n’était pas mauvaise — elle était juste mal appliquée. Le tuning ZFS est un scalpel, pas de la confetti.
3) La pratique ennuyeuse mais correcte qui a sauvé la situation : burn-in cohérent + bases SMART + planning de scrub
Une équipe exécutant des workloads mixtes sur Proxmox avait une habitude presque désuète : chaque nouveau disque recevait un burn-in.
Pas un format rapide. Un vrai test — tests SMART longs, badblocks, et un snapshot de base des attributs SMART.
Puis ils ajoutaient chaque disque au pool seulement après qu’il ait survécu à un week-end de stress.
Des mois plus tard, ils ont commencé à voir des erreurs de checksum occasionnelles sur un vdev. Rien de dramatique. ZFS a corrigé.
Mais leur monitoring a déclenché sur une augmentation du compteur UDMA CRC sur un disque, et la baseline a montré que ce n’était pas « toujours comme ça ».
Ils ont changé le câble et les erreurs ont cessé.
Deux semaines plus tard, un autre disque montrait une montée des secteurs réalloués. Là encore : la comparaison avec la baseline a rendu la tendance évidente.
Ils ont remplacé le disque pendant les heures ouvrables, resilver proprement, et personne hors infra n’a remarqué.
La magie n’était pas une architecture flashy. C’était une hygiène disciplinée et répétitive : scrubs, suivi SMART des tendances, et ne pas faire confiance aux disques neufs.
Les pratiques ennuyeuses n’ont pas d’applaudissements. Elles empêchent que les applaudissements deviennent des hurlements.
Feuille de diagnostic rapide
Quand « ZFS est lent » arrive dans votre file, vous avez besoin d’une voie vers la réponse en quelques minutes, pas un week-end de tuning basé sur des sensations.
Cette feuille suppose que vous voulez identifier rapidement le goulot et décider si c’est disque/contrôleur, sync/flush, ou couche de virtualisation.
Première étape : identifier le chemin de présentation du stockage
- Est‑ce que ZFS est sur l’hôte Proxmox ? Ou dans une VM (ESXi ou Proxmox) ?
- Le système ZFS voit‑il de vrais disques avec numéros de série ? (
lsblk,smartctl) - Y a‑t‑il un contrôleur RAID qui fait du « caching utile » ?
Deuxième étape : séparer latence et débit
- Utilisez
iostat -xpour regarderawaitet %util par périphérique. - Utilisez un test d’écriture sync (
dd ... oflag=dsync) pour voir si la douleur est spécifique aux sync. - Vérifiez l’état du pool (
zpool status) pour des erreurs impliquant des retries.
Troisième étape : cherchez file d’attente et contention au‑dessus des disques
- Dans une VM : vérifiez si le datastore hôte est saturé ou si des chaînes de snapshots existent.
- Vérifiez si l’ARC ZFS thrash à cause du ballooning VM ou de la pression hôte.
- Confirmez que vous n’exécutez pas un scrub/resilver pendant les pics IO.
Quatrième étape : décidez la classe de correction
- Correction design : passer des VMDK/RDM au pass-through HBA, ajouter SLOG/devices metadata, reconstruire avec ashift correct.
- Correction opérationnelle : remplacement câbles/firmware, ajuster planning scrub, tuner cap ARC.
- Correction d’attente : le workload est IO aléatoire sync sur des disques mécaniques ; la physique dit « non ». Ajoutez des SSD ou changez d’architecture.
Erreurs communes : symptômes → cause racine → correction
1) Symptom: Random latency spikes, especially during snapshots/backups
Cause racine : Pool ZFS construit sur des VMDK avec chaînes de snapshots hyperviseur, provoquant des IO de métadonnées et des copies supplémentaires.
Correction : Évitez les snapshots hyperviseur pour les VMs de stockage ; utilisez les snapshots/replication ZFS. Préférez le pass-through HBA pour que le pool ne soit pas un ensemble de VMDK.
2) Symptom: ZFS reports checksum errors, but SMART looks clean
Cause racine : Problèmes de transport (câble SAS/SATA, backplane, expander, connecteur marginal) ou bugs firmware du contrôleur.
Correction : Vérifiez les erreurs CRC, échangez les câbles, rebranchez les disques, mettez à jour le firmware HBA, et assurez un refroidissement correct pour HBAs et expanders.
3) Symptom: Sync writes are painfully slow; async seems fine
Cause racine : Pas de SLOG pour les workloads sync intensifs, ou sémantique cache/flush provoquant des flushs forcés qui bloquent.
Correction : Ajoutez un SLOG entreprise avec PLP ; vérifiez que le cache du contrôleur est sûr ; validez avec dd oflag=dsync et des tests spécifiques au workload.
4) Symptom: Pool imports slowly or devices “move around” after reboot
Cause racine : Nommage de périphérique instable (utilisation de /dev/sdX), surtout en virtualisé ou avec expanders.
Correction : Utilisez /dev/disk/by-id lors de la création de vdevs et du remplacement des disques ; documentez la correspondance slot-vers-serial.
5) Symptom: Great benchmark numbers, awful application performance
Cause racine : Le benchmark mesure le cache (ARC/cache hôte), pas le disque. Ou il mesure du séquentiel alors que l’app est en IO aléatoire.
Correction : Testez avec des patterns sync/aléatoires pertinents pour l’app ; surveillez la latence, pas uniquement le MB/s ; limitez l’ARC pour éviter les conflits mémoire hôte.
6) Symptom: After power loss, ZFS pool is online but apps show corruption
Cause racine : Les acquittements d’écriture n’étaient pas durables (cache non sûr, mismatch flush virtuel), provoquant des écritures partagées ou perdues hors de la conscience de ZFS.
Correction : Utilisez le pass-through HBA, désactivez les caches volatils non protégés, validez la consistance après crash, et utilisez un SLOG approprié pour les workloads sync.
7) Symptom: SSD pool performance decays over time
Cause racine : TRIM/discard non fonctionnel à travers la pile ; forte fragmentation et absence de reclamation.
Correction : Activez autotrim sur ZFS quand c’est supporté ; assurez-vous que le chemin de disque virtuel passe le discard ; sinon planifiez des trims manuels ou repensez la conception.
8) Symptom: Resilver takes forever and impacts everything
Cause racine : Pool presque plein, disques lents, et virtualisation ajoutant de la contention. Ou resilver via un contrôleur/expander contraint.
Correction : Gardez les pools sous un niveau de remplissage raisonnable, préférez des miroirs pour les workloads IOPS-intensifs, planifiez resilvers/scrubs hors-pointe, et évitez les HBAs sursouscrits.
Listes de contrôle / plan étape par étape
Checklist de conception : choisir le chemin contrôleur
- Décidez où ZFS vit : hôte Proxmox (préféré pour les shops Proxmox-first) ou VM de stockage (commun pour ESXi-first).
- Si ZFS est dans une VM : exigez le pass-through PCIe HBA sauf si vous pouvez justifier les compromis de monitoring et d’intégrité.
- Choisir l’HBA : HBA SAS en mode IT ; éviter les firmwares RAID et les caches volatils.
- Planifier le monitoring : SMART, alertes zpool, planning de scrub, et mapping serial-vers-slot.
- Planifier la récupération : pouvez-vous déplacer les disques/HBA vers un autre hôte et importer ?
Checklist d’implémentation : ZFS sur l’hôte Proxmox
- Mettre le BIOS en AHCI pour le SATA onboard ; activer IOMMU si vous avez besoin de pass-through pour d’autres périphériques.
- Installer Proxmox ; vérifier que les disques montrent des modèles/numéros de série réels dans
lsblk. - Créer le pool avec des chemins by-id ; vérifier ashift avant de s’engager.
- Activer la compression (lz4) et définir recordsize par workload.
- Configurer le planning de scrub et la surveillance SMART.
Checklist d’implémentation : ESXi avec VM de stockage ZFS
- Installer un HBA en mode IT ; confirmer qu’il est dans son propre groupe IOMMU et supporté pour le pass-through.
- Activer le pass-through sur l’hôte ESXi et attacher l’HBA à la VM de stockage.
- Dans la VM, confirmer que le pilote HBA se charge et que les disques apparaissent avec des numéros de série.
- Créer le pool ZFS directement sur les disques ; configurer scrub périodique et vérifications SMART.
- Exporter le stockage vers ESXi via NFS/iSCSI ; mesurer le comportement sync selon vos workloads.
- Documenter les contraintes opérationnelles : pas de vMotion pour cette VM ; la maintenance nécessite planification.
Checklist Ops : hygiène ennuyeuse mensuelle
- Revoir
zpool statuspour erreurs et resilvers lents. - Revoir les deltas SMART : reallocations, sectors pending, erreurs CRC, températures.
- Confirmer que les scrubs se terminent dans les fenêtres attendues.
- Valider la marge d’espace libre et les risques de fragmentation.
- Tester les restaurations (niveau fichier et VM) sérieusement.
FAQ
Faut‑il toujours utiliser le pass-through HBA pour ZFS dans une VM ?
Obligatoire ? Non. Recommandé en production quand la fiabilité, le monitoring et la récupération predictable comptent ? Oui.
Les disques virtuels peuvent fonctionner, mais vous acceptez des angles morts et des modes de défaillance plus complexes.
RDM est‑il « suffisant » sur ESXi ?
Parfois. C’est généralement mieux que les VMDK pour présenter des disques, mais ce n’est pas aussi propre que le pass-through HBA.
La grande question est de savoir si l’invité peut voir de façon fiable les erreurs et SMART et si la sémantique des flushs tient sous contrainte.
Puis‑je mettre ZFS au‑dessus d’un contrôleur RAID ?
Vous pouvez, dans le même sens que vous pouvez remorquer un bateau avec une voiture de sport : ça peut avancer, et ça créera des histoires.
Pour la redondance ZFS, utilisez un comportement JBOD/HBA afin que ZFS gère la redondance et la réparation.
Pourquoi dit‑on que ZFS a besoin d’« accès direct aux disques » ?
Parce que le modèle d’intégrité et d’auto‑guérison de ZFS est le plus fort quand il peut voir les erreurs réelles des périphériques et contrôler l’ordonnancement/durabilité.
Les couches d’abstraction peuvent masquer les signaux que ZFS utilise pour diagnostiquer et réparer.
Quel contrôleur virtuel est le meilleur si je dois utiliser des disques virtuels ?
Sur les invités Linux, paravirtual SCSI (lorsqu’il est disponible) se comporte généralement mieux que les anciens contrôleurs émulés.
Sur Proxmox, virtio-scsi est souvent le choix sensé. Mais rappelez‑vous : le choix du contrôleur ne restaurera pas la visibilité SMART perdue par les VMDK.
ZFS dans une VM élimine‑t‑il le besoin d’un SAN/NAS ?
Ça peut le remplacer pour certains environnements — surtout les PME — si vous traitez la VM de stockage comme un véritable appliance de stockage :
chemin matériel dédié, upgrades disciplinés, restorations testées, et frontières de domaines de défaillance claires.
Dois‑je exécuter ZFS sur l’hôte Proxmox ou dans une VM ?
Sur Proxmox : exécutez ZFS sur l’hôte sauf si vous avez une raison convaincante de ne pas le faire. C’est plus simple et plus observable.
Si vous avez besoin de l’écosystème appliance (services NAS, écosystème applicatif) et acceptez la complexité, une VM peut fonctionner.
Comment savoir si mes écritures sync sont le goulot ?
Si des bases de données ou des workloads NFS bloquent et que vos benchmarks async sont corrects, testez le comportement sync avec dd oflag=dsync et observez la latence.
Si le sync est lent, envisagez un SLOG avec PLP et vérifiez les politiques de cache.
Quel est le plus gros signal d’alerte dans une revue de design ZFS virtualisé ?
Une VM de stockage exécutant ZFS sur des VMDK thin-provisioned avec snapshots hyperviseur activés et sans monitoring clair de la saturation du datastore.
C’est une machine à panne lente.
Le pass-through HBA empêchera‑t‑il toute corruption ?
Non. Il réduit les couches qui peuvent mentir sur la durabilité et améliore la visibilité des erreurs.
Vous avez toujours besoin de redondance, scrubs, monitoring SMART, sauvegardes testées et processus opérationnels sains.
Prochaines étapes pratiques
Si vous construisez du neuf et que ZFS est central : choisissez l’architecture qui permet à ZFS de voir et contrôler les disques.
Sur Proxmox, cela signifie généralement ZFS sur l’hôte avec un vrai HBA (ou SATA AHCI) et aucune astuce RAID.
Sur ESXi, cela signifie généralement un HBA dédié passé en pass-through à une VM de stockage, avec le stockage exporté ensuite via NFS/iSCSI.
Si vous avez déjà déployé ZFS sur des disques virtuels en production : ne paniquez pas, mais arrêtez d’improviser.
Exécutez les tâches de diagnostic ci‑dessus, validez le comportement des écritures sync, vérifiez si vous voyez SMART, et décidez si le profil de risque correspond à votre activité.
Puis planifiez la migration vers un pass-through HBA comme vous planifiez tout projet de réduction de risque : délibérément, testé, et avec un plan de rollback.
Le chemin contrôleur n’est pas un détail cosmétique. C’est la différence entre ZFS qui est un narrateur fiable et ZFS coincé à l’arrière avec un bandeau sur les yeux.
Laissez‑le conduire.