Ceph en images : MON, MGR, OSD, MDS, PG, CRUSH¶

Day 0 · ConcevoirNiveau 1 · DécouvrirCours animéRédigé · à valider en lab

Ceph transforme les disques locaux de vos nœuds Proxmox en un stockage partagé, répliqué et auto-réparant : chaque bloc de disque de VM est découpé en objets, rangés dans des placement groups (PG), eux-mêmes placés sur des disques (OSD) par l'algorithme CRUSH. À la fin de cette page, vous savez nommer chaque démon, dire à quoi il sert et ce qui se passe quand il tombe.

Les démons Ceph¶

Démon	Rôle	Combien sur un cluster PVE	S'il tombe
MON (monitor)	Garde les « cartes » du cluster (MON, OSD, PG, CRUSH) et l'authentification. Fonctionne par quorum.	3 (un par nœud sur 3 nœuds ; 3 ou 5 au-delà)	1 MON sur 3 : rien de visible. 2 sur 3 : plus de quorum, I/O bloquées.
MGR (manager)	Statistiques, modules (tableau de bord, balancer, autoscaler de PG), API utilisée par la GUI.	1 actif + 1 ou 2 en attente, sur les nœuds MON	Bascule automatique sur un MGR en attente. Les données restent accessibles, la GUI perd ses graphes un instant.
OSD (object storage daemon)	Un OSD par disque physique. Stocke les objets (BlueStore), réplique, vérifie (scrub), reconstruit.	Tous les disques de données (au moins 12 OSD recommandés sur 3 nœuds)	Ceph recopie ses données ailleurs après 10 min (`mon_osd_down_out_interval`), sauf drapeau `noout`.
MDS (metadata server)	Métadonnées de CephFS uniquement (arborescence, droits). Inutile pour les disques de VM (RBD).	0 sans CephFS ; sinon 1 actif + 1 en attente	Bascule sur le MDS en attente ; CephFS gelé quelques secondes.

Sur Proxmox VE, tous ces démons sont gérés par pveceph et la GUI (nœud → Ceph). Pas de cephadm ni de conteneurs : ce sont des services systemd (ceph-mon@pve01, ceph-osd@7…).

Le chemin d'une écriture¶

flowchart LR
    VM["VM 101<br/>disque virtio-scsi"] --> RBD["librbd<br/>image vm-101-disk-0<br/>découpée en objets de 4 Mo"]
    RBD --> HASH["hash(nom objet)<br/>mod pg_num"]
    HASH --> PG["PG 2.1a<br/>du pool ceph-vm"]
    PG --> CRUSH{"CRUSH<br/>règle du pool"}
    CRUSH --> O1["OSD primaire<br/>pve01"]
    O1 --> O2["OSD réplique<br/>pve02"]
    O1 --> O3["OSD réplique<br/>pve03"]

Le disque de VM est une image RBD dans le pool ceph-vm. librbd la découpe en objets de 4 Mo.
Chaque objet est rattaché à un PG par un simple calcul (hash du nom, modulo le nombre de PG du pool). Aucune base de données centrale.
CRUSH calcule, à partir de la carte du cluster et de la règle du pool, quels OSD hébergent ce PG : par défaut 3 OSD sur 3 hôtes différents.
Le client écrit sur l'OSD primaire, qui transmet aux répliques. L'écriture n'est acquittée à la VM qu'une fois toutes les copies actives écrites.

Conséquence : n'importe quel client peut calculer seul où se trouve une donnée. C'est ce qui permet à Ceph de grandir sans goulet d'étranglement.

PG et CRUSH en deux minutes¶

Notion	À retenir
Pool	Espace logique avec ses règles : nombre de copies (`size`/`min_size`), règle CRUSH, nombre de PG. Exemple : `ceph-vm` en réplica 3/2.
PG	Groupe d'objets qui voyagent ensemble. On réplique, déplace et vérifie des PG, pas des objets. Ordre de grandeur : 100 PG par OSD. L'autoscaler ajuste `pg_num`.
État d'un PG	`active+clean` = tout va bien. `degraded`, `undersized` = copies manquantes. `inactive` = données inaccessibles. Détail : PG inactive, degraded, inconsistent.
Carte CRUSH	Arbre : `root default` → `host pve01` → `osd.0`… On peut y ajouter des niveaux `rack`, `room`.
Règle CRUSH	« Choisir N OSD de classe `ssd` sous `default`, chacun dans un `host` différent. » Le failure domain (ici `host`) est l'unité qui ne doit jamais porter deux copies.
Classe de périphérique	`hdd`, `ssd`, `nvme`, détectée à la création de l'OSD. Permet de séparer pools rapides et lents.

graph TD
    R["root default"] --> H1["host pve01"]
    R --> H2["host pve02"]
    R --> H3["host pve03"]
    H1 --> A["osd.0 ssd"] & B["osd.1 ssd"]
    H2 --> C["osd.2 ssd"] & D["osd.3 ssd"]
    H3 --> E["osd.4 ssd"] & F["osd.5 ssd"]

Avec cette carte et une règle host, un PG du pool ceph-vm aura par exemple ses copies sur osd.1, osd.2 et osd.5 : une par hôte. Perdre pve02 entier ne fait perdre qu'une copie de chaque PG.

Recommandations MSP¶

Trois MON et au moins deux MGR, répartis sur trois nœuds différents. Ne pas ajouter de MON sur un 4e nœud (nombre pair inutile) ; passer à 5 MON à partir de 5 nœuds.
Pas de CephFS ni de MDS si vous n'en avez pas l'usage (ISO, partage de fichiers). Les VMs utilisent RBD.
Laisser l'autoscaler de PG et le balancer actifs. Toute modification de règle CRUSH passe par le MSP (voir Règles CRUSH).

Pièges vus en support

Confondre nœud et OSD : « 3 copies » signifie 3 hôtes différents, pas 3 disques. Avec 3 nœuds, chaque nœud porte une copie de toutes les données.
Croire qu'un MON en moins ne pose pas de problème : avec 2 MON sur 3 down, tout le stockage se fige même si tous les OSD sont sains.
Penser que CephFS est nécessaire pour stocker des VMs. Non : c'est RBD.
Créer des pools « pour ranger » (un par service) : chaque pool consomme des PG. Un pool ceph-vm suffit le plus souvent.

Testez-vous¶

Quel démon faut-il pour stocker des disques de VM : MDS ou OSD ?

Réponse

L'OSD. Le MDS ne sert qu'à CephFS. Les disques de VM sont des images RBD stockées par les OSD.
Sur un cluster de 3 nœuds avec 3 MON, combien de MON peuvent tomber sans bloquer les I/O ?

Réponse

Un seul. Le quorum exige une majorité (2 sur 3). Avec deux MON perdus, les clients ne peuvent plus obtenir de carte à jour et les I/O se bloquent.
Qui décide sur quel disque va une copie d'un objet ?

Réponse

L'algorithme CRUSH, calculé par le client et les OSD à partir de la carte CRUSH et de la règle du pool. Aucune table centrale n'est consultée.
Un OSD vient de tomber. Que fait Ceph si personne n'intervient ?

Réponse

Les PG concernés passent en degraded. Après 10 minutes (valeur par défaut de mon_osd_down_out_interval), l'OSD est marqué out et Ceph reconstruit les copies manquantes sur les autres OSD, en respectant le failure domain.