Installer Ceph a longtemps eu une réputation redoutable : des dizaines de paquets, des fichiers de configuration à recopier, des démons à déclarer un par un. cephadm a changé cela — une seule commande crée le cluster, et tout le reste se pilote ensuite de façon déclarative.
Ce que cephadm est, et n'est pas
cephadm est l'outil officiel d'administration de Ceph. Il assure l'initialisation du cluster, le déploiement des démons, le cycle de vie complet — ajout, suppression, mise à jour — et l'orchestration des services.
Sa particularité : tous les composants Ceph tournent en conteneurs, gérés par podman. Aucun binaire Ceph n'est installé sur le système d'exploitation. Trois conséquences très concrètes :
- le cluster est isolé de l'hôte : pas de conflit de bibliothèques, pas de dépendance à la distribution ;
- la version est verrouillée et reproductible — l'image du conteneur fait foi ;
- une mise à jour consiste à changer d'image, démon par démon, sans interruption de service.
cephadm agit aussi comme un orchestrateur : on décrit les services voulus, il place les démons, les redéploie s'ils tombent, et maintient l'état demandé. La démarche est la même que celle de Kubernetes, appliquée au stockage.
Le bootstrap, décortiqué
Une seule commande : vérifications, création de l'identité du cluster, du premier monitor, du manager, puis déploiement de la stack de supervision et du tableau de bord.
cephadm bootstrap \ --mon-ip 192.168.50.31 \ --cluster-network 192.168.120.0/24 \ --allow-fqdn-hostname
Trois options, trois décisions : où démarre le premier monitor, quel réseau est réservé aux échanges internes, et l'autorisation d'utiliser des noms pleinement qualifiés.
Ce que la commande enchaîne ensuite mérite d'être lu, car chaque étape correspond à un prérequis :
- Vérifications — présence de podman, de lvm2, et synchronisation horaire. Sans NTP fiable, cephadm refuse de continuer.
- Identité du cluster — génération du fsid, identifiant unique qui distingue ce cluster de tous les autres et se retrouve partout : chemins, conteneurs, configuration.
- Validation réseau — les ports du monitor (3300 et 6789) sont-ils libres ? L'adresse annoncée appartient-elle bien au réseau public ?
- Récupération de l'image — le conteneur Ceph est téléchargé, sa version affichée. C'est elle qui sera utilisée partout.
- Création des clés et du premier MON — trousseaux fondamentaux, carte des monitors, démarrage. Le cluster existe à cet instant précis.
- Configuration minimale — le fichier
ceph.confest écrit avec les deux réseaux, ainsi que le trousseau administrateur. - Manager — déployé dans la foulée : c'est lui qui portera l'orchestration et le tableau de bord.
- Activation de cephadm — le module est activé, l'orchestrateur devient le pilote officiel du cluster.
- Clés SSH — cephadm génère sa propre paire, indépendante des clés personnelles. C'est ce mécanisme qui lui permettra d'ajouter les autres nœuds.
- Services annexes — Prometheus, Grafana, node-exporter, alertmanager : une supervision complète est déployée d'office, sans rien demander.
- Tableau de bord — activé, avec un certificat auto-signé et un compte administrateur dont le mot de passe est affiché à l'écran. À changer immédiatement.
Le piège des droits sur les disques
Un obstacle mérite d'être signalé, parce qu'il est déroutant et pas si rare. Les OSD sont créés depuis un conteneur, par un utilisateur interne d'UID/GID 167. Si, sur l'hôte, les disques appartiennent à un groupe que cet utilisateur ne possède pas, la création échoue sur un laconique Permission denied — parfois en boucle, avec des annulations successives.
La parade consiste à aligner les droits de l'hôte sur ce que le conteneur attend : créer un groupe portant le GID 167, puis une règle udev qui attribue à ce groupe les disques destinés aux OSD et les périphériques LVM associés.
groupadd -g 167 ceph-cont
# /etc/udev/rules.d/99-ceph-osd.rules
SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", KERNEL=="vd[b-z]", GROUP="ceph-cont", MODE="0660"
SUBSYSTEM=="block", KERNEL=="dm-*", ENV{DM_VG_NAME}=="ceph-*", GROUP="ceph-cont", MODE="0660"
udevadm control --reload-rules && udevadm trigger
Passer par udev plutôt que par un chown manuel est ce qui rend le réglage durable : les droits sont réappliqués à chaque apparition du périphérique, donc à chaque redémarrage.
Étendre la grappe depuis le tableau de bord
cephadm découvre les autres nœuds, y déploie ses clés et ses démons : l'ajout d'un hôte se fait en quelques clics ou une commande.
Une fois le premier nœud opérationnel, l'assistant « développer la grappe » du tableau de bord prend le relais : ajout des hôtes, choix des services à déployer, puis création des OSD à partir des disques disponibles. La même chose s'écrit en ligne de commande — ceph orch host add, ceph orch apply osd --all-available-devices — et c'est là que le côté déclaratif prend tout son sens : on décrit ce qu'on veut, cephadm s'occupe du reste.
Un OSD par disque : les six disques des trois nœuds deviennent six OSD, et la capacité du cluster apparaît.
Et ensuite, la supervision offerte
État de santé, capacité utilisée, débit et opérations par seconde : la supervision est déployée par le bootstrap, sans configuration supplémentaire.
C'est l'un des bénéfices les moins mis en avant de cephadm : la pile de supervision est déjà là. Santé du cluster, capacité, débit, latence, état de chaque OSD — tout est visible dès le premier jour, sans avoir à monter quoi que ce soit.
Restent deux gestes d'hygiène immédiats : changer le mot de passe administrateur affiché au bootstrap, et ne pas exposer le tableau de bord au-delà du réseau d'administration — il est servi en HTTPS avec un certificat auto-signé, ce qui protège le transport mais ne remplace pas un contrôle d'accès.
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 :