Aller au contenu

Réplica 3/2 vs erasure coding : coût, perf, cas d'usage

Day 0 · ConcevoirNiveau 3 · MaîtriserCoursRédigé · à valider en lab

Pour des disques de VM, le réplica 3/2 reste la règle : latence la plus faible, reconstruction simple, fonctionne dès 3 nœuds. L'erasure coding (EC) divise le surcoût de stockage par deux environ, mais demande plus de nœuds, plus de CPU et dégrade les petites écritures aléatoires : on le réserve aux données froides et volumineuses sur des clusters de 6 nœuds et plus.

Comment ça marche

Réplica size/min_size Erasure coding k+m
Principe size copies complètes de chaque objet Objet découpé en k fragments de données + m fragments de parité
Paramètres par défaut PVE size 3, min_size 2 Aucun ; à choisir, par exemple k=4,m=2
Efficacité 1/size : 33 % en 3/2 k/(k+m) : 67 % en 4+2, 73 % en 8+3
Pannes tolérées sans perte size - 1 (2 en 3/2) m
I/O maintenues tant qu'il reste min_size copies (2) min_size fragments : k si m = 1, k + 1 si m > 1
Hôtes nécessaires (failure domain host) size, size + 1 pour reconstruire k + m, k + m + 1 pour reconstruire
Petites écritures aléatoires Rapides : écriture directe des copies Lentes : lecture-modification-écriture des fragments, calcul de parité
CPU Faible Plus élevé (encodage, décodage, reconstruction)
Reconstruction Simple copie Lecture de k fragments pour recalculer le manquant : plus de trafic réseau
Modifiable après coup size, min_size, règle CRUSH Profil k, m, failure domain non modifiables : il faut créer un nouveau pool et migrer

size est le nombre de copies voulues ; min_size le minimum pour accepter des I/O. Avec 3/2, perdre une copie laisse le service actif ; en perdre deux suspend les I/O du PG concerné, sans perte de données, jusqu'au retour d'une copie.

Comparaison chiffrée

Pour 100 To bruts, avant marge de reconstruction (voir Sizing Ceph) :

Mode Utile théorique Nœuds minimum (recommandé) Usage MSP
Réplica 3/2 33 To 3 (4) Disques de VM, bases de données, par défaut
Réplica 2/1 50 To 2 Proscrit en production
EC 2+1 67 To 3 (4) Déconseillé : min_size = k = 2, plus aucune marge pendant une panne
EC 4+2 67 To 6 (7) Archives, CephFS de fichiers volumineux, gros clusters
EC 8+3 73 To 11 (12) Très gros clusters de capacité, hors périmètre HCI courant

Erasure coding sur Proxmox VE

Les images RBD ne peuvent pas stocker leurs métadonnées dans un pool EC. pveceph crée donc deux pools : un pool de données EC et un pool de métadonnées répliqué, puis un stockage PVE qui les associe. La création se fait en CLI.

# Pool EC 4+2, failure domain host, OSD de classe ssd
pveceph pool create ceph-ec --erasure-coding k=4,m=2,failure-domain=host,device-class=ssd
# Résultat : pools ceph-ec-data (EC) et ceph-ec-metadata (réplica 3/2), stockage PVE "ceph-ec"

ceph osd pool ls detail | grep ceph-ec        # vérifier les deux pools
ceph osd erasure-code-profile ls              # profil créé
cat /etc/pve/storage.cfg                      # entrée rbd avec data-pool ceph-ec-data

Les options --size, --min_size et --crush_rule s'appliquent au pool de métadonnées répliqué. Pour rattacher un pool EC existant : pvesm add rbd <stockage> --pool <pool-répliqué> --data-pool <pool-ec>.

Recommandations MSP

  • Pool ceph-vm en réplica 3/2 pour toutes les VMs. Ne jamais descendre min_size à 1, même temporairement, sans le MSP.
  • EC seulement si le cluster compte au moins k + m + 1 nœuds et si les données sont froides : archives, médias, dépôts de fichiers volumineux.
  • Pas de datastore PBS sur un pool EC du même cluster : la sauvegarde doit rester indépendante du stockage de production.
  • Le choix du mode se fait au Day 0 : changer de mode impose de migrer toutes les données. La création d'un pool EC est réalisée ou validée par le MSP.

Pièges vus en support

  • EC 2+1 sur 3 nœuds « pour gagner de la place » : une panne de nœud laisse exactement k fragments, la moindre erreur de disque devient une perte de données, et aucune reconstruction n'est possible.
  • Bases de données posées sur un pool EC : latences d'écriture multipliées, plaintes applicatives.
  • Croire que l'on peut passer un pool de 4+2 à 6+2 : le profil est figé à la création.
  • Mélanger dans un même cluster des pools avec règles par classe de disque et des pools sans classe : l'autoscaler de PG ne fonctionne plus correctement (voir Règles CRUSH).

Testez-vous

  1. Quelle est la capacité utile théorique de 60 To bruts en EC 4+2 ?

    Réponse

    60 × 4 / 6 = 40 To, contre 20 To en réplica 3/2.

  2. Combien d'hôtes faut-il pour qu'un pool EC 4+2 se reconstruise après la perte d'un nœud ?

    Réponse

    Au moins 7 : 6 hôtes pour placer les 6 fragments (failure domain host) plus un hôte de réserve pour reconstruire le fragment perdu.

  3. Pourquoi pveceph pool create --erasure-coding crée-t-il deux pools ?

    Réponse

    Les métadonnées RBD (en-têtes, omap) ne peuvent pas être stockées dans un pool EC. Proxmox crée un pool -data en EC pour les blocs et un pool -metadata répliqué pour les métadonnées.

  4. Pourquoi ne pas mettre min_size 1 sur un pool en réplica 3 pendant une panne pour « débloquer » les VMs ?

    Réponse

    Avec une seule copie, toute nouvelle écriture n'existe qu'à un endroit. Une seconde panne pendant cette fenêtre fait perdre des données. Proxmox le déconseille explicitement ; la décision relève du MSP en situation de crise.

Pour aller plus loin