vSAN ESA (Express Storage Architecture) est l’évolution majeure de l’architecture de stockage distribué de VMware vSAN pour les clusters entièrement flash, conçue autour des caractéristiques du NVMe moderne. Elle ne se résume pas à une optimisation de vSAN OSA : ESA remplace plusieurs mécanismes historiques, en particulier la séparation cache/capacité et le format d’objets RAID traditionnel, afin de mieux exploiter les SSD NVMe à faible latence et à haut parallélisme. Pour un administrateur, la question n’est donc pas seulement « ESA est-elle plus rapide ? », mais plutôt : le matériel, les politiques de disponibilité, les flux applicatifs et le modèle d’exploitation justifient-ils ce changement d’architecture ?

OSA et ESA : deux modèles de stockage différents

vSAN OSA, ou Original Storage Architecture, repose sur une organisation en groupes de disques. Chaque groupe comprend typiquement :

Ce modèle a accompagné vSAN depuis les débuts du produit. Il fonctionne très bien dans de nombreux environnements, y compris avec des disques NVMe. Toutefois, il provient d’une époque où les écarts de performances entre SSD de cache et SSD de capacité étaient plus marqués, et où le nombre de files d’attente exploitées par les périphériques était plus limité.

ESA supprime les groupes de disques. Chaque hôte apporte un ou plusieurs périphériques NVMe homologués à un pool de stockage unique. Il n’existe plus de distinction fonctionnelle entre disque de cache et disque de capacité. Tous les périphériques participent directement à la capacité et aux opérations d’E/S.

Cette simplification modifie profondément le chemin des données :

vSAN OSA
Machine virtuelle
    |
    v
Cache d'écriture du groupe de disques
    |
    v
Destage et placement sur disques de capacité
    |
    v
Objets RAID-1 ou RAID-5/6 selon la politique

vSAN ESA
Machine virtuelle
    |
    v
Log structuré et couche de traitement ESA
    |
    v
Pool NVMe unifié de l'hôte
    |
    v
Objets ESA avec mécanismes de protection optimisés

Dans ESA, le traitement des écritures s’appuie notamment sur un log structuré. Au lieu de multiplier les écritures aléatoires immédiatement sur les supports de capacité, l’architecture organise les données de manière plus séquentielle et plus efficace pour les SSD NVMe. Cette approche diminue l’amplification d’écriture, réduit les opérations internes inutiles et améliore l’efficacité des mécanismes de protection des données.

Les composants techniques clés de vSAN ESA

ESA introduit ou généralise plusieurs mécanismes qui expliquent l’écart constaté avec OSA sur des plateformes adaptées.

Le premier est le moteur de journalisation optimisé pour les flashs NVMe. Les écritures sont regroupées et organisées afin de réduire le nombre d’opérations de type read-modify-write, particulièrement pénalisantes pour les configurations RAID à parité.

Le second est le nouveau modèle d’objets. Dans OSA, une politique RAID-5 ou RAID-6 implique des composants de capacité et de parité répartis entre les hôtes. Cette organisation protège efficacement les données, mais peut créer une surcharge notable lors des petites écritures aléatoires. ESA utilise un format d’objet différent, conçu pour limiter ces surcoûts et faciliter la reconstruction après défaillance. Pour aller plus loin, consultez notre guide complet sur le stockage virtualisé.

Le troisième est l’encodage RAID-6 performant, souvent désigné par l’expression RAID-6 performant dans les interfaces d’administration. L’objectif est de proposer une protection contre deux pannes tout en évitant que la pénalité de performance historiquement associée à la double parité devienne rédhibitoire. Cela rend les politiques à double tolérance de panne plus réalistes pour des charges de production exigeantes.

Le quatrième est la compression native, intégrée au chemin de données. ESA utilise une compression adaptée aux blocs de données, avec une logique visant à limiter le coût CPU. Elle intervient avant certaines opérations de distribution et de protection, ce qui peut réduire à la fois la consommation de capacité et le trafic réseau entre hôtes.

Enfin, ESA bénéficie d’un chemin d’E/S NVMe plus parallèle. Les SSD modernes supportent de nombreuses files d’attente et un niveau élevé de concurrence. Les charges de bases de données, les VDI denses, les plateformes d’intégration continue ou les environnements Kubernetes virtualisés peuvent tirer parti de ce parallélisme, à condition que le réseau, les contrôleurs et les processeurs ne deviennent pas les nouveaux goulots d’étranglement.

Gains de performance : ce que les mesures signifient réellement

Les gains annoncés entre OSA et ESA peuvent être substantiels, mais ils doivent être interprétés avec méthode. ESA ne transforme pas un cluster sous-dimensionné en plateforme haute performance. Ses bénéfices apparaissent principalement lorsque l’infrastructure respecte les prérequis NVMe, réseau et processeur.

Les comparaisons publiées par l’éditeur ont montré des améliorations importantes en IOPS, en latence et en efficacité de capacité, notamment pour les politiques RAID-5 et RAID-6. Dans des scénarios à écritures aléatoires, ESA peut offrir plusieurs fois les performances d’une configuration OSA équivalente, particulièrement lorsque la protection par parité est activée.

Le NVMe local change fondamentalement l'architecture de stockage.
Le NVMe local change fondamentalement l'architecture de stockage.

Les métriques à suivre durant un test ne se limitent pas aux IOPS :

Un test crédible doit isoler les variables. Comparer OSA sur des SSD SATA à ESA sur des NVMe récents n’apporte aucune conclusion architecturale exploitable : le résultat mesure surtout l’écart entre les matériels. La comparaison pertinente utilise, autant que possible, les mêmes générations de serveurs, le même réseau, une capacité équivalente, les mêmes politiques de disponibilité et la même charge applicative.

Un protocole minimal peut ressembler à ceci :

1. Définir le profil de charge :
   - Taille de bloc : 4 KiB, 8 KiB, 32 KiB, etc.
   - Ratio lecture/écriture
   - Profondeur de file
   - Nombre de machines virtuelles ou de threads
   - Durée suffisante pour dépasser les effets de cache

2. Mesurer l'état nominal :
   - IOPS
   - Débit
   - Latence moyenne et percentiles
   - CPU et réseau

3. Introduire des événements opérationnels :
   - Évacuation d'un hôte
   - Rebuild après retrait simulé d'un périphérique
   - Resynchronisation
   - Snapshot et consolidation

4. Comparer les résultats à politique de stockage identique.

ESA montre souvent son intérêt non seulement dans les chiffres de pointe, mais aussi pendant les opérations de maintenance et les incidents. Une reconstruction plus efficace réduit la durée pendant laquelle un objet reste dégradé. Cela ne dispense pas de dimensionner correctement le cluster, mais réduit l’exposition au risque après une panne de support ou d’hôte.

Compatibilité matérielle : la HCL ESA n’est pas une formalité

Le point le plus important avant tout projet ESA est la compatibilité matérielle. Une plateforme certifiée pour vSAN OSA n’est pas automatiquement éligible à ESA.

ESA impose l’usage de périphériques NVMe certifiés pour ESA dans la VMware Compatibility Guide, souvent appelée HCL. Cette validation ne concerne pas uniquement la présence d’un contrôleur NVMe dans le serveur. Elle porte sur une combinaison précise d’éléments :

La résistance à la panne, le comportement en cas de coupure d’alimentation, la latence soutenue, l’endurance et les mécanismes de récupération d’erreurs comptent davantage que les seuls chiffres de débit séquentiel figurant sur une fiche constructeur. Un SSD NVMe grand public peut afficher des performances impressionnantes dans un poste de travail tout en étant inadapté à un cluster distribué soumis à des écritures soutenues, à des resynchronisations et à des contraintes de persistance strictes. Pour aller plus loin, consultez l’architecture vSphere et vCenter.

Le réseau doit également être traité comme un composant de stockage. ESA peut générer davantage de trafic utile parce que les périphériques et le moteur logiciel ne sont plus les mêmes limites qu’en OSA. Le 25 GbE constitue un point de départ raisonnable pour de nombreux déploiements de production, tandis que le 100 GbE peut être justifié pour des clusters denses ou des charges à fort débit. Le 10 GbE peut fonctionner dans certains cas, mais il doit être validé par des mesures réelles et non considéré comme un choix automatique.

Avant la commande, il faut vérifier les entrées exactes dans la HCL et conserver cette preuve dans le dossier d’architecture. Une vérification générique du type « le serveur est vSAN ReadyNode » est insuffisante. Le profil ReadyNode, les disques et leurs firmwares doivent correspondre au niveau requis pour ESA.

Migration vers ESA : quand le projet a du sens

Migrer vers ESA a du sens lorsque le renouvellement matériel est déjà prévu. C’est le cas le plus fréquent et le moins risqué : on déploie un nouveau cluster ESA, on valide les performances et l’exploitation, puis on migre les charges via vMotion, Storage vMotion, réplication ou outil de migration adapté.

Les environnements suivants sont de bons candidats :

Il faut néanmoins garder à l’esprit qu’ESA n’est pas une conversion en place d’un cluster OSA existant. Les architectures de stockage sont distinctes. En pratique, un passage vers ESA implique un nouveau cluster ou une stratégie de remplacement des hôtes permettant de créer une cible ESA. Les données doivent ensuite être déplacées.

Une approche progressive est généralement préférable :

1. Inventorier les politiques vSAN OSA existantes.
2. Identifier les machines virtuelles sensibles à la latence.
3. Déployer un cluster ESA validé matériellement.
4. Créer des politiques ESA équivalentes ou améliorées.
5. Migrer un périmètre pilote.
6. Mesurer performances, taux de compression et opérations de maintenance.
7. Étendre la migration par vagues.
8. Décommissionner OSA seulement après validation fonctionnelle et sauvegarde.

La migration est aussi l’occasion de revoir les politiques de stockage. Copier à l’identique une politique RAID-1 FTT=1 d’OSA vers ESA peut être justifié pour conserver un comportement connu, mais ce n’est pas forcément optimal. Les capacités de protection par parité d’ESA peuvent permettre de rééquilibrer le compromis entre disponibilité, performance et consommation de capacité.

Les cas où un SAN classique reste préférable

ESA n’élimine pas le besoin de stockage externe. Un SAN classique, qu’il soit bloc Fibre Channel, iSCSI ou NVMe/TCP, conserve des avantages structurels dans plusieurs situations.

Choisir entre stockage traditionnel et hyperconvergé reste contextuel.
Choisir entre stockage traditionnel et hyperconvergé reste contextuel.

Le premier cas concerne la mutualisation à grande échelle. Une baie SAN peut servir simultanément plusieurs clusters de virtualisation, des serveurs physiques, des plateformes de sauvegarde et parfois des environnements non VMware. Lorsqu’une organisation a besoin d’un grand domaine de stockage partagé, indépendant du cycle de renouvellement des serveurs de calcul, un SAN peut rester plus cohérent.

Le second concerne les besoins de capacité très élevés. Pour des charges peu sensibles à la latence mais volumineuses, une baie avec tiroirs denses, mécanismes de tiering et disques haute capacité peut présenter un coût au téraoctet plus favorable qu’une architecture hyperconvergée basée uniquement sur des NVMe.

Le troisième concerne les fonctionnalités avancées de baie déjà intégrées aux processus d’exploitation : réplication synchrone intersite mature, snapshots applicatifs orchestrés, clones très rapides, intégration avec des outils de sauvegarde ou exigences réglementaires spécifiques. vSAN dispose de ses propres mécanismes, mais ils ne recouvrent pas systématiquement toutes les fonctions, habitudes et certifications d’une baie d’entreprise existante.

Le quatrième est l’indépendance entre calcul et stockage. Dans vSAN, augmenter la capacité ou les performances conduit souvent à ajouter ou renouveler des hôtes qui apportent aussi du CPU et de la mémoire. Si le besoin porte uniquement sur le stockage, cette corrélation peut générer des ressources de calcul inutilisées. Un SAN permet d’augmenter le stockage sans modifier le parc de serveurs. Pour aller plus loin, consultez la sauvegarde des machines virtuelles.

Enfin, certains environnements imposent des topologies ou des contraintes d’exploitation peu compatibles avec vSAN : clusters trop petits, réseaux insuffisants, sites distants très latents, matériel non certifiable ESA, équipes séparées avec responsabilités strictement cloisonnées ou applications nécessitant une connectivité bloc directe hors ESXi.

Le choix ne doit donc pas être formulé comme « ESA contre SAN ». Il est souvent plus réaliste de positionner ESA comme une plateforme performante de virtualisation locale, tandis que le SAN reste pertinent pour les services mutualisés, les très grands volumes, les usages physiques ou les exigences de réplication spécifiques.

Décider avec des critères d’architecture, pas avec un benchmark isolé

vSAN ESA apporte une architecture plus moderne, plus cohérente avec les propriétés du NVMe et plus efficace pour les politiques de protection à parité. Dans un cluster correctement conçu, les bénéfices peuvent concerner la latence, le débit, les IOPS, l’efficacité de capacité et la vitesse de reconstruction.

Mais ESA impose une discipline supérieure sur la qualification matérielle et le dimensionnement. La HCL spécifique, la qualité des SSD, les versions de firmware, les pilotes, la capacité réseau et les objectifs de disponibilité doivent être vérifiés avant le déploiement. Il ne suffit pas de disposer de serveurs avec des emplacements NVMe.

La bonne décision s’appuie sur trois questions : les applications ont-elles réellement besoin de la réduction de latence et de la performance offerte par ESA ? Le renouvellement matériel permet-il de respecter la HCL sans compromis ? Les avantages opérationnels dépassent-ils les contraintes de migration depuis OSA ou de maintien d’un SAN externe ? Si les réponses sont positives, ESA constitue une cible très solide pour la prochaine génération de clusters vSAN.