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.

🔒 Bonnes pratiques pour un environnement de production

🛡️ Note de sécurité :

Dans cette documentation, l'accès SSH est effectué directement avec l'utilisateur root pour faciliter le déploiement dans un environnement de test ou de lab.

En production, il est recommandé de :

• Créer un utilisateur dédié, par exemple cephadmin.

• Lui accorder les droits sudo sans mot de passe pour les commandes nécessaires :

  visudo
  cephadmin ALL=(ALL) NOPASSWD:ALL

• Donner à cet utilisateur des ACLs ( package ACL installé au préalable ) spécifiques sur /etc/ceph/ :

  setfacl -R -m u:cephadmin:rwx /etc/ceph

• Restreindre l'accès SSH (par clé uniquement, fail2ban, IP source, etc.)

👉 Cela renforce la sécurité, tout en permettant à cephadm de fonctionner correctement sans ouvrir totalement l'accès root.

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.

• --initial-dashboard-password → mot de passe de l'UI

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

3.3 Copier la clé ceph.pub dans le répertoire /etc/ceph/ depuis ceph-node1 ( 192.168.10.11 )

for node in ceph-node2 ceph-node3 ceph-node4
do 
    scp /etc/ceph/ceph.pub "root@$node:/etc/ceph/ceph.pub" || echo "Failed for $node"
done

Pour un environnement de prod, avec un user dédié ( par exemple cephadmin )

for node in ceph-node2 ceph-node3 ceph-node4
do 
    sudo scp /etc/ceph/ceph.pub "cephadmin@$node:/etc/ceph/ceph.pub" || echo "Failed for $node"
done

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

Pour se connecter tapez l'ip d'un noeud en web sur le port 8443 . Vous serez redirigé vers le moniteur

Le username et le mdp sont ceux définis lors du boostrap

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)

1. 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.

2. 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)

1. 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

1. 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

Je précise que CloudStack est mentionné car cette documentation est en corrélation avec celle concernant les nœuds KVM d'Apache CloudStack et leur intégration avec Ceph pour le stockage primaire. Lien vers ladite documentation

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.

1. 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

1. Créer le pool :

ceph osd pool create prm-strg1 512

Ne pas tenir compte de mon undersized sur mon dashboard ( j'ai crash des osd pour des tests )

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