Ceph : le stockage distribué expliqué simplement

Dans un serveur classique, les données sont stockées sur des disques locaux, éventuellement en RAID. Si le serveur tombe, les données sont inaccessibles (ou perdues si le RAID ne suffit pas). Si la capacité est pleine, il faut ajouter des disques ou changer de machine.

Ceph propose une approche fondamentalement différente : les données sont réparties et répliquées sur un ensemble de serveurs. Pas de disque unique, pas de serveur unique, pas de point de défaillance unique.

D'où vient Ceph ?

Ceph est né en 2004 dans le cadre de la thèse de doctorat de Sage Weil à l'Université de Californie (Santa Cruz). Le projet est devenu open source en 2006, puis a été développé par la société Inktank, rachetée par Red Hat en 2014 (puis IBM en 2019).

Aujourd'hui, Ceph est le standard de fait du stockage distribué open source. Il est utilisé par le CERN (pour stocker les données du LHC), Deutsche Telekom, Bloomberg, DigitalOcean, OVHcloud et des milliers d'infrastructures critiques dans le monde. La communauté est active, le code est auditable, et le projet est soutenu par la fondation Ceph (sous l'égide de la Linux Foundation).

Les composants d'un cluster

Un cluster Ceph repose sur plusieurs types de démons (services) qui collaborent :

CRUSH : l'algorithme qui change tout

La clé de Ceph, c'est CRUSH (Controlled Replication Under Scalable Hashing). Contrairement à un système de stockage classique où un serveur central décide où ranger chaque fichier, CRUSH est un algorithme déterministe : n'importe quel client peut calculer lui-même où se trouve une donnée, sans interroger un index centralisé.

Concrètement, CRUSH utilise une CRUSH map qui décrit la topologie physique du cluster : quels disques sont dans quels serveurs, quels serveurs sont dans quels racks, quels racks sont dans quel datacenter. Grâce à cette carte, CRUSH garantit que les copies d'une donnée sont placées sur des domaines de défaillance différents (par exemple : trois copies sur trois serveurs physiques différents).

Pools et Placement Groups

Les données ne sont pas stockées en vrac dans le cluster. Elles sont organisées en pools (des espaces logiques avec leurs propres règles de réplication) et Placement Groups (PG).

Un PG est un regroupement d'objets qui sont gérés ensemble. Plutôt que de gérer la réplication objet par objet (ce qui serait trop coûteux), Ceph réplique des PG entiers. Chaque PG est assigné à un ensemble d'OSD par l'algorithme CRUSH.

# Exemple : créer un pool avec 128 PG en réplica 3
ceph osd pool create mon-pool 128
ceph osd pool set mon-pool size 3
ceph osd pool set mon-pool min_size 2

Le paramètre min_size définit le nombre minimum de copies disponibles pour que le pool continue à accepter les écritures. Avec size 3 et min_size 2, le cluster continue de fonctionner même si une copie est temporairement indisponible.

La réplication : comment les données survivent

Quand vous écrivez un fichier sur Ceph, il est découpé en objets, et chaque objet est automatiquement répliqué sur plusieurs OSD situés sur des serveurs différents. En réplica 3 (le standard), chaque objet existe en trois exemplaires, sur trois machines physiques distinctes.

L'écriture est considérée comme réussie uniquement lorsque toutes les copies ont été écrites. C'est la différence avec une réplication asynchrone : ici, la cohérence est garantie dès l'acquittement de l'écriture.

Réplication vs. Erasure Coding

Ceph propose deux stratégies de protection des données :

Pour les workloads de virtualisation (VPS, bases de données), la réplication reste le choix privilégié car elle offre les meilleures performances en I/O aléatoires. L'erasure coding est plus adapté au stockage de gros fichiers peu modifiés (sauvegardes, archives, médias).

L'auto-healing : le cluster se répare tout seul

C'est l'un des points les plus impressionnants de Ceph. Quand un OSD tombe (panne de disque, perte d'un serveur), le cluster réagit automatiquement :

1. Détection — les OSD s'envoient des heartbeats réguliers. Si un OSD ne répond plus, il est marqué down au bout de quelques secondes.
2. Attente — Ceph attend un court délai configurable (par défaut 10 minutes) avant de déclarer l'OSD out. Cela évite de déclencher une reconstruction pour un simple redémarrage.
3. Reconstruction — une fois l'OSD déclaré out, CRUSH recalcule le placement des PG concernés. Les données sont recopiées depuis les copies restantes vers d'autres OSD sains, jusqu'à retrouver le nombre de réplicas configuré.
4. Rééquilibrage — la reconstruction est distribuée sur tous les OSD du cluster. Contrairement à un RAID où un seul disque spare est stressé, ici la charge est répartie, ce qui accélère la reconstruction et réduit l'impact sur les performances.

Pendant tout ce processus, les données restent accessibles. Les lectures et écritures continuent via les copies restantes. L'utilisateur ne voit rien.

Les trois interfaces de Ceph

Ceph n'est pas limité à un seul type de stockage. Un même cluster peut exposer trois interfaces différentes simultanément :

RBD et Proxmox : le duo en production

Dans une infrastructure de virtualisation, RBD est l'interface la plus utilisée. Chaque VPS dispose d'un disque RBD stocké sur le cluster Ceph. Ce disque est automatiquement répliqué, et comme il n'est pas lié à un serveur physique, il rend possible :

• Live migration — déplacer un VPS d'un serveur à un autre sans interruption de service. Le stockage étant partagé, seule la mémoire vive est transférée.
• Snapshots copy-on-write — capturer l'état du disque en quelques millisecondes. Seules les différences sont stockées, ce qui consomme peu d'espace.
• Thin provisioning — allouer de l'espace disque à la demande. Un disque de 100 Go ne consomme que l'espace réellement écrit.
• Haute disponibilité — si un nœud Proxmox tombe, le VPS redémarre automatiquement sur un autre nœud, avec accès immédiat à ses données (puisqu'elles sont sur Ceph, pas sur le serveur physique).
• Clonage rapide — créer une copie d'un VPS à partir d'un snapshot, sans recopier les données. Utile pour les environnements de test ou de staging.

Pourquoi pas un RAID classique ?

Le RAID matériel (RAID 1, RAID 5, RAID 10) protège contre la panne d'un ou deux disques dans un même serveur. Mais il ne protège pas contre la panne du serveur lui-même, du contrôleur RAID, de l'alimentation ou du rack.

De plus, la reconstruction d'un RAID matériel est risquée : pendant le rebuild, tous les I/O passent par les disques survivants, qui sont déjà stressés. Un second disque qui lâche pendant cette phase critique signifie une perte de données. Avec Ceph, le rebuild est distribué sur l'ensemble du cluster, ce qui réduit considérablement ce risque.

Les limites à connaître

Ceph est puissant, mais ce n'est pas une solution miracle. Quelques points à garder en tête :

• Complexité opérationnelle — un cluster Ceph nécessite des compétences spécifiques pour être déployé, dimensionné et maintenu correctement. Ce n'est pas un « install and forget ».
• Réseau critique — la performance de Ceph dépend directement de la qualité du réseau entre les nœuds. Un réseau lent ou saturé impacte directement la latence des I/O.
• Coût en espace — la réplication 3× signifie que pour 1 To de données utiles, il faut 3 To d'espace brut. L'erasure coding réduit ce ratio, mais avec un compromis sur les performances.
• Nombre minimum de nœuds — un cluster Ceph nécessite au moins 3 nœuds pour fonctionner correctement (quorum MON + réplica 3 sur des serveurs distincts).
• Mises à jour — les upgrades de version Ceph doivent être planifiées et testées. Une mauvaise mise à jour peut impacter la disponibilité du cluster.

C'est pourquoi Ceph est généralement exploité par des équipes spécialisées ou dans le cadre d'une infogérance. Ce n'est pas un outil destiné à l'utilisateur final.

— Datacampus