🗄️ Ceph – Distributed Storage Cluster (RBD, CephFS, RGW)

Contexte & objectifs

Mission “enterprise storage” autour de Ceph dans un environnement mêlant Lockheed Martin (aéronautique & défense), intégration EMC Computer (conseil stockage) et exploitation chez Airbus pour des workloads de simulation & jumeaux numériques.

• Remplacer/compléter un SAN EMC traditionnel par un cluster Ceph scale-out.
• Fournir du block RBD pour les VM de calcul & services applicatifs.
• Exposer du stockage objet S3 (RGW) pour archives & data lake.
• Garantir résilience multi-racks + intégration dans la chaîne de backup existante (EMC / Commvault).

Enjeux principaux

• Tenir des SLA forts (défense/aéronautique) avec 0 perte de données.
• Concevoir un design compatible avec la politique sécurité (zones, air-gaps, chiffrement).
• Limiter l’impact sur les équipes d’exploitation habituées aux appliances EMC.

Architecture mise en place

                        - 18 nœuds Ceph “storage” (3 racks x 6 nœuds)
                        - ~1.5 Po brut (HDD 12/16 To + journaux SSD NVMe)
                        - Réseau :
                        • public : 2 x 25 Gb/s
                        • cluster : 2 x 25 Gb/s dédié
                        - Services :
                        • RBD (VM KVM / OpenStack)
                        • CephFS (workspace HPC)
                        • RGW (S3 privé pour archives & data lake)
                        - Pools :
                        • rbd (réplication size=3)
                        • cephfs_data (réplication size=3)
                        • archive (erasure coding k=6,m=3)
                    

Rôle personnel

• Co-design de l’architecture avec les équipes Lockheed Martin & experts EMC.
• Définition CRUSH map (racks / hosts) & politiques de réplication.
• Automatisation déploiement via ceph-ansible puis migration progressive vers cephadm.
• Mise en place des dashboards, métriques Prometheus/Grafana, alerting (health, near full, OSD down, latency).

Intégration avec Airbus & workloads

• Back-end RBD pour clusters de virtualisation (KVM / OpenStack) hébergeant :
  • simulateurs de vol & outils d’ingénierie Airbus,
  • chaîne CI/CD interne pour software embarqué.
• CephFS comme workspace partagé pour jobs HPC (analyse de télémétrie, CFD, post-traitement).
• RGW utilisé comme “S3 interne” pour :
  • archives de logs techniques,
  • datasets d’apprentissage pour IA/ML (vision, maintenance prédictive).

Résultats & enseignements

• Remplacement progressif de baies EMC pour certains usages non critiques, tout en conservant les systèmes EMC pour le cœur réglementaire (approche hybride).
• Augmentation de la capacité disponible & baisse du coût / To grâce au hardware commodity.
• Temps de reprise acceptable en cas de panne host : recovery automatisé + tuning des débits de backfill.
• Mise en place de “runbooks Ceph” : procédures standardisées pour :
  • ajout d’un nœud / OSD,
  • remplacement disque,
  • gestion alerte health WARN/ERR,
  • tests DR réguliers (simulation perte d’un rack).
• Évangélisation interne : formation des équipes Airbus/Lockheed/EMC à la culture storage distribué (CRUSH, PG, self-healing) vs logique SAN classique.

Créer un pool (réplication)

                        # pool "rbd" répliqué 3x avec 128 PG
                        ceph osd pool create rbd 128
                        ceph osd pool set rbd size 3
                    

• size = nombre de copies.
• min_size = nombre mini pour IO (avant de passer en read-only).

Erasure coding

                        ceph osd erasure-code-profile set ec42 \
                        k=4 m=2 plugin=jerasure technique=reed_sol_van

                        ceph osd pool create archive 128 128 erasure ec42
                    

Utilisé pour optimiser capacité (moins de overhead que réplication), plutôt pour workloads froids / objets.

Création d’une image RBD

                        # pool rbd déjà créé
                        rbd create --size 50G --pool rbd vm01-root

                        # Lister les images
                        rbd ls rbd
                    

Mapping sur un host Linux

                        modprobe rbd
                        rbd map vm01-root --pool rbd --name client.admin
                        mkfs.ext4 /dev/rbd0
                        mount /dev/rbd0 /mnt/vm01
                    

Snapshots & clones

                        rbd snap create rbd/vm01-root@before-upgrade
                        rbd snap ls rbd/vm01-root

                        # clonage (template → VM)
                        rbd snap create rbd/template-ubuntu@base
                        rbd snap protect rbd/template-ubuntu@base
                        rbd clone rbd/template-ubuntu@base rbd/vm02-root
                    

Très utilisé dans les environnements de virtualisation et clouds privés.

Création CephFS

                        ceph fs volume create cephfs

                        # Pools data & metadata seront créés automatiquement ou manuellement
                        ceph fs ls
                    

Montage client

                        # Kernel client
                        mkdir /mnt/cephfs
                        mount -t ceph mon1,mon2,mon3:/ /mnt/cephfs \
                        -o name=client.admin,secret=<key>

                        # Ou via ceph-fuse
                        ceph-fuse -n client.admin /mnt/cephfs
                    

MDS gère la métadonnée ; plusieurs MDS peuvent être actifs pour scale-out.

Buckets & users

                        # créer un user S3
                        radosgw-admin user create --uid="demo" --display-name="Demo User"

                        # info (contient access/secret keys)
                        radosgw-admin user info --uid="demo"
                    

Utilisation avec s3cmd / awscli

                        s3cmd mb s3://ideolab-bucket
                        s3cmd put file.txt s3://ideolab-bucket/
                        s3cmd ls s3://ideolab-bucket/
                    

RGW permet de fournir un “S3 privé” on-premise ou dans ton cloud privé.

Commandes de base

                        ceph status
                        ceph health detail
                        ceph df
                        ceph osd tree
                        ceph osd df tree
                    

Dashboard & metrics

• Module dashboard du MGR (UI web).
• Export Prometheus & Grafana pour métriques détaillées.
• Alerting sur health WARN / ERR, full ratio, OSD down, etc.

Points clés perf

• Quantité & qualité des OSD (SSD vs HDD).
• Latence réseau (public + cluster).
• Nombre de PG par pool (ni trop peu, ni trop).
• Utilisation de Bluestore (back-end moderne).

Bench rapide (rados bench)

                        # test d'écriture (10s)
                        rados bench -p rbd 10 write --no-cleanup

                        # test de lecture
                        rados bench -p rbd 10 seq
                    

Utiliser également les benchs spécifiques (FIO, rbd bench, tests applicatifs).

OSD down / out

                        ceph osd tree
                        ceph osd down <id>
                        ceph osd out <id>
                    

• Ceph recalcule les placements & re-réplique les PG affectés.
• Backfill & recovery consomment de l’IO – à tune via osd_recovery_max_*.

Scénarios typiques

• Perte d’un disque : OSD cassé, recovering automatique.
• Perte d’un host : plusieurs OSD d’un coup – d’où l’importance de CRUSH & size.
• Near full / full : cluster saturé, IO bloqués – capacity planning vital.

Cloud & virtualisation

• Back-end de stockage OpenStack (Cinder, Glance, Nova).
• Back-end RBD pour Proxmox, oVirt, etc.
• Intégration Kubernetes via Rook (PersistentVolume).

HPC & Data

• CephFS pour scratch / workspace partagé.
• RGW pour data lakes objets (S3-compatible).
• Backups & archives sur cluster Ceph dédié (erasure coding).

CLI & admin

                        ceph status                      # vue globale
                        ceph health detail               # détails des problèmes
                        ceph df                          # utilisation des pools
                        ceph osd tree                    # topologie OSD
                        ceph osd df tree                 # capacity & utilisation
                        ceph fs ls                       # CephFS
                        rbd ls rbd                       # images RBD
                    

À retenir en design

• Commencer petit, mais design scalable dès le début.
• Bien séparer les pools par usage (VM, objets, archive…).
• Surveiller en continu : health, near full, PG inconsistent.
• Documenter CRUSH & policies de réplication par niveau (host, rack, DC).