Ceph ou ZFS sur Proxmox, une seule question à se poser

C’est l’un de ces débats qui remplissent les forums homelab comme les salles de réunion et qui s’éternisent parce que les deux camps comparent des choses qui ne se comparent pas. ZFS et Ceph ne jouent pas dans la même catégorie, l’un est un système de fichiers et gestionnaire de volumes local d’une robustesse remarquable, l’autre est un stockage distribué qui vise l’échelle et l’auto-guérison et vouloir les départager dans l’absolu n’a pas plus de sens que de demander si une clé de 13 vaut mieux qu’une perceuse. La bonne question n’est pas “lequel est meilleur”, c’est “combien de nœuds et quelle haute disponibilité réelle” et une fois qu’on a répondu à celle-là, le reste se déduit presque mécaniquement.

La règle

Un ou deux nœuds, c’est ZFS, sans hésiter. Ceph a besoin d’un quorum que deux nœuds ne peuvent pas former honnêtement et à cette échelle vous ne voulez de toute façon pas de sa complexité opérationnelle. ZFS vous donne les snapshots, la compression, l’intégrité de bout en bout et le send/recv, ce qui couvre l’essentiel de ce qu’un petit cluster attend de son stockage.

Trois nœuds ou plus, avec un vrai besoin de haute disponibilité, c’est-à-dire la capacité de perdre un nœud et de voir les VM redémarrer ailleurs sur un état partagé, c’est Ceph. Distribué, réparti, capable de se reconstruire tout seul après une panne, il est fait précisément pour ce scénario et il le fait bien, à condition de lui donner ce qu’il réclame, sur quoi je reviens.

Trois nœuds ou plus, mais où vous préférez la simplicité à la haute disponibilité stricte, c’est ZFS complété par la réplication pvesr. Cette réplication asynchrone, spécifique à ZFS, vous offre un failover économique avec une fenêtre de perte égale à l’intervalle de réplication, sans le poids d’exploitation d’un Ceph. Ce n’est pas de la HA temps réel, c’est un compromis assumé et pour bien des parcs c’est exactement le bon.

Les pièges qui mordent

La règle est simple, les pièges le sont moins et ce sont eux qui transforment un déploiement propre en cauchemar de production. Ceph veut un réseau rapide et dédié, 10 GbE au strict minimum, idéalement 25 et sachez que la latence lui importe davantage que le débit brut, si bien qu’un cluster Ceph posé sur du 1 GbE partagé n’est pas lent, il est inexploitable. Ceph veut aussi ses trois réplicas, size=3 et min_size=2 par défaut, ce qui signifie que votre capacité utile vaut le tiers de votre capacité brute et il vaut mieux le savoir avant de commander les disques qu’après.

ZFS de son côté mange de la RAM par son ARC et apprécie l’ECC et si le redimensionnement des raidz s’est assoupli avec l’expansion arrivée dans OpenZFS 2.3, on planifie toujours son layout comme si l’on n’y touchait plus jamais, parce que c’est encore la meilleure façon de ne pas se piéger.

Enfin et cela vaut pour les deux, on ne met jamais, au grand jamais, un RAID matériel entre les disques et ZFS ou Ceph, qui veulent voir les disques nus, donc un HBA en mode IT et rien d’autre. Et l’on prévoit des SSD entreprise avec protection contre les coupures d’alimentation pour tout ce qui touche aux journaux et bases de données de Ceph comme au SLOG de ZFS, sous peine de voir la latence s’effondrer au premier fsync sérieux.

Le reste est affaire de goût et de contexte, mais tant que vous aurez répondu d’abord à la question du nombre de nœuds et de la HA, vous ne vous tromperez pas de catégorie et c’est là que se jouent quatre-vingt-dix pour cent des regrets.

[edit: 2026] L’implémentation Ansible de tout ceci: les rôles microceph et proxmox .