Stockage pour la virtualisation sur Proxmox : ZFS vs Ceph vs iSCSI vs NFS

Règles de décision utilisables

Si vous ne retenez qu’une chose, retenez ceci : vous ne choisissez pas « le stockage », vous choisissez des modes de défaillance. La performance est une caractéristique ; la prévisibilité est un produit.

Choisir ZFS (local) quand

• Vous pouvez tolérer que le stockage d’un nœud ne soit pas automatiquement partagé.
• Vous voulez une forte intégrité des données et un comportement de récupération transparent.
• Votre charge est principalement « les VM résident sur le nœud où elles s’exécutent », avec migration/HA gérées par réplication ou sauvegardes.
• Vous valorisez la simplicité opérationnelle : une box, un pool, un ensemble d’outils.

Conseil d’opinion : Pour 1–3 nœuds, ZFS est la réponse par défaut sauf si vous avez une exigence stricte pour un stockage bloc partagé et la migration à chaud sans planification.

Choisir Ceph quand

• Vous avez besoin d’un stockage partagé entre de nombreux hyperviseurs et vous attendez que des nœuds meurent sans drame.
• Vous pouvez financer 3+ nœuds (vraiment) et assez de disques pour que la réplication ait du sens.
• Vous disposez d’un réseau pour le supporter : faible latence, non oversubscribed, idéalement dédié au trafic stockage.
• Vous êtes prêt à exploiter un système distribué volontairement, pas par accident.

Conseil d’opinion : Ceph est excellent quand vous avez un cluster. C’est un passe-temps quand vous avez deux nœuds et un rêve.

Choisir iSCSI quand

• Vous possédez déjà un array ou SAN qui propose snapshots, réplication et contrats de support.
• Vous voulez des sémantiques bloc et une gestion centralisée du stockage.
• Vous pouvez configurer multipath correctement et comprendre le rayon d’impact d’un seul array.

Conseil d’opinion : iSCSI convient si l’array est le produit. Si votre « array » est une VM Linux avec deux disques, vous réinventez la déception.

Choisir NFS quand

• Vous voulez la voie la plus rapide vers un stockage partagé avec un comportement compréhensible.
• Vous stockez des images VM ou des sauvegardes et pouvez vivre avec « le serveur est le serveur ».
• Vous voulez une inspection humaine facile et des workflows de récupération plus simples.

Conseil d’opinion : NFS est le monospace du stockage pour virtualisation : pas sexy, presque toujours adéquat, et tout le monde a un avis sur les porte-gobelets.

Une idée paraphrasée : l’idée de fiabilité de Jim Gray (paraphrasée) : si vous ne pouvez pas expliquer votre modèle de défaillance, vous n’avez pas un système — juste une démo.

Un modèle mental : ce que font les VM au stockage

Les machines virtuelles infligent trois choses que le stockage déteste :

• Des écritures aléatoires de plusieurs invités en même temps. Même les écritures « séquentielles » des invités se fragmentent à l’hôte.
• Du churn de métadonnées : snapshots, clonage, thin provisioning et copy-on-write transforment « écrire des données » en « écrire des données plus tenue de livres ».
• Sensibilité à la latence : une VM n’est pas un serveur de base de données ; c’est une pile d’ordonnanceurs. Ajouter 5 ms au niveau stockage peut ajouter 50 ms de « pourquoi SSH est lent ? » en haut.

Ensuite, ajoutez les réalités spécifiques à Proxmox :

• Les disques VM peuvent être raw (meilleur), qcow2 (fonctionnalités mais overhead) ou RBD (block Ceph).
• Les sauvegardes et snapshots se font sur l’hôte, pas dans l’invité, ce qui est bien jusqu’à ce que votre backend storage interprète cela comme une « amplification d’écriture surprise ».
• La migration à chaud veut du stockage partagé ou une copie rapide. « Copie rapide » reste une copie. Copier reste des IO.

Donc la question devient : où voulez-vous que la complexité vive — sur chaque nœud (ZFS), dans un NAS/SAN partagé (NFS/iSCSI), ou dans le tissu du cluster (Ceph) ?

Blague 1/2 : le stockage est le seul endroit où « ça marchait en test » signifie « personne n’a testé la VM voisin bruyante ».

ZFS sur Proxmox : local d’abord, intégrité d’abord

ZFS est un système de fichiers et un gestionnaire de volumes qui a l’air personnellement offusqué par la corruption silencieuse. Checksums partout. Sémantiques copy-on-write. Snapshots vraiment utiles. send/receive de réplication ennuyeux dans le meilleur sens.

Ce pour quoi ZFS excelle en virtualisation

• Récupération prévisible : un vdev miroir perd un disque, vous le remplacez, vous resilver. Pas de magie.
• Snapshots avec de vrais outils : les snapshots ZFS sont bon marché ; leur coût est la fragmentation à long terme et la croissance des métadonnées si vous en conservez trop.
• Performance locale : avec des miroirs NVMe et suffisamment de RAM, ZFS est brutalement rapide pour des charges VM.
• Intégrité des données : les checksums end-to-end détectent les mauvais disques, câbles, contrôleurs et les mauvais jours.

Ce que ZFS n’est pas

ZFS n’est pas du stockage partagé par défaut. Vous pouvez répliquer, sauvegarder, construire une couche partagée dessus, mais ZFS lui-même ne fournira pas un stockage bloc partagé transparent entre nœuds.

Règles de conception pour rester hors de problèmes

• Mirrors battent RAIDZ pour la latence VM. RAIDZ peut convenir pour des charges axées capacité, lecture et séquentielles. La latence d’écriture aléatoire VM n’est pas ce type de charge.
• Ne vous obsessionnez pas sur SLOG sauf si vous comprenez les écritures sync. Pour beaucoup de charges VM, soit vous n’avez pas besoin d’un SLOG, soit vous en avez besoin d’un très bon. Un « SLOG SSD » pas cher est un piège de fiabilité s’il ment sur la protection contre la perte d’alimentation.
• Utilisez des disques/volumes raw quand c’est possible. qcow2 a des fonctionnalités ; il a aussi un overhead. Les ZVOLs ou fichiers raw se comportent généralement mieux pour les IO chauds.
• Gardez les snapshots sous contrôle. Des centaines de snapshots sur des datasets VM occupés transformeront lentement votre « pool rapide » en « pool rapide (reconstitution historique) ».

Les réglages qui comptent (et pourquoi)

Trois molettes apparaissent dans les postmortems plus souvent qu’elles ne le devraient :

• ashift (alignement de la taille de secteur). Se tromper à la création du pool et vous entérinez l’amplification d’écriture.
• recordsize / volblocksize. Un mismatch avec la charge et vous gaspillez des IO ou amplifiez les écritures.
• sync. « sync=disabled » est la façon de transformer une batterie UPS en loterie de perte de données.

Ceph sur Proxmox : stockage distribué avec du mordant

Ceph, c’est ce qui arrive quand vous voulez que le stockage se comporte comme un primitif cloud : auto-guérison, réplication, montée en charge et natif réseau. Ça peut être glorieux. Ça peut aussi être une leçon de physique au ralenti.

Ce pour quoi Ceph excelle

• Stockage bloc partagé (RBD) entre hôtes, avec migration à chaud qui n’implique pas de copier les disques.
• Tolérance aux pannes quand il est correctement conçu : un OSD meurt, un hôte meurt, des disques meurent, et le cluster continue de servir.
• Levier opérationnel à l’échelle : ajoutez des nœuds, ajoutez des OSD, rééquilibrez, continuez.

Ce que Ceph exige

• Qualité du réseau : latence et perte de paquets se traduiront par « lenteur VM aléatoire » et « tâches bloquées ».
• Budget IOPS : la réplication signifie que vous payez les écritures plusieurs fois. Les petites écritures se multiplient et sont journalisées. Ce n’est pas optionnel.
• Marge de capacité : fonctionner proche du plein n’est pas « efficace », c’est une falaise de performance. Le rééquilibrage a besoin d’espace.
• Maturité opérationnelle : vous devez pouvoir interpréter la santé du cluster, les états de backfill et le comportement des placement group sans paniquer sur l’interface.

Ceph pour Proxmox : conseils pratiques

Pour les disques VM, utilisez RBD sauf si vous avez un besoin spécifique d’un système de fichiers POSIX ; CephFS est excellent, mais il convient mieux aux fichiers partagés, pas aux disques VM chauds. Si votre charge est sensible à la latence et intensive en écriture, budgétez des OSD rapides (NVMe ou très bons SSD) et un vrai réseau de stockage.

Le tuning Ceph est moins une question de sysctls magiques que d’architecture sensée : assez d’OSD, réplication appropriée, CPU suffisant par hôte, et ne pas faire tourner Ceph sur des nœuds faibles que vous espériez utiliser comme compute.

Blague 2/2 : Ceph est « simple » de la même manière qu’un conteneur maritime est « juste une boîte ». Les parties intéressantes sont tout ce qui l’entoure.

iSCSI : stockage bloc aux arêtes vives

iSCSI est du stockage bloc sur IP. Ce n’est pas moderne, pas tendance, et pas prêt de disparaître. En environnement d’entreprise, c’est souvent la voie de moindre résistance parce qu’il y a déjà un SAN et une équipe qui parle fluent LUN.

Quand iSCSI est la bonne réponse

• Vous avez besoin de stockage bloc partagé et vous faites davantage confiance à votre array qu’au stockage distribué bricolé.
• Vous voulez des snapshots/réplication centralisés gérés par l’array (et le fournisseur prend les appels de nuit).
• Vous pouvez implémenter multipath et réseau redondant correctement.

Modes de défaillance à accepter

• Rayon d’impact centralisé : panne de l’array = douleur sur tout le cluster.
• Sensibilité au chemin réseau : micro-bursts et MTU mal configuré peuvent ressembler à « corruption disque VM » alors qu’il s’agit de timeouts et resets.
• Interactions profondeur de file d’attente / latence : une VM bavarde peut plonger le LUN dans des latences extrêmes si l’array n’est pas bien provisionné.

Sur Proxmox, on associera souvent iSCSI à LVM ou ZFS sur iSCSI (oui, c’est possible, mais faites-le en connaissance de cause). Si vous avez déjà ZFS local, empiler ZFS par-dessus iSCSI signifie généralement doubler la complexité pour des gains incertains.

NFS : stockage partagé simple (jusqu’à ce que ça ne le soit plus)

NFS est du stockage fichier sur le réseau. Facile à configurer, facile à raisonner, et facile à dépasser. Pour beaucoup de clusters Proxmox, c’est le compromis adéquat : stockage partagé pour ISO/templates/sauvegardes et même disques VM si les besoins en performance sont modérés et que le serveur est correct.

NFS brille quand

• Vous voulez du stockage partagé sans exécuter un système de stockage distribué.
• Vous valorisez la récupération simple : montez l’export ailleurs et vos fichiers sont là.
• Votre charge n’est pas extrêmement sensible à la latence ni très intensive en écritures.

NFS fait mal quand

• Votre NAS est sous-dimensionné et devient le goulot unique.
• Les options de montage sont incorrectes pour les images VM (le cache et le verrouillage comptent).
• Vous traitez NFS comme du stockage bloc et attendez qu’il se comporte comme un SAN.

Proxmox supporte bien NFS. Ne faites pas semblant que c’est magique. Le serveur NFS est désormais une dépendance critique : surveillez-le, patchz-le, et donnez-lui un stockage qui ne tombe pas pendant un scrub/rebuild RAID.

Faits intéressants et un peu d’histoire (utile)

1. ZFS est né chez Sun Microsystems au milieu des années 2000 avec les checksums end-to-end comme fonctionnalité centrale, pas en option.
2. Le copy-on-write prédate la virtualisation moderne ; c’est une vieille idée devenue mainstream parce que les snapshots et clones sont de l’or opérationnel.
3. Ceph a commencé comme projet universitaire et est devenu une plateforme de stockage open-source majeure adoptée massivement à l’époque OpenStack.
4. RBD existe parce que les systèmes de fichiers n’étaient pas suffisants pour les sémantiques bloc cloud : images, clones et snapshots à l’échelle voulaient une interface bloc native.
5. NFS date des années 1980 et survit parce que « un système de fichiers partagé » reste un besoin fondamental, et il est assez simple à déboguer avec des paquets.
6. iSCSI a été standardisé au début des années 2000 pour amener l’accès SAN sur les réseaux Ethernet grand public.
7. L’amplification d’écriture n’est pas un problème théorique : les systèmes COW plus les charges VM peuvent multiplier les écritures backend de façon spectaculaire, surtout avec snapshots et petits blocs.
8. L’algorithme de placement « CRUSH » de Ceph est conçu pour éviter les tables de recherche centrales pour le placement des données, ce qui importe quand vous scalez.
9. Proxmox a popularisé le clustering « batteries incluses » pour les petites et moyennes structures : vous obtenez KVM, gestion, sauvegardes et intégration stockage sans assembler une douzaine de composants.

12+ tâches pratiques : commandes, sorties, décisions

Voici les vérifications que je lance quand quelqu’un dit « le stockage est lent » ou « les migrations ont déconné ». Chaque tâche inclut : commande, ce que la sortie signifie, et la décision à prendre.

Tâche 1 : Identifier le backend de stockage par VM

cr0x@server:~$ qm config 101
boot: order=scsi0;ide2;net0
cores: 4
memory: 8192
name: app01
scsi0: local-zfs:vm-101-disk-0,size=120G
ide2: local:iso/debian-12.iso,media=cdrom
net0: virtio=DE:AD:BE:EF:00:01,bridge=vmbr0

Sens : local-zfs vous indique qu’il s’agit d’un volume ZFS sur ce nœud, pas partagé. Si vous attendiez du stockage partagé pour la migration à chaud, vous venez de trouver le mismatch.

Décision : Pour HA/migration à chaud sans downtime, soit déplacez le disque VM vers Ceph/NFS/iSCSI soit implémentez la réplication ZFS + basculement planifié.

Tâche 2 : Confirmer quels stockages Proxmox voit

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active      102305280        25165824        77175168   24.60%
local-zfs        zfspool  active     9999220736      2130706432      7868514304   21.31%
ceph-rbd         rbd      active    29997662208      8996782080     209,?         29.99%

Sens : Confirme quels backends sont en ligne et si Proxmox peut les atteindre. Si Ceph affiche une capacité bizarre ou devient inactive, arrêtez de blâmer « la VM ».

Décision : Si un store partagé flappe, traitez-le comme un incident sur la couche stockage, pas sur le compute.

Tâche 3 : Vérification de santé ZFS (ne devinez pas)

cr0x@server:~$ zpool status -x
all pools are healthy

Sens : Pool sain. Si la performance est mauvaise, ce n’est pas parce que ZFS est actuellement dégradé.

Décision : Si cela rapporte des vdevs dégradés ou des erreurs de checksum, stoppez le travail de performance et commencez par la sécurité des données.

Tâche 4 : Vérifier la topologie du pool ZFS (mirror vs RAIDZ)

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            nvme0n1   ONLINE       0     0     0
            nvme1n1   ONLINE       0     0     0

Sens : vdev miroir. Bon pour la latence VM. Si vous voyez RAIDZ1/2 avec peu de disques et des VM writes-heavy, attendez une latence tail plus élevée.

Décision : Si la latence VM est le problème et que vous êtes en RAIDZ, envisagez de migrer les VM chaudes vers des mirrors ou des vdevs SSD/NVMe.

Tâche 5 : Vérifier les propriétés ZFS qui influencent le comportement VM

cr0x@server:~$ zfs get -o name,property,value -s local recordsize,compression,atime,sync tank/vmdata
NAME         PROPERTY     VALUE
tank/vmdata  atime        off
tank/vmdata  compression  lz4
tank/vmdata  recordsize   128K
tank/vmdata  sync         standard

Sens : Valeurs par défaut sensées : lz4 aide plus souvent qu’elle ne nuit ; atime=off évite des écritures de métadonnées ; sync=standard est sûr.

Décision : Si vous voyez sync=disabled sur des datasets VM, décidez si vous acceptez de perdre des écritures récentes après un crash. La plupart des environnements de production ne devraient pas.

Tâche 6 : Trouver la pression ARC ZFS (RAM comme composant de performance)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:01   812    74      9     9   12    65   88     0    0   48G   56G
12:01:02   790    80     10     8   10    72   90     0    0   48G   56G
12:01:03   805    77     10     7    9    70   91     0    0   48G   56G

Sens : Taille ARC vs cible (arcsz vs c) et taux de miss. Un taux de miss élevé en steady-state peut signifier que votre working set ne tient pas en RAM.

Décision : Si les misses sont constamment élevés et que les disques sont occupés, ajoutez de la RAM ou migrez les workloads chauds sur des médias plus rapides ; ne micro-ajustez pas avant d’avoir la bonne dimension.

Tâche 7 : Vérifier la latence IO en direct sur l’hôte

cr0x@server:~$ iostat -x 1 3
Linux 6.8.12-pve (pve1)  12/28/25  _x86_64_  (16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         120.0   310.0  4096.0 18560.0   2.10   0.25  11.0
nvme1n1         118.0   305.0  4000.0 18200.0   2.35   0.24  10.7

Sens : await est la métrique pratique « quel est le ressenti ». Si await est 20–200 ms, les invités vont se plaindre. Si %util est saturé, vous êtes saturé.

Décision : Await élevé avec faible util suggère un en-queue ailleurs (contrôleur, locks FS, réseau). Await élevé avec util élevé suggère qu’il vous faut plus de spindles/IOPS.

Tâche 8 : Cartographier quel processus/VM fait des IO

cr0x@server:~$ pvesh get /nodes/pve1/qemu --output-format json-pretty
[
  {
    "cpu": 0.17,
    "diskread": 1610612736,
    "diskwrite": 987654321,
    "mem": 0.62,
    "name": "db01",
    "pid": 24510,
    "status": "running",
    "uptime": 182003,
    "vmid": 110
  },
  {
    "cpu": 0.04,
    "diskread": 10485760,
    "diskwrite": 7340032,
    "mem": 0.28,
    "name": "app01",
    "pid": 25111,
    "status": "running",
    "uptime": 55321,
    "vmid": 101
  }
]

Sens : Vue rapide par VM. La VM « db01 » effectue de vrais IO. Corrélez avec les métriques de latence.

Décision : Si une VM domine les IO et cause des dommages collatéraux, isolez-la (pool dédié, QoS, classe OSD séparée, ou déplacez-la hors du NFS partagé).

Tâche 9 : Sanity check du montage NFS (les options comptent)

cr0x@server:~$ findmnt -t nfs4 -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET           SOURCE                  FSTYPE OPTIONS
/mnt/pve/nfs-vm  nas01:/export/proxmox   nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys

Sens : Vous voulez des montages hard pour les images VM (pour éviter la corruption silencieuse via des écritures courtes), et des rsize/wsize raisonnables. NFSv4.2 est généralement bon si le NAS le supporte.

Décision : Si vous voyez soft mounts, corrigez-le. « Soft » est pour des lectures non critiques, pas pour des disques VM.

Tâche 10 : Vérifier la latence du serveur NFS depuis le client

cr0x@server:~$ nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
1248933    120        0

Client nfs v4:
ops count  retrans
READ 402911  18
WRITE 311220 47
COMMIT 1021   0

Sens : Les retransmissions indiquent des problèmes réseau/serveur. Quelques unes arrivent ; une hausse corrèle avec des stalls et des gels de VM.

Décision : Si les retrans spikes pendant les incidents, arrêtez de tuner Proxmox et commencez à regarder la charge du NAS, erreurs NIC, buffers de switch, mismatch MTU.

Tâche 11 : Session iSCSI et état multipath

cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.10.50:3260,1 iqn.2020-01.com.vendor:san01.lun1 (non-flash)
tcp: [2] 10.10.11.50:3260,1 iqn.2020-01.com.vendor:san01.lun1 (non-flash)

cr0x@server:~$ multipath -ll
mpatha (3600a098038314c6a6b5d4a6f4b6a6f30) dm-3 VENDOR,Array
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:10 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:10 sdc 8:32 active ready running

Sens : Deux sessions iSCSI : probablement deux fabrics/VLANs. Multipath montre un chemin actif et un chemin activé. Si vous n’avez qu’un seul chemin, vous n’avez pas de redondance.

Décision : Si les chemins flappent ou qu’un est down, fixez le réseau avant de blâmer l’array ou Proxmox.

Tâche 12 : Santé du cluster Ceph en un coup d’œil

cr0x@server:~$ ceph -s
  cluster:
    id:     3c3b1e2d-aaaa-bbbb-cccc-111122223333
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 12 sec

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 4h)
    mgr: pve1(active), standbys: pve2
    osd: 12 osds: 12 up (since 3h), 12 in (since 3h)

  data:
    pools:   2 pools, 128 pgs
    objects: 1.02M objects, 3.9 TiB
    usage:   11 TiB used, 22 TiB / 33 TiB avail
    pgs:     127 active+clean, 1 active+clean+scrubbing

Sens : « slow ops » est un drapeau rouge pour la latence. Un scrub est en cours. Parfois le scrub coïncide avec des jitter visibles par l’utilisateur.

Décision : Si les slow ops persistent, vérifiez la latence des OSD et le réseau. Si le scrub cause des douleurs, ajustez les fenêtres et priorités de scrub plutôt que de désactiver les scrubs à jamais.

Tâche 13 : Latence OSD Ceph et compteurs perf

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    3                   4
1    4                   5
2    45                  52
3    3                   4

Sens : L’OSD 2 est malade comparé aux pairs. C’est souvent un mauvais disque, un périphérique saturé, ou un voisin bruyant sur ce nœud.

Décision : Vidangez/marquezz l’OSD comme out si nécessaire, ou investigatez l’hôte/disque spécifique. Ne « tunez Ceph » globalement pour compenser un périphérique défaillant.

Tâche 14 : Vérifier la pression des sauvegardes Proxmox (le stockage peut être ok mais les backups le tuent)

cr0x@server:~$ grep -E "vzdump|INFO:|ERROR:" /var/log/syslog | tail -n 8
Dec 28 01:10:02 pve1 vzdump[31120]: INFO: starting new backup job: vzdump 110 --storage nfs-backup --mode snapshot
Dec 28 01:10:05 pve1 vzdump[31120]: INFO: VM 110 - starting backup
Dec 28 01:10:09 pve1 vzdump[31120]: INFO: VM 110 - using inotify to track modifications
Dec 28 01:12:41 pve1 vzdump[31120]: INFO: VM 110 - backup finished

Sens : Les sauvegardes tournent pendant la fenêtre de douleur. Le mode snapshot est bien, mais il génère quand même des IO de lecture et du travail de métadonnées.

Décision : Si la latence stockage s’aligne sur les fenêtres de sauvegarde, modifiez les horaires, limitez la concurrence, ou déplacez les cibles de sauvegarde hors du même goulot.

Playbook de diagnostic rapide : quoi vérifier premièrement/deuxièmement/troisièmement

Ceci est l’ordre qui trouve des réponses rapidement. L’objectif n’est pas la perfection ; c’est d’arrêter les disputes et d’isoler la couche.

Premier : déterminer si c’est local à l’hôte, partagé ou réseau

• Vérifiez l’emplacement du disque VM : qm config <vmid>.
• Vérifiez la liste de storages : pvesm status.
• Si c’est Ceph/NFS/iSCSI, assumez que le réseau est impliqué jusqu’à preuve du contraire.

Deuxième : mesurer la latence là où elle compte

• Latence disque hôte : iostat -x 1.
• « slow ops » Ceph et ceph osd perf.
• Retrans NFS : nfsstat -c.
• État iSCSI : multipath -ll.

Troisième : vérifier les états dégradés/de récupération

• ZFS : zpool status pour resilver/scrub/erreurs checksum.
• Ceph : recovery/backfill/scrub dans ceph -s.
• NAS/array : est-il en rebuild, scrub, ou snapshotting ?

Quatrième : trouver la VM « brute » et la corrélation temporelle

• Compteurs IO par VM : pvesh get /nodes/<node>/qemu.
• Vérifiez les fenêtres de sauvegarde et jobs de snapshot.
• Cherchez un locataire qui sature les queues partagées.

Cinquième : valider les trucs ennuyeux

• Erreurs et drops NIC : ip -s link, compteurs de switch.
• Consistance MTU (surtout si vous avez essayé les jumbo frames).
• Steal CPU / temps ready et IO wait : la douleur du stockage peut se déguiser en contention CPU.

Erreurs courantes : symptômes → cause racine → réparation

1) VM se fige 30–120 secondes sur NFS

Symptômes : Les logs invités montrent des timeouts disque ; l’hôte affiche des messages « server not responding » ; puis tout récupère.

Cause racine : Hics du serveur NFS (charge, latence stockage ou perte réseau). Les montages hard font attendre les clients (ce qui est plus sûr que la corruption des données).

Réparation : Corrigez le goulot NAS ou le réseau. Validez les options findmnt. Envisagez de déplacer les VM sensibles à la latence vers des miroirs ZFS locaux ou Ceph RBD.

2) Le pool ZFS semble sain mais les VM sont lentes pendant les snapshots

Symptômes : Pics de latence durant les fenêtres de sauvegarde ; patterns IO deviennent aléatoires ; les misses ARC montent.

Cause racine : Les charges lourdes en snapshots augmentent les métadonnées et la fragmentation ; les sauvegardes peuvent induire des read storms.

Réparation : Réduisez le nombre/rétention des snapshots, étalez les sauvegardes, séparez les datasets chauds, et préférez raw/ZVOL pour les disques critiques en performance.

3) Ceph paraît rapide pendant des semaines, puis devient « collant »

Symptômes : HEALTH_WARN slow ops ; jitter IO VM ; tâches parfois bloquées.

Cause racine : Fonctionnement trop proche de la capacité ou un OSD qui se dégrade lentement. Backfill/recovery entre en compétition avec les IO clients.

Réparation : Maintenez de la marge, remplacez les disques défaillants tôt, et planifiez les scrubs sensiblement. Ne négligez pas un OSD qui traîne dans ceph osd perf.

4) iSCSI « marche » mais vous avez des erreurs aléatoires de filesystem dans les invités

Symptômes : Les invités montrent des erreurs ext4/xfs ; multipath montre des flaps ; dmesg contient des resets SCSI.

Cause racine : Chemin réseau instable, MTU erroné, mauvais câbles/optique, ou multipath/timeouts mal configurés.

Réparation : Stabilisez les liens, assurez des chemins redondants, alignez MTU bout en bout, et validez la santé multipath. Ne le masquez pas par des retries.

5) ZFS « sync=disabled » a rendu tout rapide… jusqu’à ce que l’alimentation flanche

Symptômes : Après crash, certaines VM bootent avec des filesystems corrompus ; des bases de données nécessitent réparation.

Cause racine : Désactiver sync a ack les écritures avant qu’elles ne soient sûres sur un média stable.

Réparation : Remettez sync sur standard, ajoutez un SLOG correctement protégé contre la perte d’alimentation si vous avez besoin de la latence sync, et utilisez un UPS correctement (ce n’est pas un substitut absolu).

6) Ceph sur 1 GbE « marche à peu près » mais les migrations sont brutales

Symptômes : Latence élevée aux pics ; IO client stallent ; recovery prend une éternité.

Cause racine : Le réseau est le backplane pour Ceph. 1 GbE est la taxe que vous payez à chaque écriture.

Réparation : Passez au moins à 10 GbE (souvent 25 GbE pour les déploiements sérieux), séparez le trafic stockage, et cessez de traiter le réseau comme optionnel.

Checklists / plan pas à pas

Si vous construisez un setup Proxmox 1–3 nœuds

1. Par défaut, choisissez des miroirs ZFS locaux pour les disques VM.
2. Utilisez un stockage séparé (souvent NFS) pour ISO/templates/sauvegardes.
3. Décidez à l’avance comment vous gérerez la perte d’un nœud :
   • Réplication ZFS entre nœuds pour les VM importantes, ou
   • Restauration depuis des sauvegardes avec RTO/RPO définis.
4. Dimensionnez la RAM en gardant ARC en tête ; ne sous-alimentez pas ZFS.
5. Gardez la rétention des snapshots raisonnable ; concevez les horaires de sauvegarde autour des IO.

Si vous construisez un cluster 4+ nœuds et voulez du stockage VM partagé

1. Choisissez Ceph RBD si vous pouvez fournir :
   • 3+ nœuds minimum (pour quorum et réplication),
   • Dispositifs de stockage rapides,
   • Un réseau de stockage sérieux.
2. Séparez les domaines de panne : hôte, disque, rack (si vous en avez).
3. Planifiez une marge de capacité : ne pas opérer proche du plein.
4. Opérationnalisez les checks santé : slow ops, perf OSD, fenêtres de scrub.
5. Testez les pannes : retirez un OSD, redémarrez un hôte, validez la récupération et l’impact sur la latence VM.

Si votre entreprise possède déjà un SAN/NAS

1. Utilisez iSCSI pour le stockage bloc VM si l’array est éprouvé et supporté.
2. Utilisez NFS pour fichiers partagés, templates et sauvegardes là où la sémantique fichier aide.
3. Implémentez multipath et switching redondant sérieusement.
4. Obtenez l’accès aux télémétries côté array ou vous dépannerez à l’aveugle.

Une matrice simple « que devrais-je choisir »

• ZFS : meilleur pour la performance locale et l’intégrité des données ; stockage partagé via réplication/sauvegardes.
• Ceph : meilleur pour le stockage partagé et la résilience à l’échelle de cluster ; exige réseau et maturité ops.
• iSCSI : meilleur quand vous avez déjà un vrai SAN ; fort rayon d’impact mais prévisible avec un bon array.
• NFS : meilleur pour la simplicité et les fichiers partagés ; acceptable pour disques VM avec un NAS solide et des workloads modérés.

Trois mini-récits d’entreprise depuis les tranchées du stockage

Incident causé par une mauvaise hypothèse : « NFS c’est juste un disque local plus lent »

Ils avaient un cluster Proxmox propre : trois nœuds compute et un appliance NAS que tout le monde aimait parce qu’il avait une UI sympa et des voyants qui clignotent. Les disques VM vivaient sur NFS parce que la migration était facile et l’équipe stockage disait « c’est redondant ».

L’hypothèse était que NFS se comporte comme un disque local plus lent. Traduction : si le NAS est occupé, les VM ralentissent. Le comportement réel est plus dur : si le NAS pause assez longtemps, les clients se bloquent sévèrement. Ce n’est pas un bug ; c’est la façon dont les montages « hard » préservent la cohérence.

Un après-midi, un scrub NAS programmé a coïncidé avec un job de sauvegarde Proxmox. Le NAS n’a pas crashé. Il a juste mis plus de temps à répondre. Les kernels invités ont commencé à logger des timeouts IO. Les bases ont fait ce que font les bases quand elles ont peur : elles ont cessé de se faire confiance.

Le postmortem fut gênant car le graphe que tout le monde regardait montrait le débit. Le débit semblait correct. La latence était le tueur, et personne ne graphait les retrans NFS ou la profondeur de file des disques NAS.

La correction fut ennuyeuse : déplacer les VM sensibles à la latence vers des miroirs ZFS locaux, garder NFS pour sauvegardes/templates, et ajouter du monitoring montrant la latence tail et les retransmissions. La migration est devenue un peu moins magique. Les incidents, beaucoup moins fréquents.

Optimisation qui a mal tourné : « Désactivons sync ; c’est plus rapide »

Un autre shop avait ZFS sur des miroirs SSD et quelques VM avec une charge transactionnelle. Ils voyaient des pics périodiques de latence write et quelqu’un a proposé la classique : mettre sync=disabled sur le dataset. La perf s’est améliorée instantanément. Applaudissements. Un ticket a été clos.

Deux mois plus tard, un bref incident électrique est survenu. Pas une panne dramatique — plus du style « les lumières clignotent et on se rappelle que le bâtiment est plus vieux que votre pipeline CI ». Les hôtes ont rebooté. La plupart des VM sont revenues. Quelques-unes non. Une base est revenue, mais la couche applicative a commencé à lancer des incohérences de données subtiles.

Maintenant l’« optimisation performance » était un problème d’incident avec le service juridique qui regardait par-dessus l’épaule. L’équipe a appris la vérité dure : quand vous désactivez sync, vous échangez durabilité contre vitesse. Parfois ce compromis est acceptable en labo. En production, soyez explicite, documentez, et obtenez l’accord de ceux qui seront blâmés plus tard.

La réparation finale n’a pas été exotique. Ils sont revenus à un comportement sync sûr et ont ajouté un vrai SLOG avec protection contre la perte d’alimentation pour les workloads qui avaient besoin de faibles latences d’écritures sync. Ils ont aussi amélioré leurs tests UPS et cessé de croire que « il y a des batteries » était une spécification de conception.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « marge et répétitions de panne »

Une entreprise opérant un cluster Proxmox + Ceph avait une règle que tout le monde trouvait pénible : garder de l’espace libre au-dessus d’un seuil et ne jamais laisser le cluster se rapprocher du plein. C’était impopulaire parce que ça ressemblait à un budget gaspillé. Finance adore un disque plein ; les ingénieurs aiment un pager silencieux.

Ils faisaient aussi un exercice trimestriel de simulation de panne. Pas du chaos théâtral — juste retirer un OSD, redémarrer un nœud, et observer. Ils chronométraient le temps de récupération et l’effet sur la latence VM. Ce n’était pas fun. C’était du travail.

Puis un hôte est mort un lundi matin. Une vraie mort : carte mère, pas un reboot. Ceph a rééquilibré, les clients ont continué, et le cluster est resté utilisable. La latence a bondi, mais elle n’a pas explosé car il y avait de l’espace pour backfill et le réseau n’était pas déjà saturé.

La récupération a paru anticlimatique. C’est le plus grand compliment que l’on puisse faire au stockage.

Ce qui les a sauvés n’était pas un drapeau Ceph secret. C’était de la marge, du monitoring, et le fait d’avoir déjà regardé le système mal se comporter en condition contrôlée.

FAQ

1) Dois-je utiliser ZFS ou Ceph pour un cluster Proxmox à deux nœuds ?

Utilisez ZFS local avec réplication ou sauvegarde. Ceph à deux nœuds est possible de façons étranges, mais rarement worth le risque opérationnel et les compromis de performance.

2) RAIDZ est-il mauvais pour Proxmox ?

Pas « mauvais », mais souvent l’outil inadapté pour la latence VM. Les mirrors fournissent généralement de meilleures IOPS et une latence tail plus basse pour les écritures aléatoires typiques des VM mixtes.

3) ZFS sur SSD : ai-je besoin d’un SLOG ?

Seulement si vous avez un volume significatif d’écritures sync et que vous vous souciez de leur latence. Si vous ajoutez un SLOG, faites-le enterprise-grade avec protection power-loss, sinon vous avez construit un piège de fiabilité.

4) Pour Ceph sur Proxmox, dois-je utiliser RBD ou CephFS pour les disques VM ?

RBD pour la plupart des disques VM. CephFS est excellent pour des systèmes de fichiers partagés, mais les workloads disques VM correspondent typiquement mieux à des sémantiques bloc.

5) Puis-je exécuter Ceph et des VM sur les mêmes nœuds Proxmox ?

Oui, et beaucoup le font. Mais dimensionnez CPU/RAM en conséquence et souvenez-vous : quand la charge VM spike, les démons Ceph se font concurrence pour les ressources. Si vous voulez un stockage prévisible, envisagez des nœuds dédiés au stockage à plus grande échelle.

6) NFS est-il acceptable pour des disques VM ?

Oui, si le NAS est puissant et que votre charge n’est pas ultra sensible à la latence. C’est courant pour les petits clusters. Surveillez la latence et les retransmissions, et n’utilisez pas de montages « soft ».

7) iSCSI vs NFS pour Proxmox : lequel est plus rapide ?

Cela dépend plus du serveur/array et du réseau que du protocole. iSCSI peut offrir un comportement bloc prévisible ; NFS peut être plus simple opérationnellement. Choisissez selon les modes de défaillance et la gestion, pas selon une capture d’écran de benchmark.

8) Les disques VM doivent-ils être qcow2 ou raw ?

Raw est généralement plus rapide et plus simple. qcow2 apporte des fonctionnalités (snapshots internes) mais ajoute de l’overhead. Sur Proxmox, préférez raw/ZVOL pour les disques chauds sauf si vous avez besoin des fonctionnalités de qcow2.

9) Quelle est la façon la plus rapide de dire si Ceph est le problème ou si c’est la VM ?

Vérifiez ceph -s pour slow ops et ceph osd perf pour des outliers, puis corrélez avec iostat de l’hôte et les symptômes de latence disque des VM. Si Ceph montre des slow ops, ce n’est pas « juste la VM ».

10) Puis-je mélanger HDD et SSD dans Ceph ?

Vous pouvez, mais faites-le délibérément (classes de device séparées, pools séparés). Les mélanger à l’aveugle signifie généralement que les disques rapides passent leur vie à attendre les lents.

Conclusion : étapes pratiques suivantes

Choisissez un backend de stockage en fonction de l’aspect des pannes que vous voulez voir, pas en fonction de l’apparence de vos dashboards.

• Si vous êtes petit (1–3 nœuds), construisez des miroirs ZFS locaux pour les disques VM, gardez NFS pour sauvegardes et artefacts partagés, et implémentez la réplication/sauvegarde avec une restauration testée.
• Si vous êtes un vrai cluster (4+ nœuds) et pouvez financer le réseau et les disques, utilisez Ceph RBD et traitez-le comme le système distribué qu’il est : surveillez, laissez de la marge, répétez les pannes.
• Si vous possédez déjà un array sérieux, iSCSI est une réponse d’entreprise sensée — faites juste du multipath correctement et acceptez la dépendance centralisée.
• Si vous voulez du stockage partagé sans plateforme distribuée, NFS reste la solution la plus simple qui fonctionne, et la simplicité est une caractéristique de performance à 3 h du matin.

Votre prochaine action devrait être spécifique : exécutez les tâches de diagnostic ci-dessus lors d’un jour normal, capturez une baseline de latence, et écrivez ce que signifie « sain ». L’incident arrivera plus tard. Ça arrive toujours. Au moins faites-le arriver à des adultes préparés.