C'est l'étape qu'on a envie de sauter, et celle qui décide de la réussite de l'installation. Ceph est particulièrement exigeant sur trois points : la résolution des noms, l'horloge et les accès entre nœuds. Négliger l'un des trois, c'est passer une soirée à déboguer un cluster qui refuse de se former sans dire pourquoi.
Sans DNS dans le lab, la résolution passe par /etc/hosts — avec un nom distinct par réseau, ce qui est exactement ce que Ceph attend.
1. Les noms, avec une subtilité
Le lab n'a pas de serveur DNS : la résolution passe par /etc/hosts, identique sur les trois nœuds.
# LAB 192.168.50.31 vstock01 # réseau public 192.168.50.32 vstock02 192.168.50.33 vstock03 192.168.50.40 srvcli01 192.168.120.1 vstock01-sto # réseau cluster 192.168.120.2 vstock02-sto 192.168.120.3 vstock03-sto
Le point important : un nom distinct par réseau. Le suffixe -sto désigne l'interface de réplication. Cela évite l'ambiguïté classique — un nom qui résout vers le réseau public alors qu'on voulait le réseau cluster — et rend les diagnostics lisibles : un ping vstock02-sto qui échoue désigne immédiatement le réseau interne.
Le client, lui, ne connaît que les noms publics : il n'a rien à faire sur le réseau cluster, et ne doit surtout pas y accéder.
Chaque nom doit répondre depuis chaque nœud. Cette vérification fastidieuse — ping croisé sur les deux réseaux — est la seule façon de valider le câblage virtuel avant d'aller plus loin.
2. L'horloge, exigence non négociable
Ceph repose sur un quorum, des élections et des estampilles temporelles. Une dérive de quelques secondes entre nœuds suffit à provoquer des avertissements permanents, voire des élections en boucle. C'est pourquoi cephadm vérifie explicitement la synchronisation horaire avant d'accepter de démarrer — et refuse s'il ne la trouve pas.
apt install -y chrony systemctl is-active chrony
La règle est simple : les trois nœuds doivent utiliser la même source de temps. Sur un cluster isolé, cela suppose parfois de désigner un nœud comme serveur NTP local.
3. Les accès entre nœuds
cephadm déploie les démons sur les autres machines en s'y connectant en SSH. Il faut donc que cet accès existe. Dans le lab, la connexion root par SSH est autorisée le temps du déploiement :
# /etc/ssh/sshd_config PermitRootLogin yes
systemctl restart ssh
Un mot d'honnêteté sur ce point. Autoriser la connexion root par SSH est une facilité de lab. En production, on la restreint immédiatement : cephadm génère sa propre paire de clés — indépendante des clés personnelles — et l'on limite l'accès à cette clé, éventuellement avec une commande forcée. La bonne pratique consiste à revenir à PermitRootLogin prohibit-password dès le déploiement terminé, ce qui laisse fonctionner l'authentification par clé et ferme le mot de passe.
4. Les paquets prérequis
apt install -y cephadm podman chrony lvm2
- cephadm — l'outil d'orchestration ; c'est un script, pas le cluster ;
- podman — le moteur de conteneurs. Tous les démons Ceph tournent en conteneur : aucun binaire Ceph n'est installé sur le système, ce qui isole complètement le cluster de l'OS hôte et rend les mises à jour reproductibles ;
- lvm2 — indispensable à la création des OSD, qui s'appuient sur LVM pour préparer les disques ;
- chrony — l'horloge, déjà évoquée.
Les disques OSD doivent être vierges
Dernier prérequis, discret mais bloquant : Ceph n'accepte que des disques sans table de partition, sans système de fichiers, sans volume LVM résiduel. Sur un disque réutilisé, il faut le nettoyer explicitement — c'est une sécurité volontaire, personne n'a envie qu'un outil de stockage écrase un disque sans prévenir.
La check-list avant bootstrap
- chaque nœud résout et joint tous les autres, sur les deux réseaux ;
- les horloges sont synchronisées sur la même source ;
- l'accès SSH entre nœuds fonctionne ;
- podman, lvm2, chrony et cephadm sont installés partout ;
- les disques OSD sont vierges et visibles.
Cette liste paraît triviale. Elle correspond exactement aux vérifications que cephadm effectue de lui-même au démarrage — autant les avoir traitées avant.
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 :