Dimensionner Proxmox VE sur un serveur dédié 40 coeurs : combien de VM et de conteneurs

Pourquoi dimensionner avant d'installer Proxmox VE

Un serveur dédié bi-processeur Xeon Gold 6230 fournit 40 coeurs physiques, 80 threads et de 32 à 512 Go de RAM DDR4 ECC. C'est largement assez pour héberger des dizaines de machines virtuelles KVM et de conteneurs LXC sous Proxmox VE. Mais installer Proxmox sur un serveur de cette envergure sans réfléchir à la répartition des ressources, c'est gaspiller de la puissance ou créer des contentions qui ralentissent tout le monde.

Ce guide vous aide à dimensionner votre installation Proxmox VE sur un serveur dédié 40 coeurs : combien de vCPU attribuer par machine virtuelle, comment répartir la mémoire entre l'hôte, le cache ZFS et les VM, quel espace disque prévoir sur 1 To SSD, et combien de VM et de conteneurs vous pouvez raisonnablement faire tourner en parallèle. Nous détaillerons trois configurations concrètes : 64, 128 et 256 Go de RAM.

Si vous hésitez entre Proxmox VE et OpenStack, consultez d'abord notre comparatif Proxmox vs OpenStack. Pour les caractéristiques détaillées du processeur, voir la fiche technique du Xeon Gold 6230.

CPU : ratio vCPU par coeur physique

Le Xeon Gold 6230 offre 20 coeurs et 40 threads par socket. En bi-processeur, vous disposez de 40 coeurs physiques et 80 threads (fréquence de base 2,1 GHz, turbo 3,9 GHz, cache L3 de 27,5 Mo par CPU). Proxmox VE attribue des vCPU (processeurs virtuels) à chaque VM ou conteneur LXC.

Le nombre total de vCPU attribués à l'ensemble des VM peut dépasser le nombre de coeurs physiques : c'est la surallocation CPU (overcommit). Proxmox l'autorise tant que chaque VM individuelle ne dépasse pas le nombre de coeurs physiques disponibles. Concrètement, sur 40 coeurs, une VM peut recevoir au maximum 40 vCPU.

Le ratio recommandé dépend du type de charge :

En pratique, une installation mixte (quelques VM lourdes et beaucoup de services légers) fonctionne bien avec un ratio global entre 3:1 et 6:1. Surveillez le steal time (vmstat 1, colonne st) dans chaque VM : au-dessus de 5 %, la contention CPU devient perceptible.

Réservez environ 10 à 20 % de la capacité CPU pour l'hyperviseur Proxmox lui-même (émulation I/O, réseau virtuel, tâches de gestion). Sur 80 threads, cela représente 8 à 16 threads à ne pas attribuer aux VM.

RAM : mémoire hôte, ballooning et cache ZFS

La mémoire est le facteur limitant le plus fréquent en virtualisation. Contrairement au CPU, la RAM ne se partage pas facilement : chaque Go attribué à une VM est un Go en moins pour les autres. Trois postes consomment de la RAM avant vos machines virtuelles :

• Proxmox VE et le noyau Linux : comptez environ 1 à 2 Go pour l'hôte ;
• ZFS ARC (si vous utilisez ZFS comme système de fichiers) : le cache adaptatif (ARC) accélère les lectures disque en gardant les blocs fréquents en RAM. Depuis Proxmox VE 8.1, la limite par défaut est 10 % de la RAM installée, plafonnée à 16 Go. La recommandation Proxmox est de 2 Go de base + 1 Go par To de stockage. Sur un serveur avec 1 To SSD, 3 Go d'ARC constituent un bon compromis ;
• KSM (Kernel Same-page Merging) : Proxmox peut fusionner les pages mémoire identiques entre VM (typiquement les pages du noyau quand plusieurs VM tournent la même distribution). Le gain varie selon les charges de travail.

Le ballooning est le mécanisme de mémoire dynamique de Proxmox VE. Pour chaque VM, vous définissez une quantité minimale (toujours réservée) et une quantité maximale. Quand l'hôte passe au-dessus de 80 % d'utilisation mémoire (seuil configurable par noeud), il demande aux VM de restituer la RAM inutilisée via le pilote virtio-balloon. Quand la pression retombe, les VM récupèrent de la RAM jusqu'à leur maximum.

Le ballooning nécessite l'installation du QEMU Guest Agent dans chaque VM. Sur les conteneurs LXC, la mémoire est gérée nativement par les cgroups du noyau hôte : pas de driver supplémentaire, et l'overhead mémoire est quasi nul.

Formule de calcul de la RAM disponible pour vos VM et conteneurs :

RAM disponible = RAM totale - hôte (2 Go) - ZFS ARC (3 Go si ZFS)

Exemple avec 128 Go et ZFS :
128 - 2 - 3 = 123 Go pour les VM et LXC

Stockage : répartir 1 To SSD entre les VM

Les serveurs dédiés Xeon Gold ElypseCloud incluent 1 To SSD (2 x 1 To SSD sur la configuration 512 Go sur devis). Comment répartir cet espace entre Proxmox, les VM et les conteneurs LXC ?

Proxmox VE occupe environ 10 à 15 Go pour le système hôte (Debian, paquets Proxmox, logs). Si vous utilisez ZFS, le système de fichiers réserve une partie de l'espace pour les métadonnées et les snapshots.

Deux stratégies de provisioning :

• Provisioning épais (raw) : l'espace disque est alloué intégralement à la création. Plus prévisible, jusqu'à 10 % plus rapide en écriture séquentielle. Utile pour les VM dont la taille finale est connue (bases de données, serveurs de fichiers) ;
• Provisioning fin (qcow2 ou ZFS thin) : le fichier image grossit à la demande. Permet d'attribuer plus d'espace que physiquement disponible, à condition de surveiller le remplissage. Adapté aux VM de développement et aux conteneurs LXC.

Budget réaliste sur 1 To SSD avec provisioning fin :

Pour les sauvegardes, un stockage externe (NFS, second disque, stockage distant) est recommandé en complément des snapshots locaux. Consultez notre guide sauvegardes et haute disponibilité sur serveur dédié.

Réseau : bridge, bande passante et VLAN

Chaque VM et conteneur LXC se connecte à un bridge réseau Linux (vmbr0 par défaut). Sur les serveurs dédiés ElypseCloud, vous disposez d'une bande passante publique de 1 ou 10 Gbit/s, d'une adresse IPv4 dédiée et d'un bloc IPv6.

Pour un serveur hébergeant de nombreuses machines virtuelles, créez des VLAN pour isoler les flux :

• Un VLAN pour les services exposés à Internet (reverse proxy, serveurs web) ;
• Un VLAN interne pour les bases de données et les services backend ;
• Un VLAN d'administration pour l'accès SSH et l'interface Proxmox (port 8006).

Proxmox VE supporte les VLAN au niveau du bridge et, depuis la version 9.0, les SDN Fabrics pour créer des réseaux overlay (VXLAN, EVPN) sans équipement externe. La bande passante entre VM sur un même hôte n'est pas limitée par la carte réseau physique : elle transite par le bridge en mémoire. Le goulot est la bande passante vers l'extérieur (1 ou 10 Gbit/s partagés entre toutes les VM).

Topologie NUMA et placement des VM

Un serveur bi-processeur Xeon Gold 6230 expose deux noeuds NUMA : chaque CPU forme un noeud avec 20 coeurs et 6 canaux mémoire DDR4. Un processeur accède à sa mémoire locale plus rapidement qu'à la mémoire du noeud distant.

Dans Proxmox, activez l'option NUMA pour chaque VM (numa: 1 dans le fichier de configuration). L'ordonnanceur Proxmox place alors les vCPU et la mémoire de la VM sur le même noeud physique, ce qui réduit la latence. Pour les VM à 20 vCPU ou moins, un placement sur un seul noeud est optimal. Au-delà, la VM s'étend sur les deux noeuds.

Pour approfondir la gestion NUMA sur serveur dédié, consultez notre guide comprendre NUMA et répartir la charge sous Linux.

Exemple de répartition : 64 Go de RAM

La configuration SD2-G-64 (2 x Xeon Gold 6230, 64 Go DDR4 ECC, 1 To SSD, 123,50 euros TTC/mois) convient à un lab avancé ou à une petite production multi-services.

Budget mémoire :

• Hôte Proxmox : 2 Go
• ZFS ARC : 3 Go
• Disponible pour les VM et LXC : 59 Go

Exemple de répartition réaliste :

Total : 16 vCPU (ratio 0,4:1 sur 40 coeurs, aucune contention CPU) et 34 Go de RAM attribués. Il reste 25 Go de marge pour des pics de charge ou des VM supplémentaires. Avec le ballooning activé et des minimums à 50 % du maximum, la mémoire réellement consommée au repos peut descendre sous 20 Go.

Exemple de répartition : 128 Go de RAM

La configuration SD3-G-128 (2 x Xeon Gold 6230, 128 Go DDR4 ECC, 1 To SSD, 136,50 euros TTC/mois) est le point d'équilibre pour une production sérieuse avec virtualisation dense.

Budget mémoire : 128 - 2 (hôte) - 3 (ARC) = 123 Go disponibles.

Total : 37 vCPU (ratio 0,9:1, pas de surallocation) et 97 Go de RAM attribués. Il reste environ 26 Go de marge. Le ratio CPU reste conservateur : aucune VM ne subit de contention, même aux heures de pointe. Vous pouvez encore ajouter 5 à 10 conteneurs légers sans dépasser les ressources.

Exemple de répartition : 256 Go de RAM

La configuration SD4-G-256 (2 x Xeon Gold 6230, 256 Go DDR4 ECC, 1 To SSD, 195 euros TTC/mois) permet de la virtualisation dense avec des bases de données volumineuses et de nombreux services en parallèle.

Budget mémoire : 256 - 2 (hôte) - 5 (ARC élargi) = 249 Go disponibles.

Total : 57 vCPU (ratio 1,4:1 sur 40 coeurs, surallocation légère) et 232 Go de RAM attribués sur 249 Go disponibles. Les 80 threads absorbent largement 57 vCPU en charge mixte. Avec le ballooning et le provisioning fin, cette configuration héberge plus de 20 services en production simultanée.

Le stockage total dépasse le To SSD en allocation nominale, mais avec le provisioning fin (qcow2 ou ZFS thin), les disques virtuels n'occupent que l'espace réellement écrit. Surveillez le taux de remplissage et prévoyez un stockage externe pour les sauvegardes.

Tableau de synthèse par configuration

Ces chiffres supposent une charge mixte avec un ratio de surallocation CPU de 2:1 à 4:1 et le ballooning activé. Pour une charge purement CPU-bound (compilation, encodage), divisez le nombre de vCPU par deux. Pour des conteneurs LXC légers (DNS, reverse proxy, monitoring), vous pouvez en ajouter bien plus que les fourchettes indiquées.

La gamme Xeon E5 offre 16 coeurs et 32 threads pour un budget plus serré (à partir de 80 euros TTC/mois). Si votre charge ne dépasse pas une dizaine de VM, elle suffit largement.

Conteneur LXC ou VM KVM : quand choisir quoi

Proxmox VE propose deux technologies de virtualisation :

• VM KVM : virtualisation complète avec un noyau indépendant. Nécessaire pour Windows, pour les applications qui modifient le noyau, ou quand l'isolation totale est requise (environnements multi-clients). Overhead mémoire d'environ 200 à 500 Mo par VM (noyau invité, pilotes virtio) ;
• Conteneur LXC : virtualisation légère qui partage le noyau de l'hôte. Démarrage en 1 à 3 secondes, overhead mémoire quasi nul. Adapté aux services Linux mono-applicatifs (reverse proxy, DNS, monitoring, bases de données). Ne supporte pas Windows.

En règle générale, choisissez LXC par défaut et KVM uniquement quand c'est nécessaire. Sur un serveur 40 coeurs avec 128 Go de RAM, vous pouvez facilement mélanger 6 VM lourdes et 15 conteneurs LXC.

Pour automatiser le déploiement de services courants en conteneurs LXC sous Proxmox, consultez notre guide Proxmox VE Helper Scripts.

Bonnes pratiques de dimensionnement Proxmox VE

• Commencez avec des minimums bas et le ballooning activé : montez la RAM quand vous observez une pression mémoire réelle, pas par précaution ;
• Utilisez des conteneurs LXC plutôt que des VM pour les services qui ne nécessitent pas un noyau isolé (reverse proxy, DNS, monitoring, CI runners). Un conteneur LXC consomme moins de RAM et démarre en quelques secondes ;
• Activez NUMA dans la configuration de chaque VM (numa: 1) pour que Proxmox place les vCPU et la mémoire sur le même noeud physique ;
• Surveillez la consommation réelle avec l'interface Proxmox ou un outil de monitoring. Les allocations initiales sont des estimations : ajustez-les après quelques jours de production ;
• Si vous utilisez ZFS, adaptez la limite ARC à votre usage. Modifiez zfs_arc_max dans /etc/modprobe.d/zfs.conf pour libérer de la RAM pour les VM ou augmentez-la si le cache améliore vos I/O ;
• Utilisez le contrôleur de disque VirtIO SCSI pour les VM : il double le débit en écriture séquentielle par rapport à l'émulation IDE ;
• Sécurisez votre serveur dédié avant de mettre les VM en production.

Conclusion

Un serveur dédié bi-processeur Xeon Gold 6230 avec 40 coeurs, 80 threads et jusqu'à 256 Go de RAM DDR4 ECC (512 Go sur devis) offre une capacité de virtualisation considérable sous Proxmox VE. La clé d'un dimensionnement réussi repose sur trois principes : ne pas surallouer le CPU au-delà d'un ratio 4:1 pour les charges de production, réserver la mémoire pour l'hôte et le cache ZFS avant d'attribuer le reste aux VM, et préférer les conteneurs LXC pour les services légers afin de maximiser la densité.

Avec la configuration SD3-G-128 à 136,50 euros TTC par mois, vous pouvez héberger une dizaine de machines virtuelles et une quinzaine de conteneurs en production. Pour une virtualisation encore plus dense, la SD4-G-256 à 195 euros TTC par mois double la capacité mémoire. Si votre charge ne justifie pas 40 coeurs, la gamme Xeon E5 offre 16 coeurs et 32 threads à partir de 80 euros TTC par mois.