Vous montez un Proxmox cette semaine et vous hésitez sur le stockage ? Posez d’abord le calcul de côté. La bonne réponse ne sort pas d’un comparatif de fonctionnalités, elle sort de votre architecture : combien de nœuds, ce que vous attendez le jour où l’un tombe, et la charge réelle qui passe dessus. La préférence personnelle n’entre pas dans l’équation.
Le stockage Proxmox se choisit sur l’architecture : ZFS pour un nœud seul ou de la réplication, Ceph pour un vrai cluster en haute disponibilité, LVM-Thin quand vous cherchez la simplicité.
Les trois options qu’on croise
LVM-Thin. Simple, rapide, local à la machine. Aucune réplication. Pour un serveur seul, ou des charges qui n’ont pas besoin de survivre à la perte d’un nœud, ça suffit largement. Les snapshots y sont limités, et c’est le compromis à accepter.
ZFS. Snapshots instantanés, compression, contrôle d’intégrité contre la corruption qui ne dit pas son nom, réplication asynchrone vers un autre nœud. Sur une à trois machines, c’est mon choix par défaut quand Ceph n’a rien à faire là. La contrepartie, c’est la RAM : prévoyez généreusement. Un serveur que j’ai vu ramer pendant des semaines tournait avec 8 Go pour un gros pool. C’était ça, le problème, rien d’autre.
Ceph. Stockage distribué, réplication synchrone, haute disponibilité pour de vrai : une VM redémarre sur un autre nœud sans rien perdre. L’addition, elle, est salée. Plusieurs nœuds, un réseau dédié rapide (du 10 Gb/s, pas votre LAN de bureau), beaucoup de disques, et quelqu’un capable de l’exploiter le dimanche où un OSD (le démon Ceph qui gère un disque du cluster) part en vrille.
Comment je tranche
Sur un seul nœud, LVM-Thin pour la simplicité, ZFS dès que vous voulez les snapshots et l’intégrité. Ceph n’a aucun sens sur une machine isolée.
Deux ou trois nœuds, HA voulue mais budget serré : ZFS plus réplication. La bascule prend quelques minutes, pas zéro seconde. En échange vous obtenez un stockage qui tient la route, et vous dormez la nuit.
Vrai cluster, HA stricte, charge qui ne faiblit pas : là, Ceph se justifie, à condition d’y mettre le matériel et les compétences. Pas à moitié.
Le cas qui revient le plus
Trois petits serveurs sur un site industriel, un réseau partagé avec le reste du trafic. On y avait mis du Ceph « pour être tranquille ». Le résultat ? Latence disque qui grimpe, exploitation qui vire au casse-tête, et cette fameuse HA, mal réglée sur ce matériel, qui lâchait pile au moment de servir. On est repassés en ZFS avec réplication. Moins ambitieux sur le papier, autrement plus solide une fois en charge.
Au fond, ce sont votre charge et votre capacité à tenir l’outil dans le temps qui dictent le stockage. Le plus simple qui couvre le vrai besoin l’emporte sur celui qui rassure sur l’instant.
Là où ce raisonnement s’arrête
Je vous ai donné une grille, pas une vérité. Elle suppose que votre charge ressemble à ce que je croise d’habitude : des VM applicatives, des bases de taille raisonnable, un trafic qui se prévoit. Sortez de ce cadre et la grille craque. Une base très sollicitée en écriture peut transformer un pool ZFS confortable en goulot, là où un Ceph bien dimensionné respire ; à l’inverse, une boîte qui maîtrise déjà Ceph aura tort de revenir à ZFS au nom de la simplicité, puisque pour elle ce n’est plus le point dur. Bref, l’architecture décide, mais elle ne décide bien qu’une fois mesurée. Avant de figer un choix sur une charge importante, faites tourner vos propres I/O quelques jours et regardez les chiffres. Les miens ne remplacent pas les vôtres.