🧱 Storage Systems — Chapitre 12 : Ceph

• Unifier block, file et object storage.
• Construire un stockage souverain sur matériel standard.
• Servir OpenStack, Kubernetes, KVM, backup, S3 privé.
• Scale-out par ajout de nœuds et disques.
• Éviter la dépendance à une baie propriétaire unique.

Les MON forment un quorum. Une configuration typique utilise 3 ou 5 MON. Perdre le quorum ne détruit pas les données, mais bloque des décisions de cluster et peut rendre la plateforme indisponible.

Un OSD est généralement associé à un disque ou volume. Avec BlueStore, il gère directement le périphérique bloc, avec RocksDB/WAL pour metadata internes. Les OSD sont la source principale de capacité et d'I/O.

ceph osd tree
ceph osd df
ceph osd metadata 12
ceph orch ps --daemon_type osd

RBD fournit des images bloc fines, snapshottables, clonables, mappables côté Linux/KVM/OpenStack/Kubernetes. C'est souvent le service Ceph le plus utilisé en cloud privé.

rbd ls -p volumes
rbd info volumes/vm-001
rbd snap create volumes/vm-001@before-upgrade
rbd map volumes/vm-001

CephFS fournit un filesystem distribué POSIX-like. Il convient aux usages fichier partagés, mais les workloads metadata intensifs exigent un dimensionnement MDS sérieux.

ceph fs status
ceph fs volume ls
mount -t ceph mon1,mon2,mon3:/ /mnt/cephfs -o name=client.user,secretfile=/etc/ceph/secret

RGW expose S3-compatible object storage. Il sert les buckets, users, access keys, policies, lifecycle, replication/multisite selon configuration.

radosgw-admin user create --uid app1 --display-name "Application 1"
radosgw-admin bucket list
radosgw-admin bucket stats --bucket data

Ceph distingue les classes de périphériques : hdd, ssd, nvme. Les rules peuvent cibler une classe pour créer des pools différenciés : capacity HDD, fast SSD, ultra NVMe.

ceph osd crush class ls
ceph osd crush tree --show-shadow
ceph osd crush rule ls

Les weights représentent la capacité relative des OSD. Une mauvaise pondération crée des déséquilibres. Les reweight temporaires aident en incident mais ne remplacent pas un design propre.

ceph osd df tree
ceph osd reweight-by-utilization
ceph osd crush reweight osd.12 7.28

• Replication factor 3 mais copies sur même host.
• Racks non modélisés dans CRUSH.
• Mélanger HDD et NVMe dans un même pool sans règle.
• Modifier CRUSH sans comprendre rebalance induit.

L'erasure coding découpe les données en fragments data + coding. Il améliore le rendement capacité, utile pour objet/archive, mais augmente CPU, latence et complexité, surtout pour petites écritures.

ceph osd erasure-code-profile set ec84 k=8 m=4 crush-failure-domain=host
ceph osd pool create data-ec erasure ec84

Le scrub vérifie la cohérence. Le deep scrub lit plus profondément les données. Il détecte corruption latente mais consomme I/O.

ceph health detail
ceph pg dump_stuck
ceph tell osd.* version

• Backfill reconstruit les copies/fragments manquants.
• Recovery consomme réseau, disque et CPU.
• Throttle possible pour protéger production.
• Capacité libre indispensable après panne.

• RBD CSI pour volumes RWO.
• CephFS CSI pour volumes RWX.
• Rook pour gérer Ceph dans Kubernetes.
• ODF dans OpenShift.

• S3 privé on-prem.
• Backup immuable selon design RGW/Object Lock.
• Data lake interne.
• Archive réglementaire avec contrôle localisation.

Sans Prometheus/Grafana et alertes robustes, Ceph devient opaque. Il faut surveiller health, latence OSD, slow ops, PG states, capacité, recovery, réseau, disques et clients.

• MON sur 3 ou 5 nœuds fiables.
• OSD nodes dimensionnés disques + réseau + CPU.
• RGW derrière load balancer.
• MDS active/standby pour CephFS.
• MGR pour dashboard et metrics.

rbd create volumes/db01 --size 500G
rbd info volumes/db01
rbd snap create volumes/db01@before-maintenance
rbd clone images/base@golden volumes/vm01
rbd mirror pool status volumes

• Utiliser pools SSD/NVMe pour workloads sensibles.
• Surveiller latency client et OSD.
• Limiter snapshots longs non gouvernés.
• Tester restore et clone.

• Kubernetes RWX.
• Partage Linux.
• Datasets de calcul.
• Home dirs techniques.
• Mais attention aux millions de petits fichiers.

ceph fs status
ceph mds stat
ceph fs volume ls
ceph fs subvolume ls cephfs csi
ceph tell mds.* perf dump

• Plusieurs RGW derrière load balancer.
• TLS terminé proprement.
• Metrics par gateway.
• Multisite pour réplication géographique si nécessaire.

radosgw-admin user create --uid app --display-name "App"
radosgw-admin user info --uid app
radosgw-admin bucket stats --bucket data
radosgw-admin sync status

BlueStore stocke directement sur block device. RocksDB/WAL peuvent bénéficier de SSD/NVMe dédiés pour OSD HDD. Une mauvaise DB/WAL sizing peut limiter fortement les performances.

rados bench -p test 60 write --no-cleanup
rados bench -p test 60 seq
rados bench -p test 60 rand
fio --name=rbdtest --ioengine=rbd --clientname=admin --pool=volumes --rbdname=image01 --rw=randrw --bs=4k --iodepth=32 --runtime=120 --time_based

• Séparer HDD/SSD/NVMe par device class.
• Adapter replication vs EC au workload.
• Surveiller recovery throttling.
• Éviter surcharger MON/MDS/RGW.
• Optimiser réseau avant micro-tuning.

• Dashboard cluster overview.
• OSD latency.
• Pool I/O.
• RGW requests/errors.
• MDS cache and ops.
• Capacity forecast.

• HEALTH_ERR immédiat.
• OSD down.
• MON quorum risk.
• PG inactive/stuck.
• Capacity > 80/85/90%.
• RGW 5xx spike.

1. Confirmer OSD fautif.
2. out si nécessaire selon état.
3. Remplacer disque.
4. Recréer OSD.
5. Surveiller recovery/backfill.

ceph orch host maintenance enter node01
ceph -s
# maintenance
ceph orch host maintenance exit node01

• Cluster healthy avant upgrade.
• Lire release notes.
• Backup configs.
• Upgrade rolling.
• Valider clients et métriques après chaque phase.

• Access keys par application.
• Bucket policies.
• TLS obligatoire.
• Pas de bucket public par défaut.
• Rotation secrets.

• Réseau public Ceph limité aux clients autorisés.
• Réseau cluster non exposé.
• Management via bastion/VPN.
• Firewall par rôle.

• Actions admin Ceph.
• Création/suppression pools.
• RGW access logs.
• Changements caps.
• Suppression snapshots/buckets.

kubectl get storageclass
kubectl get pvc -A
kubectl get volumesnapshot -A

Rook pilote Ceph comme operator Kubernetes : déploiement, OSDs, pools, filesystems, object stores. C'est puissant mais ajoute une couche Kubernetes à diagnostiquer.

• Ne pas mettre MON/MGR sur nœuds instables.
• Prévoir anti-affinity.
• Séparer capacité app et capacité control plane.
• Tester restore PVC et snapshot.

1. Identifier MON up/down.
2. Vérifier réseau et temps/NTP.
3. Restaurer quorum majoritaire.
4. Consulter logs mon.
5. Escalader si store MON corrompu.

1. Stopper ingestion non critique.
2. Identifier pools/buckets gros consommateurs.
3. Ajouter capacité ou supprimer données validées.
4. Vérifier snapshots, versions, multipart incomplets.
5. Ne pas baisser les seuils au hasard.

1. Identifier OSDs concernés.
2. Vérifier disques, latence, réseau.
3. Vérifier recovery/backfill en cours.
4. Vérifier clients bruyants.
5. Throttle recovery si nécessaire.

ceph pg dump_stuck
ceph pg map 
ceph osd blocked-by
ceph health detail

• Replication/EC choisis par workload.
• min_size validé.
• Scrub/deep scrub planifiés.
• Backups externes pour données critiques.
• Restore drill réalisé.

• Runbook OSD down.
• Runbook full cluster.
• Runbook MON quorum.
• Procédure upgrade.
• Inventaire disques/nœuds.
• Escalade support.

• cephx caps minimales.
• Admin keys protégées.
• TLS RGW/dashboard.
• Réseaux segmentés.
• Audit actions sensibles.