Hardware et Configuration¶
Quel matériel utiliser pour créer un cluster Ceph ? C’est sans doute la question qui revient le plus souvent. Initialement, Ceph s’appuyait sur un système de fichiers Linux et des disques à plateaux pour créer les OSD, chaque objet étant stocké sous forme de fichier. De nos jours (2026), il est courant d’utiliser des disques HDD, SSD ou NVMe, avec une interconnexion réseau IPv4 ou IPv6 de 10, 25, 40 voire 100 Gbit/s.
Depuis la version Mimic, Ceph exploite une partition BlueStore pour les objets RADOS et une base RocksDB pour les métadonnées. Il est possible de colocaliser la RocksDB et le WAL (Write-Ahead Log) sur le même disque, ou de les placer sur un disque plus rapide (NVMe) pour améliorer les performances.
Pour choisir le matériel le plus adapté, il faut d’abord définir le type de cluster souhaité :
- performances équilibrées,
- optimisé IOPS,
- optimisé capacité,
- forte tolérance aux pannes,
- capacité totale faible ou élevée.
Le choix du mode de protection des données (réplication ou erasure code) est le premier élément structurant de ce dimensionnement.
Rappel : capacité nette en fonction de la protection (réplication ou Erasure Code)¶
Réplication (Replicated)¶
Avec un pool en réplication, chaque objet RADOS est écrit sur N OSD du pool. Cela consomme N fois plus d’espace de stockage, mais présente l’avantage d’être simple, rapide et de nécessiter très peu de CPU/RAM pour les calculs.
Règles de calcul :
- Capacité nette = Capacité brute / N
- Surcoût stockage = (N - 1) × 100 % de la capacité nette
- Espace utile (%) = (1 / N) × 100
- IOPS en écriture : chaque écriture client génère N écritures OSD. Le débit d’écriture maximal est limité par le plus lent des OSD impliqués, et le nombre total d’IOPS d’écriture côté cluster est celui d’un seul jeu de N OSD. Le parallélisme des clients permet de saturer l’ensemble des OSD.
- IOPS en lecture : on peut lire depuis n’importe quelle réplique. Les lectures peuvent donc être réparties sur tous les OSD du pool, offrant un gain d’IOPS proportionnel au nombre de répliques.
| Réplication (N) | Capacité nette (%) | Surcoût (% / net) |
|---|---|---|
| 2 | 50 % | 100 % |
| 3 | 33,3 % | 200 % |
| 4 | 25 % | 300 % |
Erasure Code (EC)¶
Avec un pool EC, chaque objet est découpé en K fragments de données et M fragments de parité. Le stockage des données consomme donc (K+M) fragments au total. L’erasure coding réduit fortement l’overhead de stockage, au prix d’une consommation CPU/RAM accrue lors des écritures (calcul des parités) et des lectures dégradées (reconstruction).
Règles de calcul :
- Capacité nette (%) = K / (K + M) × 100
- Surcoût stockage (% par rapport aux données utiles) = (M / K) × 100
- Amplification en écriture (écriture d’un stripe complet) = (K + M) / K Autrement dit, pour chaque octet écrit par le client, ((K+M)/K) octets sont écrits sur les OSD.
- IOPS / débit en écriture :
- Écritures séquentielles (full stripe) : débit utile = débit brut d’un OSD × K / (K+M) (si tous les OSD sont de même performance).
- Petites écritures aléatoires : l’amplification peut être bien plus élevée si le pool ne gère pas l’overwrite partiel (lecture/modification/écriture). Les versions récentes de Ceph (à partir de Reef) améliorent ce point.
- IOPS / débit en lecture : en mode normal, la lecture d’un objet ne nécessite que K fragments (parmi K+M). L’amplification en lecture est donc de 1 (pas de surcoût) et le débit peut être agrégé sur K OSD simultanément. En mode dégradé (panne d’un OSD), la lecture nécessite de reconstruire les données à partir de K fragments, ce qui mobilise plus de CPU et de réseau.
Tableau – Erasure code :
| K | M | Capacité utile (%) | Surcoût stockage (%) | Amplification écriture (ratio) |
|---|---|---|---|---|
| 2 | 1 | 66,7 % | 50 % | 1,5 |
| 2 | 2 | 50,0 % | 100 % | 2,0 |
| 2 | 3 | 40,0 % | 150 % | 2,5 |
| 3 | 1 | 75,0 % | 33,3 % | 1,33 |
| 3 | 2 | 60,0 % | 66,7 % | 1,67 |
| 3 | 3 | 50,0 % | 100 % | 2,0 |
| 4 | 1 | 80,0 % | 25 % | 1,25 |
| 4 | 2 | 66,7 % | 50 % | 1,5 |
| 4 | 3 | 57,1 % | 75 % | 1,75 |
| 5 | 1 | 83,3 % | 20 % | 1,2 |
| 5 | 2 | 71,4 % | 40 % | 1,4 |
| 5 | 3 | 62,5 % | 60 % | 1,6 |
| 6 | 1 | 85,7 % | 16,7 % | 1,17 |
| 6 | 2 | 75,0 % | 33,3 % | 1,33 |
| 6 | 3 | 66,7 % | 50 % | 1,5 |
| 7 | 1 | 87,5 % | 14,3 % | 1,14 |
| 7 | 2 | 77,8 % | 28,6 % | 1,29 |
| 7 | 3 | 70,0 % | 42,9 % | 1,43 |
| 8 | 1 | 88,9 % | 12,5 % | 1,13 |
| 8 | 2 | 80,0 % | 25 % | 1,25 |
| 8 | 3 | 72,7 % | 37,5 % | 1,38 |
Remarques¶
- Le profil 4+2 est souvent considéré comme le meilleur compromis entre efficacité capacitive et performance. Il offre 66,7 % de capacité utile avec une bonne résilience (tolère la perte de 2 OSD).
- Pour des clusters orientés très forte capacité, on peut monter jusqu’à 8+2 ou 8+3, au prix d’une amplification d’écriture plus élevée et d’une consommation CPU supérieure.
- La réplication reste la solution la plus performante en IOPS (surtout en écritures aléatoires), mais son coût de stockage peut devenir prohibitif sur de grands volumes.
Résumé des profils¶
| Profil | Type | Préconisation | Remarques |
|---|---|---|---|
| Perf équilibrée | EC | 4+2 | RocksDB et WAL sur disques rapides (NVMe) |
| Orienté capacité | EC | 6+2 ou 8+2 | Colocalisation possible de la RocksDB/WAL |
| Forte tolérance | EC | 4+3 ou 6+3 | Pour les contraintes de type bancaire ; IOPS en baisse |
| Petits clusters | EC | 2+2 ou 3+2 | Réduit le nombre minimal de serveurs pour faire de l’EC |
| Performance pure | Rep | 3x | Idéal pour bases de données ou volumes très sollicités (virtualisation avec du stockage RBD) |
| Très forte résilience | Rep | 4x | Rare, adapté à des données critiques sans contrainte de capacité |
Changements à venir¶
À partir de Ceph Tentacle (v20.2.x), l’erasure coding évolue fortement avec l’introduction des pools FastEC et de nouvelles techniques d’encodage :
- FastEC : utilisation d’algorithmes optimisés qui réduisent la pénalité réseau et CPU lors des reconstructions. FastEC introduit notamment les lectures partielles (partial reads), les écritures partielles (partial writes) et les écritures par delta de parité (parity delta writes), réduisant drastiquement l’amplification d’IO pour les petites écritures aléatoires.
- Accélération matérielle : support d’instructions vectorielles (Intel AVX-512, ARM NEON) pour le calcul des parités, diminuant drastiquement la charge CPU.
- Écritures partielles améliorées : l’overwrite partiel devient plus efficace grâce à l’optimisation Parity Delta Writes, permettant d’utiliser l’EC même pour des charges en écriture aléatoire (RBD, CephFS).
Support des plugins EC¶
Depuis Tentacle, le plugin par défaut pour les nouveaux pools EC est passé de Jerasure à ISA-L, car la bibliothèque Jerasure n’est plus maintenue. FastEC a introduit une nouvelle interface entre Ceph et les plugins d'erasure code : en pratique, seuls ISA-L (techniques reed_sol_van et cauchy) et Jerasure (technique reed_sol_van) supportent FastEC.
Dans la perspective de la version V (après Umbrella), la communauté Ceph a officiellement annoncé la fin du support pour plusieurs plugins et techniques historiques.
Plugins et techniques qui seront supprimés dans la version V :
- Jerasure : reed_sol_r6_op, cauchy_orig, cauchy_good, liberation, blaum_roth, liber8tion
- SHEC (Shingled Erasure Code)
- CLAY (Coupled Layer)
Plugins et techniques qui continueront d’être supportés dans la version V :
- Jerasure : uniquement reed_sol_van
- ISA-L : reed_sol_van et cauchy
- LRC (Locally Repairable Erasure Code) : bien que FastEC ne le supporte pas encore, il est conservé pour une utilisation future, notamment pour les clusters étendus (stretched clusters)
La raison de cette rationalisation est triple : la télémétrie montre que l’immense majorité des clusters utilisent déjà reed_sol_van (Jerasure ou ISA-L), les performances de reed_sol_van sur les CPU modernes sont excellentes, et la maintenance d’un grand nombre de plugins représente une charge de développement et de test importante.
source : https://ceph.io/en/news/blog/2025/ending-support-for-ec-plugins/
La version suivante, Ceph Umbrella (v21.2.x), continuera d’estomper les différences entre réplication et erasure code, avec l’introduction prévue des Direct Reads (lectures directes depuis les OSD secondaires sans rebond vers le primaire), rendant l’EC compétitif sur quasiment tous les plans, capacité comme IOPS.
Ces évolutions pourront remettre en cause les recommandations actuelles et élargir l’usage de l’EC aux clusters historiquement cantonnés à la réplication.
Les prérequis:¶
a completer Matériel, réseau, système d'exploitation.
Les différentes méthodes d'installation:¶
a completer Manuelle, automatisée (outils comme cephadm, cephadmAnsible).
Les principaux paramètres de configuration:¶
Résilience, performances, sécurité