Une feuille de sizing OSA ne se convertit pas en ESA en changeant le nom de deux colonnes. OSA raisonne en disk groups, cache et capacité. ESA raisonne en storage pool, capacité brute réclamée, System Usage et RAID Factor. VCF 9.1 ajoute une vue Effective Capacity qui rend cette nouvelle arithmétique explicite — à condition d’utiliser Auto-RAID.
Nordwind Logistics doit arbitrer une seule enveloppe pour trois clusters : cl-fret-prod-01, ESA avec 8 hôtes ; cl-fret-dens-01, ESA avec 4 hôtes et candidat au memory tiering ; cl-fret-legacy-01, OSA avec 6 hôtes et 2 disk groups par hôte. Le dernier est un point de comparaison, pas une architecture cible.
Pas de lab, donc pas de ratio inventé
La méthode vient de Broadcom, mais aucune valeur Nordwind de System Usage, de réduction de données ou de capacité libre n’a été relevée. Cette absence ne bloque pas l’article : elle oblige à montrer où saisir les valeurs réelles et à signaler ce qui doit être vérifié sur la plateforme cible.
TL;DR
- En ESA 9.1, la base est
Total Usable Capacity = (Total Raw Capacity - System Usage) / RAID Factor. - Les anciennes lignes operations reserve et host rebuild reserve ont disparu de l’interface 9.1 ; ne les réinjecte pas comme méthode actuelle.
- Compression, déduplication, thin provisioning et snapshots sont des effets mesurés séparément, pas un ratio de réduction promis.
- Un NVMe réservé au memory tiering ne peut plus contribuer au storage pool : le sizing doit compter les slots, pas seulement les téraoctets.
D’abord, abandonner la traduction ligne à ligne
Dans OSA, chaque disk group comporte un périphérique de cache flash et un ou plusieurs périphériques de capacité. Dans ESA, les périphériques réclamés par vSAN forment un storage pool par hôte et contribuent tous à la capacité et à la performance.
Cette différence rend plusieurs réflexes caducs : conserver une ligne de cache, reporter une réserve héritée ou appliquer un taux de réduction supposé. Une feuille ESA doit repartir des objets que la version actuelle expose.
| Poste OSA | Poste ESA 9.1 | Traitement |
|---|---|---|
| cache par disk group | aucun équivalent direct | supprimer la ligne, inventorier le storage pool |
| périphériques de capacité | tous les NVMe réclamés par vSAN | additionner la capacité brute réclamée |
| operations / host rebuild reserve | absents de l’interface 9.1 | ne pas les utiliser comme formule actuelle |
| règle de slack en pourcentage | aucune règle chargée | définir une marge locale et la qualifier |
| réduction de données globale | mesures Space Efficiency séparées | observer, ne pas prédire |
| capacité utile | Effective Capacity | appliquer la formule publiée |
RECONSTITUTION : ce tableau assemble plusieurs pages officielles. Aucune page TechDocs 9.1 chargée ne compare directement les méthodes de sizing OSA et ESA.
La formule Effective Capacity
La documentation VCF 9.1 publie l’équation suivante :
Total Usable Capacity = (Total Raw Capacity - System Usage) / RAID Factor- Total Raw Capacity additionne les volumes des disques réclamés.
- System Usage comprend les métadonnées globales, l’overhead du filesystem, les objets ESA, l’overhead de déduplication et les réservations système.
- RAID Factor vient de la configuration réelle du cluster.
L’exemple Broadcom calcule (40 - 14.5) / 1.5 et obtient 17 To utiles. Les 14.5 To de System Usage appartiennent uniquement à cet exemple : la documentation chargée ne fournit aucune méthode pour les extrapoler selon la taille ou le nombre d’hôtes.
DOCUMENTÉ — la valeur à relever
La vue de capacité affiche la capacité utile totale, consommée et libre. Le calcul de projet doit reprendre son System Usage observé et son RAID Factor effectif, jamais un pourcentage générique.
RÉSULTAT_ATTENDU : la feuille de sizing et la vue Effective Capacity convergent lorsqu’elles utilisent la même capacité brute, le même System Usage et le même RAID Factor. Si la vue cible n’a pas encore été relevée, la cellule doit dire « à collecter sur la plateforme » plutôt que contenir une estimation.
Auto-RAID fournit le facteur, pas le besoin
La vue Effective Capacity de VCF 9.1 exige Auto-RAID. Pour un cluster standard, Broadcom publie :
| Taille | Politique appliquée | RAID Factor |
|---|---|---|
| moins de 3 hôtes | FTT=0 | 1.0x |
| 3 à 5 hôtes | FTT=1, RAID-5 | 1.5x |
| 6 hôtes ou plus | FTT=2, RAID-6 | 1.5x |
Pour un cluster stretched, le mirroring entre sites porte le facteur à 3.0x à partir de 3 hôtes par site avec RAID-5 ou RAID-6 local. Un cluster 2-node utilise un miroir avec FTT=0 local et un facteur 2.0x.
Les nouveaux clusters utilisent Auto-RAID par défaut. Les clusters existants conservent leur politique et reçoivent une alerte de santé recommandant la migration. Le nombre d’hôtes n’est donc jamais une preuve suffisante de l’état effectif.
Le chemin d’écriture RAID-5/6 sur ESA explique pourquoi ces politiques deviennent des défauts crédibles. Le capacity planning, lui, doit rester agnostique : il lit le facteur réellement appliqué.
Ce qui remplace les réserves héritées
En vSAN 8.0, operations reserve réservait de l’espace aux opérations internes et host rebuild reserve à la réparation après perte d’un hôte. La première incluait un buffer additionnel de 5 %. Ce modèle explique les anciennes feuilles, mais Broadcom indique qu’en 9.1 ces mécanismes ne sont plus dans l’interface, car ils appartenaient à l’approche précédente de gestion de capacité.
Cela ne signifie pas qu’une exploitation peut consommer sans discipline tout ce qu’affiche un disque. Cela signifie que la marge opérationnelle locale n’est plus obtenue en recopiant une réserve 8.0 dans la formule 9.1.
À_VALIDER_EN_LAB — la marge opérationnelle
Aucune source chargée ne donne une règle universelle de slack en pourcentage pour ESA 9.1. La marge doit être décidée à partir de la croissance, des scénarios de panne, du temps d’approvisionnement et des observations de resynchronisation sur une plateforme de test ou pendant un pilote.
HYPOTHÈSE_DE_DESIGN : Nordwind conserve une marge d’exploitation séparée de la formule éditeur et la documente comme une décision interne. Elle n’est jamais présentée comme un prérequis Broadcom.
Mesurer l’efficacité d’espace sans la préacheter
VCF 9.1 fait passer la compression ESA de LZ4 à ZSTD. Broadcom décrit ZSTD comme offrant potentiellement une meilleure compression avec un coût CPU modeste, sans publier de chiffre. La global deduplication devient cluster-wide et post-process ; elle n’est pas supportée sur les clusters stretched ni 2-node.
La vue Space Efficiency sépare le ratio de réduction des données, les gains du thin provisioning et ceux des snapshots. Cette séparation doit rester dans la feuille de calcul. Additionner compression et déduplication dans un ratio unique avant observation masque le risque.
La méthode conservatrice est simple :
- acheter sur la capacité utile sans gain non observé ;
- relever chaque ratio après stabilisation du workload ;
- utiliser la tendance pour la prévision suivante ;
- vérifier sur plateforme de test toute assertion de gain ou de coût CPU propre aux données.
Les slots NVMe ferment l’équation
Un périphérique déjà réclamé par vSAN ne peut pas servir au memory tiering. Le tier mémoire NVMe exige un disque local, compatible et non réclamé ; son mirroring 9.1 en exige un second de taille compatible.
L’arbitrage de cl-fret-dens-01 doit donc suivre cet ordre :
- définir la capacité utile et la résilience minimales ;
- compter les NVMe nécessaires au storage pool ;
- réserver ensuite le ou les slots du tier mémoire ;
- recalculer la capacité brute ESA après cette réservation ;
- comparer le coût final à l’ajout de DRAM ou de châssis.
La contrainte physique évite un business case fictif où le même NVMe double la mémoire tout en restant disponible au stockage.
Cette approche complète VCF 9.1, efficience infra et TCO : un gain de densité ne vaut que si les ressources sacrifiées sont visibles dans le même modèle économique.
Conclusion
Partir du brut
Retirer le System Usage observé, puis appliquer le RAID Factor réel.
Séparer les gains
Compression, dédup, thin et snapshots restent des mesures distinctes.
Compter les slots
Le budget NVMe relie capacité de stockage et densité mémoire.
ESA ne rend pas le capacity planning plus vague ; il le recentre sur des valeurs observables. La formule est publiable sans lab. Le System Usage, la marge et les ratios locaux restent simplement identifiés comme des données à vérifier sur la plateforme cible.
Sources principales : Effective Capacity VCF 9.1, nouvelle vue de capacité, Auto-RAID VCF 9.1 et compression et déduplication VCF 9.1.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
