Stockage virtualise : vSAN, Ceph et ZFS compares

Le stockage virtualisé ne se limite plus à présenter des LUN à des hyperviseurs. En 2026, le choix d’une architecture détermine directement la résilience des services, les performances applicatives, la simplicité d’exploitation et une part importante du coût total de possession. Les administrateurs doivent arbitrer entre des piles intégrées, comme VMware vSAN dans un environnement vSphere, des plateformes distribuées ouvertes comme Ceph pour Proxmox VE ou OpenStack, et du stockage local ZFS lorsque la simplicité, la maîtrise des données et le coût priment sur la mobilité native des machines virtuelles.

L’hyperconvergence a modifié le modèle classique de stockage partagé. Les mêmes nœuds fournissent les ressources de calcul et leurs disques locaux au cluster. Les données sont distribuées, répliquées ou protégées par codage à effacement, puis présentées comme un datastore partagé aux hyperviseurs. Cette approche réduit la dépendance à une baie SAN externe, mais elle impose une discipline forte sur le réseau, l’homogénéité matérielle, le dimensionnement des capacités et les procédures de remplacement. Un cluster hyperconvergé mal dimensionné peut sembler performant au départ, puis devenir difficile à faire évoluer lorsque les marges de capacité ou de performances disparaissent.

Ce guide compare les modèles vSAN, vSAN ESA, Ceph et ZFS avec une approche d’exploitation. L’objectif n’est pas de désigner une solution universelle, mais de donner un cadre pour choisir une architecture cohérente avec la taille de l’infrastructure, les contraintes budgétaires, les compétences disponibles et les exigences de disponibilité.

Comprendre les principes du stockage hyperconvergé

Dans une architecture hyperconvergée, chaque hôte contribue une partie de ses disques locaux à un pool distribué. L’hyperviseur ou une couche de stockage logicielle découpe les données en objets, distribue ces objets entre les nœuds et applique une politique de disponibilité. Une machine virtuelle ne dépend donc pas d’un seul disque ou d’un seul serveur, même si elle s’exécute localement sur un hôte donné.

Le principal bénéfice est l’alignement entre calcul et stockage. Ajouter un nœud ajoute généralement des cœurs, de la mémoire, de la capacité et des IOPS. En contrepartie, la croissance est souvent plus couplée qu’avec une architecture à baie externe : si le besoin porte uniquement sur la capacité, il peut être nécessaire d’acheter aussi du calcul.

Les composants à dimensionner ensemble

Un cluster HCI repose sur quatre ressources qui ne doivent pas être évaluées séparément :

• La capacité brute et utilisable.
• Les IOPS et la latence des supports.
• Le débit réseau Est-Ouest entre nœuds.
• La puissance CPU et mémoire consommée par la couche de stockage.

Le réseau est particulièrement critique. Une écriture synchrone avec réplication doit être transmise à plusieurs nœuds avant validation. Un lien saturé, une mauvaise configuration MTU ou une latence excessive entre hôtes dégrade immédiatement les écritures. En pratique, 25 GbE constitue désormais un point de départ raisonnable pour les nouveaux clusters NVMe à usage général ; 10 GbE peut suffire à de petits environnements, mais laisse peu de marge avec des charges intensives.

Le domaine de panne réel

La redondance doit être pensée selon les domaines de panne, pas seulement selon le nombre de copies. Un replica supplémentaire sur un autre disque du même serveur ne protège pas d’une panne de serveur. Une copie dans une autre baie du même rack ne protège pas nécessairement d’une panne d’alimentation de rack.

Les domaines de panne habituels sont :

• Le disque ou le SSD.
• Le serveur.
• Le rack.
• Le site ou la salle informatique.
• La zone de disponibilité dans un cloud privé ou public.

Une politique de stockage efficace place les copies ou fragments sur des domaines distincts. Cela doit être vérifié après chaque ajout de nœud, opération de maintenance ou changement de topologie.

VMware vSAN : stockage intégré à vSphere

VMware vSAN reste une solution étroitement intégrée à vSphere. Les disques locaux des hôtes ESXi sont agrégés dans un datastore partagé, piloté par des Storage Policies. L’administrateur peut appliquer à chaque machine virtuelle ou disque virtuel une politique indiquant, par exemple, le niveau de tolérance aux pannes, la méthode de protection, les règles d’affinité et les exigences de chiffrement. Pour aller plus loin, consultez vSAN ESA face au stockage traditionnel.

Cette intégration constitue son avantage principal dans un parc VMware existant. Les opérations habituelles de vSphere, telles que vMotion, DRS, HA, Storage vMotion et les sauvegardes compatibles VADP, conservent un fonctionnement familier. Les objets vSAN sont directement visibles dans les outils d’administration vCenter et les alertes de santé sont centralisées.

OSA et ESA : deux architectures distinctes

La version historique, souvent appelée OSA pour Original Storage Architecture, repose sur un modèle en groupes de disques avec une couche cache et une couche capacité. Elle reste pertinente pour certains environnements hybrides ou des clusters existants, mais elle ne constitue plus le modèle le plus intéressant pour un nouveau projet entièrement NVMe.

vSAN ESA, Express Storage Architecture, est conçu pour tirer parti de périphériques NVMe performants. ESA utilise une structure interne différente, avec un journal haute performance et un format optimisé pour les écritures. Il évite la logique traditionnelle de groupes de disques OSA et exploite davantage les capacités des SSD NVMe modernes.

ESA n’est pas simplement une option logicielle à activer. Elle implique une validation précise de la plateforme matérielle, des contrôleurs, des périphériques NVMe, du firmware et de la compatibilité VMware. Le recours à la VMware Compatibility Guide reste indispensable avant tout achat.

Les politiques de disponibilité vSAN

Dans vSAN, la politique FTT, Failures To Tolerate, définit le nombre de pannes de domaines que l’objet doit survivre. FTT=1 avec mirroring implique généralement deux copies de données et un composant témoin. FTT=2 augmente fortement les besoins de capacité et impose davantage de nœuds pour garantir un placement correct.

Les politiques peuvent également utiliser l’erasure coding dans les configurations compatibles. Le codage à effacement améliore l’efficacité de capacité par rapport au mirroring, mais augmente le coût CPU, les échanges réseau et la sensibilité aux petites écritures aléatoires. Il est souvent adapté à des charges avec une bonne profondeur d’E/S ou à des données plus froides ; le mirroring reste généralement le choix le plus prévisible pour des bases de données transactionnelles exigeantes.

vSAN ESA et l’impact des licences Broadcom

Depuis les évolutions de licence VMware sous Broadcom, la décision vSAN ne peut plus être prise uniquement sur des critères techniques. Les offres ont été consolidées autour de souscriptions, souvent liées au nombre de cœurs, avec des paliers et conditions qui peuvent modifier brutalement l’économie d’un petit ou moyen cluster.

Le coût réel doit inclure :

• Les licences ou souscriptions vSphere et vSAN nécessaires.
• Les éventuels minimums de cœurs applicables.
• Le support et les renouvellements pluriannuels.
• Le matériel certifié, y compris réseau et NVMe.
• La montée en capacité future : ajout de disques, d’hôtes ou de cœurs.
• Les coûts indirects de migration si le modèle de licence devient incompatible avec le budget.

Pour un cluster VMware existant, vSAN ESA peut rester rationnel si l’environnement exploite fortement les fonctions vSphere et que les équipes souhaitent limiter les changements opérationnels. Dans ce cas, l’intégration, la maturité des procédures et la compatibilité de l’écosystème de sauvegarde peuvent justifier un coût de licence supérieur.

En revanche, pour un renouvellement complet d’infrastructure, il faut comparer vSAN à Ceph et à des architectures ZFS locales, pas seulement au coût d’une baie SAN. Le différentiel de souscription peut financer du matériel supplémentaire, des liens réseau plus rapides, de la formation ou une capacité de réserve plus importante. Il ne faut toutefois pas confondre absence de licence propriétaire et absence de coût : Ceph demande des compétences d’exploitation spécifiques, du temps de conception et éventuellement un support professionnel.

Ceph : stockage distribué pour Proxmox et OpenStack

Ceph est une plateforme de stockage distribué open source capable de fournir du stockage bloc, objet et fichier. Dans les environnements de virtualisation, le cas d’usage principal est Ceph RBD, un stockage bloc distribué utilisé nativement par Proxmox VE et largement employé dans OpenStack via Cinder et Glance. Le wiki Proxmox VE consacré au stockage ZFS détaille l’alternative locale pour les architectures qui ne justifient pas encore un cluster Ceph.

Ceph répartit les données sur des OSD, Object Storage Daemons, généralement associés à un ou plusieurs périphériques de stockage. Les moniteurs MON maintiennent les informations de quorum et de topologie, tandis que les gestionnaires MGR exposent des services de supervision et d’orchestration. Le placement est piloté par CRUSH, un algorithme qui distribue les objets sans dépendre d’un contrôleur central de métadonnées pour chaque accès.

Replication et erasure coding dans Ceph

Les pools Ceph peuvent être répliqués ou protégés par erasure coding. Un pool répliqué de taille 3 conserve trois copies de chaque objet sur des OSD et hôtes distincts selon les règles CRUSH. Il offre une sémantique simple et des performances généralement plus prévisibles pour les disques de machines virtuelles.

Avec erasure coding k+m, les données sont découpées en k fragments de données et m fragments de parité. Par exemple, un profil 4+2 stocke six fragments et peut survivre à la perte de deux fragments. L’efficacité théorique est de 4/6, soit environ 66 %, supérieure à un replica 3 dont l’efficacité est proche de 33 %.

Cependant, l’erasure coding impose une lecture, une reconstruction et des écritures plus complexes. Pour des disques RBD fortement sollicités, son emploi doit être validé par des tests représentatifs. Une approche fréquente consiste à utiliser des pools répliqués pour les workloads transactionnels et des pools EC pour les données moins sensibles à la latence, les sauvegardes ou les objets.

Réseau et séparation des flux Ceph

Ceph peut utiliser un réseau public pour les clients et un réseau cluster pour la réplication, la récupération et les échanges entre OSD. Dans un petit cluster, un réseau unique correctement dimensionné peut fonctionner. À partir d’une certaine densité d’OSD ou pour des charges soutenues, séparer les flux apporte davantage de prévisibilité.

Les priorités sont les suivantes :

1. Éviter la saturation des liens lors d’une reconstruction.
2. Garantir une faible latence entre nœuds.
3. Prévoir la bande passante nécessaire aux opérations de maintenance.
4. Surveiller les latences disque et réseau au niveau des OSD.
5. Tester la perte d’un nœud, puis mesurer le comportement du backfill.

Ceph ne doit pas être déployé comme un simple remplacement gratuit de vSAN. Il offre une grande flexibilité, mais exige une compréhension réelle des PG, des CRUSH rules, de la santé des OSD, du rebalancing et des mécanismes de récupération. Pour aller plus loin, consultez la sauvegarde des machines virtuelles.

ZFS : stockage local robuste et performant

ZFS est un système de fichiers et gestionnaire de volumes qui combine intégrité des données, snapshots, compression, clones et mécanismes de correction via checksums. Il est particulièrement intéressant pour du stockage local performant dans Proxmox VE, pour des serveurs autonomes, des clusters avec réplication asynchrone, des plateformes de sauvegarde ou des usages nécessitant une administration simple et transparente.

Contrairement à Ceph ou vSAN, ZFS seul ne transforme pas les disques de plusieurs hôtes en datastore partagé distribué. Chaque pool appartient à un serveur. La haute disponibilité des machines virtuelles doit donc être assurée autrement : réplication ZFS, stockage partagé externe, bascule orchestrée, sauvegardes fréquentes ou combinaison avec un mécanisme de clustering adapté.

Compression, snapshots et copies sur écriture

ZFS utilise un modèle copy-on-write. Une modification n’écrase pas directement les blocs existants : les nouveaux blocs sont écrits ailleurs, puis les métadonnées sont mises à jour de façon atomique. Cette conception facilite les snapshots cohérents et réduit certains risques de corruption après incident.

La compression doit être activée dans la majorité des cas, typiquement avec LZ4. Son coût CPU est faible et elle réduit souvent les écritures physiques, ce qui peut améliorer les performances en plus de réduire la consommation de capacité. Il faut toutefois mesurer les taux réels de compression plutôt que de bâtir un dimensionnement sur une hypothèse optimiste.

Les snapshots sont rapides et peu coûteux au moment de leur création, mais leur coût augmente avec les blocs modifiés conservés. Une rétention excessive de snapshots peut empêcher la libération d’espace et dégrader les performances. Une politique de rétention claire est indispensable.

Les vdevs déterminent les performances

Dans ZFS, le pool agrège des vdevs, et non des disques de manière complètement interchangeable. Les IOPS aléatoires sont fortement liées au nombre de vdevs. Ajouter de gros disques dans un seul vdev RAIDZ augmente surtout la capacité, pas les IOPS. Pour des machines virtuelles, des miroirs multiples ou des vdevs RAIDZ de largeur raisonnable sont souvent plus adaptés qu’un unique très large groupe RAIDZ.

Dimensionnement : capacité utile, réserve et performances

Le dimensionnement doit partir des besoins applicatifs, pas de la capacité brute affichée par les disques. Il faut collecter au minimum la consommation actuelle, le taux de croissance, les IOPS moyennes et de pointe, la taille des écritures, le ratio lecture/écriture, les exigences de RPO et RTO, ainsi que les fenêtres de sauvegarde.

La formule de capacité doit intégrer la protection, les réserves opérationnelles et la marge de croissance :

Capacité brute nécessaire =
(données utiles + croissance + snapshots + marge)
÷ efficacité de protection
÷ taux de remplissage maximal visé

Un replica 3 donne approximativement une efficacité de 33 %. Une protection miroir à deux copies donne environ 50 %, sans compter les métadonnées et témoins. Un schéma EC 4+2 atteint environ 66 %, mais ne doit pas être retenu uniquement pour ce chiffre.

La réserve de capacité n’est pas négociable

Un cluster distribué a besoin d’espace libre pour rééquilibrer les données après une panne, remplacer un disque et absorber les opérations de maintenance. Exploiter durablement un cluster à 85 ou 90 % de remplissage transforme toute panne matérielle en incident opérationnel.

Les recommandations exactes dépendent de la technologie et de la politique de disponibilité, mais il est prudent de prévoir :

• Une capacité libre correspondant au moins à la perte du plus gros domaine de panne.
• Une marge supplémentaire pour la croissance avant le prochain cycle d’achat.
• L’espace nécessaire aux snapshots, clones et opérations de sauvegarde.
• Une réserve pour les reconstructions et les migrations temporaires.

Choisir entre replicas et erasure coding

Le choix dépend autant du comportement des E/S que du coût par téraoctet. Les replicas simplifient la lecture, réduisent la complexité de reconstruction et offrent souvent une meilleure latence sur les charges aléatoires. Leur contrepartie est une forte consommation de capacité.

L’erasure coding réduit le besoin en disques, mais amplifie les écritures et consomme davantage de CPU et de bande passante. Il convient mieux lorsque la capacité est le facteur dominant, que les nœuds sont nombreux et que les workloads tolèrent une latence légèrement plus variable.

Pour un cluster de virtualisation généraliste, une stratégie pragmatique consiste à réserver les replicas aux volumes système, aux bases de données, aux disques de VM intensifs et aux services critiques. L’erasure coding peut être utilisé pour les archives, les référentiels d’images, certaines sauvegardes ou les données applicatives moins actives.

Choisir selon la taille de l’infrastructure

Le bon choix dépend moins du nombre absolu de machines virtuelles que de la maturité opérationnelle, du nombre de nœuds, du budget et des objectifs de disponibilité.

Petite infrastructure : deux à quatre hôtes

Pour un petit environnement, ZFS local avec sauvegardes fiables, réplication et procédures de reprise documentées est souvent plus rationnel qu’un cluster distribué complexe. Une architecture Proxmox avec ZFS local, Proxmox Backup Server et réplication planifiée peut fournir un niveau de service solide à condition d’accepter un RPO non nul et une bascule moins transparente.

vSAN peut être pertinent si l’organisation est déjà standardisée sur VMware et dispose du budget de souscription. Ceph devient techniquement possible à trois nœuds, mais il faut éviter de le considérer comme un choix par défaut si l’équipe n’a pas le temps de l’exploiter correctement. Pour aller plus loin, consultez le réseau virtuel d’un cluster.

Infrastructure intermédiaire : quatre à douze hôtes

Cette taille correspond souvent au meilleur terrain pour l’hyperconvergence. vSAN ESA est cohérent pour les environnements vSphere qui privilégient l’intégration et un support fournisseur. Ceph est une option très crédible pour Proxmox VE ou OpenStack, notamment si l’équipe maîtrise Linux et souhaite éviter une dépendance de licence. Pour aller plus loin, consultez la sécurisation d’un cluster.

Le réseau doit passer au premier plan : 25 GbE, commutation redondée, latence faible, supervision des erreurs interfaces et validation des scénarios de panne sont recommandés.

Grande infrastructure et services multi-équipes

Au-delà d’une douzaine d’hôtes ou lorsqu’il existe plusieurs classes de service, Ceph gagne en intérêt grâce à sa capacité à séparer des pools, des règles CRUSH et des profils de protection. Il peut aussi servir plusieurs usages : RBD pour les VM, S3 pour les applications et stockage de sauvegarde, CephFS pour certains besoins fichiers.

vSAN reste adapté si l’écosystème VMware demeure stratégique et que le budget est maîtrisé contractuellement. Dans ce cas, il faut modéliser les coûts de souscription sur trois à cinq ans, en incluant la croissance CPU et les renouvellements.

Exploitation quotidienne, supervision et tests de panne

Le stockage distribué échoue rarement de façon binaire. Les incidents prennent plus souvent la forme de latences élevées, de disques lents, de reconstructions qui saturent le réseau, de déséquilibres de capacité ou d’alertes ignorées jusqu’à la seconde panne.

Les indicateurs à superviser incluent :

• Latence lecture et écriture par machine virtuelle ou volume.
• Saturation CPU liée à la compression, à l’EC ou aux services de stockage.
• Usure et température des SSD NVMe.
• Erreurs média, timeouts, resets de contrôleur et erreurs PCIe.
• Taux de remplissage global et par nœud.
• Débit de resynchronisation, de rebalance ou de backfill.
• Santé du quorum et disponibilité des services de contrôle.

Les tests de panne doivent être planifiés. Il ne suffit pas de constater qu’une politique FTT ou un pool replica 3 existe. Il faut vérifier les temps de reconstruction, la dégradation de performances, le comportement lors d’une maintenance planifiée et la capacité réelle à rester dans les objectifs RPO/RTO.

Une architecture de stockage réussie est celle dont les équipes comprennent les compromis avant l’incident. vSAN ESA offre une expérience intégrée et très efficace sur NVMe, mais son coût de licence et ses exigences matérielles doivent être acceptés explicitement. Ceph fournit une base ouverte, scalable et polyvalente, au prix d’une exploitation plus spécialisée. ZFS apporte des garanties d’intégrité et une grande efficacité locale, mais ne remplace pas seul un stockage partagé distribué. Le choix final doit être fondé sur les compétences réelles, le budget sur plusieurs années et le niveau de disponibilité que l’organisation est prête à financer et à opérer.