Le « x2 » du memory tiering NVMe n’est ni un multiplicateur magique ni une simple promesse marketing. Broadcom a publié ce doublement sur plusieurs benchmarks au ratio DRAM:NVMe 1:1, avec un coût allant de nul dans un essai VDI à 5–10 % sous HammerDB. La bonne question n’est donc pas « est-ce que ça marche ? », mais « mon working set, mes NVMe et mes contraintes d’exploitation ressemblent-ils aux conditions documentées ? »
Chez Nordwind Logistics, cl-fret-dens-01 est un cluster ESA de 4 hôtes candidat à la densification. Le projet PRJ-2026-DENS-01 partage une enveloppe entre DRAM, NVMe de stockage et NVMe de tiering. Aucun de ces trois postes ne peut être compté deux fois.
Les chiffres ne sont pas des mesures Nordwind
Aucun lab local n’a été exécuté. Les résultats cités sont ceux publiés par Broadcom avec leurs benchmarks. Ils rendent le cas d’usage crédible, mais l’éligibilité et le coût applicatif doivent être vérifiés sur une plateforme de test ou pendant un pilote contrôlé.
TL;DR
- Depuis ESX 9.0, le memory tiering est GA ; son passage en Technical Preview concernait vSphere 8.0 U3.
- Au ratio recommandé 1:1,
tier_size_pct=100, un NVMe égal à la DRAM fournit 2x de capacité mémoire totale. - Broadcom publie 2x de densité avec un coût qui dépend du workload ; active memory ≤ 50 % de la DRAM et absence d’overcommit sont les premières portes d’entrée.
- Le NVMe de tiering doit rester local, compatible et non réclamé par vSAN.
Une fonction ESX, pas une fonction vSAN
Memory Tiering over NVMe ajoute une seconde classe de mémoire à un hôte ESX :
- Tier 0 : DRAM, pour la mémoire principale ;
- Tier 1 : NVMe local, pour les pages mémoire de VM placées dans le tier secondaire.
Les pages NVMe servent uniquement aux allocations mémoire des VM. Le mécanisme n’est ni un datastore, ni du swap vSAN, ni un remplacement de l’overcommit ou du ballooning. La fonction est désactivée par défaut.
La chronologie évite un malentendu fréquent. vSphere 8.0 U3 proposait une Technical Preview, non destinée à la production et encore incomplètement optimisée. La documentation vSphere 9.0 établit le passage en GA. VCF 9.1 ajoute notamment la configuration sans reboot, la levée de restrictions sur certains profils de VM et le mirroring logiciel d’un second NVMe.
DOCUMENTÉ — le ratio de départ
Broadcom recommande le ratio DRAM:NVMe 1:1. Avec tier_size_pct=100, le tier NVMe égale la DRAM et la capacité mémoire totale devient 2x. Le paramètre accepte 1 à 400, mais aucun résultat de densité n’a été trouvé pour un autre ratio.
La partition de tiering ne peut pas dépasser 4 To. Au ratio recommandé, le NVMe doit être au moins aussi grand que la DRAM du système. Une annonce 9.1 parle de jusqu’à 4x de mémoire disponible par hôte, mais aucune source chargée ne confirme que ce chiffre correspond exactement à tier_size_pct=400. Ce rapprochement reste une RECONSTITUTION, pas une règle de sizing.
Le x2 publié, avec son coût
Tous les résultats ci-dessous viennent d’une étude Broadcom de 2025 et utilisent le ratio 1:1. Les modèles de CPU, de NVMe et la configuration réseau ne ressortent pas de la page chargée ; il serait donc incorrect de transposer ces résultats au châssis Nordwind.
| Benchmark Broadcom | DRAM seule | Memory Tiering 1:1 | Coût publié |
|---|---|---|---|
| Login Enterprise, cluster vSAN 3 hôtes | 300 sessions | 600 sessions | aucune perte face à l’équivalent all-DRAM annoncée |
| VMmark 3.1 | 3 tiles | 6 tiles | 5 % dans le comparatif 1 To contre 1 To |
| DVD Store / Oracle, 1 hôte ESX | 4 VM | 8 VM | moins de 5 % dans le comparatif 1 To contre 1 To |
| HammerDB, SQL et MySQL | densité de référence | 2x | 5–10 % |
Ce tableau ne dit pas que chaque application accepte 2x de VM. Il montre que Broadcom a observé ce résultat sur quatre familles de tests au ratio 1:1, avec une sensibilité différente. La perte de 5–10 % sous HammerDB est aussi importante que le doublement : elle donne un ordre de décision, pas une promesse pour une base de production.
Broadcom recommande également une latence de lecture du NVMe inférieure à 200 µs pour les meilleures performances. C’est une cible publiée, pas une mesure locale.
Le vrai critère : l’active memory
TechDocs indique que la plupart des workloads maintiennent typiquement 10 à 30 % d’active memory. Pour la planification, la contrainte est plus stricte : l’active memory d’un hôte ne doit avoir dépassé 50 % de sa DRAM à aucun moment avant l’activation.
Les pages froides commencent à être déplacées vers le NVMe lorsque la consommation atteint environ 80 % de la DRAM. Cela explique le modèle : la capacité secondaire absorbe ce qui n’a pas besoin de la latence DRAM immédiate, tandis que le working set actif reste prioritaire en Tier 0.
À_VALIDER_EN_LAB — éligibilité du workload
Une moyenne d’active memory ne suffit pas. Il faut vérifier les pointes, la latence applicative et les périodes de batch. Une charge qui dépasse 50 % de DRAM active, ou dont le working set change brutalement, ne doit pas être déclarée éligible sur la seule base d’un benchmark Broadcom.
Une qualification légère peut suffire même sans lab permanent : extraire l’historique d’active memory, sélectionner quelques VM représentatives, établir une référence DRAM seule, puis répéter le scénario sur une plateforme de test temporaire. Les champs à comparer sont la densité, le percentile de latence applicative, le CPU, l’active memory et la latence de lecture NVMe.
RÉSULTAT_ATTENDU : au ratio 1:1, le cluster fournit 2x de capacité mémoire totale et respecte le budget de performance défini pour le pilote. Tant que le pilote n’existe pas, le dossier doit porter « à vérifier sur plateforme de test », pas une valeur estimée.
Un disque ne peut avoir qu’un rôle
Le lien avec vSAN ESA est physique, pas fonctionnel. Un NVMe déjà réclamé par un datastore, notamment vSAN, ne peut pas servir au memory tiering. Le disque doit rester non réclamé, local et compatible. Broadcom documente trois parcours : le réserver avant la réclamation vSAN, l’exclure de cette réclamation, ou retirer un périphérique du storage pool après migration des données.
Pour cl-fret-dens-01, la checklist devient :
- inventorier les slots et les périphériques certifiés ;
- réserver un NVMe de tiering distinct des NVMe du storage pool ;
- vérifier que sa capacité couvre la DRAM au ratio 1:1 sans dépasser la partition de 4 To ;
- vérifier active memory ≤ 50 % de la DRAM et interdire l’overcommit ;
- décider si un second NVMe est réservé au mirroring logiciel ;
- qualifier latence de lecture et endurance avec les données constructeur puis un test.
En 9.1, le second périphérique de mirroring doit avoir une capacité égale ou supérieure au premier. Broadcom affirme que ce mirroring ne dégrade pas les performances et empêche une défaillance du tier liée à la durée de vie du NVMe. Cette assertion produit mérite, elle aussi, une vérification sur le matériel choisi.
Exclusions qui changent l’exploitation
Le memory tiering n’est pas compatible avec le hot-plug, prepare to remove, suspend-to-memory, Quick Boot, Intel Optane PMem, NVDIMM-N ou un NVMe accessible par fabric ou Ethernet. Il ne faut pas non plus présenter le tiering comme un levier d’overcommit : TechDocs demande explicitement de ne pas utiliser l’overcommit mémoire lorsqu’il est actif.
HYPOTHÈSE_DE_DESIGN — garde-fou Nordwind
Nordwind démarre uniquement à 1:1, sur des hôtes restés sous 50 % d’active memory, sans overcommit et avec des périphériques séparés pour vSAN. Tout autre ratio devient une expérimentation distincte.
Cette discipline prolonge l’analyse VCF 9.1, efficience infra et TCO : la densité n’est utile que si l’économie de DRAM et de slots reste supérieure au coût de qualification, de NVMe et d’exploitation.
Conclusion
1:1 d’abord
Le x2 publié appartient au ratio recommandé, pas à une extrapolation de 1 à 400.
Le working set tranche
L’active memory et la latence applicative déterminent l’éligibilité réelle.
Un slot, un rôle
Un NVMe de tiering ne contribue plus au storage pool ESA.
Le x2 est suffisamment étayé pour ouvrir un projet, pas pour fermer une validation. Une fois les périphériques mémoire réservés, il faut recalculer ce qu’il reste au stockage : Capacity planning ESA vs OSA, ce qui change vraiment.
Sources principales : Memory Tiering vSphere 9.1, bonnes pratiques, activation avec vSAN et étude de performance Broadcom.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
