Comprendre Ceph par la lecture a ses limites : c'est en montant un cluster, en débranchant un disque et en regardant la reconstruction que les concepts prennent corps. Voici le cadrage d'un lab complet — trois nœuds de stockage et un client — monté sur une seule machine avec KVM.
Ce que le lab doit permettre
- comprendre le fonctionnement de Ceph et ses prérequis réels ;
- dérouler une installation complète sur trois nœuds ;
- prendre en main l'administration par cephadm et son tableau de bord ;
- et surtout consommer le stockage depuis une quatrième machine — un volume bloc RBD et un montage CephFS.
Ce dernier point n'est pas anecdotique : un cluster de stockage qu'on n'a jamais monté depuis un client reste une abstraction.
L'architecture
Trois nœuds portant tous les rôles, un client de test, et deux réseaux séparés : le public pour les clients, l'autre réservé aux échanges internes du cluster.
Quatre machines virtuelles sous Ubuntu Server 24.04 :
- VSTOCK01, VSTOCK02, VSTOCK03 — 2 vCPU, 4 Gio de mémoire, un disque système de 15 Gio et deux disques de 10 Gio destinés aux OSD ;
- SRVCLI01 — le client de test, sans disque supplémentaire.
Deux disques OSD par nœud plutôt qu'un seul : c'est ce qui permet d'observer la répartition des données à l'intérieur d'un nœud, et de simuler la perte d'un disque sans perdre le nœud entier. Six OSD au total, ce qui est déjà représentatif.
Deux réseaux, et c'est fondamental
Chaque nœud de stockage a deux interfaces réseau :
- le réseau public (192.168.50.0/24) — les accès clients, les monitors, l'API, le tableau de bord, l'administration ;
- le réseau cluster (192.168.120.0/24) — réservé aux échanges internes : réplication, heartbeats, reconstruction, rééquilibrage.
Pourquoi cette séparation, alors qu'un seul réseau fonctionnerait ? Parce que le trafic interne de Ceph est massif et imprévisible. Une reconstruction après perte d'un disque peut saturer un lien pendant des heures. Si ce trafic partage le réseau des clients, la panne d'un disque dégrade tout le service — au moment précis où l'on aurait besoin que rien ne bouge. La séparation isole l'orage.
C'est une pratique standard en production, et le lab la reproduit délibérément : autant prendre l'habitude tout de suite.
Le plan d'adressage
réseau public réseau cluster VSTOCK01 192.168.50.31 192.168.120.1 VSTOCK02 192.168.50.32 192.168.120.2 VSTOCK03 192.168.50.33 192.168.120.3 SRVCLI01 192.168.50.40 — passerelle 192.168.50.254
Les adresses sont fixes : un nœud de stockage qui change d'adresse au gré d'un bail DHCP est une source d'ennuis garantie. La passerelle du réseau — réutilisée du lab Kubernetes — fournit l'accès à Internet nécessaire au téléchargement des paquets et des images de conteneurs.
La répartition des rôles
Le lab ne comporte aucun serveur maître : les rôles sont distribués et redondés.
- MON sur les trois nœuds — le quorum est garanti à 2 sur 3 ;
- MGR sur deux nœuds — un actif, un en veille ;
- OSD sur les six disques de données ;
- MDS sur un nœud, pour tester CephFS.
C'est la configuration minimale qui reste honnête vis-à-vis d'une architecture de production : à trois nœuds, on peut réellement perdre une machine et continuer de servir.
Ce qui vient ensuite
Trois étapes : construire l'infrastructure virtuelle (pool de stockage, réseau dédié, disques, machines), préparer les systèmes (résolution de noms, horloge, accès), puis initialiser le cluster avec cephadm et créer les OSD. C'est l'objet des articles suivants.
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 :