Stockage Proxmox : Ceph vs ZFS — L’arbre de décision que personne ne vous montre

février 6, 2026 • février 6, 2026 • Lecture : 32 min • Views: 0

Cet article vous a aidé ?

Vous ne sentez pas les décisions de stockage le premier jour. Vous les sentez la première fois qu’un nœud meurt à 2h13, que le PDG est dans un avion avec une connexion Wi‑Fi aléatoire, et que votre histoire « HA » devient « nous enquêtons ». C’est là que vous découvrez si vous avez acheté de la résilience ou simplement un nouveau passe‑temps.

Dans Proxmox, la question Ceph vs ZFS ressemble à une comparaison de fonctionnalités. En production, c’est une décision basée sur les modes de défaillance. Cet article est l’arbre de décision que j’aurais voulu que plus d’équipes aient avant de construire quelque chose de mauvais en toute confiance.

L’arbre de décision (utilisez ceci, pas les impressions)

Voici la version sans fard. Si vous n’êtes pas d’accord, très bien — lancez les tests plus loin dans cet article et laissez vos graphiques trancher le débat.

Étape 1 : Avez‑vous besoin d’un stockage partagé pour la migration à chaud et le HA entre nœuds ?

Si oui, et que vous le voulez intégré : choisissez Ceph (RBD). C’est l’idée principale : un stockage bloc distribué qui survit à la perte d’un nœud et continue de servir.
Si non (ou si vous pouvez accepter « migration avec interruption » ou des approches basées sur la réplication) : ZFS sur chaque nœud est généralement le meilleur compromis fiabilité/effort que vous puissiez acheter.

Étape 2 : Combien de nœuds avez‑vous, en réalité ?

1 nœud : ZFS. Ceph n’est pas un produit mono‑nœud à moins que vous fassiez du labo ou que vous aimiez la complexité auto‑infligée.
2 nœuds : ZFS, avec un troisième vote (qdevice) pour le quorum du cluster. Ceph sur 2 nœuds est un piège ; vous inventerez de nouvelles formes de tristesse.
3 nœuds : Ceph devient viable. ZFS reste plus simple. Votre besoin de stockage partagé et de tolérance aux pannes décide.
4–8 nœuds : Ceph brille si vous avez besoin de stockage partagé et si vous pouvez payer le réseau et les disques pour le faire correctement.
9+ nœuds : Ceph est souvent le choix par défaut pour le stockage partagé, mais seulement si vous le traitez comme un système de stockage, pas une case à cocher.

Étape 3 : Quel est votre budget de défaillance ?

« Un hôte peut mourir et personne ne doit le remarquer » : Ceph avec réplication (size 3) et des domaines de défaillance sensés.
« Un hôte peut mourir et nous pouvons basculer en quelques minutes, peut‑être restaurer quelques VM » : ZFS avec réplication (zfs send/receive), sauvegardes et RTO réaliste.
« Nous avons juste besoin de bons disques locaux, on restaurera depuis la sauvegarde » : ZFS, miroirs et un plan de sauvegarde qui restaure réellement.

Étape 4 : Quel réseau avez‑vous pour le trafic de stockage ?

10GbE avec commutation partagée et sans isolation : ZFS tend à gagner sauf si votre cluster Ceph est petit et peu sollicité. Ceph peut tourner sur 10GbE, mais les performances et la récupération vont se battre contre vous.
25GbE+ réseau de stockage dédié (ou au moins VLAN/QoS bien séparés) : Ceph devient beaucoup plus prévisible, surtout pendant backfill/rebalance.

Étape 5 : Quel type d’E/S font réellement vos VM ?

Écritures aléatoires sensibles à la latence (bases de données, queues) : les miroirs ZFS semblent souvent plus rapides. Ceph peut gérer, mais il faut l’ingénier : OSDs NVMe, bon réseau et recovery réglé.
Principalement des lectures, écritures modérées, beaucoup de VM : Ceph est un bon choix si vous voulez du stockage partagé et acceptez l’amplification d’écriture de la réplication/EC.
Gros workloads séquentiels : les deux peuvent le faire ; choisissez selon votre modèle opérationnel et le comportement en cas de panne.

Étape 6 : Qui va l’exploiter à 2 h du matin ?

Petite équipe, faible tolérance pour l’on‑call spécifique au stockage : ZFS. Moins de pièces mobiles, moins de comportements émergents à l’échelle du cluster.
Équipe prête à investir dans la maturité opérationnelle : Ceph peut devenir ennuyeux — dans le bon sens — une fois que vous êtes discipliné.

Règle d’opinion : si vous choisissez Ceph pour éviter d’acheter un SAN partagé, vous devez quand même payer l’équivalent en réseau, disques et effort opérationnel. Ceph n’est pas du « stockage partagé pas cher ». C’est du « stockage partagé que vous possédez ».

Ce que vous achetez vraiment : sémantique et modes de défaillance

ZFS dans Proxmox : vérité locale, forte intégrité

ZFS est un système de fichiers et un gestionnaire de volumes avec checksumming de bout en bout, copy‑on‑write, snapshots, réplication et un modèle de cache qui peut rendre vos VM réactives. Dans Proxmox, ZFS est typiquement utilisé comme stockage local par nœud : pools pour les disques VM (zvols) et datasets pour les sauvegardes ou les templates.

Ce que vous obtenez : des performances prévisibles, une excellente intégrité des données et une simplicité opérationnelle. Si un nœud meurt, le stockage meurt avec lui — sauf si vous avez répliqué ailleurs.

Ce que vous n’obtenez pas : du bloc partagé prêt à l’emploi. Vous pouvez construire des sémantiques partagées via la réplication plus de l’orchestration, mais ce n’est pas la même chose que « n’importe quel nœud peut exécuter n’importe quelle VM maintenant avec son disque attaché ».

Ceph dans Proxmox : stockage bloc distribué, partagé par conception

Ceph vous fournit un cluster de stockage : les OSD stockent les données, les MONs gardent l’état du cluster, et les clients (vos nœuds Proxmox) parlent au cluster via le réseau. Avec RBD, vous obtenez des blocs partagés que Proxmox peut utiliser pour les disques VM. Si un nœud ou un disque meurt, le cluster répare en répliquant les données.

Ce que vous obtenez : stockage partagé, réplication auto‑réparatrice, conscience des domaines de défaillance et la capacité de perdre un nœud sans perdre l’accès aux disques VM.

Ce que vous n’obtenez pas : la simplicité. Vous opérez un système distribué. Les systèmes distribués sont formidables, jusqu’à ce que vous réalisiez que le réseau fait maintenant partie de votre contrôleur RAID.

Vérité sèche : ZFS a tendance à échouer « localement et bruyamment ». Ceph a tendance à échouer « globalement et subtilement » s’il est mal configuré, parce que la santé du cluster et les comportements de recovery peuvent dégrader tout en même temps.

Idée paraphrasée (attribuée) : Werner Vogels (CTO d’Amazon) a longtemps encouragé l’idée que « tout échoue, donc vous concevez pour la défaillance ». Les choix de stockage sont l’endroit où vous le prenez au sérieux ou non.

Faits intéressants et contexte historique (pour arrêter de répéter les erreurs de 2012)

Ceph a commencé comme projet de recherche (thèse de Sage Weil), et son design initial misait fortement sur le matériel grand public et la fiabilité pilotée par le logiciel.
CRUSH (l’algorithme de placement de Ceph) est conçu pour éviter les goulots d’étranglement centraux de métadonnées en calculant le placement des objets plutôt qu’en le recherchant.
RBD (RADOS Block Device) est devenu le « disque VM » de référence parce que la sémantique du stockage bloc se mappe bien aux hyperviseurs et formats d’images.
ZFS est né chez Sun avec un modèle de « pool de stockage » qui traitait les disques comme une ressource gérée, pas comme un ensemble fixe de partitions avec une prière.
ZFS a popularisé le checksumming de bout en bout dans la conscience admin grand public : la corruption silencieuse cesse d’être un mythe quand ZFS vous montre les preuves.
Les premiers clusters Ceph avaient la réputation d’être complexes opérationnellement parce que le tuning de recovery, le compte des PGs et la variance matérielle pouvaient rendre le comportement imprévisible. Beaucoup s’est amélioré, mais la physique n’a pas changé.
L’erasure coding est devenu important pour Ceph parce que la réplication (3x) est chère ; l’EC réduit l’overhead mais augmente la complexité et le coût en écriture.
Proxmox a adopté tôt à la fois Ceph et ZFS parce que les petites et moyennes structures avaient besoin de vraies options de stockage sans acheter tout un écosystème SAN.

Blague #1 : RAID signifie « Redundant Array of Inexpensive Disks », et puis vous achetez des switches 25GbE et ça devient « Remarkably All‑Incostly Decision ».

Matériel et topologie : la partie que tout le monde sous‑budgete

Matériel Ceph : les minimums ne sont pas la même chose que « ça marche bien »

Ceph veut des disques cohérents, une latence cohérente et suffisamment de bande passante réseau pour survivre aux événements de recovery. Il tournera sur toutes sortes de matériel. Il vous punira aussi pour les choix créatifs.

Choix d’agencement des disques

HDD OSDs : bon pour la capacité, mauvais pour la latence d’écriture aléatoire. OK pour des workloads VM de type archivage, pas pour des bases actives sauf si vous acceptez une latence plus élevée.
SSD/SATA OSDs : compromis utilisable, mais attention à l’endurance et aux performances d’écriture soutenues.
NVMe OSDs : l’expérience « Ceph qui ressemble à du stockage local » est généralement NVMe plus bon réseau.

Le coût de Ceph est souvent dominé par l’amplification d’écriture : la réplication (size 3) écrit plusieurs copies ; l’EC répartit données et parité ; les petites écritures aléatoires coûtent cher. Ne « budgétez » pas Ceph par TB brut. Budgétez‑le en TB utilisable à la latence dont vous avez besoin pendant la récupération.

Réseau

Ceph est un système de stockage en réseau. Cela signifie que votre bus de stockage est l’Ethernet. Le sous‑dimensionner, et vous obtenez l’équivalent stockage d’essayer de boire un milkshake avec un agitateur à café.

10GbE : peut fonctionner pour de petits clusters, mais la récupération vous mangera. Vous avez besoin de séparation du trafic client ou d’un shaping extrêmement soigné.
25GbE : le baseline sensé pour « on se soucie des performances et du temps de récupération ».
Réseaux doubles : toujours utiles (public/client vs cluster/backfill), mais de nombreux déploiements réussissent avec un seul réseau bien conçu si vous êtes discipliné.

Matériel ZFS : l’ennuyeux est une fonctionnalité

ZFS vous récompense pour faire les choses basiques : mémoire ECC (de préférence), vdevs en miroir pour le stockage VM, et garder les pools confortablement loin d’être pleins. ZFS peut faire RAIDZ pour la capacité, mais les workloads VM ne sont pas « un gros fichier séquentiel ». Ce sont un tas de petites écritures aléatoires déguisées.

Miroir vs RAIDZ pour les workloads VM Proxmox

Miroirs : latence plus faible, IOPS plus élevés, comportement de rebuild plus simple. Excellent par défaut pour les pools VM.
RAIDZ2/3 : meilleure efficacité de capacité, mais pénalité sur les écritures aléatoires et temps de resilver potentiellement douloureux. Mieux pour le stockage en masse, les sauvegardes et les workloads moins sensibles à la latence.

SLOG et L2ARC : cessez d’acheter des pièces magiques d’abord

La plupart des équipes n’ont pas besoin d’un dispositif SLOG séparé. Si votre workload est majoritairement en écritures asynchrones (commun pour beaucoup de workloads VM), le SLOG n’aidera pas beaucoup. Si vous exécutez des bases de données sync‑intensives et que vous vous souciez de la latence, alors oui, un SLOG haut de gamme avec protection contre la perte de puissance peut compter.

L2ARC peut aider les lectures, mais il consomme aussi de la RAM pour les métadonnées et peut créer un faux sentiment de sécurité. Commencez par assez de RAM et une mise en pool sensée. Ajoutez L2ARC quand vous pouvez prouver un problème de cache miss.

Réalité des performances : latence, IOPS, rebuilds et la taxe du « voisin bruyant »

Ceph : état stable vs état de défaillance

À l’état stable, Ceph peut fournir un excellent débit et une bonne latence — surtout sur NVMe et réseaux rapides. À l’état de défaillance (OSD down, reboot d’un nœud, pépin réseau), Ceph commence à faire ce pour quoi il est conçu : répliquer, backfiller, rééquilibrer. Ce travail de recovery concurrence les IO clients.

Votre travail est d’empêcher la récupération de se transformer en panne partielle du cluster. Cela signifie :

Prévoir de la marge réseau et disque adaptée.
Paramètres raisonnables de recovery/backfill (pas « illimité, YOLO »).
Domaines de défaillance qui correspondent à la réalité (hôte, châssis, rack).

ZFS : l’ARC vous fait paraître intelligent (jusqu’à ce que non)

Les performances ZFS sont souvent perçues comme « rapides » parce que l’ARC (cache en mémoire) masque la latence de lecture. C’est une vraie valeur. Mais ça peut aussi masquer que votre pool est sous‑dimensionné pour les écritures, ou que vous êtes sur le point d’atteindre la fragmentation et d’être détruit par des écritures sync.

Autre réalité ZFS : une fois que vous dépassez ~80% d’utilisation du pool, les performances se dégradent souvent. On débattra du chiffre exact ; vos graphiques trancheront. Gardez des pools VM avec de la marge. Vous ne stockez pas des photos de famille. Vous stockez les délais des autres.

« Voisin bruyant » en pratique

Avec des pools ZFS locaux, une VM bruyante tend à affecter ce nœud. Avec Ceph, une VM bruyante peut amplifier la douleur à l’échelle du cluster si elle génère beaucoup d’écritures entraînant un trafic de réplication conséquent et des délais de récupération. C’est pourquoi la QoS et des limites de disque VM sensées comptent davantage dans l’univers Ceph.

Charge opérationnelle : qui est de garde pour quoi

Opérations ZFS : moins de pièces mobiles, mais vous devez faire réplication/sauvegardes

La charge opérationnelle de ZFS consiste surtout à :

Surveiller la santé des pools (scrubs, SMART, compteurs d’erreurs).
Gérer les snapshots et la rétention (ne pas snapshotter éternellement ; ce n’est pas un plan, c’est de la procrastination).
Réplication si vous voulez une résilience au‑delà d’un seul hôte.
Gestion de la capacité : ajouter des vdevs, ne pas se peindre dans un coin d’expansion RAIDZ.

Opérations Ceph : un cluster de stockage est un être vivant

Ceph requiert de l’aisance avec :

La santé du cluster : placement groups, backfill, objets dégradés.
Le dépannage réseau comme compétence de stockage, pas comme le hobby d’une autre équipe.
La gestion des changements : ajouter des OSD change le placement des données et déclenche un rééquilibrage.
La compréhension des comportements de recovery : compromis vitesse vs impact.

Blague #2 : Ceph, c’est comme avoir une pieuvre de compagnie — brillante, puissante, et si vous l’ignorez un week‑end elle redécore la maison.

Trois mini‑histoires d’entreprise (toutes assez réelles pour faire mal)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une société SaaS de taille moyenne est passée de ZFS local à Ceph parce qu’elle voulait des migrations à chaud transparentes. L’ingénieur stockage (bonnes intentions, temps limité) a supposé que le réseau 10GbE existant serait « suffisant » parce que les benchmarks en état stable semblaient acceptables. Ils ont construit un cluster Ceph à 4 nœuds, réplication size 3, mixé des OSDs SSD SATA et quelques vieux disques « temporairement », et sont passés en production.

Deux mois plus tard, un OSD a commencé à flapper — up/down toutes les quelques minutes — à cause d’un disque marginal et d’un HBA qui n’aimait pas son câblage. Ceph a fait ce que Ceph fait : le backfill a démarré, puis pause, puis reprise, puis récidive. La latence IO client a grimpé. Les disques VM ont commencé à timeouter. Les hyperviseurs semblaient « sains », mais le stockage thrashait essentiellement.

La mauvaise hypothèse était subtile : ils ont supposé que le trafic de recovery était une tâche de fond. Ce n’est pas le cas. Dans Ceph, la recovery est une charge de travail de première classe. Sur 10GbE, recovery + IO client peut saturer les mêmes liens, causant des pics de latence qui ressemblent à des « problèmes applicatifs aléatoires ».

La solution n’a pas été glamour. Ils ont isolé le trafic stockage, mis à niveau les interconnexions et fixé des limites de recovery conservatrices pendant les heures ouvrables. Ils ont aussi standardisé les classes de média OSD et arrêté de mélanger des disques « temporaires » aux profils de latence différents.

La leçon : si vous ne pouvez pas vous permettre la marge réseau pour les événements de recovery, vous ne pouvez pas vous permettre Ceph. Vous empruntez juste de la fiabilité au futur à des intérêts terribles.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une autre organisation faisait tourner Proxmox avec des miroirs ZFS. À court de capacité, ils ont « optimisé » en passant de nouveaux pools en RAIDZ2. Le calcul était séduisant. Les tableaux de bord paraissaient plus verts. La finance était ravie.

Puis le workload VM a changé. Une équipe produit a ajouté un pipeline d’analytics très écritif, beaucoup de petites écritures aléatoires, et quelques bases configurées pour des fsync agressifs. La latence est passée de « correcte » à « mon appli est hantée ». ZFS a passé beaucoup de temps à faire des calculs de parité et à gérer des patterns d’écriture aléatoires que RAIDZ n’apprécie pas. Les scrubs et les resilvers se sont allongés. Les performances sous charge sont devenues en dents de scie.

Ils ont essayé de colmater avec des SSD plus rapides en L2ARC, qui ont surtout aidé les lectures et n’ont rien fait pour la douleur de latence en écriture. Puis ils ont acheté un SLOG sans vérifier que leur workload était réellement lié aux sync writes. Ce n’était pas le cas, du moins pas de la manière qu’ils pensaient. Le SLOG a amélioré quelques métriques mais n’a pas réglé le problème visible par les utilisateurs.

Finalement, ils ont migré le stockage des VM les plus chargées vers des vdevs en miroir et ont gardé RAIDZ2 pour les datasets en masse et les sauvegardes. Le gain de capacité était réel, mais c’était le mauvais niveau pour ce workload.

La leçon : l’optimisation sans modèle de workload n’est que roulette de performance. Parfois vous gagnez. Les opérations se souviennent quand vous perdez.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise liée aux soins de santé utilisait Proxmox avec Ceph pour des disques VM partagés. Rien de fancy : OSD NVMe cohérents, VLAN de stockage dédié, et une fenêtre de changement stricte. La partie peu sexy était leur routine hebdomadaire : vérifier la santé Ceph, confirmer les scrubs, contrôler les compteurs SMART, et tester la restauration d’au moins une VM depuis les backups.

Un jeudi, un switch top‑of‑rack a commencé à perdre des paquets sous charge. Pas une panne totale. Juste assez pour provoquer des pics de latence intermittents. Les applications ont commencé à se plaindre. Les hyperviseurs semblaient corrects. Les graphiques de stockage montraient une hausse des retransmissions et une baisse du débit client.

Parce qu’ils avaient des baselines ennuyeuses, ils ont rapidement vu ce qui avait changé : les erreurs réseau ont augmenté et Ceph a commencé à afficher des slow ops. Ils ont limité la recovery, déplacé un peu de trafic et coordonné avec le réseau pour remplacer le matériel. Le cluster est resté disponible.

Le vrai secours est venu plus tard. Pendant l’événement réseau, un OSD a été marqué out et a commencé à backfiller. Ils l’ont remarqué immédiatement grâce aux contrôles de santé de routine, ont confirmé que les données se rééquilibraient en sécurité, et ont empêché qu’une seconde défaillance ne devienne un risque de perte de données en mettant en pause les tâches de maintenance non essentielles.

La leçon : les pratiques ennuyeuses — baselines, contrôles de santé réguliers et tests de restauration — transforment une « panne mystérieuse » en « incident contrôlé ». Ce n’est pas glamour. C’est ainsi que vous gardez vos week‑ends.

Tâches pratiques avec commandes : quoi lancer, ce que ça signifie, quelle décision en tirer

Ci‑dessous des tâches pratiques à exécuter sur des nœuds Proxmox. Chacune inclut : une commande, une sortie d’exemple réaliste, ce que ça signifie, et la décision qu’elle entraîne. Exécutez‑les. Ne les débattez pas dans Slack.

Task 1: Confirm what storage types Proxmox thinks you have

cr0x@server:~$ pvesm status
Name             Type     Status  Total     Used     Available  %
local            dir      active  196.00G   21.30G    164.70G  10%
local-zfs        zfspool  active  1.75T     612.00G   1.14T    35%
ceph-rbd         rbd      active  10.00T    6.20T     3.80T    62%

Signification de la sortie : Vous avez à la fois ZFS local et Ceph RBD configurés, et Ceph est à 62% d’utilisation.

Décision : Si Ceph est votre magasin principal de disques VM, 62% n’est pas « plein », mais c’est assez avancé pour que la récupération/rééquilibrage coûte plus cher. Planifiez la capacité avant 75–80%.

Task 2: Check ZFS pool health and spot silent trouble early

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

Signification de la sortie : Aucun erreur connue, pas de vdev dégradé.

Décision : Si ce n’est pas « all pools are healthy », arrêtez de débattre Ceph vs ZFS et corrigez d’abord votre pool actuel. L’hygiène du stockage précède les débats architecturaux.

Task 3: Inspect ZFS layout (mirror vs RAIDZ tells you performance expectations)

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

        NAME                         STATE     READ WRITE CKSUM
        rpool                        ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_1        ONLINE       0     0     0
            ata-SAMSUNG_SSD_2        ONLINE       0     0     0
          mirror-1                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_3        ONLINE       0     0     0
            ata-SAMSUNG_SSD_4        ONLINE       0     0     0

Signification de la sortie : Deux vdevs en miroir (mirrors striés). Idéal pour les IOPS VM et le comportement de rebuild.

Décision : Si vous êtes en RAIDZ pour les disques VM et que vous êtes sensible à la latence, c’est le moment de considérer la migration des workloads chauds vers des mirrors.

Task 4: Check ZFS compression and volblocksize (quiet performance killers)

cr0x@server:~$ zfs get -o name,property,value -s local compression,volblocksize local-zfs/vmdata
NAME               PROPERTY      VALUE
local-zfs/vmdata   compression   lz4
local-zfs/vmdata   volblocksize  8K

Signification de la sortie : Compression LZ4 activée (généralement bon), volblocksize 8K (commun pour les disques VM).

Décision : Si la compression est désactivée, activez‑la sauf raison spécifique. Si volblocksize est énorme pour des workloads random write, attendez-vous à de l’amplification d’écriture.

Task 5: Check ARC size pressure (ZFS performance often equals RAM reality)

cr0x@server:~$ arcstat 1 1
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:11   892    73      8    39   53    34   47     0    0   48G   56G

Signification de la sortie : ARC est à 48G, target 56G, taux de miss 8%. Pas terrible.

Décision : Si miss% est constamment élevé et que vos disques sont occupés, envisagez plus de RAM avant d’acheter des SSD cache. La RAM est le meilleur upgrade performance en ZFS.

Task 6: Confirm whether sync writes are a bottleneck (SLOG decisions live here)

cr0x@server:~$ zfs get -o name,property,value sync local-zfs/vmdata
NAME               PROPERTY  VALUE
local-zfs/vmdata   sync      standard

Signification de la sortie : Comportement sync par défaut. Les applis demandant sync l’obtiendront ; les autres non.

Décision : Ne mettez pas sync=disabled pour « régler la perf » des disques VM. Si vous le faites, renommez votre cluster « maybe-later » et mettez votre CV à jour.

Task 7: Check Ceph cluster health at a glance

cr0x@server:~$ ceph -s
  cluster:
    id:     8e0c2d8f-7e2b-4c2a-9d1b-2c9e5d2e3a1a
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 38 sec
            1 osds down
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3
    mgr: pve1(active), standbys: pve2
    osd: 12 osds: 11 up, 12 in
  data:
    pools:   4 pools, 256 pgs
    objects: 1.20M objects, 4.6 TiB
    usage:   13 TiB used, 24 TiB / 37 TiB avail
    pgs:     240 active+clean
             16  active+degraded

Signification de la sortie : Un OSD est down mais toujours « in », et vous avez des slow ops et des PGs dégradés.

Décision : Traitez HEALTH_WARN avec slow ops comme un incident de production s’il persiste. Trouvez l’OSD down et la raison avant de rebooter autre chose.

Task 8: Identify the down or flapping OSD quickly

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         37.260   root default
-3         12.420       host pve1
 0    ssd   3.105            osd.0     up   1.00000  1.00000
 1    ssd   3.105            osd.1   down   1.00000  1.00000
 2    ssd   3.105            osd.2     up   1.00000  1.00000
 3    ssd   3.105            osd.3     up   1.00000  1.00000
-5         12.420       host pve2
 4    ssd   3.105            osd.4     up   1.00000  1.00000
 5    ssd   3.105            osd.5     up   1.00000  1.00000
 6    ssd   3.105            osd.6     up   1.00000  1.00000
 7    ssd   3.105            osd.7     up   1.00000  1.00000
-7         12.420       host pve3
 8    ssd   3.105            osd.8     up   1.00000  1.00000
 9    ssd   3.105            osd.9     up   1.00000  1.00000
10    ssd   3.105            osd.10    up   1.00000  1.00000
11    ssd   3.105            osd.11    up   1.00000  1.00000

Signification de la sortie : osd.1 est down sur l’hôte pve1.

Décision : Décidez si c’est un problème de démon transitoire (restart) ou un problème de périphérique (SMART, logs kernel). Si matériel, marquez‑le out et remplacez correctement.

Task 9: Check if Ceph is backfilling/recovering (performance impact predictor)

cr0x@server:~$ ceph -w
2026-02-04T12:03:10.123+0000 mon.pve1 [WRN] Health check update: 1 osds down (OSD_DOWN)
2026-02-04T12:03:12.456+0000 osd.3 [INF] 1.2% backfill_recovery 120/10000 objects recovered
2026-02-04T12:03:13.222+0000 mgr.pve1 [WRN] Slow OSD heartbeats on back (osd.6)

Signification de la sortie : Recovery/backfill actif, plus avertissements de heartbeat lent (réseau ou OSD surchargé).

Décision : Si la latence client est impactée, envisagez de limiter temporairement la recovery pour maintenir les services, puis l’accélérer hors heures ouvrables.

Task 10: Confirm Ceph pool replication settings (you can’t guess durability)

cr0x@server:~$ ceph osd pool ls detail
pool 1 'rbd' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 128 pgp_num 128 autoscale_mode on
pool 2 'cephfs_data' erasure profile ec-4-2 crush_rule 3 pg_num 64 pgp_num 64 autoscale_mode on

Signification de la sortie : Votre pool de disques VM (rbd) est en réplication size 3, min_size 2.

Décision : Si vous êtes en size 2 pour « l’espace », comprenez que vous sacrifiez la tolérance aux pannes. Size 2 transforme souvent une seconde défaillance en indisponibilité ou risque de données.

Task 11: Check Ceph OSD latency and utilization (who is the slow kid in group projects)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    5                   7
1    0                   0
2    6                   8
3    52                  75
4    6                   9
5    5                   7
6    7                   10

Signification de la sortie : osd.3 est dramatiquement plus lent que ses pairs.

Décision : Inspectez le matériel de l’hôte osd.3, la santé du disque et le réseau. Un OSD lent peut provoquer de la latence cluster‑wide via des slow ops.

Task 12: Validate the storage network (packet loss turns into “Ceph is slow”)

cr0x@server:~$ ip -s link show eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9823456789  8123456  0       0        0       12345
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  7123456  0       0        0       0

Signification de la sortie : Pas d’erreurs RX/TX ni de drops sur cette interface.

Décision : Si vous voyez des erreurs/paquets dropés, corrigez le réseau avant de tuner Ceph. Le trafic stockage déteste le « ça marche à moitié ».

Task 13: Verify disk health signals (ZFS and Ceph both die from boring disks)

cr0x@server:~$ smartctl -a /dev/nvme0n1 | egrep -i "critical_warning|media_errors|num_err_log_entries|percentage_used"
critical_warning                    : 0x00
percentage_used                     : 7%
media_errors                        : 0
num_err_log_entries                 : 0

Signification de la sortie : NVMe semble sain ; faible usure, pas d’erreurs médias.

Décision : Si media_errors augmente ou critical_warning est activé, ne faites plus confiance au périphérique. Planifiez le remplacement avant qu’il ne décide pour vous.

Task 14: Measure IO latency on the node (prove whether it’s disk or network)

cr0x@server:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.11    0.00    4.25    8.90    0.00   74.74

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  r_await  w_await  aqu-sz  %util
nvme0n1         120.0   850.0  4800.0 55200.0    0.0     2.0     1.2     18.4    6.5   92.0

Signification de la sortie : Le périphérique est fortement utilisé, et w_await est ~18ms — élevé pour du NVMe, suggérant saturation ou mise en file.

Décision : Si %util est saturé et que l’await augmente, vous êtes lié par le disque sur ce nœud/hôte OSD. Dans Ceph, cela peut être un OSD lent ; dans ZFS, peut‑être un vdev surchargé.

Task 15: Check Proxmox VM disk IO settings (sometimes the bottleneck is self-inflicted)

cr0x@server:~$ qm config 101 | egrep -i "scsi|virtio|iothread|cache|discard"
scsihw: virtio-scsi-single
scsi0: ceph-rbd:vm-101-disk-0,discard=on,iothread=1,ssd=1

Signification de la sortie : virtio-scsi-single avec iothread activé et discard on, utilisant Ceph RBD.

Décision : Bon baseline pour beaucoup de workloads. Si vous voyez cache=unsafe quelque part, traitez‑le comme un item du registre des risques avec une échéance courte.

Task 16: Watch Ceph client IO from the cluster perspective

cr0x@server:~$ ceph osd pool stats
pool rbd id 1
  client_io_rate: 48 MiB/s rd, 22 MiB/s wr, 310 op/s rd, 420 op/s wr
pool cephfs_data id 2
  client_io_rate: 12 MiB/s rd, 4 MiB/s wr, 90 op/s rd, 60 op/s wr

Signification de la sortie : Le pool RBD fait la majorité des IO.

Décision : Quand les utilisateurs disent « le stockage est lent », validez si l’IO a vraiment augmenté, ou si la latence a monté sans débit (souvent réseau ou un OSD).

Mode d’urgence : diagnostiquer un goulot en quelques minutes

Voici l’ordre de triage que j’utilise quand quelqu’un dit « les VM sont lentes » et que la salle commence à blâmer le stockage comme rituel.

Premier : est‑ce local au nœud ou à l’échelle du cluster ?

Vérifiez la charge du nœud Proxmox : si un nœud est chaud, il peut s’agir d’un IO local ou d’ordonnancement CPU.
Vérifiez si seules les VM sur Ceph sont affectées : si oui, concentrez‑vous sur la santé Ceph et le réseau ; sinon, il peut s’agir du CPU de l’hôte, d’une pression mémoire ou d’un problème réseau partagé.

Second : Ceph est‑il unhealthy ou en recovery ?

Lancez : ceph -s et cherchez HEALTH_WARN/ERR, slow ops, PGs dégradés, OSD down, recovery/backfill.
Décision : Si une recovery a lieu, supposez qu’elle contribue à la latence. Décidez s’il faut limiter temporairement la recovery.

Troisième : perte/latence réseau ?

Vérifiez les erreurs/drops d’interface : ip -s link sur tous les nœuds et ports VLAN de stockage.
Regardez les avertissements heartbeat Ceph : ils pointent souvent vers une micro‑perte réseau ou des liens saturés.
Décision : Si vous voyez des drops/retransmits, traitez le réseau comme suspect principal.

Quatrième : est‑ce un disque/OSD lent ?

Ceph : ceph osd perf pour identifier les outliers ; puis check SMART et dmesg sur l’hôte.
ZFS : zpool status pour erreurs ; iostat -x pour saturation ; vérifiez si un vdev supporte plus de charge.
Décision : Remplacez le matériel défaillant tôt. Un disque dégradé mais encore fonctionnel est le début des outages.

Cinquième : est‑ce la configuration VM ou le comportement invité ?

Vérifiez le bus disque et les iothreads : des devices mal configurés peuvent plafonner les performances.
Vérifiez le comportement fsync de l’invité : les bases de données peuvent transformer le stockage en microscope de latence.
Décision : Si une VM est coupable, appliquez des limites IO ou déplacez‑la vers un niveau conçu pour elle.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: “Ceph is slow during the day, fine at night”

Cause racine : Recovery/backfill concurrence avec l’IO client ; la charge en heures ouvrables ne laisse aucune marge.

Fix : Limiter la recovery pendant les pics ; augmenter la capacité réseau ; utiliser des médias plus rapides ; réduire la variance de performance des OSD.

2) Symptom: Random VM freezes/timeouts on Ceph

Cause racine : Perte de paquets ou micro‑sauts sur le réseau de stockage ; un OSD qui flappe ; slow ops qui s’accumulent.

Fix : Valider compteurs d’erreurs et santé switch ; isoler le trafic stockage ; corriger MTU ; remplacer disques/OSD instables.

3) Symptom: ZFS pool “healthy” but performance keeps degrading over months

Cause racine : Pool trop plein ; fragmentation ; snapshots conservés indéfiniment ; petites écritures aléatoires sur RAIDZ.

Fix : Garder de la marge ; supprimer les snapshots inutiles ; migrer le stockage chaud des VM vers des vdevs en miroir ; ajouter des vdevs avant la crise.

4) Symptom: “Adding disks made Ceph worse”

Cause racine : Rebalancing/backfill déclenché et saturation réseau/disque ; OSDs non uniformes ; domaines CRUSH mal appairés.

Fix : Ajouter de la capacité pendant des fenêtres contrôlées ; limiter le backfill ; garder les classes OSD cohérentes ; valider la topologie CRUSH.

5) Symptom: ZFS corruption scare after power event

Cause racine : Pas de UPS ; SSDs grand public sans protection contre perte de puissance ; réglages de cache risqués.

Fix : UPS plus SSDs adaptés aux workloads critiques ; éviter le caching unsafe ; tester les procédures de restauration.

6) Symptom: Ceph looks healthy but latency spikes persist

Cause racine : Un OSD lent (apply latency élevée) ou contention CPU sur les hôtes OSD ; voisin bruyant saturant l’IO.

Fix : Utiliser ceph osd perf et iostat au niveau hôte ; déplacer les VM lourdes ; appliquer des limites IO ; assurer de la marge CPU sur les hôtes OSD.

7) Symptom: Live migration is slow or fails under load

Cause racine : Le trafic de migration partage un réseau contraint avec Ceph ; ou le stockage est ZFS local et vous copiez réellement des disques.

Fix : Séparer le réseau de migration ; si vous avez besoin de sémantiques partagées, utilisez Ceph ou acceptez une migration planifiée avec réplication.

8) Symptom: “We set sync=disabled and everything got fast”

Cause racine : Vous avez troqué la durabilité pour la vitesse ; vous êtes maintenant vulnérable à la perte de données lors d’une coupure de courant ou d’un kernel panic.

Fix : Rétablissez. Si les sync writes sont trop lents, corrigez le chemin de stockage (miroirs, SLOG avec PLP, médias plus rapides, meilleur tuning), pas les lois de la physique.

Listes de contrôle / plan pas à pas

Checklist A: If you’re leaning ZFS (local storage, simpler ops)

Choisir des miroirs pour les pools VM sauf si vous avez un workload prouvé adapté à RAIDZ.
Activer la compression (lz4) et la vérifier sur les datasets/zvols VM.
Planifier la marge : viser <70% d’utilisation pour les pools VM ; considérer 80% comme une falaise de performance, pas une suggestion.
Planifier des scrubs et surveiller les erreurs de checksum.
Mettre en place la réplication (zfs send/receive) vers un autre nœud ou une cible de backup si vous avez besoin de restaurations rapides.
Tester les restaurations mensuellement au minimum ; plus souvent si vous changez les politiques de rétention.
Décider de votre récit de défaillance : perte d’un nœud = restauration depuis backup, ou basculement via disques VM répliqués.

Checklist B: If you’re leaning Ceph (shared storage, HA semantics)

Commencez avec 3+ nœuds avec hardware OSD cohérent ; évitez de mélanger des classes de latence dans le même pool.
Budgétez correctement le réseau : 25GbE baseline pour les workloads sérieux ; isolez le trafic stockage.
Choisissez la taille de réplication intentionnellement (souvent size 3). Écrivez ce que cela tolère en panne.
Définissez les domaines de défaillance (hôte/rack) pour que CRUSH corresponde à la réalité physique.
Fixez des limites de recovery/backfill pour la stabilité diurne ; ayez un profil « hors heures » si nécessaire.
Surveillez les slow ops et les outliers de perf OSD ; traitez‑les comme des alertes précoces.
Pratiquez le remplacement d’OSD un jour non critique. Vous ne voulez pas que votre première fois soit en état dégradé.

Checklist C: Migration plan if you chose wrong last year

Inventoriez les workloads : quelles VM ont besoin de faible latence, quelles VM ont besoin de capacité, quelles VM ont besoin de sémantiques partagées.
Créez des niveaux : stockage hot (mirrors/NVMe), stockage général, stockage bulk/sauvegarde.
Déplacez une charge d’abord et mesurez avant/après (latence, débit, latences tail).
Automatisez le rollback pour que votre migration ne soit pas une porte sans retour.
Documentez des runbooks opérationnels pour le nouveau niveau (comment remplacer un disque, comment diagnostiquer une IO lente, qui alerte qui).

FAQ

1) Can I run Ceph on 3 nodes with mixed SSD and HDD?

Vous pouvez, mais vous ne devriez probablement pas pour des disques VM. Mélanger des latences dans le même pool tend à créer des problèmes de tail‑latency. Si vous devez mixer, séparez par classe de périphérique et utilisez des pools distincts.

2) Is Ceph always slower than local ZFS?

Non. Mais Ceph ajoute des sauts réseau et un overhead de réplication. Sur du très bon matériel et un excellent réseau, Ceph peut être rapide et consistant. Sur du « 10GbE récupéré », ZFS local semblera souvent meilleur pour les écritures sensibles à la latence.

3) Is RAIDZ “bad” for ZFS VM storage?

Pas moralement. Pratiquement, RAIDZ peut être un mauvais choix pour les workloads VM à écritures aléatoires à cause de la parité et du comportement IOPS. Les miroirs sont généralement le choix sûr par défaut pour les disques VM.

4) Should I use Ceph erasure coding for VM disks?

Généralement non pour les disques VM primaires à moins d’avoir une bonne raison et de comprendre les compromis de performance. L’EC brille pour l’efficacité de capacité, souvent mieux adapté aux workloads objet/fichier qu’aux IO bloc aléatoires sensibles à la latence.

5) What’s the minimum “serious” Ceph network?

Pour la production avec une charge significative : 25GbE et des switches sensés. 10GbE peut fonctionner, mais vous finirez par tuner autour des events de recovery et vivre avec plus de variance.

6) Do I need ECC RAM for ZFS?

Fortement recommandé, surtout pour les workloads critiques. ZFS protège les données sur disque avec des checksums, mais les erreurs RAM peuvent toujours causer de mauvais résultats. L’ECC réduit une classe de pannes silencieuses et horribles.

7) How do snapshots differ operationally between Ceph and ZFS?

Les snapshots ZFS sont extrêmement matures et faciles à raisonner. Les snapshots Ceph RBD existent et sont utiles, mais votre mémoire opérationnelle sera plus forte avec les workflows style ZFS. Pour les backups Proxmox, vous utiliserez typiquement Proxmox Backup Server quoi qu’il arrive.

8) Can I combine them: ZFS for local and Ceph for shared?

Oui, et de nombreuses organisations le font. Placez les workloads sensibles à la latence ou à affinité nœud sur ZFS local, et utilisez Ceph pour les VM qui bénéficient du stockage partagé et du HA. L’astuce est d’avoir des règles de placement claires et de surveiller les deux chemins.

9) What’s the most common reason Ceph deployments disappoint?

Réseau sous‑dimensionné et hardware OSD incohérent. Les gens s’attendent à ce que le stockage distribué se comporte comme un SSD local. Ceph peut le faire, mais seulement si vous le payez en conception.

10) What’s the most common reason ZFS deployments disappoint?

Pression de capacité et prolifération de snapshots. Les pools deviennent trop pleins, les performances chutent, et quelqu’un « corrige » en supprimant la mauvaise chose. Planifiez la marge et la rétention dès le premier jour.

Prochaines étapes réalisables cette semaine

Exécutez les commandes ci‑dessous sur votre cluster actuel et notez ce qui est vrai (layout, santé, outliers de latence, drops réseau). Cela devient votre baseline.
Décidez de ce dont vous avez réellement besoin : sémantiques de stockage partagé (Ceph) ou stockage local solide avec réplication/sauvegardes (ZFS). Ne prétendez pas avoir besoin des deux si ce n’est pas le cas.
Si vous êtes sur Ceph : validez l’isolation réseau et la marge ; confirmez size/min_size des pools ; identifiez les OSDs lents et corrigez‑les avant qu’ils ne causent l’incident.
Si vous êtes sur ZFS : confirmez des miroirs pour les pools VM, compression activée et suffisante marge ; auditez la rétention des snapshots ; faites un test de restauration impliquant le démarrage d’une VM.
Rédigez l’histoire de défaillance sur une page : « Si un nœud meurt, nous faisons X ; si un disque meurt, nous faisons Y ; si le réseau flanche, nous faisons Z. » Si vous ne pouvez pas l’écrire, vous ne le maîtrisez pas encore.

La décision Ceph vs ZFS n’est pas « lequel est meilleur ». C’est « quel ensemble de compromis voulez‑vous déboguer à 2 h du matin ». Choisissez celui que vous pouvez exploiter, pas celui qui gagne un argument de forum.