En RF2, chaque octet est stocké deux fois ; en RF3, trois fois. L’erasure coding de Nutanix, EC-X, remplace une partie de ces copies par de la parité et peut ramener le surcoût à 1,25x, à condition que les données s’y prêtent et que le cluster soit assez grand.
Le principe
Comme en RAID 4, 5 ou 6, EC-X encode un « strip » de blocs de données répartis sur des nœuds différents et calcule une parité. Chez AOS, le bloc de données est un extent group. Le nombre de blocs de données et de parité dépend du niveau de tolérance visé : par défaut 4/1 pour une disponibilité équivalente à RF2, 4/2 pour l’équivalent RF3. Selon la Nutanix Bible :
- strip 4/1 : surcoût de 1,25x, contre 2x en RF2 ;
- strip 4/2 : surcoût de 1,5x, contre 3x en RF3.
Le calcul complet de la capacité utile en RF2 et RF3 est dans ce billet.
Le strip se règle au niveau du container, via ncli container create ou edit et le paramètre erasure-code=<N>/<K> (N blocs de données, K blocs de parité).
Post-process, sur les données froides en écriture
EC-X ne touche pas au chemin d’écriture. L’écriture passe d’abord en RF classique (voir le chemin d’une écriture), puis Curator, lors de ses scans complets, repère les extent groups « write-cold », ceux qui n’ont pas été écrits depuis un certain temps. Le seuil est le gflag curator_erasure_code_threshold_seconds ; la Bible n’en donne pas la valeur. Une fois le strip encodé, les répliques sont supprimées.
Froid en écriture ne veut pas dire froid en lecture : selon Josh Odgers en 2015, des données chaudes en lecture restent candidates tant qu’elles ne sont pas réécrites. Son exemple de 2020, sur le blog communautaire Nutanix : sur un serveur SQL de 10 To dont 1 To est activement écrit, EC-X s’applique aux 9 To restants, le To chaud gardant la protection RF.
Le gain de capacité arrive donc progressivement : en 2018, Odgers notait que la tâche ErasureCode:Encode a une priorité 3, contre 1 pour la reconstruction après panne.
Combien de nœuds
Tableau de la Bible :
| Nœuds | Strip FT1 | Surcoût | Strip FT2 | Surcoût |
|---|---|---|---|---|
| 4 | 2/1 | 1,5x | N/A | N/A |
| 5 | 3/1 | 1,33x | N/A | N/A |
| 6 | 4/1 | 1,25x | 2/2 | 2x |
| 7 | 4/1 | 1,25x | 3/2 | 1,6x |
| 8 et plus | 4/1 | 1,25x | 4/2 | 1,5x |
La Bible recommande au moins un nœud (ou un bloc, en placement block-aware) de plus que la taille du strip : 6 nœuds pour un 4/1. Après une panne, Curator peut alors reconstruire les strips, ce qui supprime le surcoût de calcul en lecture.
Ce que ça coûte
- En fonctionnement normal : la Bible annonce aucun impact sur les I/O de lecture et d’écriture.
- En panne : surcoût de lecture tant que la donnée doit être décodée, c’est-à-dire jusqu’à la reconstruction des strips.
- À la réécriture : une donnée froide encodée puis réécrite subit, selon Odgers, une pénalité supérieure à celle d’une écriture RF2 ou RF3.
Quand l’activer, quand l’éviter
À activer : containers dont une large part des données est écrite une fois puis surtout lue. La Bible le juge adapté à la plupart des charges, « ideal for Nutanix Files/Objects », et cumulable avec la compression inline.
À éviter : VDI, charges à forte réécriture, clusters trop petits pour la règle du strip plus un nœud.
L’EC inline, lui, encode dès l’écriture. La Bible ne le recommande que pour les charges sans besoin de localité et sans réécritures nombreuses ; Nutanix Objects l’active par défaut.
Ce qu’il faut retenir
- EC-X s’applique en tâche de fond, par Curator, aux seuls extent groups froids en écriture, même chauds en lecture.
- 4/1 coûte 1,25x contre 2x en RF2, avec au moins 6 nœuds ; 4/2 coûte 1,5x contre 3x en RF3, à partir de 8 nœuds.
- Pas d’impact en fonctionnement normal ; un surcoût de lecture en panne, une pénalité à la réécriture.
- À réserver aux containers majoritairement write-cold, à éviter pour le VDI.
In English
EC-X brings the RF2 overhead down from 2x to 1.25x, but only on write-cold data and only from a certain cluster size. Strips, minimum node counts and real impact: Curator applies it in post-process, a 4/1 strip calls for 6 nodes, and it is not recommended for rewrite-heavy workloads such as VDI.
Sources & vérification
Relevé sur : Documentation publique Nutanix (Nutanix Bible, communauté Nutanix) et blog de Josh Odgers, relevé 2026-10
- Nutanix Bible, Data Efficiency (Erasure Coding) nutanixbible.com
- Josh Odgers, Erasure Coding Comparison – Nutanix ADSF vs VMware vSAN (blog communautaire Nutanix, 2020) next.nutanix.com
- Josh Odgers, Nutanix Erasure Coding (EC-X) Deep Dive (2015) joshodgers.com
- Josh Odgers, Nutanix Resiliency Part 4, Converting RF3 to EC-X (2018) joshodgers.com