L’incident n’a pas commencé par une explosion. Il a commencé par un e-mail « sauvegarde réussie » et un datastore qui s’est ralenti de 3 % chaque jour jusqu’à la panne.
Quand vous exécutez des VM pour des charges réelles, le stockage est l’endroit où l’optimisme va mourir—tranquillement, à 2 h du matin, après la troisième « suppression d’instantané » bloquée.
Ceci est une comparaison de niveau production : ZFS sur Proxmox contre VMFS sur ESXi. Pas des fonctionnalités sur une diapositive — des modes de défaillance, des falaises de performance, le comportement des instantanés,
et comment vous récupérez réellement quand quelqu’un a supprimé la mauvaise chose en toute confiance.
Prendre la décision comme un opérateur
Si vous voulez une version courte : ZFS est un système de fichiers + gestionnaire de volumes avec des avis. VMFS est un système de fichiers cluster conçu pour héberger des fichiers de VM en toute sécurité sur un stockage partagé.
Ils résolvent des problèmes différents, et le piège est de prétendre qu’ils sont interchangeables.
Choisissez ZFS sur Proxmox quand
- Vous possédez les disques (NVMe/SATA/SAS locaux) et vous voulez l’intégrité de bout en bout, des scrubs, et des outils de récupération prévisibles.
- Vous valorisez les instantanés comme primitive de premier ordre que vous pouvez répliquer (zfs send/receive) et raisonner dessus.
- Vous pouvez imposer une discipline de stockage : recordsize/volblocksize, ashift correct, et éviter les pièges d’amplification d’écriture.
- Vous voulez de la transparence pour le débogage : ZFS vous dit ce qu’il sait. Il vous dit aussi ce qu’il suspecte.
Choisissez VMFS sur ESXi quand
- Vous êtes sur un SAN partagé (FC/iSCSI/NVMe-oF) et vous avez besoin d’accès cluster avec le verrouillage de VMware, le multipathing et l’intégration écosystémique.
- Vous êtes standardisé opérationnellement sur vSphere : workflows vCenter, DRS, HA, playbooks de support constructeur.
- Vous voulez un comportement prévisible approuvé par le fournisseur même s’il est moins transparent. Parfois l’ennui est la caractéristique recherchée.
Ne choisissez pas en fonction d’une idéologie (« open source » vs « enterprise »). Choisissez en fonction de ce que vous pouvez maintenir en bonne santé à l’échelle avec vos équipes,
votre rotation d’astreinte et votre réalité matérielle.
Une citation à garder en poche lors des débats sur le stockage : l’idée de Werner Vogels (paraphrasée) que « tout tombe en panne, tout le temps »,
et les systèmes doivent être conçus autour de cela.
Blague n°1 : Si quelqu’un dit « le stockage, c’est facile », soit il ne s’est jamais réveillé en pleine nuit pour intervenir, soit il est sur le point de le faire.
Faits intéressants et contexte historique
- ZFS a été lancé chez Sun au milieu des années 2000 comme un système de fichiers combiné et gestionnaire de volumes, visant à remplacer des couches RAID + LVM + système de fichiers par une pile cohérente.
- Copy-on-write (CoW) n’était pas nouveau, mais ZFS l’a rendu opérationnellement utile à grande échelle : instantanés, sommes de contrôle et auto-réparation intégrés plutôt que greffés.
- VMFS a été conçu pour le stockage de virtualisation en cluster, se concentrant sur le fait de permettre à plusieurs hôtes ESXi d’accéder simultanément au même datastore en sécurité.
- Le mécanisme d’instantané de VMware n’est pas « une sauvegarde » par conception ; c’est une chaîne de deltas pour des tâches opérationnelles courtes — pourtant les gens continuent à le traiter comme une machine à remonter le temps.
- ZFS calcule la somme de contrôle de chaque bloc (données et métadonnées), permettant la détection de corruptions silencieuses que les RAID traditionnels pourraient renvoyer comme « réussi ».
- VMFS a évolué des réservations SCSI anciennes vers des verrous plus fins (ATS et mécanismes liés), réduisant la contention sur les LUN partagés.
- L’ARC de ZFS a changé la façon dont on pense au cache : il est adaptatif, conscient des métadonnées, et peut dominer la planification mémoire pour les hyperviseurs si vous le laissez faire.
- Les deux piles peuvent souffrir de « succès lent » : pas d’erreurs dures, juste une latence qui monte jusqu’à ce que les applications expirent et que les humains paniquent.
Instantanés : ce que vous pensez qui se passe vs ce qui se passe
Instantanés ZFS sur Proxmox : sémantique propre, arêtes vives
Les instantanés ZFS sont peu coûteux à créer et coûteux à conserver — spécifiquement, coûteux dans le sens où ils retiennent les anciens blocs et empêchent la réutilisation de l’espace libre.
L’instantané lui-même est de la métadonnée ; le coût en espace est la divergence après l’instantané. Opérationnellement, c’est excellent : vous obtenez des vues rapides à un point dans le temps,
des sémantiques de rollback prévisibles, et une réplication efficace via zfs send.
Dans Proxmox, vous stockerez typiquement les disques de VM soit en tant que ZVOLs (périphériques bloc soutenus par ZFS) soit en tant que fichiers (qcow2/raw) dans des datasets.
Les snapshots de ZVOL se mappent bien aux instantanés de disque VM parce que l’hyperviseur obtient un instantané cohérent du périphérique bloc. Ce n’est pas magique cependant :
la cohérence applicative nécessite toujours la coopération du guest (qemu-guest-agent, quiesce du système de fichiers, hooks spécifiques aux bases de données).
Les arêtes vives sont familières :
- Prolifération d’instantanés : des instantanés toutes les 15 minutes conservés pendant des mois transformeront « espace libre » en « fiction comptable ». ZFS ne supprimera pas les blocs encore référencés.
- Fragmentation : une forte rotation d’instantanés peut fragmenter les allocations ; les lectures ralentissent et les resilvers deviennent plus pénibles.
- Risque de rollback : revenir à un snapshot d’un dataset ou d’un ZVOL est un instrument grossier. C’est rapide. C’est aussi définitif pour tout ce qui a été écrit après l’instantané.
Instantanés VMFS sur ESXi : chaînes de deltas et drames de consolidation
Les instantanés ESXi créent des VMDK delta. Les écritures vont dans le delta ; la base reste principalement inchangée. C’est opérationnellement pratique pour des fenêtres de maintenance courtes.
Le coût apparaît plus tard : plus la chaîne d’instantanés existe et plus elle change, plus les E/S deviennent une chasse au trésor à travers plusieurs fichiers.
Le mode de défaillance le plus courant n’est pas « l’instantané existe ». C’est « la suppression d’un instantané déclenche la consolidation, qui déclenche une copie/merge importante,
qui déclenche de la latence, qui déclenche des timeouts applicatifs, qui pousse les gens à empirer la situation. »
Si vous n’avez jamais vu une consolidation se bloquer alors que le datastore est rempli à 92 %, vous n’avez pas vraiment fait l’expérience du genre spécial de peur
où chaque clic est une décision morale.
Conseils sur les instantanés pour tenir la route
- ZFS : maintenez des plannings d’instantanés serrés et une rétention intentionnelle. Répliquez hors hôte. Surveillez explicitement used-by-snapshots.
- ESXi/VMFS : traitez les instantanés comme un échafaudage opérationnel temporaire. Si vous avez besoin de points de restauration, utilisez un produit de sauvegarde qui comprend VMware.
- Les deux : mesurez l’impact des instantanés par la latence, pas par l’idéologie.
Performance : latence, IOPS et le « ça dépend » que vous pouvez mesurer
Ce que la performance signifie réellement pour les hyperviseurs
Les hyperviseurs ne « demandent » pas des IOPS. Ils demandent une latence basse et prévisible. Une VM avec une base de données se fiche que votre stockage fasse 400k IOPS à queue depth 128
si la latence d’écriture au 99e percentile monte à 40 ms pendant les merges d’instantanés. Vos utilisateurs vivront les pics, pas vos benchs.
Caractéristiques de performance de ZFS
La performance de ZFS est dominée par quelques leviers :
- Recordsize / volblocksize : un mauvais appairage avec la charge de travail vous fabriquera de l’amplification d’écriture.
- Dimensionnement de l’ARC : priver l’hôte du cache de pages et priver les VMs sont deux façons différentes d’avoir une mauvaise journée.
- Comportement du SLOG : n’importe que pour les écritures synchrones ; ce n’est pas un « cache d’écriture » comme les gens le souhaitent.
- Compression : peut être un gain gratuit sur les CPU modernes, mais dépend de la charge et peut augmenter la contention CPU sur des nœuds chargés.
Pour des charges VM, les ZVOLs avec volblocksize sensé (souvent 8K–16K selon la charge) et compression=lz4 sont des points de départ courants.
Mais ne faites pas de cargo-cult. Mesurez avec vos invités réels.
Caractéristiques de performance de VMFS
La performance de VMFS est façonnée par le stockage sous-jacent et le chemin : cache d’array, agencement RAID, saturation du contrôleur, réglages iSCSI/FC, firmware HBA,
politique de multipathing, profondeurs de file d’attente, et contention entre hôtes.
VMFS lui-même n’est généralement pas le goulot d’étranglement à moins que :
- vous fassiez beaucoup d’opérations metadata sur un datastore stressé,
- vous souffriez de contention de verrouillage, de thrashing de chemins, ou d’événements APD/PDL,
- vous exécutiez des chaînes profondes d’instantanés forçant des lectures aléatoires à travers des deltas.
Où les gens se trompent dans les comparaisons de performance
Ils comparent un ZFS NVMe local à VMFS sur un array milieu de gamme via iSCSI et concluent que ZFS est « plus rapide ». Sans surprise.
Ou ils comparent VMFS sur un SAN FC optimisé à ZFS sur un miroir SATA unique et concluent que VMware est « plus rapide ». Toujours sans surprise.
Comparez les architectures honnêtement : local vs partagé, niveau de redondance, cache de contrôleur, réseau, et domaines de défaillance.
Blague n°2 : Benchmarker le stockage, c’est comme tester un parachute en lisant le manuel — réconfortant jusqu’au saut.
Récupération : les éléments que vous toucherez pendant un incident
Récupération ZFS : outils déterministes, réalité impitoyable
ZFS brille quand quelque chose se corrompt silencieusement. Les sommes de contrôle le détectent. Les miroirs/RAIDZ peuvent s’auto-réparer. Les scrubs trouvent les problèmes avant que les utilisateurs ne les voient.
Quand un disque tombe en panne, le resilvering est généralement plus sûr que le rebuild RAID classique parce que ZFS sait quels blocs sont alloués et pertinents.
Mais ZFS exige que vous respectiez la physique :
- La capacité compte : ZFS n’aime pas tourner à chaud. À mesure que les pools se remplissent, la fragmentation et les performances d’écriture se dégradent. Les temps de resilver augmentent.
- Un ashift incorrect est pour toujours : choisissez un mauvais alignement de secteur et vous paierez en latence pour la durée de vie du pool.
- Les rebuilds RAIDZ ne sont pas magiques : ils lisent toujours beaucoup et stressent les disques restants.
Récupération VMFS : chemins opérationnels et limites fournisseur
La récupération VMFS dépend souvent du comportement de l’array de stockage, du tissu SAN, et de la gestion VMware des défaillances de chemins.
Si un LUN disparaît brièvement, vous pouvez obtenir des scénarios APD (All Paths Down) ou PDL (Permanent Device Loss).
Votre récupération porte moins sur « réparer un système de fichiers » et plus sur stabiliser l’accès et assurer la cohérence des métadonnées.
VMFS impose aussi une discipline concernant les instantanés et l’espace libre. Vous pouvez souvent récupérer d’un « oups, j’ai supprimé une VM » si vous avez des sauvegardes,
ou si l’array fournit ses propres instantanés. Mais VMFS ne vous sauvera pas des fantasmes de thin provisioning ou d’un array qui ment sur les blocs libres.
La question de récupération qui compte
Demandez : « Quand les choses déraillent, ai-je une procédure déterministe qu’un ingénieur d’astreinte peut exécuter sans être au téléphone avec le fournisseur de stockage ? »
ZFS obtient souvent une meilleure note sur le stockage local. VMFS est meilleur quand vous avez déjà une pratique SAN mûre et un modèle de support.
Pièges concrets qui mordent les adultes
Pièges ZFS sur Proxmox
- ARC vs VMs : ZFS prendra volontiers la mémoire. Si vous ne le limitez pas, vous affamerez les guests et blâmerez la « lenteur aléatoire ».
- zvol vs qcow2 : qcow2 apporte son propre CoW et une surcharge de métadonnées ; empiler CoW sur CoW peut être correct ou horrible selon le comportement sync/trim.
- Mauvaises interprétations du SLOG : un SLOG rapide aide les écritures sync, mais il ne peut pas réparer un pool qui ne peut pas soutenir votre charge d’écriture.
- Attentes TRIM/discard : le thin provisioning et le discard nécessitent un alignement entre l’OS invité, l’hyperviseur et les réglages ZFS.
- Penser que « les instantanés sont gratuits » : ce n’est pas vrai. Ce sont des factures différées.
Pièges VMFS sur ESXi
- Chaînes d’instantanés : les instantanés de longue durée détruisent la prévisibilité. La consolidation peut ruiner les performances au pire moment.
- Thin provisioning en couches : VMDK thin sur LUN thin sur array thin est une astuce de confiance. À un moment, quelqu’un manquera d’espace réel.
- Hypothèses sur la politique de multipath : « round robin » n’est pas toujours configuré ou approprié par défaut. Un déséquilibre de chemins peut ressembler à une latence aléatoire.
- Profondeur de file d’attente et limites HBA : un hôte peut intimider le datastore pendant que d’autres souffrent. On pense que « VMware est lent » alors que c’est de la contention.
- Gestion APD/PDL : si vous ne l’avez pas répétée, la première fois sera pendant un incident, ce qui est un terrible environnement de répétition.
Piège partagé : surveiller la mauvaise chose
Les deux mondes échouent quand vous surveillez des moyennes et ignorez la latence en queue, les tendances d’espace libre, et le travail de maintenance en arrière-plan.
Le stockage n’a pas besoin de votre attention jusqu’à ce qu’il en ait vraiment, vraiment besoin. Votre travail est de le remarquer plus tôt.
Mode opératoire pour diagnostic rapide
Quand le stockage est « lent », ne devinez pas. Triez rapidement, isolez la couche, puis commencez à ajuster.
Cet ordre réduit le temps pour atteindre la vérité en production.
Première étape : confirmez que c’est la latence du stockage, pas le CPU steal ou la pression mémoire
- Sur l’hyperviseur : vérifiez CPU ready/steal, swap de l’hôte, ballooning, et charge générale.
- Sur la VM : vérifiez si l’application est bloquée sur les E/S (iowait) ou bloquée sur des verrous.
Deuxième étape : identifiez lecture vs écriture, sync vs async, aléatoire vs séquentiel
- Des pics de latence d’écriture pendant les fenêtres de sauvegarde signifient souvent snapshot/replication/consolidation.
- Des pics de latence de lecture avec des écritures stables signifient souvent fragmentation, ratés de cache, ou problèmes de chemin.
- La douleur des écritures sync suggère SLOG (ZFS) ou cache d’array/BBU (SAN).
Troisième étape : trouvez le point de contention
- ZFS : pool occupé ? un vdev saturé ? ARC en thrash ? scrub/resilver en cours ?
- VMFS : contention sur le datastore ? thrash de chemins ? saturation des ports d’array ? limites de profondeur de file d’attente ?
Quatrième étape : vérifiez l’espace libre et la dette d’instantanés
- ZFS : pool à 80%+ avec beaucoup d’instantanés est une falaise de performance prévisible.
- VMFS : datastore quasi plein rend les opérations d’instantané risquées et peut déclencher une douleur de consolidation d’urgence.
Cinquième étape : choisissez une action sûre
- Réduisez la charge d’écriture, mettez en pause les sauvegardes non critiques, replanifiez les scrubs, évacuez les VMs chaudes.
- Ne « touchez pas à tout » pendant l’incident. Changez une chose que vous pouvez annuler.
Tâches pratiques : commandes, sorties et décisions
Voici des tâches réelles que vous lancerez quand quelque chose semble étrange. Chacune inclut : la commande, ce que la sortie signifie, et la décision que vous prenez.
Les commandes sont écrites pour un hôte Proxmox/ZFS ou un hôte ESXi selon le cas.
1) ZFS : vérifier la santé du pool et les compteurs d’erreurs
cr0x@server:~$ zpool status -v
pool: rpool
state: ONLINE
status: Some supported features are not enabled on the pool.
action: Upgrade the pool to enable all supported features.
scan: scrub repaired 0B in 00:12:41 with 0 errors on Sun Dec 22 03:00:18 2025
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme-SAMSUNG_MZVLB1T0 ONLINE 0 0 0
nvme-SAMSUNG_MZVLB1T0_2 ONLINE 0 0 0
errors: No known data errors
Signification : ONLINE avec zéro erreurs READ/WRITE/CKSUM est ce que vous voulez. Un scrub terminé avec 0 erreurs est une confiance silencieuse.
« Some supported features… » n’est généralement pas un incident ; c’est un choix de maintenance.
Décision : Si vous voyez des CKSUM non nuls, supposez des problèmes matériels/chemins jusqu’à preuve du contraire ; planifiez le remplacement du disque et lancez un scrub après.
Si un scrub tourne pendant un pic, envisagez de le replanifier mais ne l’annulez pas à la légère.
2) ZFS : identifier qui consomme l’espace (surtout les instantanés)
cr0x@server:~$ zfs list -o name,used,avail,refer,usedbysnapshots,mountpoint -r rpool
NAME USED AVAIL REFER USEDBYSNAPSHOTS MOUNTPOINT
rpool 820G 120G 192K 0B /rpool
rpool/data 810G 120G 192K 0B /rpool/data
rpool/data/vm-100-disk-0 220G 120G 180G 40G -
rpool/data/vm-101-disk-0 310G 120G 140G 170G -
Signification : usedbysnapshots montre les blocs retenus à cause des instantanés. Ces 170G sont de « l’espace que vous ne pouvez pas récupérer » tant que vous n’effacez pas les instantanés.
Décision : Si la marge du pool est serrée, supprimez les instantanés intentionnellement (les plus anciens en premier), ou répliquez puis taillez. N’attendez pas d’être à 95% plein.
3) ZFS : lister les instantanés et repérer la dérive de rétention
cr0x@server:~$ zfs list -t snapshot -o name,used,creation -s creation | tail -n 6
rpool/data/vm-101-disk-0@auto-2025-12-27_0200 1.2G Sat Dec 27 02:00 2025
rpool/data/vm-101-disk-0@auto-2025-12-27_0300 1.1G Sat Dec 27 03:00 2025
rpool/data/vm-101-disk-0@auto-2025-12-27_0400 1.3G Sat Dec 27 04:00 2025
rpool/data/vm-101-disk-0@auto-2025-12-27_0500 1.4G Sat Dec 27 05:00 2025
rpool/data/vm-101-disk-0@weekly-2025-11-24 32G Mon Nov 24 00:00 2025
rpool/data/vm-101-disk-0@monthly-2025-09-01 58G Mon Sep 1 00:00 2025
Signification : les instantanés horaires vont bien jusqu’à ce que des snapshots hebdomadaires/mensuels restent indéfiniment et accumulent de la divergence.
Décision : imposez une rétention ; si des snapshots mensuels sont requis, assurez-vous que la taille du pool en tient compte ou répliquez hors nœud et taillez localement.
4) ZFS : confirmer recordsize/volblocksize et compression pour le stockage VM
cr0x@server:~$ zfs get -o name,property,value -H recordsize,compression rpool/data
rpool/data recordsize 128K
rpool/data compression lz4
cr0x@server:~$ zfs get -o name,property,value -H volblocksize,compression rpool/data/vm-101-disk-0
rpool/data/vm-101-disk-0 volblocksize 8K
rpool/data/vm-101-disk-0 compression lz4
Signification : les datasets ont recordsize (E/S fichier). Les ZVOLs ont volblocksize (E/S bloc). Une VM DB-intensive sur un volblocksize 128K peut souffrir.
Décision : si vous observez une amplification d’écriture pathologique, créez de nouveaux ZVOLs avec un volblocksize approprié et migrez les disques. Vous ne pouvez pas changer volblocksize en place.
5) ZFS : vérifier la latence I/O du pool et quel vdev souffre
cr0x@server:~$ zpool iostat -v 1 3
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
rpool 820G 120G 210 980 12.3M 55.1M
mirror-0 820G 120G 210 980 12.3M 55.1M
nvme-SAMSUNG_MZVLB1T0 - - 102 480 6.1M 27.5M
nvme-SAMSUNG_MZVLB1T0_2 - - 108 500 6.2M 27.6M
-------------------------- ----- ----- ----- ----- ----- -----
Signification : ceci montre la distribution par vdev. Si un côté d’un miroir fait toutes les lectures ou écritures, vous pourriez avoir un problème de périphérique ou de chemin.
Décision : si la bande passante/ops est inégale ou si des erreurs apparaissent, vérifiez SMART et le câblage/backplane ; préparez-vous à remplacer le périphérique suspect.
6) ZFS : voir si un scrub/resilver vous vole votre repas
cr0x@server:~$ zpool status
pool: rpool
state: ONLINE
scan: scrub in progress since Sun Dec 28 10:03:11 2025
312G scanned at 1.10G/s, 84G issued at 302M/s, 820G total
0B repaired, 10.24% done, 00:41:12 to go
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme-SAMSUNG_MZVLB1T0 ONLINE 0 0 0
nvme-SAMSUNG_MZVLB1T0_2 ONLINE 0 0 0
Signification : un scrub est I/O-intensif. Sur certains pools c’est acceptable ; sur d’autres c’est un événement de performance.
Décision : si les pics de latence coïncident avec des scrubs, replanifiez les scrubs hors-pointe ; envisagez le réglage zfs_vdev_scrub_max_active seulement après avoir mesuré l’impact.
7) Proxmox : vérifier quel type de stockage soutient un disque VM (zvol vs qcow2)
cr0x@server:~$ qm config 101 | egrep 'scsi|virtio|ide|sata'
scsi0: local-zfs:vm-101-disk-0,size=200G
scsi1: local-lvm:vm-101-disk-1,size=50G
Signification : local-zfs indique un volume soutenu par ZFS (souvent un ZVOL). Cela impacte la mécanique des instantanés et les réglages de performance.
Décision : si une VM est sensible en performances, préférez un disque simple bloc (ZVOL ou raw sur stockage rapide) plutôt que des formats CoW empilés sauf si vous avez besoin des fonctionnalités de qcow2.
8) Linux/Proxmox : vérifier si ZFS affame la mémoire de l’hôte
cr0x@server:~$ arcstat 1 3
time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
10:21:11 812 44 5 9 20 10 23 25 57 62.1G 64.0G
10:21:12 790 51 6 11 21 9 18 31 61 62.2G 64.0G
10:21:13 805 47 5 10 21 8 17 29 62 62.2G 64.0G
Signification : la taille ARC proche de c indique que ZFS utilise ce qu’il est autorisé à utiliser. Si l’hôte swap alors que l’ARC est énorme, les guests souffrent.
Décision : limitez l’ARC (zfs_arc_max) si l’hôte a besoin de mémoire pour les VMs ; ne laissez pas « ZFS manger la RAM » sur un hyperviseur chargé sauf si vous avez prouvé que c’est sûr.
9) ZFS : vérifier le comportement des écritures sync et si vous forcez le sync
cr0x@server:~$ zfs get -o name,property,value -H sync,logbias rpool/data/vm-101-disk-0
rpool/data/vm-101-disk-0 sync standard
rpool/data/vm-101-disk-0 logbias latency
Signification : sync=standard respecte les demandes d’application. sync=disabled est un levier de perte de données déguisé en réglage de performance.
Décision : laissez sync tel quel sauf si vous comprenez les besoins de durabilité de votre charge. Si vous avez besoin de performance sync, investissez dans un SLOG approprié et une protection contre la perte d’alimentation.
10) ESXi : lister les datastores et l’espace libre (vérif sécurité des snapshots)
cr0x@server:~$ esxcli storage filesystem list
Mount Point Volume Name UUID Mounted Type Size Free
------------------------------------------------- ----------- ----------------------------------- ------- ---- ---------- ----------
/vmfs/volumes/DS_VMFS01 DS_VMFS01 64c1d7f1-0b12c9a0-3b7d-001b21aabbcc true VMFS-6 10.00T 1.12T
/vmfs/volumes/BOOTBANK1 BOOTBANK1 5f2a0f13-5caa1122-0000-000000000000 true vfat 3.99G 2.10G
Signification : 1.12T libre peut être suffisant — ou dangereusement bas — selon le comportement de consolidation d’instantanés et le thin provisioning en dessous.
Décision : si l’espace libre diminue et que vous avez des instantanés, ne prenez pas de risques : consolidez, évacuez des VMs, étendez le datastore, ou supprimez en toute sécurité avec un plan.
11) ESXi : identifier l’état des instantanés (depuis l’hôte)
cr0x@server:~$ vim-cmd vmsvc/getallvms | head
Vmid Name File Guest OS Version Annotation
12 app-portal-01 [DS_VMFS01] app-portal-01/app-portal-01.vmx ubuntu64Guest vmx-19
cr0x@server:~$ vim-cmd vmsvc/snapshot.get 12
GetSnapshot: Snapshot tree:
|-ROOT
+-Snapshot Name : pre-upgrade
Snapshot Id : 1
Snapshot Created On : 12/27/2025 01:12:44
Snapshot State : poweredOn
Signification : un instantané existe et n’est pas récent. C’est un risque. L’âge compte car la croissance du delta et la surcharge de chaîne se cumulent.
Décision : planifiez la consolidation pendant une charge faible. Si la VM écrit beaucoup, attendez-vous à une fusion bruyante ; prévoyez capacité et marge de performance.
12) ESXi : repérer les problèmes de pathing et les chemins morts
cr0x@server:~$ esxcli storage core path list | egrep -A3 'Runtime Name|State:|Preferred'
Runtime Name: vmhba64:C0:T2:L10
State: active
Preferred: true
Runtime Name: vmhba64:C0:T3:L10
State: dead
Preferred: false
Signification : un chemin mort peut créer une latence intermittente et un basculement thrash selon la politique de multipathing et le comportement de l’array.
Décision : réparez le fabric avant de tuner quoi que ce soit. Remplacez optiques/câbles, vérifiez les ports de switch, validez le zoning, et confirmez la santé de la cible array.
13) ESXi : vérifier la latence des périphériques depuis la vue de l’hyperviseur
cr0x@server:~$ esxtop -b -n 1 | head -n 12
# esxtop batch mode
# Time: 2025-12-28 10:35:11
# ...
Signification : En pratique vous utiliserez esxtop en interactif et regarderez des métriques disque comme DAVG (device), KAVG (kernel), et GAVG (guest).
Un DAVG élevé suggère l’array/stockage ; un KAVG élevé suggère de la mise en file ESXi ; un GAVG élevé est ce que ressentent les VMs.
Décision : si DAVG est élevé sur plusieurs hôtes, parlez à l’équipe array. Si KAVG est élevé sur un hôte, regardez la profondeur de file d’attente, le HBA, et les VMs « voisin bruyant ».
14) Proxmox : mesurer rapidement la pression I/O et la latence au niveau du nœud
cr0x@server:~$ iostat -x 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
12.01 0.00 4.20 8.55 0.00 75.24
Device r/s w/s rMB/s wMB/s await r_await w_await svctm %util
nvme0n1 210.0 980.0 12.3 55.1 6.20 3.10 6.90 0.40 48.0
Signification : await vous donne une image approximative de la latence. Un %util élevé avec un await croissant suggère saturation.
Décision : si vous satuez un périphérique/vdev unique, déplacez la charge ou redesign (plus de vdevs, disques plus rapides, séparer les charges). Ne « sysctllez » pas la physique.
Trois mini-histoires du monde de l’entreprise
Mini-histoire n°1 : un incident causé par une fausse hypothèse
Une entreprise de taille moyenne a migré un cluster d’un array vieillissant vers des NVMe locaux sous Proxmox avec des miroirs ZFS. La performance était immédiatement meilleure.
L’équipe a célébré en activant des instantanés fréquents « parce que les instantanés sont bon marché ».
Ils ont supposé que « bon marché » signifiait « gratuit ». Après quelques mois, le pool est resté autour de 88% alloué, mais la surveillance semblait correcte
parce que l’espace brut libre n’était jamais tombé à zéro et rien n’émettait d’erreurs. Puis la fenêtre de sauvegarde nocturne a commencé à durer plus longtemps,
et le helpdesk a commencé à marquer des tickets « lenteur ».
Un week-end, une grosse mise à niveau d’application a écrit beaucoup de données nouvelles. La latence a grimpé. Le pool est passé dans la zone où la fragmentation et les maps d’espace
rendaient les allocations coûteuses. Les VMs ne sont pas tombées ; elles sont juste devenues non réactives. C’est le pire type de panne parce que ça ressemble à un problème réseau,
un problème d’application, un problème DNS — tout sauf « stockage ».
L’ingénieur d’astreinte a supprimé une poignée d’anciens instantanés, s’attendant à un soulagement immédiat. Ça a aidé, mais pas vite ; la suppression devait encore libérer des métadonnées,
et le pool était déjà stressé. La vraie correction a été douloureuse mais simple : mettre en place une rétention avec plafonds stricts, répliquer hors hôte,
et garder une marge opérationnelle. Ils ont aussi appris à tracer « used by snapshots » par dataset.
Fausse hypothèse : « Si l’UI me laisse les créer indéfiniment, ça doit être sûr. » Les UI de stockage sont polies. La physique ne l’est pas.
Mini-histoire n°2 : une optimisation qui a mal tourné
Une autre organisation faisait tourner ESXi avec VMFS sur un array iSCSI partagé. Ils essayaient de réduire la latence sur une VM SQL chargée.
Quelqu’un a lu que « thin provisioning est lent », alors ils ont converti plusieurs gros VMDK en eager-zeroed thick pendant les heures de bureau.
La conversion elle-même a généré un énorme flux d’écriture. Le cache d’écriture de l’array l’a géré jusqu’à ce qu’il ne puisse plus.
Le réseau iSCSI a commencé à montrer des micro-bursts. D’autres hôtes ont subi des pics de latence intermittents, ce qui a déclenché des timeouts applicatifs,
ce qui a déclenché des retries, ce qui a augmenté la charge. Boucle de rétroaction classique.
L’équipe a vu que le datastore VMFS était « correct » et que l’array était « sain ». C’est le piège : les indicateurs de santé signifient souvent « pas mort », pas « rapide ».
vCenter affichait des alarmes de latence de stockage croissantes. L’équipe DB voyait des deadlocks et blâmait l’application.
Après stabilisation en mettant en pause les conversions et en évacuant quelques VMs bruyantes, ils ont fait l’analyse ennuyeuse :
compteurs de chemin de stockage, profondeurs de file d’attente, et graphiques de performance de l’array. L’array n’était pas cassé ; il était saturé par un travail d’écriture massif bien intentionné.
L’optimisation n’était pas fausse. Le timing l’était.
Optimisation qui a mal tourné : « Faisons des transformations de stockage lourdes sur le datastore de production pendant les heures de pointe. » Parfois le travail de performance ne fait que déplacer la douleur.
Mini-histoire n°3 : la pratique ennuyeuse mais correcte qui a sauvé la journée
Une société de services financiers utilisait Proxmox avec ZFS pour les charges de succursales et ESXi avec VMFS pour les charges cœur. Deux piles différentes, une habitude commune :
ils répétaient les procédures de récupération et tenaient des runbooks réellement exécutables.
Un nœud Proxmox a perdu un disque dans un miroir. Pas de drame : alerte, l’ingénieur a vérifié zpool status, a remplacé le disque, a regardé le resilver progresser,
et a validé un scrub plus tard. Les VMs sont restées en marche. Personne n’a écrit de postmortem parce que rien n’a brûlé.
Des semaines plus tard, un bug de firmware d’un switch SAN a provoqué de brefs flaps de chemins. Les hôtes ESXi ont vu des chemins morts intermittents.
Parce que l’équipe avait répété leur playbook APD/PDL, ils n’ont pas couru après des fantômes dans l’OS invité.
Ils ont vérifié les chemins, stabilisé le fabric, puis seulement commencé à évacuer les VMs du datastore le plus affecté.
La pratique salvatrice n’était pas une fonctionnalité élégante. C’était des scrubs de routine, des restaurations testées, et une culture du « prouve que ça marche » plutôt que « suppose que ça marche ».
L’ennui a gagné. Encore.
Erreurs courantes : symptôme → cause → correction
1) Le pool ZFS semble sain, mais les VMs ralentissent chaque semaine
Symptôme : pas d’erreurs disque, mais la latence de lecture grimpe et l’I/O aléatoire empire.
Cause : churn d’instantanés et forte occupation du pool causant fragmentation ; ratés ARC en augmentation ; pool trop plein.
Correction : réduisez la rétention d’instantanés, gardez plus d’espace libre (visez une marge significative), envisagez d’ajouter des vdevs (pas seulement des disques plus gros), et mesurez avant/après avec des percentiles de latence.
2) L’« espace libre » ZFS semble correct, mais vous ne pouvez pas récupérer d’espace après suppression de données
Symptôme : données supprimées dans la VM, mais l’usage du dataset reste élevé ; le pool reste tendu.
Cause : les instantanés retiennent les anciens blocs ; le discard invité n’est pas transmis ; TRIM non configuré/fonctionnel bout en bout.
Correction : vérifiez usedbysnapshots, taillez les instantanés, activez discard si approprié, et validez avec des tests contrôlés — pas par espoir.
3) Une VM ESXi se fige pendant la suppression d’un instantané
Symptôme : la suppression d’un instantané se bloque, la latence du datastore explose, la VM devient non réactive.
Cause : la consolidation/merge est lourde ; le datastore est trop plein ; l’array sous-jacent est saturé ; la chaîne d’instantanés est profonde.
Correction : assurez-vous de l’espace libre du datastore, faites la consolidation hors-pointe, réduisez les I/O concurrentes (pause des sauvegardes), et évitez les instantanés de longue durée par politique.
4) Le datastore VMFS signale beaucoup d’espace, puis tombe soudainement en comportement « out of space »
Symptôme : les écritures échouent, les VMs se mettent en pause, alarmes array, mais le datastore ne paraissait pas « plein » la semaine précédente.
Cause : thin provisioning en couches ; la capacité réelle de l’array est épuisée tandis que VMFS pensait encore avoir de la place.
Correction : surveillez la capacité réelle de l’array, fixez des limites d’overcommit conservatrices, et imposez des alarmes à la fois dans vCenter et côté stockage.
5) Les écritures sync ZFS sont douloureusement lentes après un « tuning »
Symptôme : les commits de la base de données rament ; la latence explose ; quelqu’un dit « ajoute un SLOG » et cela n’aide pas.
Cause : la charge est sync-heavy et le pool ne peut pas la soutenir ; le périphérique SLOG est lent ou sans protection puissance ; ou le sync a été forcé involontairement.
Correction : validez le comportement sync, utilisez des SSD/NVMe entreprise avec PLP pour le SLOG, et corrigez la performance du pool sous-jacent (plus de vdevs, média meilleur).
6) Les pics de latence ESXi n’affectent qu’un seul hôte
Symptôme : un hôte voit une latence élevée alors que les autres vont bien sur le même datastore.
Cause : mauvaise configuration de pathing, différences de profondeur de file d’attente, mismatch firmware, ou un seul hôte saturant son HBA.
Correction : comparez la config multipath entre hôtes, vérifiez les chemins morts, alignez versions firmware/driver, et identifiez les voisins bruyants avec esxtop.
Listes de contrôle / plan pas-à-pas
Checklist de planification : choisir entre stockage local ZFS et stockage partagé VMFS
- Définissez les domaines de défaillance : voulez-vous qu’une panne d’hôte emporte le stockage (local), ou avez-vous besoin de continuité de stockage partagé ?
- Définissez les objectifs de récupération : RPO/RTO pour la restauration de VM, et si vous pouvez restaurer sans intervention fournisseur.
- Inventoriez les patterns d’écriture : bases de données, logging, queues — ces charges punissent les pics de latence.
- Décidez de la politique d’instantanés : instantanés opérationnels vs sauvegardes ; rétention ; cible de réplication ; procédure de restauration testée.
- Plan de capacité avec marge : inclure la rétention d’instantanés, la charge rebuild/resilver, et la croissance « jour de merde ».
- Plan de surveillance : latence queue, tendance espace libre, nombre/âge d’instantanés, état scrub/resilver, santé des chemins.
ZFS sur Proxmox : construisez et exploitez sérieusement
- Choisissez la topologie adaptée : miroirs pour IOPS/latence ; RAIDZ pour capacité ; ne prétendez pas que RAIDZ est aussi rapide qu’un miroir.
- Définissez ashift correctement à la création du pool : supposez des secteurs 4K (ou plus pour certains SSD). Un ashift mauvais est une taxe à vie.
- Décidez ZVOL vs fichiers dataset : par défaut ZVOL pour les disques VM sauf si vous avez besoin des fonctions qcow2.
- Définissez des valeurs par défaut sensées : compression=lz4 ; atime=off pour les datasets VM ; volblocksize cohérent pour les nouveaux disques VM selon la classe de charge.
- Limitez l’ARC si nécessaire : les hyperviseurs ont besoin de mémoire pour les guests d’abord, ARC ensuite.
- Planifiez les scrubs : mensuel est courant ; plus fréquent pour du hardware capricieux. Surveillez la durée.
- Instantané et réplication : snapshots locaux pour rollback rapide, snapshots répliqués pour véritable récupération.
- Testez les restaurations : « zfs send succeeded » n’équivaut pas à « la VM a booté ».
VMFS sur ESXi : exploitez-le en sécurité sous charge réelle
- Faîtes le multipathing correctement : cohérence de politique entre hôtes, alerting sur chemins morts, et hygiène switch/array.
- Surveillez la latence au bon niveau : connaissez les motifs DAVG/KAVG/GAVG et ce qu’ils impliquent.
- Définissez une politique d’instantanés : instantanés opérationnels uniquement ; imposez des limites d’âge ; automatisez les rapports.
- Discipline de capacité : gardez la marge sur les datastores ; ne pariez pas l’entreprise sur des illusions thin-on-thin.
- Répétez les scénarios APD/PDL : décidez quand basculer, quand évacuer, et quand arrêter de toucher au système.
- Sauvegardes qui comprennent VMware : cohérence applicative quand nécessaire, et tests de restauration incluant réseau et vérification de boot.
FAQ
1) Les instantanés ZFS sont-ils « meilleurs » que les instantanés ESXi ?
Ils sont meilleurs en tant que primitive de stockage : sémantique cohérente, création bon marché, et réplication via send/receive. Les instantanés ESXi sont des outils opérationnels qui deviennent des responsabilités quand on les garde trop longtemps.
Si vous voulez des points de restauration, traitez les snapshots ESXi comme transitoires et utilisez des sauvegardes pour la durabilité.
2) ZFS remplace-t-il les contrôleurs RAID ?
Dans beaucoup de designs, oui : utilisez des HBAs/JBOD et laissez ZFS gérer la redondance et l’intégrité. Mais vous devez concevoir les vdevs correctement et les surveiller.
Le RAID matériel peut encore être approprié dans certains environnements contraints, mais empiler RAID sous ZFS réduit souvent l’observabilité et complique la récupération.
3) Dois-je utiliser qcow2 sur ZFS dans Proxmox ?
Seulement si vous avez besoin des fonctionnalités de qcow2 (par ex. certains comportements sparse) et que vous avez testé les performances. Pour la plupart des disques VM en production sur ZFS, les ZVOLs sont plus simples et souvent plus rapides.
CoW-sur-CoW peut être correct, mais c’est aussi une manière facile de créer une latence que vous diagnostiquerez mal pendant des semaines.
4) Le SLOG est-il obligatoire pour le stockage VM ZFS ?
Non. Le SLOG compte pour les écritures synchrones. Beaucoup de charges VM sont largement asynchrones. Si vous avez des bases de données ou NFS avec exigences sync, un bon SLOG peut aider.
Un mauvais périphérique SLOG peut nuire — ou au moins échouer de manière spectaculaire.
5) À quel niveau un pool ZFS est-il « trop plein » ?
Il n’y a pas un chiffre unique, mais la performance et le risque de resilver s’aggravent à mesure que vous remplissez le pool. Au-delà d’environ ~80% vous devriez agir comme si vous étiez dans la zone de danger,
surtout avec des instantanés lourds. Au-delà de ~90% vous négociez avec l’entropie.
6) À quel niveau un datastore VMFS est-il « trop plein » ?
Si vous dépendez d’instantanés ou avez une croissance imprévisible, « confortablement plein » est un mythe. Gardez de la marge pour les événements de consolidation et la croissance inattendue des deltas.
Le seuil exact dépend de la taille des VM et du taux de changement, mais des datastores proches du plein rendent les opérations d’instantané risquées.
7) ZFS peut-il me fournir du stockage partagé comme VMFS ?
Pas directement de la même manière. ZFS est typiquement local à un hôte. Vous pouvez construire du stockage partagé par-dessus (NFS/iSCSI exporté depuis ZFS),
ou utiliser des systèmes de fichiers cluster et des stratégies de réplication, mais c’est une architecture différente avec des modes de défaillance différents.
8) Quelle est la manière la plus propre de répliquer le stockage VM ZFS de Proxmox ?
La réplication d’instantanés via zfs send/receive est la primitive propre. Proxmox propose des outils autour, mais la vérité sous-jacente reste :
vous envoyez des deltas d’instantanés. Validez la bande passante, l’alignement de rétention, et la capacité à booter les VMs restaurées.
9) Pourquoi les consolidations d’instantanés ESXi prennent-elles parfois une éternité ?
Parce que la consolidation est une grande opération de copie/merge sous charge, et elle rivalise avec l’I/O de production. Si le delta est énorme, le datastore occupé,
ou l’array proche de saturation, la fusion rame. La « correction » est préventive : gardez les instantanés de courte durée.
10) Si mon array a des instantanés, dois-je encore me soucier des snapshots VMFS ?
Oui. Les snapshots d’array peuvent être excellents pour un rollback crash-consistent au niveau LUN, mais vous devez comprendre la coordination avec VMware,
la quiescence, et les workflows de restauration. Les snapshots VMFS ne sont pas un substitut ; ce sont un outil différent avec un rayon d’impact différent.
Prochaines étapes
Si vous exécutez Proxmox avec ZFS : auditez la rétention d’instantanés, tracez usedbysnapshots, limitez l’ARC si les hôtes manquent de mémoire, et vérifiez que les scrubs se terminent selon le planning.
Ensuite faites un test de restauration qui boote une VM et valide la santé applicative. Pas « le dataset existe » — la VM fonctionne réellement.
Si vous exécutez ESXi avec VMFS : inventoriez les instantanés sur la flotte, imposez un âge maximum, vérifiez la marge des datastores, et validez le multipath.
Ensuite répétez une consolidation dans des conditions contrôlées pour que la première fois ne soit pas pendant un incident.
Si vous choisissez entre eux : arrêtez d’en faire une guerre de religion. Cartographiez vos domaines de défaillance, votre maturité opérationnelle, et vos exigences de récupération.
Choisissez la pile que vous pouvez garder ennuyeuse.