Hyper-V S2D vs Proxmox Ceph : le comparatif qui a tranché

Le débat Hyper-V contre Proxmox se tranche rarement sur un chiffre unique, parce que les deux plateformes ne paient pas le même prix pour les mêmes garanties. Hyper-V avec Storage Spaces Direct reste taillé pour un monde Windows, là où Proxmox VE avec Ceph vise la flexibilité d’un parc mixte et une facture de licences nulle. Le vrai arbitrage se joue sur deux axes, la performance que l’on peut attendre du stockage et le coût de possession étalé sur plusieurs années.

Ce que la performance veut dire ici

Il faut se méfier des chiffres bruts qu’on lit dans les livres blancs des éditeurs, parce qu’ils ne mesurent presque jamais la même chose: comparer une lecture aléatoire d’un côté à une écriture de l’autre, c’est le genre de tour de passe-passe qui fait dire n’importe quoi à un tableau. Un constat reste pourtant robuste quand on change d’outil de mesure. Sur de l’écriture aléatoire en petits blocs et à faible profondeur de file, un stockage local répliqué en miroir comme S2D sur NVMe garde l’avantage, tout simplement parce qu’il écrit à côté du processeur et n’attend personne. Ceph, lui, paie une traversée réseau et une coordination de réplication à chaque écriture et c’est structurel, pas accidentel, puisque l’écriture n’est acquittée qu’une fois les réplicas confirmés, ce qui situe sa latence dans l’ordre de la milliseconde plutôt que de la microseconde.

Sur de la lecture ou sur du séquentiel, l’écart se resserre et il finit même par s’inverser dès que l’on parle de passage à l’échelle, parce que Ceph répartit la charge sur l’ensemble de ses OSD quand S2D reste borné par la géométrie de son cluster. La conséquence pratique tient en une phrase: pour une base de données sensible à la latence d’écriture, le stockage local l’emporte; pour un pool qui doit grossir, encaisser des pannes et se rééquilibrer de lui-même, Ceph a été pensé pour cela dès l’origine, la résilience étant incluse plutôt que rapportée.

Le coût de possession

Hyper-V + S2D:

• Windows Server Datacenter requis (licences par cœur, coûteuses)
• les outils d’administration en plus
• support Microsoft inclus
• intégration native avec l’infrastructure Windows existante

Proxmox VE + Ceph:

• zéro licence (open source)
• les outils sont inclus (Proxmox VE, dashboard Ceph)
• support communautaire ou souscription Proxmox pour l’entreprise

La décision pour un parc de studios

Un parc de studios de jeu vidéo mélange du Windows et du Linux, des stations de dev, des serveurs de build et des VMs déjà en place, de sorte que le choix dépend d’abord de l’existant. Si l’infrastructure est déjà Windows-centrique avec des licences Datacenter en place, S2D tire son épingle du jeu. Si l’infrastructure est à construire de zéro, Proxmox et Ceph remportent le calcul de TCO en éliminant les licences.

Le compromis qui tient la route combine les deux: Proxmox VE pour l’hyperviseur, open source et Ceph intégré et Windows Server à l’intérieur des VMs pour les stations et les serveurs de build. Les licences Windows s’appliquent alors aux VMs, pas à l’hyperviseur, ce qui divise la facture de licences par le facteur de densité.

Le cluster HA et la question de la capacité utile

C’est ici que la première version de cet article disait une bêtise qu’il faut corriger franchement. Avec une réplication à trois exemplaires (size=3, min_size=2), la capacité utile reste au tiers du brut et elle y reste quel que soit le nombre de nœuds: tripler chaque donnée coûtera toujours les deux tiers de l’espace. Ce que le nombre de nœuds fait varier, ce n’est pas ce ratio, c’est la tolérance aux pannes et la marge dont dispose le cluster pour se reconstruire.

• trois nœuds: le minimum honnête pour le quorum et pour size=3, mais la perte d’un nœud laisse le cluster sans marge pour recréer le troisième réplica;
• cinq nœuds: le point d’équilibre, où la perte d’un nœud se rééquilibre sans douleur pendant que le quorum tient;
• sept nœuds et au-delà: la panne d’un nœud ne retire qu’une faible fraction de la capacité et l’impact sur les performances pendant la reconstruction devient négligeable.

Si l’objectif est d’augmenter la capacité utile plutôt que la tolérance, le levier n’est pas d’empiler des nœuds en réplication à trois, il est de passer en erasure coding, un profil 4+2 par exemple, qui remonte la capacité utile autour des deux tiers au prix d’une latence et d’une charge CPU supérieures et qui réclame justement davantage de nœuds pour être sûr. Le vrai arbitrage, c’est réplication contre erasure coding, pas le nombre de nœuds pris isolément.

La règle Ceph habituelle reste valable telle quelle: un réseau dédié (10 GbE au minimum), ses trois réplicas ou son profil d’erasure coding et des SSD protégés contre les coupures d’alimentation.

[edit: 2026] L’implémentation Ansible de tout ceci: les rôles hyperv et proxmox .