Un cluster Ceph n'est pas un logiciel unique, mais un ensemble de démons aux rôles distincts. Savoir lequel fait quoi est la condition pour dimensionner correctement — et pour comprendre un cluster qui va mal.
Les MON tiennent la carte et votent, les OSD stockent, le MGR administre, MDS et RGW n'existent que pour CephFS et l'objet.
MON — le Monitor
Les monitors maintiennent l'état global du cluster : la liste des nœuds, celle des OSD, la carte CRUSH, les règles de placement. Ils ne stockent aucune donnée applicative — ce sont les gardiens de la vérité, pas du contenu.
Ils fonctionnent au quorum, comme etcd dans Kubernetes : toute modification de la carte doit être acceptée par une majorité stricte. D'où la règle universelle, trois monitors minimum en production, et toujours un nombre impair. Avec trois MON, la perte d'un nœud ne change rien ; avec deux, la perte d'un seul bloque tout.
C'est aussi auprès d'un MON que le client s'adresse en premier : il y récupère la carte, puis n'a plus besoin de lui pour lire ou écrire.
OSD — l'Object Storage Daemon
C'est le muscle du cluster. Un OSD par disque — pas un par serveur : une machine avec huit disques fait tourner huit OSD. Chacun :
- stocke les objets sur son disque ;
- réplique vers ses pairs ou calcule les fragments d'erasure coding ;
- participe au rééquilibrage quand la topologie change ;
- surveille ses voisins et signale les défaillances aux MON ;
- exécute le scrubbing, la vérification d'intégrité en tâche de fond.
Le principe à retenir tient en une phrase : plus il y a d'OSD, plus le cluster est rapide et résilient. Les accès se répartissent davantage, les reconstructions impliquent plus de disques donc vont plus vite, et le poids relatif d'une panne diminue.
MGR — le Manager
Le manager fournit tout ce qui n'est ni le stockage ni le consensus : métriques et statistiques, modules d'extension, tableau de bord web, et surtout l'orchestration — c'est lui qui héberge cephadm. On en déploie deux, l'un actif et l'autre en veille.
Un MGR indisponible ne fait pas tomber le stockage : les clients continuent de lire et d'écrire. On perd en revanche la supervision et l'administration, ce qui est déjà très inconfortable.
MDS — le Metadata Server
Uniquement nécessaire pour CephFS, le système de fichiers partagé. Il gère l'arborescence, les permissions, les verrous — toute la sémantique POSIX — pendant que les données, elles, passent directement par les OSD.
Cette séparation entre métadonnées et données est ce qui permet à CephFS de monter en charge : plusieurs MDS peuvent se répartir des sous-arbres du système de fichiers. Si vous ne faites que du bloc, aucun MDS n'est nécessaire.
RGW — la passerelle objet
La RADOS Gateway expose le cluster via une API compatible S3 et Swift. C'est un service HTTP sans état : on en déploie plusieurs derrière un répartiteur de charge quand le trafic le justifie. Là encore, il n'existe que si l'on consomme du stockage objet.
Comment les répartir
Sur un cluster de trois nœuds — la taille minimale raisonnable, celle du lab — la distribution habituelle est la suivante :
- un MON sur chacun des trois nœuds : le quorum est assuré ;
- deux MGR, sur deux nœuds différents : un actif, un en veille ;
- un OSD par disque de données, sur tous les nœuds ;
- un ou deux MDS si l'on veut CephFS.
Aucun nœud n'est « le maître » : chaque machine porte plusieurs rôles complémentaires, et aucune n'est indispensable à elle seule. C'est exactement ce que l'on attend d'une architecture sans point de défaillance unique.
Lire l'état d'un cluster
Deux commandes suffisent à se faire une idée, et elles sont les premières à taper quand quelque chose cloche :
ceph -s # santé globale, quorum des MON, OSD up/in, capacité, activité ceph osd tree # la topologie vue par CRUSH : hôtes, disques, poids, état
Un cluster en bonne santé affiche HEALTH_OK. Un cluster en HEALTH_WARN pendant une reconstruction n'est pas un cluster en panne : c'est un cluster en train de faire exactement ce pour quoi il a été conçu.
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 :