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.

Ce qui distingue Ceph

Ces six caractéristiques expliquent pourquoi Ceph est retenu là où un serveur NFS ou un MinIO ne suffisent plus. Aucune n'est gratuite : c'est le même moteur qui apporte la scalabilité et la charge opérationnelle.

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

Le positionnement de Ceph

Ceph vise le stockage unifié à grande échelle : objet (S3/Swift via le RADOS Gateway), bloc (RBD) et fichier (CephFS) dans un même cluster, du téraoctet à l'exaoctet, avec auto-réparation et placement sans métadonnées centrales (CRUSH). C'est la brique de stockage des clouds privés (OpenStack, Proxmox, Kubernetes via Rook). En contrepartie, il demande un investissement opérationnel réel (plusieurs démons, cephadm, tuning). Pour situer Ceph parmi les solutions de stockage objet auto-hébergées, voir la vue d'ensemble du stockage.

Architecture et concepts clés

Cette section pose le vocabulaire que l'on retrouve dans toutes les commandes du guide. Un cluster Ceph n'est pas un service unique mais un ensemble de daemons aux rôles distincts, posés sur une couche commune appelée RADOS. Savoir qui fait quoi évite les erreurs de diagnostic les plus fréquentes : chercher des données sur un MON, ou s'étonner qu'aucun MDS ne tourne alors qu'on n'utilise pas CephFS.

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

Le lab reproduit une architecture minimale mais réaliste : 3 nœuds, chacun avec un disque dédié aux données. Trois nœuds constituent le plancher pour obtenir à la fois un quorum de monitors et une réplication en 3 copies sur des hôtes différents. L'ensemble se déploie avec cephadm, l'outil officiel, qui installe chaque daemon dans un conteneur et pilote le cluster depuis un seul nœud.

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

Deux façons de créer les VMs : le script complet, ou le fichier cloud-init qu'il consomme. Le point à ne pas manquer est le second disque, qui doit rester vierge : cephadm ne convertit en OSD que les disques dépourvus de partition et de système de fichiers.

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

Le déploiement suit toujours le même ordre : bootstrap du premier nœud, ajout des autres hôtes, puis création des OSD. Vérifiez chaque étape avant de passer à la suivante, car un défaut de connectivité SSH ou une horloge désynchronisée bloque tout ce qui suit.

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

Un pool est le conteneur logique dans lequel vivent les objets. Les deux chiffres 32 32 fixent le nombre de Placement Groups demandés et effectifs. La ligne application enable n'est pas décorative : sans elle, le cluster passe en HEALTH_WARN.

# 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

La commande rados manipule les objets directement, sans passer par RBD ni CephFS. Le - en fin de commande remplace un nom de fichier par l'entrée ou la sortie standard.

# É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

ceph df se lit sur deux niveaux : RAW STORAGE donne l'espace physique brut agrégé de tous les OSD, tandis que MAX AVAIL, dans la section POOLS, indique l'espace réellement écrivable une fois le facteur de réplication et le seuil de remplissage pris en compte.

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 objet S3 avec le RADOS Gateway (RGW)

Au-delà de l'accès RADOS natif, Ceph expose une API S3 (et Swift) via le RADOS Gateway (RGW). C'est la face « stockage objet compatible S3 » de Ceph : toute application ou client S3 (AWS CLI, mc, Rclone) s'y connecte comme à Amazon S3.

Déployer le RGW

Avec cephadm, on déploie un service RGW en une commande :

# Déployer 2 gateways RGW (haute disponibilité)
ceph orch apply rgw s3 --placement="2 node1 node2"
ceph orch ls rgw            # vérifier le service

Le RGW écoute par défaut sur le port 80 (ou 8080). On crée ensuite un utilisateur S3 qui reçoit une paire de clés :

radosgw-admin user create --uid=app --display-name="Application" \
  --access-key=<accessKey> --secret-key=<secretKey>

Fonctions S3 disponibles

Le RGW couvre l'essentiel de l'API S3, vérifié en lab sur un cluster de test :

• Versioning, delete markers et restauration de version.
• Object Lock / WORM (rétention GOVERNANCE et COMPLIANCE) : une version verrouillée ne peut pas être supprimée avant l'échéance.
• Cycle de vie, multipart, copy, requêtes conditionnelles, CORS, notifications d'événements (vers Kafka, AMQP, HTTP).
• Bucket policies au format IAM, avec conditions s3:prefix pour cloisonner un utilisateur à un préfixe.
• Chiffrement au repos (SSE-S3/SSE-KMS via un backend de clés comme Vault, SSE-C côté client).

Fédération OIDC et identités temporaires (STS)

Le RGW embarque un service STS : un utilisateur fédéré par un fournisseur OIDC externe (Keycloak, Authentik...) échange son jeton contre des identifiants temporaires via AssumeRoleWithWebIdentity, avec une portée limitée à un rôle et sa politique. La configuration se fait avec radosgw-admin :

1. Déclarer le fournisseur OIDC (l'IdP), avec son empreinte de certificat :

   radosgw-admin oidc-provider create \
     --oidc-provider-url=https://sso.example.com/realms/stockage \
     --client-id=ceph-rgw --thumbprint=<sha1-du-certificat-idp>

2. Créer un rôle dont la trust policy autorise ce fournisseur à l'assumer. Le principal est l'ARN du fournisseur OIDC :

   { "Version": "2012-10-17", "Statement": [
     { "Effect": "Allow",
       "Principal": { "Federated": ["arn:aws:iam:::oidc-provider/sso.example.com/realms/stockage"] },
       "Action": ["sts:AssumeRoleWithWebIdentity"],
       "Condition": { "StringEquals": { "sso.example.com/realms/stockage:app_id": "ceph-rgw" } } } ] }

   radosgw-admin role create --role-name=EquipeARole --assume-role-policy-doc=file://trust.json

3. Attacher une politique de permission scopée au préfixe equipe-a/ :

   radosgw-admin role-policy put --role-name=EquipeARole --policy-name=equipe-a \
     --policy-doc='{"Version":"2012-10-17","Statement":[
       {"Effect":"Allow","Action":["s3:GetObject","s3:PutObject"],"Resource":["arn:aws:s3:::data/equipe-a/*"]},
       {"Effect":"Allow","Action":["s3:ListBucket"],"Resource":["arn:aws:s3:::data"],"Condition":{"StringLike":{"s3:prefix":["equipe-a/*"]}}}]}'

L'application échange alors le jeton OIDC contre des identifiants temporaires (AssumeRoleWithWebIdentity) : ceux-ci sont cloisonnés au préfixe de la politique et expirent automatiquement. Un utilisateur shadow est créé côté RGW pour chaque identité fédérée (dérivé du claim sub).

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

Une image RBD est un volume logique découpé en objets de 4 MiB répartis sur tout le cluster. La mapper sur un nœud la fait apparaître comme un disque /dev/rbdN ordinaire, qu'il reste à formater et à monter comme n'importe quel disque.

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

Ces fonctionnalités s'activent image par image, sans toucher au pool. Les snapshots et les clones reposent sur le Copy-on-Write : leur création est instantanée et l'espace n'est consommé qu'au fil des écritures suivantes.

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

ceph fs volume create fait trois choses d'un coup : il crée le pool de métadonnées, le pool de données, et déploie les daemons MDS qui gèrent l'arborescence.

# 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

Deux méthodes de montage, avec un arbitrage simple : le client FUSE s'installe en un paquet et fonctionne partout, le client noyau est plus rapide mais dépend du support de CephFS dans le noyau de la machine cliente. Dans les deux cas, listez plusieurs monitors pour ne pas dépendre d'un seul nœud.

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

CephFS ne convient pas à tous les usages : il excelle sur l'accès partagé et concurrent, mais se comporte mal sur les charges très sensibles à la latence, où RBD reste le bon choix.

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

Ce mémento regroupe les commandes du quotidien, classées par domaine. Toutes s'exécutent depuis le nœud portant le label _admin, le seul à détenir le keyring et la configuration du cluster.

Santé et état du cluster

ceph status est la commande à lancer en premier devant n'importe quel incident ; ceph health detail en donne ensuite la cause précise.

# 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

Les pools se créent et se suppriment à chaud, mais la suppression est définitive : c'est la raison de la double confirmation exigée sur la dernière commande.

# 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)

Le sous-ensemble orch pilote cephadm : il agit sur les hôtes, les services et les daemons, jamais sur les données elles-mêmes.

# 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

Sortir un OSD avec osd out déclenche immédiatement la redistribution des données vers les OSD restants ; sur un petit cluster, l'opération peut occuper le réseau plusieurs minutes.

# 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é

La sécurité d'un cluster Ceph se joue sur trois plans distincts : l'authentification des clients avec CephX, l'isolation réseau entre le trafic client et le trafic de réplication, et le chiffrement des échanges entre daemons. Seul le premier est couvert par la configuration par défaut.

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é

Ces pratiques se décident au moment du déploiement : plusieurs d'entre elles, en particulier la séparation des réseaux, sont pénibles à introduire sur un cluster déjà en service.

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

Ceph annonce ses problèmes sous forme d'états de santé lisibles, HEALTH_WARN ou HEALTH_ERR, assortis d'un code précis. Le bon réflexe consiste à partir de ce code plutôt que du symptôme ressenti côté client.

Problèmes courants et solutions

Repérez le message exact renvoyé par ceph status dans la colonne de gauche. Les avertissements nearfull et clock skew sont de loin les plus fréquents sur un cluster de lab.

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

Ces commandes prennent le relais quand le message de santé ne suffit pas. Attention à rados bench : il écrit réellement des données dans le pool visé, à réserver donc à un pool de test.

# 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

Trois axes déterminent le comportement d'un cluster en production : son dimensionnement, l'organisation des disques et des pools, et les réglages de performance. Un cluster sous-dimensionné ne tombe pas franchement en panne, il se dégrade, ce qui rend le diagnostic bien plus long.

Dimensionnement

La colonne « minimum » convient à un lab, pas à un service exploité. L'écart le plus coûteux à rattraper reste le réseau : le redimensionner après coup suppose de revenir sur le câblage et les commutateurs.

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

Ces règles évitent les contentions les plus courantes, quand plusieurs OSD se partagent un même disque physique ou qu'un seul pool mélange des charges de nature différente.

• 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

Ces leviers se règlent une fois les charges réelles observées, pas au déploiement. Méfiance sur le dernier : passer la réplication à 2 copies fait perdre toute tolérance à une panne survenant pendant une reconstruction.

• 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

CephFS pour un cluster Incus OS Attacher un CephFS partagé aux instances d'un cluster Incus

Comparatif des alternatives S3 Le RADOS Gateway face aux moteurs S3 légers : auth OIDC et droits par préfixe

Ressources

Les références officielles pour approfondir et suivre le calendrier de support des versions.

• 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 →