CEPH est une plateforme de stockage distribué conçue pour fournir, à partir de matériel standard, un stockage :
- hautement disponible
- scalable horizontalement
- tolérant aux pannes
- auto-réparant
CEPH ne se limite pas à un type de stockage : il constitue un socle unique capable de fournir simultanément :
- du stockage bloc (RBD)
- du stockage objet (compatible S3 / Swift)
- du stockage fichier (CephFS)
L’objectif fondamental est de supprimer les points de défaillance uniques et les contrôleurs centraux, tout en conservant des garanties fortes d’intégrité et de disponibilité des données.
Cette section du blog contient un LAB qui permet de créer de bout en bout un cluster de stockage CEPH :
Au cœur de CEPH se trouve RADOS (Reliable Autonomic Distributed Object Store).
Les données sont :
- découpées en objets
- distribuées sur l’ensemble des disques du cluster
- répliquées ou codées (erasure coding)
- accessibles sans intermédiaire central
Chaque accès client communique directement avec les nœuds stockant les données.
L’algorithme CRUSH décide du placement des données en fonction :
- de règles définies par l’architecture (disques, hôtes, racks, salles)
- de la topologie réelle du cluster
Aucune table centrale n’est consultée :
- le client calcule lui-même où écrire ou lire
- en cas de panne, le recalcul est automatique
- le cluster se rééquilibre sans intervention manuelle
CRUSH est l’un des piliers qui permet à CEPH de changer d’échelle sans refonte d’architecture.
Les MON assurent :
- le maintien de l’état global du cluster
- la gestion du quorum
- la diffusion de la carte CRUSH et des maps internes
Un cluster CEPH en production repose systématiquement sur au moins trois MON, afin de garantir la continuité du quorum.
Les OSD sont responsables :
- du stockage physique des données
- de la réplication ou du codage
- de la réparation automatique
- du scrubbing (vérification d’intégrité)
Un principe clé de CEPH est le suivant :
plus il y a d’OSD, plus le cluster devient performant et résilient
Les MDS sont utilisés exclusivement pour CephFS :
- gestion des métadonnées POSIX
- séparation claire entre données et métadonnées
- montée en charge horizontale possible
Cephadm est l’outil officiel d’administration moderne de CEPH.
Il permet :
- l’initialisation du cluster
- le déploiement des démons CEPH
- la gestion du cycle de vie (ajout, suppression, mise à jour)
- la supervision et l’orchestration des services
Tous les composants CEPH sont exécutés sous forme de conteneurs, ce qui :
- isole CEPH du système hôte
- simplifie les mises à jour
- standardise l’exploitation
Cephadm agit comme un orchestrateur natif :
- placement automatique des services
- redéploiement en cas de défaillance
- approche déclarative de l’infrastructure CEPH
Cette approche marque une rupture nette avec les anciennes méthodes d’installation manuelle.
CEPH est couramment utilisé comme :
- backend de virtualisation (KVM, Proxmox, OpenStack)
- stockage persistant pour Kubernetes
- stockage objet interne ou exposé à des applications
Il est courant de séparer :
- un réseau public (clients)
- un réseau cluster (réplication, recovery)
CEPH est conçu pour :
- tolérer la perte de disques
- tolérer la perte de nœuds
- continuer à fonctionner pendant les phases de réparation
Le système n’essaie pas d’éviter les pannes, mais de les absorber sans perte de données.
- absence de dépendance à un fournisseur
- montée en charge horizontale
- mutualisation bloc / fichier / objet
- auto-réparation native
- matériel standard
- architecture distribuée éprouvée
- algorithme CRUSH robuste
- large écosystème et intégrations
- utilisé à très grande échelle en production
- complexité conceptuelle réelle
- courbe d’apprentissage exigeante
- consommation réseau importante
- latence supérieure à certains SAN haut de gamme
- nécessité d’une architecture rigoureuse
Un cluster CEPH mal conçu devient rapidement difficile à exploiter.
Un cluster CEPH correctement dimensionné devient au contraire extrêmement stable.
CEPH n’est généralement pas pertinent lorsque :
- l’environnement est trop petit
- les compétences internes sont absentes
- la latence ultra-faible est critique
- l’infrastructure est figée et non scalable
CEPH est avant tout un choix stratégique, pas un simple outil de stockage.