Ceph revient dès qu'il est question de stockage à l'échelle : c'est le socle de nombreux clouds privés, le stockage persistant de plateformes Kubernetes entières, le backend de virtualisation de Proxmox ou d'OpenStack. Sa réputation de complexité est méritée — mais elle repose sur deux idées seulement, qu'il vaut la peine de comprendre avant de taper la moindre commande.
Ce que Ceph promet
À partir de matériel standard — pas de baie propriétaire, pas de contrôleur dédié — fournir un stockage :
- hautement disponible : la perte d'un disque ou d'un serveur n'interrompt pas le service ;
- extensible horizontalement : on ajoute des machines, la capacité et les performances suivent ;
- auto-réparant : après une panne, le cluster reconstruit seul les copies manquantes ;
- polyvalent : bloc, fichier et objet sur un même socle.
Cette dernière propriété est plus rare qu'il n'y paraît. La même grappe fournit simultanément des volumes bloc (RBD) pour des machines virtuelles ou des conteneurs, un système de fichiers POSIX partagé (CephFS), et du stockage objet compatible S3 (RGW). Là où l'on empilerait habituellement trois solutions distinctes, il n'y en a qu'une à exploiter.
RADOS : tout est objet
Sous les trois interfaces, un seul moteur : RADOS (Reliable Autonomic Distributed Object Store). Un fichier de 100 Mo, un disque virtuel de 200 Go, un objet S3 : tout est découpé en objets de taille fixe, répartis sur l'ensemble des disques du cluster, puis répliqués ou encodés.
Une conséquence pratique : ce que vous apprenez sur la résilience du bloc vaut pour l'objet et pour le fichier. Ce n'est pas trois produits qui partagent une marque, c'est une seule mécanique avec trois façades.
CRUSH : le calcul plutôt que l'annuaire
Le client découpe, calcule le placement avec CRUSH, puis écrit directement sur les OSD concernés — sans passer par un serveur de métadonnées.
C'est l'idée centrale, et la plus contre-intuitive. Dans un stockage distribué classique, un serveur de métadonnées sait où se trouve chaque donnée : le client l'interroge, puis va chercher la donnée. Ce serveur devient un point de passage obligé — donc un goulot d'étranglement et un point de défaillance.
Ceph supprime cet annuaire. L'algorithme CRUSH permet au client de calculer lui-même l'emplacement d'un objet, à partir de la carte du cluster et de règles décrivant la topologie réelle : disques, hôtes, baies, salles. Le client écrit ensuite directement sur les OSD concernés.
Trois bénéfices en découlent :
- pas de goulot central : les accès clients se répartissent naturellement sur tout le cluster ;
- la topologie devient une règle : « trois copies, jamais deux sur le même hôte », voire « jamais deux dans la même baie » — le placement respecte la réalité physique ;
- l'ajout de capacité est un recalcul : on déclare de nouveaux disques, la carte change, et seules les données concernées se déplacent. Aucune migration manuelle.
Réplication ou codage : deux façons de survivre
Deux stratégies de protection coexistent :
- la réplication — trois copies complètes, typiquement. Simple, rapide en lecture, tolérante ; mais trois fois l'espace pour une donnée utile ;
- l'erasure coding — la donnée est découpée en fragments accompagnés de blocs de parité, à la manière d'un RAID distribué. Beaucoup plus économique en espace, au prix de calculs supplémentaires et d'une reconstruction plus coûteuse.
En pratique : réplication pour ce qui est sollicité et sensible à la latence — machines virtuelles, bases de données ; erasure coding pour les gros volumes froids — sauvegardes, archives, objets.
L'auto-réparation, et le scrubbing
Quand un disque disparaît, Ceph ne se contente pas de le signaler : il recalcule le placement et reconstruit ailleurs les copies manquantes, automatiquement. Le cluster passe en état dégradé, travaille, puis revient de lui-même en bonne santé.
À cela s'ajoute le scrubbing : une vérification périodique de cohérence entre les copies d'un même objet, qui détecte les corruptions silencieuses — celles qu'aucune application ne remarque avant de lire la donnée, souvent des années plus tard. C'est une différence de fond avec un simple RAID.
Où Ceph n'a pas sa place
Autant l'écrire franchement, la documentation d'origine le fait aussi : Ceph est un choix d'architecture, pas un simple outil.
- Trop petit : en dessous de trois nœuds et d'une poignée de disques, la complexité l'emporte largement sur le bénéfice.
- Sans compétence interne : un cluster mal conçu devient rapidement pénible à exploiter — et un cluster de stockage qu'on n'ose plus toucher est un risque, pas une sécurité.
- Latence critique : une baie de stockage haut de gamme fera mieux sur ce seul critère. Ceph optimise le débit, la résilience et l'échelle.
- Réseau modeste : la réplication consomme de la bande passante, et une reconstruction en consomme beaucoup. C'est pourquoi on sépare le réseau des clients de celui du cluster.
À l'inverse, correctement dimensionné et compris, un cluster Ceph devient remarquablement stable — et surtout indépendant de tout fournisseur.
La documentation de référence est sur le wiki
Ces articles ne remplacent pas la documentation : ils en expliquent les choix et les mécanismes. Le pas à pas complet — commandes, sorties intégrales, captures d'écran — est publié sur mon wiki, section Datacenter / Stockage / CEPH.
La série Ceph
Deux fiches pour comprendre, quatre étapes pour construire :
- Comprendre Ceph : RADOS, CRUSH et l'absence de contrôleur central — vous y êtes
- Les démons : MON, OSD, MGR, MDS et RGW
- Lab (1) : cadrage et architecture
- Lab (2) : construire l'infrastructure sous KVM
- Lab (3) : préparer les systèmes
- Lab (4) : cephadm, du bootstrap aux OSD