Sur-allocation (Oversubscription) et bonnes pratiques du dimensionnement des Hyperviseurs

1. Introduction

Dans un environnement virtualisé, il est courant de sur-allouer (ou oversubscribe en anglais) des ressources CPU, c'est-à-dire d'attribuer un nombre total de vCPU (virtual CPU) supérieur au nombre de cœurs physiques (pCPU : physical CPU cores) d'un serveur hôte. L'idée derrière cette pratique est que toutes les machines virtuelles (VM) ne solliciteront pas leurs ressources au même moment ou de façon continue, permettant ainsi d'optimiser l'utilisation du matériel.

Toutefois, cette oversubscription doit être contrôlée. Un dimensionnement excessif des vCPU peut engendrer une dégradation des performances globales : temps de latence élevé, ralentissements voire contention CPU sur l'hôte. L'équilibre doit donc être trouvé entre la consolidation des VMs et la performance globale.

Dans cet article, nous allons donc passer en revue :

Les notions de base liées à l'oversubscription.
Les bonnes pratiques générales pour le choix du ratio de sur-allocation (vCPU/pCPU).
Les spécificités pour trois solutions d'hypervision couramment utilisées : Hyper-V, Proxmox, et VMware ESXi.

2. Définition de l'oversubscription

2.1. Qu'est-ce que l'oversubscription ?

Oversubscription CPU : Attribuer plus de vCPU que le nombre total de cœurs physiques disponibles.
Exemple : un serveur dispose de 2 sockets, chacun doté de 8 cœurs physiques, soit un total de 16 cœurs. Si on y crée plusieurs VMs pour un total de 32 vCPU, on a un ratio de 2:1 (32 vCPU / 16 cœurs physiques).
Oversubscription Mémoire : Attribuer plus de mémoire virtuelle que la quantité de mémoire physique. (Non abordé en détail ici, mais le concept est similaire !)

2.2. Avantages et risques

Avantages :

Maximiser l'utilisation des ressources.
Réduire les coûts d'infrastructure (moins de serveurs physiques nécessaires).
Permettre un meilleur retour sur investissement du matériel existant.

Risques :

Contentions CPU si plusieurs VMs sont fortement consommatrices en même temps.
Dégradation des performances si le ratio d'oversubscription est trop élevé.
Difficultés de diagnostic et de dépannage en cas de ralentissements inattendus.

3. Bonnes pratiques générales pour le ratio vCPU/pCPU

3.1. Notion de ratio d'oversubscription

On parle souvent de ratio entre le nombre de vCPU alloués et le nombre de cœurs physiques (pCPU) d'un serveur. Ce ratio peut être exprimé sous forme :

Ratio = Nombre total de vCPU / Nombre total de cœurs physiques

Exemples de ratios courants :

1:1 : Aucun oversubscription (un vCPU pour un pCPU). C'est l'idéal pour les charges de travail très intensives (HPC, bases de données critiques, etc.), mais rarement réalisable à grande échelle.
2:1 : Légère oversubscription. Courant pour des environnements de production modérée.
4:1 : Ratio souvent considéré comme « standard » pour un environnement mixte de production.
6:1 ou 8:1 : Couramment rencontré dans des environnements de test, de développement ou des workloads peu exigeants (bureautique, serveurs web légers, etc.).

3.2. Paramètres à prendre en compte

1. Type de charges de travail (workloads)

Pour des charges intensives (SQL, Oracle, serveurs d'applications, HPC), il est préférable de limiter l'oversubscription (1:1, 2:1 ou 3:1 max).
Pour des charges plus légères (serveurs de fichiers, contrôleurs de domaine, serveurs web faiblement sollicités), un ratio plus élevé (4:1, 6:1 ou plus) peut être envisagé.

2. Profil d'utilisation

Heures de pointe, cycles de charge, besoins de burst (pics de ressources) : il est important de connaître le comportement de chaque VM pour éviter une contention simultanée.

3. Qualité de service (SLA)

Les environnements qui exigent une très haute disponibilité et performance doivent viser un ratio conservateur (1:1 ou 2:1).
Les environnements de laboratoire, tests ou sandbox peuvent supporter un ratio bien plus élevé.

4. Capacités de gestion de la ressource CPU de l'hyperviseur

Tous les hyperviseurs ne gèrent pas l'oversubscription de la même manière (gestion des priorités, de l'équité CPU, etc.).

4. Spécificités par hyperviseur

4.1. Microsoft Hyper-V

1. Oversubscription CPU sur Hyper-V

Par défaut, Hyper-V permet la sur-allocation de vCPU, mais Microsoft recommande la prudence pour les environnements critiques.
Les recommandations officielles ne fixent pas un ratio clair et unique, car tout dépend de la charge réelle. Cependant, on trouve souvent des ratios de 2:1 à 4:1 comme bonnes pratiques pour des environnements de production.
Pour des environnements de test, ce ratio peut monter jusqu'à 8:1, voire plus, si la charge reste faible.

2. Gestion dynamique

Hyper-V utilise un planificateur CPU qui distribue les cycles CPU en fonction des besoins.
Il est toutefois important d'utiliser les outils de monitoring (PerfMon, etc.) pour s'assurer que la contention ne dépasse pas un seuil acceptable.

3. Bonnes pratiques spécifiques

Limiter le nombre de vCPU par VM : N'attribuez pas systématiquement 4 ou 8 vCPU à chaque VM « juste au cas où ». Commencez petit (1 ou 2 vCPU) et augmentez en cas de besoin.
Suivre l'Average CPU Usage des hôtes et des VMs pour adapter en permanence le ratio.

4.2. Proxmox VE

1. Oversubscription CPU sur Proxmox

Proxmox VE (basé sur KVM/QEMU) supporte l'oversubscription sans limite stricte technique (vous pouvez même aller jusqu'à 10:1 ou plus).
Toutefois, pour un usage en production, un ratio de 2:1 ou 4:1 est fréquent, afin d'assurer une certaine stabilité et réactivité.

2. Gestion des ressources

Proxmox gère les cgroups et dispose d'outils de limitation (CPU limit, CPU units) pour affiner la répartition des ressources.
Il est essentiel de définir correctement les limites et les priorités (par exemple, CPU shares) pour éviter qu'une VM gourmande n'affecte toute la plateforme.

3. Bonnes pratiques spécifiques

Utiliser le ballon de mémoire et la surveillance fine (p. ex. : pvestatd ou via l'interface graphique) pour identifier les VMs sous-utilisées ou surprovisionnées.
Pour des workloads critiques, rester sur un ratio 1:1 à 2:1. Pour du test ou du lab, on peut monter plus haut.

4.3. VMware ESXi

1. Oversubscription CPU sur VMware

VMware ESXi est réputé pour son planificateur CPU efficace (CPU Scheduler), permettant des oversubscriptions plus élevées.
VMware ne fournit pas de chiffre officiel unique (car très dépendant du contexte), mais en pratique, les ratios de 4:1 à 6:1 sont souvent constatés dans des environnements de production standard.

2. Fonctionnalités clés

vSphere DRS (Distributed Resource Scheduler) permet de répartir automatiquement la charge CPU (et mémoire) entre plusieurs hôtes dans un cluster, optimisant l'allocation et permettant des oversubscriptions plus agressives.
vMotion pour migrer les VMs à chaud vers d'autres hôtes moins chargés.

3. Bonnes pratiques spécifiques

Surveiller régulièrement les indicateurs clés (CPU Ready Time, Co-Stop, etc.) : si le CPU Ready Time devient élevé, c'est le signe d'une contention.
Ne pas sur-allouer la mémoire de façon excessive, car le swapping ou le ballooning peut encore aggraver la performance globale.

5. Recommandations pratiques et synthèse

Évaluer la charge réelle : Avant d'adopter un ratio d'oversubscription, analysez les utilisations CPU moyennes et maximales (peak usage) de vos VMs. Les outils de monitoring (vCenter, SCVMM, Proxmox GUI, ou des solutions tierces) sont essentiels pour avoir une vision claire.
Commencer "petit" : Il est préférable de démarrer avec des ratios raisonnables (2:1 ou 4:1), puis de surveiller l'évolution. Ajouter des vCPU ou augmenter le nombre de VM au fil de l'eau, plutôt que de commencer trop haut et d'avoir des performances médiocres.
Tenir compte de la criticité des services : Pour des VMs critiques (base de données, ERP, etc.), limitez drastiquement l'oversubscription. Pour des VMs peu sollicitées (serveurs de fichiers, petits services web), vous pouvez vous permettre un ratio plus élevé.
Surveiller et ajuster en continu : La charge CPU et l'usage des ressources varient dans le temps. Ce qui était acceptable hier peut devenir sous-dimensionné ou sur-dimensionné demain. Mettez en place des alertes ou des tableaux de bord (dashboards) pour ajuster rapidement le ratio si besoin.
Ne pas oublier les autres ressources : L'oversubscription est aussi possible sur la mémoire et, dans certains cas, sur le stockage. Assurez-vous de considérer la bande passante réseau, l'IO disque, etc. Un goulot d'étranglement sur ces ressources peut impacter la performance globale, même si le CPU est correctement dimensionné.

6. Exemples de scénarios

Scénario 1 : Environnement de production critique

Description : Plusieurs bases de données SQL, serveurs d'applications transactionnels.
Recommandation : Ratio conservateur (1:1 ou 2:1) pour limiter la contention CPU. Surveillez le CPU Ready Time (sous ESXi), la queue CPU (sous Hyper-V), ou les load averages (sous Proxmox).

Scénario 2 : Environnement de production mixte

Description : Applications web, serveurs de fichiers, contrôleurs de domaine, quelques bases de données moyennes.
Recommandation : Ratio intermédiaire (2:1 à 4:1). Ajustez en fonction de l'utilisation réelle et des pics de charge.

Scénario 3 : Environnement de test / DevOps / Lab

Description : Serveurs de test, maquettes, CI/CD, etc.
Recommandation : Ratio plus élevé (4:1, 6:1, voire 8:1). Acceptez une baisse de performance temporaire en période de forte sollicitation, car la criticité est moindre.

7. Conclusion

L'oversubscription est un levier puissant pour tirer pleinement parti d'un hyperviseur.
Bien géré, il permet de déployer plus de VMs sur moins de serveurs physiques, réduisant les coûts et optimisant l'exploitation. Toutefois, la règle d'or est de toujours surveiller finement l'usage CPU (et les autres ressources) en fonction de la charge attendue des futures systèmes invités, afin de ne pas engendrer de contention nuisible pour les performances.

Chaque hyperviseur (Hyper-V, Proxmox, VMware ESXi) dispose de ses mécanismes de planification et d'outils de gestion de la ressource. Les ratios d'oversubscription courants varient entre 2:1 et 4:1 pour une production standard, 1:1 ou 2:1 pour des charges critiques, et des valeurs plus élevées (6:1 ou 8:1) dans des environnements de tests ou de charges légères.

En somme, il n'existe pas de "recette miracle" fixe ! Il faut évaluer la charge, démarrer avec prudence et ajuster en fonction du retour d'expérience et de la surveillance continue.
Ainsi, l'oversubscription deviendra un atout plutôt qu'une source de problèmes.

⬆️ Retour en haut de la page