Ceph propose deux stratégies principales pour protéger les données dans un cluster distribué : la réplication en triplicate (Replica 3) et l’Erasure Coding, une technique qui divise les données en fragments et ajoute des informations de parité pour les reconstruire en cas de défaillance. Le choix entre ces deux méthodes n’est pas anodin : il impacte le coût par téraoctet utile, la performance, la latence, la charge CPU, la complexité opérationnelle et le type de charges à héberger.

Le débat revient souvent quand la capacité coûte cher et que les données s’accumulent. Mais l’Erasure Coding n’est pas un remplacement direct de Replica 3. Dans Ceph, chaque approche trouve sa place dans des scénarios spécifiques, et une erreur de choix peut transformer une économie de stockage en goulot d’étranglement en performance ou en disponibilité.

Replica 3 : simple, rapide, gourmande en capacité

La réplication en triplicate est la méthode la plus intuitive. Chaque donnée est sauvegardée en trois copies réparties sur différents OSD, généralement distribués entre plusieurs nœuds ou domaines de panne définis par le mécanisme CRUSH. Si un disque ou un nœud tombe, le cluster conserve deux copies, garantissant la disponibilité des données. Sa popularité dans les environnements de virtualisation, bases de données et charges sensibles à la latence repose sur cette simplicité.

Son principal inconvénient est le coût : pour 1 TB de données utiles, il faut environ 3 TB de stockage brut, soit 200 % d’overhead. En contrepartie, l’opération est simple, les calculs sont minimaux et le comportement en lecture comme en écriture est très prévisible. Pour les volumes critiques (RBD, machines virtuelles, systèmes transactionnels), Replica 3 reste une option solide et éprouvée.

Le problème apparaît quand la capacité augmente considérablement. Stocker des dizaines ou des centaines de téraoctets avec Replica 3 implique d’acheter énormément de capacité brute, ce qui devient prohibitif pour des données froides, archivées ou peu accédées. C’est exactement le contexte où l’Erasure Coding devient intéressant, y compris dans les grandes infrastructures de centres de données où l’optimisation de la densité de stockage est critique.

Erasure Coding : plus efficace en capacité, plus complexe en calcul

L’Erasure Coding fonctionne différemment. Plutôt que de dupliquer intégralement chaque objet, Ceph le divise en fragments de données (k) et ajoute des fragments de parité (m). Ces fragments suffisent à reconstruire l’ensemble, même si certains OSD ou domaines de panne sont défaillants. La documentation Ceph décrit ce modèle comme une division des données en « chunks » de données et en « chunks » de codage stockés sur différents OSD.

Exemple concret : avec un profil 4+2, les données sont réparties en 4 fragments, auxquels s’ajoutent 2 fragments de parité. La perte de deux fragments est tolérée. Pour stocker 100 TB utiles, il faut environ 150 TB de capacité brute avec un profil 4+2, contre 300 TB avec Replica 3. Mais cette efficacité a un prix : calcul de parité à chaque écriture, plus de coordination entre OSD, et sensibilité accrue à la latence, au CPU, au réseau et à la taille des blocs.

Ajouter plus de parité ne réduit pas nécessairement la capacité consommée. Le vrai enjeu est l’équilibre entre efficacité, résilience, nombre minimal d’OSD ou de nœuds, et coûts de reconstruction. Plus le profil est ambitieux, plus la conception du cluster doit être rigoureuse.

Ceph recommande que la majorité des déploiements en Erasure Coding disposent d’au moins k + m domaines de panne CRUSH, représentés par des hôtes ou des racks. Si les fragments sont trop concentrés, la perte d’un nœud peut impacter plus de fragments que ce que le profil peut tolérer.

Performances : l’avantage dépend du mode

Replica 3 offre de meilleures performances en écriture pour de petites opérations et des charges aléatoires. Pas besoin de calculer de parité ni de reconstruire des fragments lors des opérations courantes. Le système copie, réplique et confirme immédiatement. C’est particulièrement adapté pour RBD, disques de VM, bases de données, files d’attente ou applications avec beaucoup de petites écritures.

L’Erasure Coding brille quand l’efficience en capacité prime : fichiers de grande taille, données froides ou principalement en lecture, dépôt documentaire, contenu multimédia, sauvegardes secondaires, jeux de données scientifiques. La documentation Ceph présente souvent des cas de stockage froid avec de gros objets et peu d’écritures.

Le problème survient si on utilise l’Erasure Coding comme on ferait avec Replica 3. Les petites écritures sont pénalisantes, la reconstruction après défaillance consomme plus de CPU et de bande passante, et le délai de récupération peut être plus long. En mode dégradé, le cluster doit lire plusieurs fragments, recalculer et rassembler, ce qui augmente la charge.

RBD, CephFS et allow_ec_overwrites

Historiquement, les pools Erasure Coded étaient limités aux opérations de chargement complet d’objets, comme RGW. Depuis Ceph Luminous, l’activation de allow_ec_overwrites autorise les écritures partielles dans des pools Erasure Coded, ce qui ouvre leur utilisation à RBD et CephFS.

Mais cela ne signifie pas que l’Erasure Coding soit systématiquement recommandé pour tout stockage de machine virtuelle. En RBD, l’approche privilégiée consiste à conserver un pool en réplication pour les métadonnées et un pool en Erasure Coding pour les données. Cette architecture fonctionne bien pour des VM peu modifiées ou des gros fichiers. Pour des bases de données très actives ou des charges transactionnelles, Replica 3 reste plus sûr.

La bonne question n’est pas « puis-je utiliser l’Erasure Coding ? » mais « quel est le pattern d’accès en I/O ? » Si l’application écrit intensivement en petits blocs avec une exigence de faible latence, le gain en capacité ne compensera pas le surcoût. Si les écritures sont rares, les lectures peu fréquentes et la volumetrie importante, l’Erasure Coding devient intéressant.

Décision pratique : coût vs comportement

Une architecture optimale combine souvent les deux. Un cluster Ceph peut utiliser des pools Replica 3 pour les charges critiques sensibles à la latence, et des pools Erasure Coding pour les données froides, archives ou stockage d’objets. Cette approche sélective optimise le coût tout en maintenant performance et résilience, une logique similaire à celle des grandes infrastructures IA en Europe qui combinent plusieurs niveaux de stockage selon la nature des charges.

L’Erasure Coding ne remplace pas une stratégie de sauvegarde. Il protège contre la défaillance de disques ou de nœuds dans le cluster, mais pas contre la suppression accidentelle, la corruption logique, les attaques ransomware ou les erreurs humaines. La gestion des sauvegardes, la rétention et la réplication externe restent indispensables pour une protection complète.

Ceph offre une grande flexibilité, mais cette flexibilité demande une conception rigoureuse. Replica 3 est le choix prudent pour des charges critiques et actives. L’Erasure Coding est un outil puissant pour gagner en capacité utile quand le profil des données le justifie. La meilleure décision n’est pas de choisir une technologie gagnante, mais d’affecter chaque approche à l’usage où elle apporte le plus de valeur.

Questions fréquentes sur Ceph Replica 3 et Erasure Coding

Quelle est la différence entre Replica 3 et Erasure Coding dans Ceph ?

Replica 3 conserve trois copies complètes des données sur différents OSD. L’Erasure Coding divise les données en fragments avec des parités pour les reconstruire en cas de panne. Replica 3 consomme plus de capacité, mais offre une latence plus faible et une gestion plus simple.

Que signifie un profil 4+2 en Erasure Coding dans Ceph ?

L’objet est divisé en 4 fragments de données et 2 fragments de parité. La perte de deux fragments est tolérée. Pour 100 TB utiles, environ 150 TB bruts sont nécessaires, contre 300 TB avec Replica 3.

Peut-on utiliser l’Erasure Coding pour des machines virtuelles dans Ceph ?

C’est possible avec allow_ec_overwrites activé et une séparation entre un pool de métadonnées en réplication et un pool de données en Erasure Coding. Ce n’est cependant pas recommandé pour des VM à forte fréquence d’écriture, où Replica 3 reste plus sûr.

Dans quels cas faut-il privilégier l’Erasure Coding ?

Pour de gros fichiers, des données froides, des archives, du stockage d’objets, des sauvegardes secondaires ou des contenus peu modifiés mais volumineux. Pour des charges transactionnelles ou très sensibles à la latence, Replica 3 reste la meilleure option.