Ceph : le stockage distribué ne pardonne pas

Ceph a cette réputation bizarre d’être à la fois le Graal du stockage open source et le truc que tout le monde conseille de ne pas toucher sans casque lourd.

Et franchement, les deux camps ont raison.

Sur le papier, Ceph est magnifique : du stockage objet, bloc et fichier, distribué, auto-réparant, sans point unique de panne, avec une scalabilité presque insolente. Dans la vraie vie, Ceph est surtout un révélateur brutal. Il ne crée pas toujours vos problèmes. Il les rend impossibles à ignorer.

Un réseau moyen ? Ceph va vous le faire sentir. Des disques mélangés n’importe comment ? Ceph va vous le faire payer. Une topologie de panne pensée à moitié ? Ceph va la transformer en incident. Une équipe qui veut juste “un gros disque partagé” ? Mauvaise nouvelle : Ceph n’est pas un gros disque partagé.

C’est une machine distribuée.

Et une machine distribuée, ça ne pardonne pas l’approximation.

Pourquoi on regarde Ceph

Dans un cluster classique, le stockage est souvent traité comme une annexe. On pense compute, réseau, hyperviseur, Kubernetes, GPU, VM. Puis à la fin, quelqu’un pose la question : “Et les données, on les met où ?”

C’est là que les mauvaises décisions commencent.

Sur un petit lab, on peut s’en sortir avec du stockage local. Sur un NAS. Sur un NFS bien configuré. Sur un datastore Proxmox simple. C’est propre, compréhensible, facile à réparer à trois heures du matin.

Mais dès qu’on commence à parler de plusieurs nœuds, de workloads qui bougent, de VM critiques, de données qui doivent survivre à la perte d’une machine, le stockage local devient une dette. On ne déplace plus une VM librement. On ne redémarre plus un nœud sereinement. On se retrouve à faire de l’infrastructure distribuée avec un stockage qui, lui, ne l’est pas.

Ceph apparaît exactement à ce moment-là.

Il promet une chose simple : arrêter de dépendre d’un serveur de stockage unique. Les disques de vos machines deviennent un pool distribué. Les données sont répliquées. Les clients parlent au cluster. Si un disque meurt, le cluster reconstruit. Si un nœud tombe, les données restent disponibles.

Ça, c’est la promesse.

Mais la promesse cache une condition : vous devez accepter que votre stockage devienne un système à part entière, avec sa propre topologie, ses propres métriques, ses propres pannes, et sa propre discipline d’exploitation.

Ceph en une phrase

Ceph, ce n’est pas “un filesystem distribué”. C’est d’abord RADOS, un système de stockage objet distribué. Tout le reste est construit au-dessus.

• RBD expose du bloc pour les VM, Kubernetes, Proxmox, OpenStack.
• CephFS expose un filesystem distribué avec des Metadata Servers.
• RGW expose une API objet compatible S3.

Mais le cœur, c’est RADOS : des objets placés sur des OSD selon une carte CRUSH, surveillés par des MON, pilotés par des MGR.

Si vous comprenez ça, vous évitez déjà 50% des mauvaises discussions. CephFS n’est pas Ceph. RBD n’est pas Ceph. RGW n’est pas Ceph. Ce sont des portes d’entrée. Le vrai sujet, c’est ce qu’il se passe derrière : comment les objets sont placés, répliqués, reconstruits et servis.

La CRUSH map : le cerveau que tout le monde sous-estime

Le concept le plus important dans Ceph, ce n’est pas le nombre de disques. Ce n’est même pas la taille du cluster. C’est la CRUSH map.

CRUSH, pour faire simple, c’est l’algorithme qui décide où placer les données. Pas avec une table centrale bête, mais avec une fonction déterministe basée sur le nom des objets, le poids des OSD et la topologie du cluster : hosts, racks, rooms, datacenters, règles de réplication.

Imaginez un bibliothécaire qui ne garde pas un fichier Excel avec “livre X = étagère Y”. À la place, il connaît les règles de rangement : tel type de livre va dans telle salle, jamais deux copies dans la même armoire, toujours une copie dans un autre bâtiment. Si tout le monde connaît les règles, tout le monde peut retrouver le livre sans demander à un chef central.

C’est brillant.

Mais ça veut dire une chose : si vos règles sont mauvaises, Ceph va être brillamment mauvais.

Exemple classique : vous avez trois nœuds, chaque nœud avec plusieurs disques, et vous dites à Ceph de répliquer à trois copies. Si la règle CRUSH est bien faite, Ceph place une copie par host. Vous pouvez perdre un nœud complet. Si la règle est mal comprise, vous pouvez vous retrouver avec plusieurs copies sur le même domaine de panne logique. Et là, votre “réplication x3” devient un mensonge confortable.

Ceph ne protège pas contre ce que vous n’avez pas modélisé.

Il protège contre les domaines de panne que vous avez correctement décrits.

Les Placement Groups : le détail qui devient énorme

Les PG, ou Placement Groups, sont souvent expliqués comme un détail de tuning. C’est une erreur.

Un PG est une sorte de groupe intermédiaire entre les objets et les OSD. Au lieu de placer chaque objet individuellement sur chaque disque, Ceph place les objets dans des PG, puis place les PG sur les OSD. Ça réduit la complexité et rend le cluster administrable.

Le problème, c’est que les PG sont invisibles quand tout va bien, et très visibles quand tout va mal.

Trop peu de PG : vous répartissez mal la charge. Certains OSD prennent plus que les autres. Vous avez un cluster qui semble avoir de la capacité, mais qui se comporte comme un système déséquilibré.

Trop de PG : vous augmentez l’overhead, la mémoire consommée par les OSD, le temps de peering, la complexité du recovery. Vous avez voulu “optimiser”, vous avez créé du bruit permanent.

Aujourd’hui, l’autoscaler aide beaucoup. Mais “autoscaler” ne veut pas dire “je ne comprends plus”. Il faut quand même regarder ce qu’il propose, comprendre les pools, les tailles de réplication, les usages RBD/CephFS/RGW, et éviter de créer des pools comme on crée des dossiers.

ceph osd pool autoscale-status
ceph osd pool ls detail
ceph pg stat

Si vous ne regardez jamais ces commandes, vous pilotez à l’aveugle.

Le réseau : le faux détail

Le plus gros mensonge qu’on se raconte avec Ceph, c’est que le stockage dépend surtout des disques.

Non.

Ceph dépend énormément du réseau.

À chaque écriture, le client parle au cluster, les OSD parlent entre eux, les réplicas doivent être confirmés, les recovery passent par le réseau, les backfill aussi. Une panne disque n’est pas juste une panne disque : c’est un événement réseau. Le cluster doit recopier des données ailleurs. Et s’il le fait sur un réseau déjà chargé, vous venez de transformer une dégradation normale en ralentissement général.

Sur un petit cluster, ce piège est encore plus violent. Vous avez trois nœuds. Un OSD tombe. Ceph reconstruit. Les mêmes liens réseau servent aux clients, au cluster, au management, parfois aux VM. Tout se mélange. Et vous vous demandez pourquoi les latences explosent.

Ceph aime la bande passante. Mais surtout, Ceph déteste la latence instable.

Un lien 10 GbE propre peut être très correct pour beaucoup d’usages. Un 1 GbE bricolé avec des workloads sérieux, c’est souvent une invitation à souffrir. Et si vous avez des workloads type VM avec beaucoup d’I/O sync, la latence devient plus importante que le débit brut.

Le stockage distribué, ce n’est pas de la magie. C’est du réseau avec des disques au bout.

Longhorn, Gluster, NFS, local : pourquoi ne pas choisir plus simple ?

Il faut être honnête : Ceph n’est pas toujours le bon choix.

NFS est parfois suffisant. Pour du partage simple, des backups, des fichiers peu critiques, un bon serveur NFS bien monitoré peut être plus intelligent qu’un cluster Ceph mal exploité.

Le stockage local est parfois meilleur. Pour des workloads stateless, du cache, des bases qui répliquent déjà elles-mêmes, ou des nœuds spécialisés, la simplicité vaut de l’or.

Longhorn est très intéressant dans Kubernetes. Il est plus simple à prendre en main, orienté volumes persistants, bien intégré à l’écosystème cloud-native. Mais Longhorn n’est pas Ceph. Il ne joue pas exactement dans la même catégorie d’usage, surtout si vous voulez couvrir VM, bloc, objet, fichier et plusieurs plateformes.

GlusterFS, historiquement, a rendu service. Mais aujourd’hui, pour un nouveau design sérieux, je serais très prudent. L’écosystème, la dynamique projet, et les patterns modernes ne jouent pas vraiment en sa faveur face à Ceph.

Ceph devient intéressant quand vous avez besoin d’un socle de stockage distribué polyvalent, durable, intégré à Proxmox/OpenStack/Kubernetes, et que vous acceptez de l’opérer comme un vrai composant critique.

Pas comme un plugin.

Le vrai coût de Ceph

Le coût de Ceph ne se résume pas aux disques.

Il y a le coût matériel : disques, SSD/NVMe, réseau, cartes, switchs, câbles, slots, consommation, remplacement. Jusque-là, c’est visible.

Mais il y a surtout le coût mental.

Ceph ajoute une couche d’abstraction qui demande une vraie compréhension. Quand tout est vert, c’est agréable. Quand HEALTH_WARN apparaît, il faut savoir lire. Pas paniquer. Pas cliquer partout. Lire.

ceph -s
ceph health detail
ceph osd tree
ceph df
ceph osd df tree

Ces commandes doivent devenir banales. Pas des incantations que vous copiez depuis Stack Overflow quand le cluster brûle.

Il faut aussi prévoir les opérations normales : remplacer un disque, ajouter un OSD, retirer un nœud, gérer un backfill, surveiller les latences, comprendre pourquoi un pool prend trop de place, savoir si un warning est urgent ou simplement informatif.

Et il faut documenter. Parce que le jour où quelqu’un reprend le cluster, “Ceph est auto-réparant” ne suffira pas.

Auto-réparant ne veut pas dire auto-compréhensible.

Ce que je regarderais pendant un audit

Si je devais auditer un cluster Ceph, je ne commencerais pas par demander “combien de To ?”. Je commencerais par demander : quels scénarios de panne êtes-vous prêts à encaisser ?

Perte d’un disque ? D’un nœud ? D’un rack ? D’un switch ? D’un site ? Combien de temps de performance dégradée est acceptable ? Quels workloads sont sensibles à la latence ? Quelles données doivent être restaurées vite ? Qui reçoit l’alerte à deux heures du matin ?

Ensuite seulement, je regarderais le cluster.

# état global
ceph -s
ceph health detail

# topologie et domaines de panne
ceph osd tree
ceph osd crush tree
ceph osd crush rule dump

# capacité, skew et remplissage
ceph df
ceph osd df tree

# pools et placement groups
ceph osd pool ls detail
ceph osd pool autoscale-status
ceph pg stat

# performance côté OSD
ceph osd perf

Ce que je cherche, ce n’est pas un score parfait. Je cherche les contradictions.

Un cluster qui prétend tolérer la perte d’un nœud, mais dont la topologie CRUSH ne reflète pas les hosts réels. Un réseau unique qui sert à la fois les clients, le cluster, les migrations et le management. Des pools créés sans politique claire. Des OSD presque pleins à côté d’OSD tranquilles. Des disques hétérogènes mélangés comme si un HDD, un SSD SATA et un NVMe avaient le même comportement.

Ceph accepte beaucoup de choses.

La production, beaucoup moins.

Le piège du petit cluster

Ceph peut tourner sur trois machines. La vraie question, c’est : est-ce que Ceph doit tourner sur vos trois machines ?

Un petit cluster Ceph est paradoxal. Il donne une impression de robustesse, mais il a peu d’espace pour absorber les erreurs. Avec trois nœuds et une réplication à trois, vous pouvez perdre un nœud, oui. Mais pendant la panne, vous êtes déjà dans une zone où chaque opération compte. Le recovery consomme les ressources des survivants. Les upgrades demandent de la discipline. Les maintenances deviennent plus sensibles.

Ce n’est pas forcément mauvais. Pour un homelab sérieux, un cluster Proxmox, un environnement de test avancé, c’est formateur et utile. Mais il faut arrêter de vendre ça comme “simple”.

Un petit Ceph bien compris vaut mieux qu’un gros NAS mal sauvegardé.

Mais un petit Ceph incompris peut être pire qu’un simple stockage local correctement backupé.

Quand Ceph vaut le coup

Ceph vaut le coup quand vous cochez plusieurs cases.

Vous avez plusieurs nœuds et vous voulez que le stockage survive à la perte d’une machine. Vous avez besoin de volumes bloc pour des VM ou des workloads orchestrés. Vous voulez éviter un SAN propriétaire. Vous avez une équipe capable de lire les métriques, de maintenir le cluster, de faire des upgrades proprement. Vous acceptez de payer le coût réseau et opérationnel.

Ceph vaut aussi le coup quand il devient un socle commun : Proxmox aujourd’hui, OpenStack demain, Kubernetes à côté, stockage objet interne, backups, expérimentation. Dans ce cas, il apporte une cohérence forte. Vous apprenez un système, et ce système sert plusieurs usages.

C’est exactement là qu’il devient intéressant dans une infrastructure ambitieuse : pas comme une case “stockage distribué” dans un schéma d’architecture, mais comme une brique que vous assumez vraiment.

Quand il faut passer son chemin

Si vous voulez juste “un dossier partagé”, ne prenez pas Ceph.

Si vous n’avez pas de monitoring sérieux, ne prenez pas Ceph.

Si votre réseau est déjà limite, ne prenez pas Ceph.

Si personne ne veut être responsable du stockage, ne prenez pas Ceph.

Si vos données sont importantes mais que vous n’avez pas de stratégie de backup, ne prenez surtout pas Ceph en pensant que la réplication est un backup. Ce n’en est pas un. Une suppression logique, une corruption applicative, une mauvaise commande, un ransomware : Ceph répliquera très efficacement votre problème.

C’est dur, mais c’est la vérité : Ceph n’est pas une solution pour éviter de penser au stockage. C’est une solution pour penser le stockage sérieusement.

La checklist minimale avant de dire oui

Avant de déployer Ceph pour autre chose qu’un lab, je voudrais répondre clairement à ces questions :

• Quels sont les domaines de panne réels : disque, host, rack, switch, site ?
• La CRUSH map reflète-t-elle cette réalité ?
• Le réseau cluster est-il séparé ou au moins dimensionné correctement ?
• Les disques sont-ils homogènes par classe de performance ?
• Les pools ont-ils une raison d’exister ?
• Les PG sont-ils surveillés et cohérents ?
• Les alertes sont-elles comprises par quelqu’un ?
• Le remplacement d’un OSD a-t-il déjà été testé ?
• Les backups existent-ils hors Ceph ?
• Le cluster a-t-il été testé en mode dégradé ?

Si la moitié des réponses sont floues, le problème n’est pas Ceph. Le problème, c’est que l’architecture n’est pas encore prête.

Ceph ne ment pas

Ceph est exigeant parce qu’il touche à quelque chose de brutal : la donnée.

Une VM qui redémarre, c’est pénible. Un pod qui crash, on peut le relancer. Un service qui tombe, on peut parfois bricoler. Mais une donnée perdue, corrompue ou indisponible au mauvais moment, ça change le niveau de gravité.

C’est pour ça que j’aime bien Ceph, malgré sa complexité. Il oblige à penser en systèmes. Il oblige à parler de panne avant qu’elle arrive. Il oblige à dessiner la topologie réelle au lieu de se raconter que “le cluster gère”.

Mais je ne le recommanderais jamais comme une solution magique.

Ceph est un excellent choix quand vous voulez construire une vraie plateforme d’infrastructure, que vous acceptez le coût, et que vous avez envie de comprendre ce que vous opérez. Sinon, prenez plus simple. Sérieusement.

Le stockage, ce n’est pas l’endroit où il faut prouver qu’on est courageux.

C’est l’endroit où il faut être lucide.

Et sur ce, vérifiez vos HEALTH_WARN avant qu’ils deviennent votre prochain post-mortem.