¶ 4. Installation de CEPH ADM
Cette section s'attache à l'installation et à la mise en fonctionnement de CEPH ADM.
¶ 4.1. Installation des packages
- Installer sur les trois noeuds les paquets suivants :
root@vstock01:~# apt install -y cephadm podman chrony lvm2
root@vstock02:~# apt install -y cephadm podman chrony lvm2
root@vstock03:~# apt install -y cephadm podman chrony lvm2¶ 4.2. Initialisation du cluster CEPH
- Sur VSTOCK01 (uniquement), saisir la commande permettant l'instanciation de CEPH ADM
root@vstock01:~# cephadm bootstrap \
--mon-ip 192.168.50.31 \
--cluster-network 192.168.120.0/24 \
--allow-fqdn-hostname
- L'installation se déroule et donne les premières informations de connexion à la plateforme CEPH:
URL: https://vstock01:8443/
User: admin
Password: ***********¶ 4.3. Que fait cette commande ?
¶ La commande elle-même
cephadm bootstrap \
--mon-ip 192.168.50.31 \
--cluster-network 192.168.120.0/24 \
--allow-fqdn-hostname
¶ Ce qui est explicitement demandé
- Démarrer le premier MON sur
vstock01 - Séparer réseau public / cluster
- Autoriser les noms FQDN (sinon Ceph fait la police)
¶ Phase 1 — Vérifications préalables (sanity checks)
Verifying podman|docker is present...
Verifying lvm2 is present...
Verifying time synchronization is in place...
Cephadm vérifie que la machine peut physiquement héberger un cluster Ceph.
¶ Concrètement
- Runtime conteneur → obligatoire
lvm2→ indispensable pour les OSD plus tard- Synchronisation horaire → critique (quorum, élections, logs)
Unit chrony.service is enabled and running
Sans NTP fiable, Ceph refuse d’être sérieux.
¶ Phase 2 — Revalidation finale du nœud
Repeating the final host check...
podman (/usr/bin/podman) version 4.9.3 is present
systemctl is present
lvcreate is present
Host looks OK
Cephadm refait les checks juste avant de s’engager.
¶ Phase 3 — Création de l’identité du cluster
Cluster fsid: 32ccad64-e3d7-11f0-9ce0-525400aa7819
C’est l’ADN du cluster :
- Identifiant unique mondial
- Sert à distinguer les clusters entre eux
- Utilisé partout (chemins, containers, orchestration)
¶ Phase 4 — Validation réseau MON
Verifying IP 192.168.50.31 port 3300 ...
Verifying IP 192.168.50.31 port 6789 ...
Ceph vérifie que :
- Le MON pourra écouter sur ses ports
- Rien ne bloque (firewall, service déjà présent)
Mon IP `192.168.50.31` is in CIDR network `192.168.50.0/24`
Il confirme que ton --mon-ip est cohérent.
¶ Phase 5 — Récupération de Ceph (conteneur)
Pulling container image quay.io/ceph/ceph:v19...
Ceph version: 19.2.3 squid (stable)
Important :
- Aucun binaire Ceph n’est installé sur l’OS
- Tout tourne en conteneur
- Version verrouillée et reproductible
¶ Phase 6 — Création des clés et du MON initial
Creating initial keys...
Creating initial monmap...
Creating mon...
Ici, Ceph :
- Génère les keyrings fondamentaux
- Crée la monmap (liste des MON connus)
- Lance le tout premier MON
Waiting for mon to start...
mon is available
Le cluster existe officiellement à cet instant précis.
¶ Phase 7 — Génération du ceph.conf minimal
Generating new minimal ceph.conf...
Setting public_network to 192.168.50.0/24
Setting cluster_network to 192.168.120.0/24
Ceph écrit la vérité officielle du cluster :
- Réseau public → clients + MON + MGR
- Réseau cluster → réplication OSD (plus tard)
Wrote config to /etc/ceph/ceph.conf
Wrote keyring to /etc/ceph/ceph.client.admin.keyring
Le cluster est accessible.
¶ Phase 8 — Création du MGR
Creating mgr...
Waiting for mgr...
mgr is available
Le Manager :
- Orchestration
- Dashboard
- Cephadm
- Monitoring
- Modules dynamiques
¶ Phase 9 — Activation de cephadm dans Ceph
Enabling cephadm module...
Setting orchestrator backend to cephadm...
Ceph devient auto-orchestré :
Ceph ADM contrôle désormais :
- MON
- MGR
- OSD
- services annexes
¶ Phase 10 — Gestion SSH Ceph → hôtes
Generating ssh key...
Adding key to root@localhost authorized_keys...
Adding host vstock01...
Ceph génère sa propre clé SSH :
- Utilisée pour déployer des services
- Sans dépendre de tes clés perso
- Scoped au cluster
C’est ce mécanisme qui permettra d’ajouter vstock02, vstock03.
¶ Phase 11 — Déploiement automatique des services
Deploying mon service...
Deploying mgr service...
Deploying crash service...
Deploying prometheus service...
Deploying grafana service...
Deploying node-exporter service...
Deploying alertmanager service...
Cephadm met en place:
- Stack de monitoring clé en main
- Observabilité native
- Rien d’obligatoire, mais tout est prêt
¶ Phase 12 — Dashboard Ceph
Enabling the dashboard module...
Generating a dashboard self-signed certificate...
Creating initial admin user...
Résultat :
URL: https://vstock01:8443/
User: admin
Password: ********
L'Interface graphique est opérationnelle immédiatement :
- Visualisation cluster
- OSD, pools, alertes
- Actions d’admin
¶ 4.4. — Pré-requis OSD : alignement des droits /dev (fix UID/GID Podman/Ceph)
¶ Pourquoi cette étape existe
Avec cephadm, la création d’OSD est orchestrée via podman en lançant ceph-volume dans un conteneur.
Pendant la phase de création BlueStore (ceph-osd --mkfs), l’accès au device block (ex: /dev/vdb) et aux devices LVM/device-mapper (/dev/dm-*) est fait en tant que user ceph dans le conteneur (typiquement UID/GID 167:167).
Si, sur l’hôte :
/dev/vdb appartient à root:disk (GID 6) mais que dans le conteneur ce groupe ne matche pas (ou que ceph n’en est pas membre),
ou si les /dev/dm-* sortent avec un groupe non accessible,
alors on obtient :
open got: (13) Permission denied pendant mkfs,
ou des zaps qui échouent / rollback en boucle.
¶ Objectif
Donner au conteneur Ceph un accès fiable aux disques OSD et aux mappings LVM, en alignant le groupe hôte sur le GID attendu par le conteneur.
¶ 4.4.1 — Créer un groupe hôte au même GID que “ceph” dans le conteneur
Sur chaque nœud qui hébergera des OSD (vstock01/02/03) :
# Vérifier si le GID 167 est libre
getent group 167 || true
# Créer un groupe hôte portant le GID 167 (nom libre)
groupadd -g 167 ceph-cont
getent group ceph-cont
Le nom
ceph-contest arbitraire. Ce qui compte, c’est GID=167.
¶ 4.4.2 — Règles udev pour attribuer les disques OSD et dm-* au groupe GID 167
Créer les règles udev (sur chaque nœud) :
tee /etc/udev/rules.d/99-ceph-osd.rules >/dev/null <<'EOF' # Disques data (virtio / scsi) destinés aux OSD
SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", KERNEL=="vd[b-z]", GROUP="ceph-cont", MODE="0660"
SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", KERNEL=="sd[b-z]", GROUP="ceph-cont", MODE="0660"
# Device-mapper/LVM utilisés par ceph-volume (VG/LV "ceph-*", "osd-block-*")
SUBSYSTEM=="block", KERNEL=="dm-*", ENV{DM_VG_NAME}=="ceph-*", GROUP="ceph-cont", MODE="0660"
SUBSYSTEM=="block", KERNEL=="dm-*", ENV{DM_LV_NAME}=="osd-block-*", GROUP="ceph-cont", MODE="0660"
EOF
Recharger et appliquer :
udevadm control --reload-rules
udevadm trigger
Vérifier :
ls -l /dev/vdb
# attendu : ... ceph-cont en groupe (gid 167)
¶ 4.4.3 — Test rapide “réalité terrain” depuis un conteneur Ceph (optionnel mais très rassurant)
On valide que l’UID/GID 167 peut lire le disque :
podman run --rm --privileged \
--security-opt apparmor=unconfined \
-v /dev:/dev \
--user 167:167 \
quay.io/ceph/ceph:v19.2.3 \
bash -lc 'id; ls -l /dev/vdb; dd if=/dev/vdb of=/dev/null bs=1M count=1 status=none; echo "OK dd as 167:167"'
¶ 4.4.4 — Notes importantes
Cette étape est surtout utile en lab / VM où les devices sont simples (/dev/vdb, /dev/vdc, etc.).
Sur une infra plus “prod”, on peut préférer une approche plus stricte (filtrer par ID_SERIAL, WWN, paths /dev/disk/by-id/...).
¶ 4.5. Récupération et partage de la clef CEPH avec les noeuds VSTOCK02 et VSTOCK03
- Sur VSOTCK01, saisir la commande et copier la clef :
root@vstock01:~# ceph cephadm get-pub-key
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCzjcuslezVFpbS/690UTvaJD9HiP6Sv3hYD91wVvBgDfWJxIALjhGyj9aWkKaXp2T9Oqqw+zaHuQ2/wtJkpBSf0rvZnXdLlncCwEbdyWaoDORKOeHkyLdzHfNwa3rpgg17UZ8Uy5p2YyiDwsOWUt/f2GlrCXIpHs5THTaK3lilHvyaG5Vy4aPTcv5+r3/mb/AcxYCUyxvn8180OKtbqtp7cqW2ONlS5Dz4blqm1Z3Fk/sNugl02U4OZa4dMhGK+GHaBIjFd0T+wCouI3LfAObDfAHJBEQbIPjPWI6u3UWiiP45Jqa4YuZVndSkVnmhoBJBuDn3cErLEH8qbb5Oj71DqZsWiunzh1W7wO6pcJoStIlsJ+X7cN/Zo8VQv/aKBICDj6EJZJpMcbJqKc+Ly0qGYD8iAWgStEiSUvALySRfNrDX7XvIJJZKgF4w+LC+/Ust4M7MVZsau0oqr+iyAsEiEoFpEwHBa0dd0vvuO0EmPdEwkQVpg/pkIe5u5lKCezc= ceph-32ccad64-e3d7-11f0-9ce0-525400aa7819
- Sur VSTOCK02 et VSTOCK03, éditer le fichier /root/.ssh/authorized_keys et ajouter la clef :
root@vstock02:~# vim /root/.ssh/authorized_keys
root@vstock02:~# cat /root/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ2OHo7DZAcqh5jjlvhMWdsLvT591oMjiPL3zA7MfucZ root@vstock01
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILVHnFm7LJ8w8qrFxsPlNUBzEB5FPh+iuyvq66srl9uh root@vstock03
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCzjcuslezVFpbS/690UTvaJD9HiP6Sv3hYD91wVvBgDfWJxIALjhGyj9aWkKaXp2T9Oqqw+zaHuQ2/wtJkpBSf0rvZnXdLlncCwEbdyWaoDORKOeHkyLdzHfNwa3rpgg17UZ8Uy5p2YyiDwsOWUt/f2GlrCXIpHs5THTaK3lilHvyaG5Vy4aPTcv5+r3/mb/AcxYCUyxvn8180OKtbqtp7cqW2ONlS5Dz4blqm1Z3Fk/sNugl02U4OZa4dMhGK+GHaBIjFd0T+wCouI3LfAObDfAHJBEQbIPjPWI6u3UWiiP45Jqa4YuZVndSkVnmhoBJBuDn3cErLEH8qbb5Oj71DqZsWiunzh1W7wO6pcJoStIlsJ+X7cN/Zo8VQv/aKBICDj6EJZJpMcbJqKc+Ly0qGYD8iAWgStEiSUvALySRfNrDX7XvIJJZKgF4w+LC+/Ust4M7MVZsau0oqr+iyAsEiEoFpEwHBa0dd0vvuO0EmPdEwkQVpg/pkIe5u5lKCezc= ceph-32ccad64-e3d7-11f0-9ce0-525400aa7819
root@vstock03:~# vim /root/.ssh/authorized_keys
root@vstock03:~# cat /root/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ2OHo7DZAcqh5jjlvhMWdsLvT591oMjiPL3zA7MfucZ root@vstock01
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILOTcYp5KMJadriCtEZNyTzLlZW9E8sqqm51agk9OHgh root@vstock02
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCzjcuslezVFpbS/690UTvaJD9HiP6Sv3hYD91wVvBgDfWJxIALjhGyj9aWkKaXp2T9Oqqw+zaHuQ2/wtJkpBSf0rvZnXdLlncCwEbdyWaoDORKOeHkyLdzHfNwa3rpgg17UZ8Uy5p2YyiDwsOWUt/f2GlrCXIpHs5THTaK3lilHvyaG5Vy4aPTcv5+r3/mb/AcxYCUyxvn8180OKtbqtp7cqW2ONlS5Dz4blqm1Z3Fk/sNugl02U4OZa4dMhGK+GHaBIjFd0T+wCouI3LfAObDfAHJBEQbIPjPWI6u3UWiiP45Jqa4YuZVndSkVnmhoBJBuDn3cErLEH8qbb5Oj71DqZsWiunzh1W7wO6pcJoStIlsJ+X7cN/Zo8VQv/aKBICDj6EJZJpMcbJqKc+Ly0qGYD8iAWgStEiSUvALySRfNrDX7XvIJJZKgF4w+LC+/Ust4M7MVZsau0oqr+iyAsEiEoFpEwHBa0dd0vvuO0EmPdEwkQVpg/pkIe5u5lKCezc= ceph-32ccad64-e3d7-11f0-9ce0-525400aa7819¶ 4.6. Ajout des noeuds VSTOCK02 et VSTOCK03
- Sur VSTOCK01, saisir la commande d'ajout des noeuds VSTOCK02 et VSTOCK03 :
root@vstock01:~# ceph orch host add vstock02 192.168.50.32
root@vstock01:~# ceph orch host add vstock02 192.168.50.32
Added host 'vstock02' with addr '192.168.50.32'
root@vstock01:~# ceph orch host add vstock03 192.168.50.33
root@vstock01:~# ceph orch host add vstock03 192.168.50.33
Added host 'vstock03' with addr '192.168.50.33'¶ 4.7. Première connexion à l'interface
- Dans un navigateur, se connecter à l'adresse :
https://192.168.50.31:8443(Adresse de VSTOCK01).
- Saisir le mot de passe temporaire, puis changer le mot de passe.
- La plateforme est maintenant accessible