Ceph propose différentes stratégies pour assurer la protection des données dans un cluster distribué, parmi lesquelles deux approches prédominent : la réplication en triplicate, communément appelée Replica 3, et l’Erasure Coding, une technique qui divise les données en fragments et ajoute des informations de parité permettant leur reconstruction en cas de défaillance. Le choix entre ces méthodes n’est pas anodin, car 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 adaptées à chaque solution.

Dans un contexte où le coût de capacité augmente, où la croissance des données devient exponentielle, et où la pression pour optimiser les budgets s’intensifie, l’Erasure Coding revient souvent dans le débat. Toutefois, il ne s’agit pas d’un remplacement direct de Replica 3. Dans Ceph, chaque approche trouve sa place dans des scénarios spécifiques ; une erreur de choix peut transformer une économie de stockage en un goulot d’étranglement en termes de performance ou de disponibilité.

Replica 3 : simplicité, rapidité, coûteuse 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. En cas de défaillance d’un disque ou d’un nœud, le cluster conserve deux copies, garantissant ainsi la disponibilité des données. Cette simplicité explique sa popularité dans les environnements de virtualisation, bases de données, stockage de machines virtuelles et charges sensibles à la latence.

Son principal inconvénient réside dans le coût : pour 1 TB de données utiles, il faut prévoir environ 3 TB de stockage brut, ce qui représente un overhead de 200 %. Cependant, cette approche offre une opération plus simple, moins de calculs nécessaires et un comportement très prévisible en lecture comme en écriture. Pour les volumes de données critiques, tels que RBD, machines virtuelles ou systèmes transactionnels, Replica 3 reste une option solide et éprouvée.

Le principal désavantage apparaît lorsque la capacité du volume augmente considérablement. Stocker des dizaines ou centaines de téraoctets avec Replica 3 implique d’acquérir énormément de capacité brute, ce qui peut devenir prohibitif pour des données froides, archivées ou dont les accès sont peu fréquents. Dans ces cas, des solutions plus efficaces en capacité peuvent être envisagées.

Erasure Coding : capacité plus efficace, calcul supplémentaire et planification accrue

L’Erasure Coding fonctionne différemment. Au lieu de dupliquer intégralement chaque objet, Ceph le divise en fragments désignés par le paramètre k et ajoute des fragments de parité, définis par m. Grâce à ces fragments, il est possible de 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 OSDs.

Par exemple, pour un profil 4+2, les données sont réparties en 4 fragments, auxquels s’ajoutent 2 fragments de parité. Cela permet de tolérer la perte de deux fragments tout en réduisant la capacité brute nécessaire par rapport à Replica 3. Concrètement, pour stocker 100 TB utiles, il faut environ 150 TB de capacité brute avec un profil 4+2, contre 300 TB pour Replica 3. Cette méthode est plus efficace, mais elle exige un calcul de parité pour chaque écriture, plus de coordination entre OSD, et une sensibilité accrue à la latence, au CPU, au réseau et à la taille des blocs.

Il est important de souligner que l’Erasure Coding ne permet pas systématiquement d’économiser davantage de capacité en ajoutant plus de parité. Le vrai enjeu réside dans l’équilibre entre efficacité, résilience, nombre minimal d’OSDs ou de nœuds, et coûts de reconstruction. Plus le profil est ambitieux, plus il est crucial de concevoir soigneusement le cluster.

Ceph recommande que la majorité des déploiements utilisant des pools en Erasure Coding disposent d’au moins k + m domaines de panne CRUSH, souvent représentés par des hôtes ou des racks. Il ne faut pas se limiter à la simple présence de disques, car 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 : avantage selon le mode

Replica 3 offre généralement de meilleures performances en écriture pour de petites opérations, charges aléatoires, et dans les services nécessitant une faible latence. Il n’est pas nécessaire de calculer la parité ni de reconstruire des fragments lors d’opérations classiques. Le système copie, réplique et confirme instantanément. Cela le rend particulièrement adapté pour RBD, disques de VM, bases de données, files d’attente ou applications avec beaucoup de petites écritures.

En revanche, l’Erasure Coding excelle lorsque l’efficience en capacité prime, pour des données volumineuses, peu modifiées, ou majoritairement en lecture. Les fichiers de grande taille, stockage d’objets, dépôt documentaire, contenu multimédia, sauvegardes secondaires, jeux de données scientifiques ou archives peuvent tirer parti de sa moindre overhead. La documentation Ceph présente souvent des cas de stockage froid avec de gros objets et peu d’écritures en comparaison des lectures.

Le problème apparaît si on essaie d’utiliser l’Erasure Coding comme le ferait une Replica 3. Les petites écritures sont pénalisantes, la reconstruction après défaillance nécessite 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 réassembler, ce qui augmente la charge du système.

RBD, CephFS et gestion d’allow_ec_overwrites

Historiquement, l’utilisation des pools Erasure Coded se limitait principalement aux opérations de chargement complet d’objets, comme celles de RGW. Depuis Ceph Luminous, il est possible d’activer allow_ec_overwrites pour permettre des écritures partielles dans des pools Erasure Coded, ouvrant la voie à leur utilisation avec RBD, CephFS et ceintures de stockage.

Cependant, 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 à maintenir un pool en réplication pour les métadonnées, tout en utilisant un pool en Erasure Coding pour les données. Bien adaptée dans certains cas, cette architecture nécessite cependant une compréhension précise de ses implications. Pour une VM avec peu de changements ou de gros fichiers, cela peut être intéressant. En revanche, pour des bases de données très actives ou des charges transéconomiques, Replica 3 reste souvent plus sûr.

En virtualisation, la question ne doit pas être « puis-je utiliser l’Erasure Coding ? » mais « quel est le pattern d’accès en I/O ? » Si l’application écrit intensément, en blocs petits, avec une exigence de faible latence, le gain en capacité risque de ne pas compenser le coût supplémentaire. Si, au contraire, les écritures sont rares, les lectures peu fréquentes, et la volumétrie importante, l’Erasure Coding devient une option séduisante.

Décision pratique : coût vs comportement

La comparaison entre Replica 3 et l’Erasure Coding commence souvent par la capacité, mais devrait se conclure sur le type de service recherché. Replica 3 consomme davantage en capacité, mais simplifie la gestion et garantit un comportement performant pour les charges actives. L’Erasure Coding permet de réduire la capacité nécessaire, mais demande plus de calcul, une architecture réseau adaptée, et une planification minutieuse des domaines de panne et profils.

Une architecture optimale combine souvent ces deux approches. Un cluster Ceph peut utiliser des pools Replica 3 pour héberger des charges critiques sensibles à la latence, et dédier d’autres pools en Erasure Coding pour des données froides, archives ou stockage d’objets. Cette approche sélective optimise le coût tout en maintenant la performance et la résilience.

Il est également important de rappeler que 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 ne prévient pas la suppression accidentelle, la corruption logique, les attaques ransomware ou les erreurs humaines. La gestion des sauvegardes, la rétention, ainsi que la restauration de test ou la réplication extérieure restent indispensables pour une protection complète.

Ceph offre une grande flexibilité, mais cette dernière nécessite une conception rigoureuse. Replica 3 est la réponse prudente pour des charges critiques et actives. L’Erasure Coding, quant à lui, est un outil puissant pour gagner efficacement en capacité utile lorsque le profil de données le permet. 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

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

Replica 3 conserve trois copies complètes des données, tandis que l’Erasure Coding divise les données en fragments avec des parités pour leur reconstruction en cas de panne. Replica 3 consomme plus de capacité, mais offre généralement une latence plus faible et une gestion plus simple.

Que signifie un profil 4+2 en Erasure Coding ?

Cela indique que chaque objet est divisé en 4 fragments de données et 2 fragments de parité. Il peut tolérer la perte de deux fragments, offrant ainsi une meilleure efficacité capactité que Replica 3.

Puis-je utiliser l’Erasure Coding pour des machines virtuelles ?

C’est possible avec une configuration adaptée, comme l’activation de allow_ec_overwrites et une séparation entre un pool de métadonnées en réplication et un pool de données en Erasure Coding. Toutefois, ce n’est pas recommandé pour des VM critiques ou des charges à forte fréquence d’écriture, où Replica 3 reste plus sûr.

Quand faut-il privilégier l’Erasure Coding ?

Il est pertinent 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. En revanche, pour des charges transactionnelles ou très sensibles à la latence, Replica 3 demeure souvent la meilleure option.