CEPH

Déployer un cluster Ceph avec cephadm (Rocky Linux)

📘 Déploiement d’un cluster Ceph avec `cephadm` (Rocky Linux 9)

Ceph est un système de stockage distribué open-source conçu pour fournir un stockage d'objets, de blocs et de fichiers hautement évolutif et performant. Il utilise une architecture décentralisée avec des nœuds autonomes pour assurer la résilience, la scalabilité et la gestion automatique des données.

Documentation offcielle

Objectif

Fournir un stockage primaire haute disponibilité à un cloud (ex. Apache CloudStack) en déployant un cluster Ceph sur 4 nœuds, avec séparation des trafics public et cluster pour optimiser performances et sécurité.

A savoir

📘 Explication des daemons Ceph

Daemon

Rôle

MON

Gérer la carte du cluster et le quorum.

Requis : 3 MONs minimum.

MGR

Fournir les métriques, orchestrer les services, gérer l’interface web.

Recommandé : 2 MGR (1 actif + 1 standby).

OSD

Gérer les blocs physiques (1 OSD = 1 disque brut). Réplication automatique des données.

MDS

Gérer les métadonnées du système de fichiers CephFS

RGW

Fournir une interface compatible S3 pour le stockage objet.

Public Network

Réseau utilisé pour les communications entre les clients (applications, utilisateurs) et les services Ceph (comme les monitors, OSD, et RGW). Il transporte les requêtes des clients et les données lues/écrites. Exemple : réseau accessible pour les opérations de stockage.

Cluster Network

Réseau interne dédié aux communications entre les nœuds du cluster Ceph, principalement pour la réplication des données, la synchronisation des OSD, et la récupération (rebalancing). Il est conçu pour être isolé et optimisé pour un trafic interne intensif.

1. Prérequis matériels et réseau

4 nœuds physiques ou VMs Rocky Linux 9
Sur chaque nœud :
- 1 disque système (32 Go) → installation de l’OS
- 3 disques de données (200 Go chacun) → destinés aux OSD Ceph
Deux interfaces réseau par nœud :
- eth0 → réseau public (accès API, clients) – exemple : 192.168.10.0/24
- eth1 → cluster network (backend Ceph, réplication, heartbeat) – exemple : 10.0.0.0/24

Pourquoi deux réseaux ?

Séparer le trafic client (lectures/écritures RBD) du trafic interne Ceph (réplication entre OSD, échanges MON/MGR) améliore la performance et la stabilité.

2. Préparer chaque nœud

2.1 Installer les paquets nécessaires

sudo dnf update -y
sudo dnf install -y epel-release chrony curl lvm2
sudo systemctl enable --now chronyd

chrony → synchroniser l’heure sur tous les nœuds (critique pour Ceph).
lvm2 → nécessaire si l’on veut partitionner ou gérer les disques OSD en LVM (optionnel).

2.2 Configurer la résolution des noms

Ajouter dans /etc/hosts sur chacun des 4 nœuds :

192.168.10.11 ceph-node1
192.168.10.12 ceph-node2
192.168.10.13 ceph-node3
192.168.10.14 ceph-node4

Permettre à chaque nœud de résoudre les autres par nom, simplifiant la configuration Ceph.

2.3 Activer SSH sans mot de passe

Sur ceph-node1, générer une clé SSH et la distribuer :

ssh-keygen -t ed25519
ssh-copy-id root@ceph-node2
ssh-copy-id root@ceph-node3
ssh-copy-id root@ceph-node4

Faciliter l’orchestration automatisée de Ceph via cephadm.

3. Initialiser le cluster Ceph (`cephadm bootstrap`)

Doc officielle : 1 - 2

3.1 Installer `cephadm`

sudo dnf install -y cephadm

3.2 Lancer le bootstrap

sudo cephadm bootstrap \
  --mon-ip 192.168.10.11 \
  --cluster-network 10.0.0.0/24 \
  --initial-dashboard-user admin \
  --initial-dashboard-password monMdpSecurise

--mon-ip → IP du premier MON sur le réseau public.
--cluster-network → plage IP dédiée au trafic backend Ceph.
Dashboard → interface web activée dès le départ.

Le premier MON (monitor) et le MGR (manager) sont créés automatiquement sur ceph-node1.

4. Ajouter les autres nœuds au cluster

sudo cephadm shell

ceph orch host add ceph-node2 192.168.10.12
ceph orch host add ceph-node3 192.168.10.13
ceph orch host add ceph-node4 192.168.10.14

Entrer dans le container Ceph pour exécuter les commandes d’orchestration.
orch host add → enregistrement des nœuds au sein de l’orchestrateur Ceph.

5. Gérer les labels (facultatif mais recommandé)

5.1 Ajouter un label à un nœud

ceph orch host label add ceph-node1 mon
ceph orch host label add ceph-node2 mon
ceph orch host label add ceph-node3 mon

ceph orch host label add ceph-node1 mgr
ceph orch host label add ceph-node2 mgr

ceph orch host label add ceph-node1 osd
ceph orch host label add ceph-node2 osd
ceph orch host label add ceph-node3 osd
ceph orch host label add ceph-node4 osd

ceph orch host label add ceph-node1 _admin
ceph orch host label add ceph-node2 _admin
ceph orch host label add ceph-node3 _admin
ceph orch host label add ceph-node4 _admin

Labels : regrouper les hôtes par rôle (mon, mgr, osd…) pour simplifier les déploiements.

Le label _admin permet d'avoir le keyring CEPH et pouvoir administrer le cluster

6. Déployer les daemons Ceph

6.1 Méthode A – avec labels

# Déployer tous les MONs d’un coup selon leur label
ceph orch apply mon --placement=label:mon

# Déployer les MGRs
ceph orch apply mgr --placement=label:mgr

# OSDs (tous les disques disponibles)
ceph orch apply osd --all-available-devices --placement=label:osd

6.2 Méthode B – manuelle (sans labels)

# MON
ceph orch daemon add mon ceph-node1
ceph orch daemon add mon ceph-node2
ceph orch daemon add mon ceph-node3

# MGR
ceph orch daemon add mgr ceph-node1
ceph orch daemon add mgr ceph-node2

# OSD (3 disques par nœud)
ceph orch daemon add osd ceph-node1:/dev/sdb
ceph orch daemon add osd ceph-node1:/dev/sdc
ceph orch daemon add osd ceph-node1:/dev/sdd
# Répéter pour node2 à node4 en ajotant bien les 3 disques qui serviriont à ceph sdb, sdc et sdd

6.2.3 Déployer OSDs en séparant WAL/DB ( facultatif mais très good )

📘 Rôle du WAL et de la DB (Bluestore)

DB (RocksDB)
- Stocker les métadonnées des objets Ceph : index key→emplacement.
- Permettre des lectures rapides et efficaces dans la base de données interne.
WAL (Write-Ahead Log)
- Journaliser toutes les écritures avant de les confirmer.
- Accélérer la latence d’écriture en absorbant rapidement chaque transaction.
- Garantir la durabilité même en cas de crash, avant d’écrire définitivement les données dans l’OSD.

Sans SSD dédié pour WAL/DB, Ceph place ces deux zones sur le même disque Bluestore de l’OSD, ce qui reste fonctionnel mais moins performant.

Notez que la syntaxe peut changer en fonction de la version de ceph installée ( Quincy, Reef, Pacific, squid, ou les plus récentes)

Lister les disques

S'assurer d'avoir un disque SSD de dispo au moins par noeud. Le seul disque peut etre partitionné pour avoir une de ses partitions en WAL et l'autre en DB

Sinon avoir deux SSD, un por WAL et l'autre pour DB ( ce qui sera le cas dans cet exemple )

ceph orch device ls ceph-node1

Ajouter chaque disque OSD en séparant les disque de datas ( sdb,sdc,sdd, ) et les disques pour Wal et DB

ceph orch daemon add osd ceph-node1:data_devices=/dev/sdb,/dev/sdc,/dev/sdd,wal_devices=/dev/nvme0n1,db_devices=/dev/nvme1n2
ceph orch daemon add osd ceph-node2:data_devices=/dev/sdb,/dev/sdc,/dev/sdd,wal_devices=/dev/nvme0n1,db_devices=/dev/nvme1n2
ceph orch daemon add osd ceph-node3:data_devices=/dev/sdb,/dev/sdc,/dev/sdd,wal_devices=/dev/nvme0n1,db_devices=/dev/nvme1n2
ceph orch daemon add osd ceph-node4:data_devices=/dev/sdb,/dev/sdc,/dev/sdd,wal_devices=/dev/nvme0n1,db_devices=/dev/nvme1n2

7. Créer le pool RBD pour CloudStack

Placement Groups (PG) dans Ceph : Unités logiques qui organisent les objets de données, les répartissent sur les OSD (disques) via l'algorithme CRUSH(Controlled Replication Under Scalable Hashing) , et gèrent la réplication pour assurer résilience et performance dans un cluster Ceph.

Calculer le nombre de Placement Groups (PG) :

PG ≈ (Total OSDs × 100) / Réplication 
   = (12 × 100) / 3 
   = 400 PG

Choix final du PG

Arrondir à la puissance de deux supérieure la plus proche → 512 PG
Les puissances de deux facilitent la répartition uniforme des objets dans le cluster.
Le PG est donc de 512

Créer le pool :

ceph osd pool create cloudstack-primary 512

8. Vérifier le fonctionnement

ceph -s                  # état global
ceph health detail       # détails sur les problèmes
ceph osd tree            # arborescence des OSD/MON
ceph df                  # utilisation du stockage
ceph orch ps             # statut des daemons orchestrés

9. Activer le dashboard (optionnel)

ceph mgr module enable dashboard
ceph dashboard create-self-signed-cert
ceph dashboard set-login-credentials admin monMdpSecurise

Accéder à : https://<ceph-node1>:8443
Consulter les métriques, la santé du cluster et les logs.

10. Ouverture – CephFS et MDS

Objectif : partager un filesystem distribué (NAS) via Ceph.
Daemon MDS (Metadata Server) : gérer les métadonnées POSIX (arborescence, permissions).

Déploiement :

ceph orch apply mds --placement=label:mds --active-count 2
ceph fs volume create myfs

Montage :

mkdir /mnt/cephfs
mount -t ceph 192.168.10.11:/ /mnt/cephfs -o name=admin,secretfile=/etc/ceph/admin.secret

🔍 Commandes de debug

Commande

Description

ceph health detail

Afficher toutes les alertes et warnings

ceph osd crush tree

Visualiser la topologie CRUSH (OSD via racks, hosts)

ceph orch device ls

Lister tous les disques physiques détectés

ceph orch host ls --label osd

Lister les hôtes portant un label “osd”

ceph mgr services

Vérifier les services MGR actifs

ceph daemon <type>.<id> config show

Afficher la config d’un daemon spécifique

ceph debug monconfig <host>

Debug du config MON

journalctl -u ceph-\*

Logs système pour tous les services Ceph

ceph -s

Etat général du cluster

PreviousPartitionnement LVM NextPostgreSQL

Last updated 5 days ago

Was this helpful?