Ceph : déployer un stockage distribué unifié

Ceph est le système de stockage distribué open source le plus complet : un seul cluster fournit du stockage objet (compatible S3), bloc (RBD) et fichier (CephFS). Conçu pour n’avoir aucun point de défaillance unique, il réplique les données automatiquement grâce à l’algorithme CRUSH. Ce guide vous accompagne du bootstrap d’un cluster 3 nœuds à l’utilisation des trois types de stockage, avec toutes les commandes testées sur Ubuntu 24.04.

Ce que vous allez apprendre

• Architecture Ceph : RADOS, MON, OSD, MGR, MDS et algorithme CRUSH
• Trois types de stockage : objets RADOS, blocs RBD, fichiers CephFS
• Lab complet : déployer un cluster 3 nœuds avec KVM et cephadm
• Commandes essentielles : créer des pools, des images bloc, un CephFS
• Monitoring : dashboard intégré, Grafana, Prometheus
• Dépannage et bonnes pratiques : diagnostic, sécurité, performance

Version actuelle

Ce guide utilise Ceph Squid 19.2.3 (stable, maintenu jusqu’à ~septembre 2026). La version Tentacle 20.2.0 est sortie en novembre 2025 (maintenue jusqu’à ~novembre 2027). Nouveautés de Squid : BlueStore optimisé pour les snapshots, compression LZ4 par défaut dans RocksDB, améliorations CephFS snapshot/clone, nouvelles API IAM compatibles AWS pour RGW. Calendrier complet : docs.ceph.com/en/latest/releases.

Qu’est-ce que Ceph ?

Ceph est un système de stockage distribué open source créé en 2004 par Sage Weil dans le cadre de sa thèse de doctorat à l’UC Santa Cruz. Il est conçu pour fournir d’excellentes performances, fiabilité et scalabilité sur du matériel standard.

Analogie : imaginez un entrepôt logistique géant avec des dizaines de hangars (les OSD). Un système intelligent (l’algorithme CRUSH) détermine dans quels hangars stocker chaque colis et crée automatiquement des copies dans d’autres hangars. Des superviseurs (MON) surveillent l’état de chaque hangar, et un tableau de bord (MGR) donne une vue d’ensemble en temps réel. Le tout sans chef central : si un hangar brûle, les colis restent accessibles depuis les copies dans les autres hangars.

Ce qui distingue Ceph

Caractéristique	Description
Stockage unifié	Objets (S3/Swift), blocs (RBD) et fichiers (CephFS) dans un seul cluster
Algorithme CRUSH	Placement des données sans serveur de métadonnées central pour les objets
Auto-réparation	Re-réplication automatique après panne d’un OSD
Scalabilité	De quelques nœuds à des exaoctets sur des milliers de serveurs
Conteneurisé	Déploiement via cephadm avec Docker/Podman
Open source	Licence LGPL 2.1/3.0, maintenu par la fondation Ceph (Linux Foundation)

Glissez pour voir

Ceph vs alternatives

Critère	Ceph	GlusterFS	MinIO	NFS classique
Types de stockage	Objet + Bloc + Fichier	Fichier	Objet (S3)	Fichier
Complexité	Élevée	Modérée	Faible	Très faible
Scalabilité	Exaoctets	Pétaoctets	Pétaoctets	Limité
Cas d’usage idéal	Cloud privé complet	Stockage partagé	Stockage S3	Partages simples
Métadonnées	MON + MDS (CephFS)	Distribuées (DHT)	Distribuées	Centralisées
Intégration Kubernetes	Rook (natif)	CSI tiers (Heketi archivé)	Native (S3)	Provisioner NFS

Glissez pour voir

Quand choisir Ceph

Choisissez Ceph si vous avez besoin de plusieurs types de stockage (objet, bloc, fichier) dans un même cluster, ou si vous construisez un cloud privé avec OpenStack, Proxmox ou Kubernetes (via Rook). Pour du stockage fichier simple, GlusterFS est plus facile à déployer. Pour du S3 uniquement, MinIO suffit.

Architecture et concepts clés

Les composants fondamentaux

Un cluster Ceph repose sur une couche de stockage distribuée appelée RADOS (Reliable Autonomic Distributed Object Store) et plusieurs types de daemons :

• OSD (Object Storage Daemon) : un daemon par disque, responsable du stockage des données, de la réplication et de la récupération. C’est le composant le plus nombreux du cluster.

• MON (Monitor) : maintient la carte du cluster (cluster map). Un quorum de 3 ou 5 monitors assure la cohérence. Les MON ne stockent pas de données utilisateur.

• MGR (Manager) : fournit les modules de monitoring (dashboard, Prometheus, Grafana), le balancing et les métriques. Au moins 2 MGR (1 actif + 1 standby).

• MDS (Metadata Server) : gère les métadonnées du système de fichiers CephFS (arborescence, permissions, verrouillage). Requis uniquement si vous utilisez CephFS.

• RGW (RADOS Gateway) : passerelle HTTP qui expose une API compatible S3 et Swift. Requis uniquement pour le stockage objet via HTTP.

L’algorithme CRUSH

CRUSH (Controlled Replication Under Scalable Hashing) est l’algorithme qui détermine où stocker chaque objet dans le cluster. Contrairement à une table de correspondance centralisée, CRUSH est un algorithme déterministe : chaque client peut calculer indépendamment la position d’un objet.

Fonctionnement :

1. Les données sont découpées en objets (4 MiB par défaut pour RBD)
2. Chaque objet est assigné à un Placement Group (PG)
3. L’algorithme CRUSH mappe chaque PG vers N OSD (selon le facteur de réplication)
4. La CRUSH map définit la topologie du cluster (racks, hôtes, disques)

Pools et Placement Groups

Un pool est un espace logique de stockage avec ses propres règles de réplication :

• Pool répliqué : chaque objet est copié N fois (typiquement 3). Simple et sûr.
• Pool erasure-coded : les données sont découpées en fragments avec parité (comme un RAID 5/6). Plus efficace en espace mais plus coûteux en CPU.

Les PG (Placement Groups) sont l’intermédiaire entre les objets et les OSD. Un pool contient typiquement 32 à 256 PG, chaque PG est répliqué sur N OSD.

Lab : déployer un cluster Ceph 3 nœuds

Prérequis

• 3 machines virtuelles Ubuntu 24.04 (KVM, VirtualBox ou cloud)
• 4 Go de RAM et 2 vCPU minimum par VM
• 1 disque système (20 Go) + 1 disque dédié aux OSD (10 Go minimum) par VM
• Docker ou Podman installé sur chaque nœud
• Connectivité réseau entre les 3 nœuds

Ressources nécessaires

Un cluster Ceph de test consomme au minimum 12 Go de RAM et 6 vCPU au total (3 × 4 Go / 3 × 2 vCPU). En production, prévoyez 8 Go de RAM par OSD et des disques SSD pour les WAL/DB.

Créer les VMs avec KVM

Script automatisé

Le script suivant crée 3 VMs avec cloud-init, chacune avec 2 disques :

#!/bin/bash
# Créer 3 VMs pour le lab Ceph
for i in 1 2 3; do
  # Disque système
  qemu-img create -f qcow2 /var/lib/libvirt/images/ceph${i}.qcow2 20G

  # Disque OSD dédié
  qemu-img create -f qcow2 /var/lib/libvirt/images/ceph${i}-osd.qcow2 10G

  virt-install --name ceph${i} \
    --ram 4096 --vcpus 2 \
    --disk /var/lib/libvirt/images/ceph${i}.qcow2 \
    --disk /var/lib/libvirt/images/ceph${i}-osd.qcow2 \
    --os-variant ubuntu24.04 \
    --cloud-init user-data=cloud-init-ceph${i}.yaml \
    --network network=default \
    --graphics none --noautoconsole
done

Cloud-init

Chaque VM utilise un fichier cloud-init (adapter le hostname) :

#cloud-config
hostname: ceph1
users:
  - name: bob
    groups: sudo, docker
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... votre-clé-publique
packages:
  - docker.io
  - lvm2
  - chrony
runcmd:
  - systemctl enable --now docker

Déployer le cluster avec cephadm

1. Installer cephadm sur le premier nœud

   cephadm est l’outil officiel de déploiement de Ceph. Il gère tous les daemons via des conteneurs Docker ou Podman :

   curl --silent --remote-name --location \
     https://download.ceph.com/rpm-squid/el9/noarch/cephadm
   chmod +x cephadm
   sudo mv cephadm /usr/sbin/

   Le chemin rpm-squid/el9/noarch peut surprendre sur Ubuntu : cephadm est un script Python autonome (“noarch”), le répertoire RPM est simplement le chemin officiel pour le récupérer, il fonctionne sur toute distribution.

   Vérification :

   cephadm version
   # cephadm version 19.2.3 (...) squid (stable)

2. Bootstrapper le cluster

   Le bootstrap initialise le premier MON, le premier MGR et configure le dashboard :

   sudo cephadm bootstrap \
     --mon-ip 192.168.122.173 \
     --initial-dashboard-password cephadmin \
     --dashboard-password-noupdate \
     --allow-fqdn-hostname

   Cette commande :

   • Crée le premier MON et le premier MGR
   • Active le dashboard (interface web) sur le port 8443
   • Peut déployer Prometheus, Grafana et Alertmanager (selon la version et la configuration)
   • Génère une clé SSH pour la communication entre nœuds

   Vérification :

   sudo ceph --version
   # ceph version 19.2.3 (c92aebb...) squid (stable)

3. Installer les outils CLI

   Pour utiliser les commandes Ceph en dehors du conteneur :

   sudo cephadm install ceph-common

4. Ajouter les nœuds au cluster

   Récupérez la clé SSH publique de Ceph et copiez-la sur chaque nœud :

   # Récupérer la clé SSH de Ceph
   sudo cat /etc/ceph/ceph.pub
   # Copier cette clé dans /root/.ssh/authorized_keys sur ceph2 et ceph3
   
   # Ajouter les nœuds
   sudo ceph orch host add ceph2 192.168.122.174
   sudo ceph orch host add ceph3 192.168.122.175

   Vérification :

   sudo ceph orch host ls
   # HOST   ADDR              LABELS  STATUS
   # ceph1  192.168.122.173  _admin
   # ceph2  192.168.122.174
   # ceph3  192.168.122.175

   Cephadm déploie automatiquement les MON et MGR supplémentaires sur les nouveaux nœuds.

   MON : 5 par défaut, 3 suffisent en lab

   Par défaut, cephadm vise 5 MON pour tolérer 2 pannes simultanées (docs.ceph.com). En lab avec 3 nœuds, fixez explicitement le placement à 3 :

   sudo ceph orch apply mon 3

   Vérifiez ensuite avec ceph orch ls que la ligne mon affiche 3/3 au lieu de 3/5.

5. Déployer les OSD

   Les OSD utilisent les disques vierges disponibles sur chaque nœud :

   sudo ceph orch apply osd --all-available-devices

   Attendez 1 à 2 minutes que les OSD se déploient, puis vérifiez :

   sudo ceph status

   cluster:
     id:     900350e1-148f-11f1-a563-525400ccdd01
     health: HEALTH_OK
   
   services:
     mon: 3 daemons, quorum ceph1,ceph2,ceph3
     mgr: ceph1.llmtxu(active), standbys: ceph2.ybyuif
     osd: 3 osds: 3 up, 3 in
   
   data:
     pools:   1 pools, 1 pgs
     objects: 2 objects, 449 KiB
     usage:   80 MiB used, 30 GiB / 30 GiB avail
     pgs:     1 active+clean

6. Vérifier la topologie CRUSH

   L’arbre OSD montre la répartition des disques par hôte :

   sudo ceph osd tree

   ID  CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
   -1         0.02939  root default
   -3         0.00980      host ceph1
    0    hdd  0.00980          osd.0       up   1.00000  1.00000
   -5         0.00980      host ceph2
    1    hdd  0.00980          osd.1       up   1.00000  1.00000
   -7         0.00980      host ceph3
    2    hdd  0.00980          osd.2       up   1.00000  1.00000

Services déployés automatiquement

Après le bootstrap et l’ajout des nœuds, cephadm peut déployer automatiquement une pile complète de monitoring (le comportement exact dépend de la version et des options de bootstrap) :

sudo ceph orch ls

NAME                       PORTS        RUNNING  REFRESHED  AGE  PLACEMENT
alertmanager               ?:9093,9094      1/1  103s ago   10m  count:1
ceph-exporter                               3/3  103s ago   10m  *
crash                                       3/3  103s ago   10m  *
grafana                    ?:3000           1/1  103s ago   10m  count:1
mgr                                         2/2  103s ago   10m  count:2
mon                                         3/5  103s ago   10m  count:5
node-exporter              ?:9100           3/3  103s ago   10m  *
osd.all-available-devices                     3  103s ago   4m   *
prometheus                 ?:9095           1/1  103s ago   10m  count:1

La liste détaillée des daemons :

sudo ceph orch ps

NAME                 HOST   PORTS             STATUS       VERSION   IMAGE ID
alertmanager.ceph1   ceph1  *:9093,9094       running      0.25.0    c8568f914cd2
crash.ceph1          ceph1                    running      19.2.3    aade1b12b8e6
crash.ceph2          ceph2                    running      19.2.3    aade1b12b8e6
crash.ceph3          ceph3                    running      19.2.3    aade1b12b8e6
grafana.ceph1        ceph1  *:3000            running      10.4.0    c8b91775d855
mgr.ceph1.llmtxu     ceph1  *:9283,8443       running      19.2.3    aade1b12b8e6
mgr.ceph2.ybyuif     ceph2  *:8443,9283       running      19.2.3    aade1b12b8e6
mon.ceph1            ceph1                    running      19.2.3    aade1b12b8e6
mon.ceph2            ceph2                    running      19.2.3    aade1b12b8e6
mon.ceph3            ceph3                    running      19.2.3    aade1b12b8e6
osd.0                ceph1                    running      19.2.3    aade1b12b8e6
osd.1                ceph2                    running      19.2.3    aade1b12b8e6
osd.2                ceph3                    running      19.2.3    aade1b12b8e6
prometheus.ceph1     ceph1  *:9095            running      2.51.0    1d3b7f56885b

Dashboard Ceph

Le dashboard est accessible à https://ceph1:8443/ (login : admin). Il offre une vue complète du cluster : état de santé, pools, OSD, performances I/O et alertes. Grafana est disponible sur le port 3000 pour des tableaux de bord avancés.

Stockage objet avec RADOS

RADOS est la couche fondamentale de Ceph. Tous les types de stockage (RBD, CephFS, RGW) reposent dessus. Vous pouvez interagir directement avec RADOS via la commande rados.

Créer un pool

# Créer un pool répliqué avec 32 PG
sudo ceph osd pool create test-pool 32 32 replicated

# Configurer la réplication (3 copies)
sudo ceph osd pool set test-pool size 3

# Activer l'application sur le pool
sudo ceph osd pool application enable test-pool rbd

PG Autoscaler

Depuis Nautilus, Ceph ajuste automatiquement le nombre de PG grâce au module pg_autoscale. Les valeurs 32 32 ci-dessus conviennent pour un lab, mais en production laissez l’autoscaler faire :

sudo ceph osd pool set test-pool pg_autoscale_mode on

Le nombre optimal dépend du nombre d’OSD et de pools. L’autoscaler évite le piège classique d’un PG mal dimensionné (trop peu → hotspots, trop → consommation mémoire). Vérifiez les recommandations : sudo ceph osd pool autoscale-status.

Opérations sur les objets

# Écrire un objet dans le pool
echo "Bonjour depuis le cluster Ceph !" | sudo rados -p test-pool put test-object -

# Lister les objets du pool
sudo rados -p test-pool ls
# test-object

# Lire un objet
sudo rados -p test-pool get test-object -
# Bonjour depuis le cluster Ceph !

Voir l’utilisation du stockage

sudo ceph df

--- RAW STORAGE ---
CLASS    SIZE   AVAIL     USED  RAW USED  %RAW USED
hdd    30 GiB  30 GiB  100 MiB   100 MiB       0.33
TOTAL  30 GiB  30 GiB  100 MiB   100 MiB       0.33

--- POOLS ---
POOL                ID  PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
.mgr                 1    1  449 KiB        2  904 KiB      0     14 GiB
test-pool            2   32     33 B        1   12 KiB      0    9.5 GiB
rbd-pool             3   32  652 KiB       12  1.3 MiB      0     14 GiB
cephfs.cephfs.meta   4   16  6.2 KiB       22   72 KiB      0     14 GiB
cephfs.cephfs.data   5  128     12 B        1    8 KiB      0     14 GiB

Stockage bloc avec RBD

RBD (RADOS Block Device) fournit des volumes bloc similaires à des disques durs virtuels. Chaque image RBD est découpée en objets de 4 MiB et répliquée dans le cluster. C’est le choix idéal pour les VM, les bases de données et Kubernetes (via le CSI driver).

Créer et utiliser une image RBD

1. Créer le pool RBD et l’image

   # Créer un pool dédié au stockage bloc
   sudo ceph osd pool create rbd-pool 32 32 replicated
   sudo ceph osd pool application enable rbd-pool rbd
   
   # Créer une image de 1 Go
   sudo rbd create rbd-pool/test-image --size 1024

2. Vérifier l’image

   sudo rbd ls rbd-pool
   # test-image
   
   sudo rbd info rbd-pool/test-image

   rbd image 'test-image':
     size 1 GiB in 256 objects
     order 22 (4 MiB objects)
     snapshot_count: 0
     id: 8546de9f7be9
     block_name_prefix: rbd_data.8546de9f7be9
     format: 2
     features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
     create_timestamp: Sat Feb 28 10:35:46 2026

3. Mapper, formater et monter

   /dev/rbd0

   # Mapper l'image RBD comme block device
   sudo rbd map rbd-pool/test-image
   # Formater en ext4
   sudo mkfs.ext4 /dev/rbd0
   
   # Monter
   sudo mkdir -p /mnt/rbd-test
   sudo mount /dev/rbd0 /mnt/rbd-test
   
   # Écrire un fichier de test
   echo "Test RBD Ceph" | sudo tee /mnt/rbd-test/test.txt
   # Test RBD Ceph

4. Vérifier le montage

   df -h /mnt/rbd-test

   Filesystem      Size  Used Avail Use% Mounted on
   /dev/rbd0       974M   28K  907M   1% /mnt/rbd-test

Fonctionnalités avancées RBD

Fonctionnalité	Description
Snapshots	rbd snap create rbd-pool/test-image@snap1 — sauvegarde instantanée
Clones	Créer un volume à partir d’un snapshot (Copy-on-Write)
Mirroring	Réplication asynchrone vers un autre cluster Ceph
Encryption	Chiffrement côté client (LUKS) depuis la version Pacific
QoS	Limitation d’IOPS et de bande passante par image

Glissez pour voir

Système de fichiers CephFS

CephFS fournit un système de fichiers POSIX distribué. Il utilise un serveur de métadonnées (MDS) pour gérer l’arborescence et les permissions, tandis que les données sont stockées directement dans RADOS.

Créer un CephFS

# Créer le volume CephFS (crée automatiquement les pools data et metadata)
sudo ceph fs volume create cephfs

Vérification :

sudo ceph fs ls
# name: cephfs, metadata pool: cephfs.cephfs.meta, data pools: [cephfs.cephfs.data ]

sudo ceph fs status cephfs

cephfs - 0 clients
======
RANK  STATE           MDS             ACTIVITY     DNS    INOS   DIRS   CAPS
 0    active  cephfs.ceph1.eajrqr  Reqs:    0 /s    10     13     12      0
       POOL           TYPE     USED  AVAIL
cephfs.cephfs.meta  metadata  64.0k  14.2G
cephfs.cephfs.data    data       0   14.2G
    STANDBY MDS
cephfs.ceph3.docawv
MDS version: ceph version 19.2.3 (c92aebb...) squid (stable)

Monter CephFS

FUSE (simple, idéal lab)

Le montage FUSE est le plus simple et ne nécessite pas de module noyau. Idéal pour le lab et le dépannage :

sudo apt-get install -y ceph-fuse

sudo mkdir -p /mnt/cephfs
sudo ceph-fuse /mnt/cephfs

Test d’écriture :

echo "Test CephFS" | sudo tee /mnt/cephfs/test.txt
# Test CephFS

df -h /mnt/cephfs

Filesystem      Size  Used Avail Use% Mounted on
ceph-fuse        15G     0   15G   0% /mnt/cephfs

Noyau (perf / usage courant)

Le montage noyau offre de meilleures performances et est recommandé pour un usage durable en production :

# Récupérer la clé admin
sudo ceph auth get-key client.admin > /tmp/ceph-secret

# Monter via le noyau — lister plusieurs MON pour éviter un SPOF
sudo mkdir -p /mnt/cephfs
sudo mount -t ceph ceph1:6789,ceph2:6789,ceph3:6789:/ /mnt/cephfs \
  -o name=admin,secretfile=/tmp/ceph-secret

Syntaxe v2 (msgr2)

Si votre cluster utilise le protocole v2 (port 3300), préférez la syntaxe msgrv2 dans mon_host :

sudo mount -t ceph ceph1:3300,ceph2:3300,ceph3:3300:/ /mnt/cephfs \
  -o name=admin,secretfile=/tmp/ceph-secret

Le port 3300 (msgr2/v2) est à privilégier en environnement moderne. Le port 6789 (v1) reste disponible pour la compatibilité, mais évitez de l’exposer largement.

Quand utiliser CephFS

Cas d’usage	Adapté ?	Alternative
Partages de fichiers en équipe	✅ Oui	NFS, GlusterFS
Home directories	✅ Oui	NFS
Données d’applications conteneurisées	✅ Oui (via CSI)	RBD
Base de données	⚠️ Préférer RBD	RBD
Stockage S3	❌ Utiliser RGW	RGW

Glissez pour voir

Commandes essentielles

Santé et état du cluster

# Statut global (commande la plus utilisée)
sudo ceph status

# Détail des problèmes de santé
sudo ceph health detail

# Utilisation du stockage par pool
sudo ceph df

# Arbre OSD (topologie CRUSH)
sudo ceph osd tree

# Crashs récents (devrait être vide)
sudo ceph crash ls

Gestion des pools

# Lister les pools avec détails
sudo ceph osd pool ls detail

# Créer un pool répliqué
sudo ceph osd pool create mon-pool 32 32 replicated

# Configurer la taille de réplication
sudo ceph osd pool set mon-pool size 3

# Activer l'application
sudo ceph osd pool application enable mon-pool rbd

# Supprimer un pool (double confirmation)
sudo ceph osd pool rm mon-pool mon-pool --yes-i-really-really-mean-it

Orchestration (cephadm)

# Lister les hôtes
sudo ceph orch host ls

# Lister les services
sudo ceph orch ls

# Lister les daemons
sudo ceph orch ps

# Ajouter un hôte
sudo ceph orch host add nouveau-noeud 10.0.0.10

# Supprimer un hôte
sudo ceph orch host rm ancien-noeud

# Redémarrer un service
sudo ceph orch restart mon

Gestion des OSD

# Lister les disques disponibles
sudo ceph orch device ls

# Déployer les OSD sur tous les disques disponibles
sudo ceph orch apply osd --all-available-devices

# Marquer un OSD hors service (maintenance)
sudo ceph osd out 0

# Remettre un OSD en service
sudo ceph osd in 0

Sécurité

Authentification CephX

Ceph utilise par défaut CephX, un protocole d’authentification basé sur des clés partagées. Chaque client et chaque daemon possède une clé unique.

# Lister les clés d'authentification
sudo ceph auth ls

# Créer un utilisateur avec accès restreint
sudo ceph auth get-or-create client.app \
  mon 'allow r' \
  osd 'allow rw pool=app-pool' \
  -o /etc/ceph/ceph.client.app.keyring

Bonnes pratiques sécurité

Pratique	Description
Réseau dédié	Séparer le réseau public (clients) du réseau cluster (réplication OSD)
Utilisateurs restreints	Créer un utilisateur CephX par application avec des droits minimaux
Chiffrement en transit	Activer ms_cluster_mode = secure pour le trafic inter-daemon
Pare-feu	Ports MON : 3300 (msgr2/v2, privilégié) et 6789 (v1 legacy/compat). OSD/MDS/MGR : 6800-7300. Dashboard : 8443. Prometheus MGR : 9283
Dashboard HTTPS	Toujours actif par défaut avec certificat auto-signé
Mise à jour	Suivre les releases de sécurité, cephadm facilite les upgrades rolling

Glissez pour voir

Réseau cluster dédié

En production, séparez toujours le réseau public (accès client) du réseau cluster (réplication entre OSD). La réplication génère un trafic important qui peut saturer le réseau si les deux cohabitent. Configurez cluster_network dans ceph.conf pour ce réseau dédié.

Dépannage

Problèmes courants et solutions

Symptôme	Cause probable	Solution
HEALTH_WARN: X OSD(s) down	Daemon OSD en panne	sudo ceph orch daemon restart osd.X
HEALTH_WARN: pool X has no application	Application non activée	sudo ceph osd pool application enable X rbd
HEALTH_WARN: X nearfull osd(s)	Disque OSD presque plein	Ajouter des OSD ou supprimer des données
HEALTH_ERR: X pg(s) degraded	Réplication incomplète	Vérifier les OSD down avec ceph osd tree
ceph orch host add échoue	Clé SSH non copiée	Copier /etc/ceph/ceph.pub dans authorized_keys du root
Dashboard inaccessible	Port 8443 bloqué	sudo ufw allow 8443/tcp
no available devices	Disques déjà utilisés	sudo ceph orch device ls pour vérifier, ceph-volume lvm zap pour nettoyer
clock skew detected	Horloge désynchronisée	Installer et configurer chrony sur tous les nœuds

Glissez pour voir

Commandes de diagnostic

# Vérifier la santé détaillée
sudo ceph health detail

# Voir le statut de chaque PG
sudo ceph pg stat

# Analyser la performance en temps réel
sudo ceph osd perf

# Voir les événements récents
sudo ceph log last 20

# Tester les performances d'un pool
sudo rados bench -p test-pool 30 write --no-cleanup
sudo rados bench -p test-pool 30 seq

Bonnes pratiques

Dimensionnement

Composant	Minimum (test)	Recommandé (production)
MON	3	5 (tolérance 2 pannes)
OSD	3	10+ (au moins 3 hôtes)
RAM par OSD	2 Go	8 Go (Bluestore)
Réseau	1 Gbps	10 Gbps (25 Gbps idéal)
Disques OSD	HDD	SSD pour WAL/DB + HDD données
MGR	1	2 (actif + standby)

Glissez pour voir

Organisation

• Chaque OSD utilise un disque dédié : pas de partitions partagées.
• Séparer WAL/DB sur SSD si les données sont sur HDD : ceph-volume lvm create --data /dev/sdb --block.db /dev/nvme0n1p1
• Utiliser des pools séparés par application (bases de données, fichiers, objets).
• PG Autoscaler activé : voir la section Créer un pool pour le détail. Vérifiez avec ceph osd pool autoscale-status.
• Étiqueter les hôtes avec des labels pour contrôler le placement : ceph orch host label add ceph1 osd.

Performance

• BlueStore (par défaut depuis Luminous) : stockage natif sur disque, sans filesystem intermédiaire.
• Compression : activer la compression sur les pools peu sensibles à la latence : ceph osd pool set pool-name compression_algorithm lz4.
• Cache tiering : utiliser un pool SSD comme cache devant un pool HDD pour les workloads mixtes.
• Réduire le facteur de réplication à 2 pour les données non critiques (logs, caches temporaires).

À retenir

• Ceph = stockage unifié : objets (S3), blocs (RBD) et fichiers (CephFS) dans un même cluster.
• RADOS est la couche fondamentale : tous les types de stockage reposent dessus.
• CRUSH élimine le point de défaillance central : chaque client calcule indépendamment où stocker les données.
• cephadm simplifie le déploiement : un seul outil pour bootstrapper, ajouter des nœuds et gérer les daemons en conteneurs.
• 3 MON minimum pour le quorum, 3 OSD minimum pour la réplication.
• RBD pour les VM et bases de données, CephFS pour le partage de fichiers, RGW pour l’accès S3.
• Monitoring inclus : dashboard, Prometheus, Grafana déployés automatiquement.
• Séparer les réseaux public et cluster en production pour éviter la saturation.

Prochaines étapes

GlusterFS : stockage distribué fichier Alternative plus simple pour le stockage fichier partagé

MinIO : stockage objet S3 Solution légère pour le stockage objet compatible S3

NFS : partage de fichiers réseau Partage simple pour les environnements locaux

Kubernetes Storage Intégrer Ceph avec Kubernetes via Rook

Ressources

• Site officiel : ceph.io
• Documentation : docs.ceph.com
• GitHub : github.com/ceph/ceph
• Releases : docs.ceph.com/en/latest/releases
• Rook (Kubernetes) : rook.io

×

📖 Voir la documentation →