Quatre nœuds de 10 To ne stockent pas 20 To de données de VM en RF2. Réplication, réserve de reconstruction, seuil où Stargate refuse les écritures : la capacité utile se calcule en trois étapes, et dépend aussi du domaine de panne.
Deux réglages au nom presque identique
- Replication factor (RF) : nombre de copies des données. Selon la Nutanix Bible : « Data RF is configured via Prism and is done at the container level. » C’est lui qui consomme de la capacité.
- Redundancy factor : réglage du cluster. Selon une réponse d’un employé Nutanix sur le forum communautaire (2020), passer le cluster de 2 à 3 ne change pas sa capacité ; il conserve alors 5 copies des métadonnées Cassandra et de la configuration Zookeeper au lieu de 3, et peut héberger des conteneurs RF2 comme RF3.
La Bible relie les deux par le niveau de tolérance aux pannes (FT) : FT1 correspond aux métadonnées en RF3 et aux données en RF2, FT2 aux métadonnées en RF5 et aux données en RF3. D’où le minimum de 5 nœuds pour RF3, « since metadata will be RF5 ».
Étape 1 : le coût de la réplication
La Bible chiffre le coût : 2X en RF2, 3X en RF3. Josh Odgers le traduisait en 2015 par environ 50 % et 33 % du brut utilisables.
L’erasure coding réduit ce coût si le cluster est assez grand : selon la Bible, la bande 4/1 (1,25X) n’existe qu’à partir de 6 nœuds, la 4/2 (1,5X) qu’à partir de 8. Détails dans ce billet sur l’erasure coding.
Étape 2 : réserver la reconstruction
Après une panne, le cluster reconstruit les copies manquantes sur les nœuds restants. La Resilient Capacity est ce qui reste utilisable après la perte prévue, le cluster pouvant encore revenir au RF voulu ; Nutanix recommande de ne jamais la dépasser. L’option Reserve Rebuild Capacity et le piège des clusters hétérogènes sont détaillés dans la simulation de capacité.
Étape 3 : le seuil de 95 %
La Bible pose la limite physique : « 95% is threshold at which Stargate goes read-only mode not taking any more user writes. » Son exemple, en FT1 et RF2 sur quatre nœuds de 10 To :
Resilient Capacity = (40 - 10) × 0,95 = 28,5 ToLa Bible s’arrête à 28,5 To physiques. Calcul de l’auteur : en RF2, 28,5 / 2 = 14,25 To de données de VM avant réduction de données, loin des 20 To d’un calcul « brut divisé par deux ».
Selon un billet du blog communautaire Nutanix (2021, mis à jour en 2022), Prism affichait alors la barre de capacité en orange au-delà de 75 % de la Resilient Capacity (seuil par défaut), en rouge au-delà de 100 %.
Domaines de panne : bloc et rack
Disque et nœud sont toujours des domaines de panne. Bloc et rack sont optionnels : les répliques sont alors écrites dans d’autres blocs ou racks.
Minimums donnés par la Bible :
| Domaine | FT1 sans EC | FT1 avec EC | FT2 sans EC | FT2 avec EC |
|---|---|---|---|---|
| Nœud | 3 nœuds | 4 nœuds | 5 nœuds | 6 nœuds |
| Bloc | 3 blocs | 4 blocs | 5 blocs | 6 blocs |
| Rack | 3 racks | 4 racks | 5 racks | 6 racks |
La block awareness fonctionne sur option ou en « best effort » ; en dessous de 3 blocs, c’est la node awareness qui s’applique. La rack awareness suppose que l’administrateur ait déclaré ses racks.
Conséquence sur la capacité : en domaine bloc, ce n’est plus la perte d’un nœud qu’il faut absorber, mais celle d’un bloc entier. La réserve de reconstruction grossit d’autant.
Ce qu’il faut retenir
- Le replication factor se règle par conteneur et coûte 2X ou 3X ; le redundancy factor du cluster ne change pas la capacité.
- RF3 exige 5 nœuds, à cause des métadonnées en RF5, et seuls les conteneurs RF3 tolèrent deux pannes simultanées.
- Capacité de données de VM = (brut − réserve de reconstruction) × 0,95, divisé par le coût du RF, avant réduction de données.
- En domaine bloc ou rack, la réserve se compte en blocs ou en racks, avec au moins 3 unités en FT1 et 5 en FT2 sans erasure coding.
In English
Replication factor per container, redundancy factor per cluster, the 95 % threshold where Stargate refuses writes, and block and rack fault domains. A step-by-step calculation of usable capacity: the replication factor costs capacity while the cluster redundancy factor only sets metadata copies, and FT2 means metadata in RF5 and data in RF3, hence a minimum of 5 nodes.
Sources & vérification
Relevé sur : Documentation publique Nutanix (Nutanix Bible) et forums Nutanix Community, relevé 2026-10
- Nutanix Bible, Data Resilience and HA nutanixbible.com
- Nutanix Bible, Data Efficiency (Erasure Coding) nutanixbible.com
- Nutanix Community, Redundancy Factor vs Replication Factor (2020) next.nutanix.com
- Nutanix Community, RF2 -> RF3 (2020) next.nutanix.com
- Nutanix Community, Managing Storage Resiliency is now Simpler than Ever (2021, mis à jour 2022) next.nutanix.com
- Josh Odgers, RF2 & RF3 Usable Capacity with Erasure Coding (EC-X) (2015) joshodgers.com