Broadcom annonce « jusqu’à -40 % de TCO » avec VCF 9.1. Si tu as déjà entendu ce genre de chiffre, tu sais qu’il faut le décortiquer avant de le mettre dans une slide budget. C’est exactement l’objet de cet article.
VCF 9.1 n’est pas une révolution d’architecture — la rupture, c’était 9.0. C’est une release d’efficience : memory tiering NVMe musclé, déduplication vSAN globale, provisioning vSphere repensé, scale à 5000 hôtes. Chaque brique grignote un poste de coût. Mises bout à bout, elles construisent le chiffre des -40 %. On va voir d’où il vient, ligne par ligne, et ce que ça change pour ton design.
Série « Nouveautés VCF 9.1 » — 1/4
Mini-série sur les nouveautés de VMware Cloud Foundation 9.1 :
- Efficience d’infrastructure & TCO (cet article)
- Networking & scale
- Kubernetes & self-service
- Sécurité & résilience
Prérequis conceptuel : La nouvelle architecture VCF 9.
Crédits visuels
Schémas et captures © Broadcom, repris de la documentation et du blog officiels VCF (liens en fin d’article). Synthèse et analyse personnelles.
Enhanced NVMe Memory Tiering : la RAM qui n’en est pas
Le memory tiering existait déjà en 9.0 en tech preview. En 9.1, il devient une feature de production, et c’est le premier levier du chiffre TCO.
Le principe. L’hyperviseur classe les pages mémoire par chaleur d’accès. Les pages chaudes — celles touchées en permanence par les workloads actifs — restent en DRAM. Les pages froides — buffers dormants, allocations rarement relues — sont déplacées de façon transparente vers un device NVMe local de l’hôte. Le tout est exposé aux VM comme un espace mémoire unifié : une VM voit « sa » RAM, sans savoir qu’une fraction réside physiquement sur du flash.
Pourquoi ça change le coût. La DRAM est le poste matériel le plus cher d’un hôte moderne, et le moins élastique. Avec le tiering, tu étends la mémoire effective d’un hôte sans ajouter une seule barrette : un hôte avec 1 To de DRAM peut présenter 1,5 à 2 To de mémoire adressable selon le ratio froid/chaud des workloads. Résultat direct : un ratio de consolidation plus élevé — plus de VM par hôte, donc moins d’hôtes pour la même charge.
Source : Broadcom — VCF Blog
| Aspect | VCF 9.0 | VCF 9.1 |
|---|---|---|
| Statut | Tech preview | Production, supporté |
| Modèle mémoire | DRAM + NVMe distincts visibles | Modèle unifié transparent pour les VM |
| Classement des pages | Heuristique basique | Détection de chaleur affinée, repromotion dynamique |
| Ratio mémoire effective typique | ~1,25x | ~1,5–2x selon les workloads |
| Intégration DRS | Limitée | DRS conscient du tiering pour le placement |
Impact architecte. Le tiering n’est pas de la RAM gratuite : un défaut de page froide implique un aller-retour NVMe, donc une latence de l’ordre de la dizaine à la centaine de microsecondes au lieu de la nanoseconde de la DRAM. Pour 90 % des workloads d’entreprise (apps web, middleware, bases de taille moyenne), c’est invisible. Pour les workloads latency-sensitive (trading, in-memory DB type SAP HANA, RT analytics), il faut explicitement les pinner sur des hôtes sans tiering ou avec un ratio conservateur. La décision de design : segmenter ton parc en pools « tiering agressif » et « DRAM pure », et router les workloads par profil de sensibilité.
Migration. Pas de rupture : le tiering s’active par cluster. Prévoir le sizing NVMe (device dédié, pas le datastore vSAN) et valider la matrice de compatibilité hôte. Démarrer avec un ratio conservateur, mesurer le swap-in rate dans VCF Operations, puis pousser.
vSAN : déduplication globale et compression étendue
vSAN ESA gagne en 9.1 une déduplication globale à l’échelle du cluster, et non plus au niveau du disque ou du groupe de disques. C’est le deuxième levier TCO.
Ce qui change. En 9.0, la dédup vSAN ESA opérait avec une portée limitée — les blocs identiques n’étaient dédupliqués que dans un périmètre restreint. En 9.1, la portée devient le cluster entier : un bloc identique présent sur dix VM réparties sur dix hôtes n’est stocké qu’une fois logiquement. Les ratios grimpent mécaniquement dès qu’il y a de la redondance de données (OS templates, images de conteneurs, datasets partagés). La compression est étendue en parallèle, avec de meilleurs ratios sur les données déjà compressibles.
Le point qui manquait. 9.1 supporte le chiffrement at-rest des données dédupliquées. C’est le détail qui débloque les contextes réglementés : jusqu’ici, certaines organisations devaient choisir entre efficience de stockage et chiffrement at-rest. Le compromis disparaît.
| Aspect | VCF 9.0 | VCF 9.1 |
|---|---|---|
| Portée dédup | Disque / groupe de disques | Cluster entier (global) |
| Ratio typique observé | 1,5–2x | 2–4x selon redondance des données |
| Compression | Standard ESA | Ratios étendus, plus de types de données |
| Chiffrement + dédup | Mutuellement exclusifs dans certains modes | Dédup sur données chiffrées at-rest supportée |
| Granularité de gestion | Par groupe de disques | Politique cluster, pilotée par SPBM |
Impact architecte. Le gain de capacité se traduit directement en TiB vSAN non achetés — et la licence vSAN se facture au TiB. Mais la dédup globale a un coût CPU et un coût de rebuild : reconstruire une donnée dédupliquée globalement après une panne de disque sollicite plus le cluster qu’un rebuild classique. Dimensionner les hôtes avec une marge CPU, et tester un scénario de perte de disque sur un cluster représentatif avant de promettre les ratios en production.
vSphere Elastic Provisioning / Zero Touch Provisioning
Le provisioning des hôtes ESX est repensé en profondeur. Auto Deploy, la mécanique historique de PXE boot, est progressivement remplacée par un modèle Zero Touch Provisioning (ZTP).
Ce qu’apporte le ZTP. Imaging par le réseau, mais modernisé : découverte automatisée des hôtes nus, imaging parallèle de plusieurs hôtes simultanément, et application du Single Image (vLCM) dès le premier boot. Là où Auto Deploy reposait sur une chaîne PXE/TFTP fragile et un imaging largement séquentiel, le ZTP industrialise le bring-up de cluster — passer de quelques hôtes à plusieurs dizaines sans linéariser le temps de déploiement.
Source : Broadcom — VCF Blog
| Aspect | Auto Deploy (legacy) | ZTP / Elastic Provisioning 9.1 |
|---|---|---|
| Mécanique de boot | PXE / TFTP, stateless ou stateful cache | Imaging réseau moderne, découverte automatisée |
| Parallélisme | Largement séquentiel | Imaging parallèle multi-hôtes |
| Modèle d’image | Baselines ou Single Image | Single Image natif dès le premier boot |
| Découverte d’hôtes | Manuelle / scriptée | Automatisée |
| Trajectoire | En fin de vie | Remplaçant désigné |
Impact architecte. C’est une feature forward-looking : Auto Deploy reste là, mais sa trajectoire est claire. Si tu construis une nouvelle plateforme VCF 9.1, ne pas réinvestir dans une mécanique Auto Deploy custom — partir directement sur le modèle ZTP. Si tu opères un parc existant avec Auto Deploy fortement scripté, planifier la migration comme un chantier à part entière : les hooks, les profils, et les scripts d’auto-déploiement ne se transposent pas tels quels. Le gain opérationnel — temps de bring-up divisé, moins d’heures d’ingénieur par hôte — est un poste réel du calcul TCO.
Scale à 5000 hôtes et vMotion encryption offload
Deux évolutions qui jouent à la fois sur le scale et sur le coût opérationnel.
Scale. Une instance VCF 9.1 supporte désormais jusqu’à 5000 hôtes ESX. Au-delà du chiffre marketing, l’intérêt est la consolidation de domaines : moins d’instances à opérer pour la même flotte physique, donc moins de plans de contrôle, moins de consoles, moins d’overhead de gouvernance. Le coût opérationnel d’une plateforme ne croît pas linéairement avec le nombre d’hôtes si on réduit le nombre d’instances.
vMotion encryption offload. Le chiffrement du trafic vMotion était jusqu’ici porté par le CPU de l’hôte — un coût notable lors de migrations massives (maintenance, rééquilibrage DRS, évacuation d’hôte). En 9.1, ce chiffrement est déchargé sur le matériel réseau (NIC compatibles). Broadcom annonce ~70 % d’économie CPU pendant les migrations chiffrées. Concrètement : les fenêtres de maintenance raccourcissent, et le CPU récupéré reste disponible pour les workloads pendant les opérations.
| Aspect | VCF 9.0 | VCF 9.1 |
|---|---|---|
| Hôtes max par instance | Inférieur à 5000 | Jusqu’à 5000 hôtes ESX |
| Chiffrement vMotion | Logiciel, CPU hôte | Offload matériel sur NIC compatibles |
| Coût CPU migration chiffrée | Plein tarif CPU | ~70 % d’économie CPU annoncée |
| Impact fenêtre de maintenance | Limité par le CPU de chiffrement | Migrations plus rapides, moins d’impact workload |
Impact architecte. L’offload vMotion ne fonctionne que sur des NIC capables — c’est une décision de BOM, pas un flag logiciel. Sur un parc hétérogène, le bénéfice est partiel tant que toutes les NIC ne sont pas alignées. À inscrire dans les standards d’achat hôte si le chiffrement vMotion est imposé par la politique de sécurité.
VCF Management Services : un runtime commun
VCF 9.1 unifie l’exécution des services de gestion (lifecycle, opérations) sous un runtime commun à travers la stack. Moins de composants de gestion redondants à patcher et à opérer, c’est un poste d’efficience opérationnelle souvent sous-estimé dans les calculs TCO.
L’intérêt pour l’architecte : la surface de gestion à maintenir se réduit, les dépendances entre composants de gestion sont rationalisées, et les fenêtres de patch de la couche de management se simplifient. Ce n’est pas spectaculaire en démo, mais sur trois ans d’exploitation, c’est plusieurs centaines d’heures d’ingénieur économisées sur une grande plateforme.
-40 % de TCO : d’où vient le chiffre ?
Le chiffre n’est pas un seul gain massif, c’est la somme de quatre contributions qui se cumulent. Voici la décomposition honnête.
Memory tiering — la DRAM est le poste matériel le plus cher. Étendre la mémoire effective de 1,5 à 2x sans acheter de barrette réduit directement le coût matériel par VM. C’est probablement la plus grosse contribution au chiffre.
Efficience stockage — la dédup globale et la compression étendue réduisent les TiB vSAN consommés, donc à la fois le matériel de stockage et la licence vSAN facturée au TiB.
Consolidation — plus de VM par hôte (effet combiné mémoire + stockage) signifie moins d’hôtes physiques pour la même charge : moins de cores VCF licenciés, moins d’énergie, moins de rack, moins de refroidissement.
Réduction de l’OpEx — ZTP, scale à 5000 hôtes, runtime de management unifié : moins d’heures d’ingénieur pour provisionner, opérer et patcher. L’OpEx pèse lourd dans un TCO à trois ou cinq ans.
La lecture honnête. « Jusqu’à -40 % » est un plafond, pas une moyenne. Le chiffre suppose un workload mix favorable au tiering (beaucoup de pages froides), des données à forte redondance pour la dédup, et une organisation capable de capitaliser sur la réduction d’OpEx. Un parc full latency-sensitive avec des datasets peu redondants verra une fraction de ce gain. Le bon réflexe d’architecte : refaire le calcul sur ton workload mix, avec des hypothèses explicites, et présenter une fourchette — pas le chiffre plafond seul.
Pièges & points de vigilance
Memory tiering et workloads latency-sensitive
Coût CPU et rebuild de la dédup vSAN globale
Migration Auto Deploy vers ZTP
vMotion offload : dépendance matérielle
Le -40 % de TCO est un plafond conditionnel
NVMe de tiering = device dédié, pas le datastore vSAN
Conclusion
Levier mémoire
Le memory tiering NVMe en production est le premier moteur du gain TCO : mémoire effective 1,5 à 2x sans achat de DRAM, au prix d’une latence à arbitrer par profil de workload.
Levier stockage
Dédup vSAN globale + chiffrement at-rest des données dédupliquées : moins de TiB achetés et licenciés, sans plus avoir à choisir entre efficience et conformité.
Levier opérationnel
ZTP, scale 5000 hôtes et offload vMotion réduisent l’OpEx et raccourcissent les fenêtres — un poste sous-estimé dans un TCO à trois ou cinq ans.
Prochaine étape. Si l’efficience d’infra est le levier coût, le réseau est le levier scale. L’article suivant, Networking & scale, décode les nouveautés réseau de VCF 9.1 et ce qu’elles changent pour les architectures à grande échelle — la suite logique une fois le calcul TCO posé.
Pour aller plus loin.
- Release Notes VCF 9.1 — la référence officielle, à lire avant tout projet
- Annonce VCF 9.1 — le post Broadcom qui pose le chiffre TCO
- What’s new vSphere 9.1 — détail Elastic Provisioning et ZTP
- William Lam et vmexplorer — deep-dives communautaires de référence
