Points essentiels

  • Le ratio vCPU/pCPU recommandé est de 3:1 à 5:1 en production générale, 1:1 pour les charges temps réel (bases de données, VoIP)
  • La RAM ne tolère pas l'overcommit en production : prévoir 1:1 + 20 % de marge HA par nœud + overhead ZFS ARC
  • Le stockage Ceph exige 3 réplicas (×3 la volumétrie utile) ; ne jamais dépasser 80 % d'occupation du pool
  • Un cluster Proxmox HA nécessite 3 nœuds minimum pour le quorum Corosync sans QDevice externe

Dimensionner un cluster Proxmox VE sans outil structuré conduit inévitablement à deux écueils : le sous-dimensionnement qui génère des contentions et des interruptions de service, ou le surdimensionnement qui immobilise du budget et complexifie l'exploitation. Le calculateur de sizing interactif ci-dessous vous permet d'évaluer avec précision les ressources CPU, mémoire, stockage et réseau nécessaires à vos charges de travail virtualisées, en intégrant les marges de haute disponibilité recommandées par Proxmox et l'ANSSI.

Ce calculateur est conçu pour Proxmox VE 8.x et 9.x. Il intègre les ratios de consolidation issus des bonnes pratiques documentées par la communauté Proxmox, ainsi que les recommandations ANSSI sur la segmentation des environnements virtualisés (PA-022). Les résultats sont des estimations orientatives : un audit de charge réelle reste indispensable avant tout achat matériel.

Calculateur de dimensionnement Proxmox VE

Charges de travail

Stockage

Haute disponibilité & réseau

Résultats — Dimensionnement recommandé

Score de configuration —

    Ratios de consolidation et formules de dimensionnement

    Le dimensionnement d'un cluster Proxmox repose sur quatre ressources interdépendantes : le CPU, la mémoire, le stockage et le réseau. Une erreur sur l'un de ces axes compromet l'ensemble de l'architecture.

    Dimensionnement d'un cluster Proxmox VE : ressources, ratios et marges de sécurité
    Ressource Méthode de calcul Ratio recommandé Marge HA Erreur fréquente
    vCPU / cœurs physiquesSomme vCPU ÷ cœurs physiques réels (hors Hyper-Threading)3:1 à 5:1 en production, 1:1 pour temps réelN+1 : un nœud entier libéréCompter les threads logiques comme des cœurs physiques
    Mémoire vive (RAM)RAM VMs + overhead hyperviseur 5 % + ARC ZFSOvercommit 1:1 max ; 1,25:1 avec KSM uniquement20-30 % libre par nœud pour absorber une bascule HAOublier que l'ARC ZFS consomme jusqu'à 50 % de la RAM par défaut
    Stockage capacitaireVolumétrie utile × facteur de réplication + snapshotsCeph 3 réplicas = ×3 ; ZFS RAID-10 = ×2Ne jamais dépasser 80 % d'occupation (85 % = alerte Ceph)Dimensionner sur la capacité brute au lieu de la capacité utile
    IOPS et latenceIOPS agrégées VMs en pic × 1,5SSD NVMe entreprise avec PLP obligatoirePrévoir la dégradation pendant un rebuild de poolUtiliser des SSD grand public pour du Ceph ou ZFS sync
    Réseau de productionDébit cumulé VMs + trafic migration live2 × 10 GbE minimum en LACP par nœudDoublement des liens et des commutateurs (pas de SPOF)Mutualiser production, stockage et Corosync sur le même lien
    Réseau CorosyncTrafic faible ; exigence latence stricte < 5 msLien physique dédié, 2 anneaux Corosync distinctsQuorum obligatoire : 3 nœuds min. ou QDevice témoinPartager Corosync avec Ceph : latence → fencing intempestif

    Dimensionnement CPU : le ratio vCPU/pCPU

    Le ratio de consolidation CPU est le premier paramètre à établir avant tout achat matériel. Il exprime le rapport entre le nombre total de vCPU alloués aux machines virtuelles et le nombre de cœurs physiques réels disponibles sur un nœud. L'erreur la plus fréquente consiste à compter les threads logiques (Hyper-Threading) comme des cœurs physiques : un processeur EPYC 9354 affiche 32 cœurs et 64 threads, mais le ratio doit être calculé sur 32, pas 64.

    Les ratios pratiques selon les charges :

    • 1:1 — Bases de données relationnelles, VoIP, trading haute fréquence, systèmes temps réel. Toute contention CPU produit des latences inacceptables.
    • 2:1 à 3:1 — Applications métier lourdes, compilation, rendu, ERP avec charges pics marquées.
    • 4:1 à 5:1 — Serveurs web, messagerie, SIEM, environnements de développement, charges prévisibles et lissées dans le temps.
    • Au-delà de 5:1 — Environnements de test ou formations uniquement ; jamais en production.

    Pour la haute disponibilité N+1, la règle est simple : dimensionnez comme si vous aviez un nœud de moins. Si votre cluster a 3 nœuds, la capacité totale doit être supportable par 2 nœuds en cas de panne du troisième.

    Dimensionnement mémoire : l'ARC ZFS, le grand oublié

    La mémoire est la ressource la moins flexible d'un cluster Proxmox : contrairement au CPU, l'overcommit RAM en production est déconseillé. L'overhead de l'hyperviseur Proxmox est faible (~5 % de la RAM allouée aux VMs), mais deux postes sont régulièrement sous-estimés.

    L'ARC ZFS (Adaptive Replacement Cache) est activé par défaut sur tous les nœuds utilisant un pool ZFS pour le stockage des VMs. Par défaut, Proxmox alloue jusqu'à 50 % de la RAM disponible à l'ARC. Sur un nœud à 256 Go, cela représente 128 Go consommés par le cache disque, avant même de démarrer une seule VM. La recommandation est de limiter l'ARC à 25-30 % via `/etc/modprobe.d/zfs.conf` :

    options zfs zfs_arc_max=68719476736   # 64 Go pour un nœud 256 Go
options zfs zfs_arc_min=4294967296    # 4 Go minimum

    La marge HA impose de maintenir 20 à 30 % de RAM libre par nœud pour absorber les migrations live lors d'une bascule. Sur un cluster 3 nœuds à 256 Go chacun, la capacité réellement utilisable est : 3 × 256 × 0,70 = 537 Go de RAM VM maximum, pas 768 Go.

    Dimensionnement stockage : Ceph vs ZFS

    Le choix du backend de stockage détermine le facteur multiplicatif de votre volumétrie brute. Pour 100 To de données utiles :

    • Ceph avec 3 réplicas : 300 To bruts nécessaires + 25 % de marge (jamais remplir au-delà de 80 % sous peine d'alerte HEALTH_WARN) = 375 To à provisionner.
    • ZFS RAID-10 : 200 To bruts + marge = 250 To.
    • ZFS RAIDZ2 : environ 160 To bruts pour 100 To utiles + marge = 200 To.

    Ceph offre la scalabilité horizontale (ajout d'OSD à chaud) et la redondance multi-nœuds, mais exige une latence réseau inférieure à 1 ms entre les nœuds OSD — un réseau 10/25 GbE dédié est impératif. ZFS local offre de meilleures performances IOPS et latence, mais sans redondance inter-nœuds native : la réplication Proxmox (pvesr) est une sauvegarde asynchrone, pas un miroir synchrone comme Ceph.

    Architecture de référence : cluster 3 nœuds

    L'architecture minimale recommandée pour un environnement Proxmox de production est un cluster de 3 nœuds homogènes. L'homogénéité matérielle simplifie les migrations live (pas de contention sur les sets d'instructions CPU) et le dimensionnement.

    Configuration de référence — PME (50-100 VMs)

    Matériel par nœud : 2 × AMD EPYC 9254 (24c/48t) | 512 Go DDR5 ECC | 4 × NVMe 3,84 To U.2 (Ceph OSD) | 2 × 10 GbE (production+migration) | 1 × 10 GbE (Corosync dédié)

    Capacité effective : 144 cœurs physiques → 576 vCPU à ratio 4:1 | RAM utilisable : 3 × 512 × 0,65 = 998 Go | Stockage Ceph : 4 × 3,84 × 3 nœuds ÷ 3 réplicas × 0,8 = 12,3 To utiles

    Coût indicatif : 45 000 à 65 000 € (hors switch 10 GbE et baie de sauvegarde PBS)

    Réseau : VLAN segmentation et bande passante

    Proxmox distingue quatre plans réseau qui doivent être isolés sur des VLANs ou des interfaces physiques dédiées :

    1. Réseau de production VM — trafic applicatif des machines virtuelles.
    2. Réseau de stockage — trafic Ceph entre OSDs ou iSCSI/NFS vers le SAN. Exige < 1 ms de latence.
    3. Réseau de migration — trafic live migration KVM. Partage possible avec la production mais bande passante à réserver.
    4. Réseau de cluster (Corosync) — heartbeat du cluster. Latence critique (< 5 ms), débit faible. Toujours physiquement séparé.

    La configuration LACP (802.3ad) sur les interfaces de production est recommandée pour combiner redondance et agrégation de bande passante. Le QoS sur le switch doit prioriser le trafic Corosync pour éviter que des migrations massives ne déclenchent des fencing intempestifs.

    Checklist de validation avant mise en production

    • [ ] Ratio vCPU/pCPU documenté et approuvé par l'équipe ops
    • [ ] ARC ZFS limité via zfs_arc_max dans /etc/modprobe.d/zfs.conf
    • [ ] RAM disponible après marge HA vérifiée (commande : pvesh get /nodes/{node}/status)
    • [ ] Pool de stockage < 75 % d'occupation après déploiement initial
    • [ ] SSD avec Power Loss Protection (PLP) pour tous les OSD Ceph et ZFS intent log (SLOG)
    • [ ] Réseau Corosync dédié avec latence mesurée < 5 ms (corosync-cfgtool -s)
    • [ ] Test de failover HA : arrêt forcé d'un nœud, vérification de la bascule automatique
    • [ ] Sauvegardes PBS configurées avec rétention 7j/4s/3m et testées en restauration
    • [ ] Monitoring Ceph santé : ceph -s retourne HEALTH_OK
    • [ ] Firewall Proxmox activé avec règles de whitelist pour les interfaces d'administration

    Questions fréquentes

    Peut-on overcommiter la RAM dans Proxmox VE ?

    Le KSM (Kernel Same-page Merging) permet un léger overcommit mémoire (ratio 1,25:1 maximum) en fusionnant les pages mémoire identiques entre VMs. Cependant, cette technique est réservée aux environnements de développement ou aux VMs homogènes (même OS, même empreinte mémoire). En production, l'overcommit RAM expose à un risque d'OOM (Out Of Memory) lors de pics de charge simultanés, entraînant des kills de processus VM. La règle d'or reste : RAM disponible ≥ RAM allouée aux VMs + marge HA 20 %.

    Combien de nœuds minimum pour un cluster Proxmox HA ?

    Proxmox VE requiert un cluster de 3 nœuds minimum pour garantir le quorum Corosync sans composant externe. Avec 2 nœuds uniquement, en cas de panne d'un nœud, le cluster perd le quorum et se met en read-only pour éviter le split-brain. Il est possible de contourner cette limitation avec un QDevice (Quorum Device), un troisième serveur léger (Raspberry Pi, VM sur un autre site) qui vote dans le quorum Corosync sans héberger de VMs. Cette solution est valide pour les budgets contraints, mais elle introduit une dépendance réseau supplémentaire.

    Quelle différence entre Ceph et ZFS pour le stockage Proxmox ?

    Ceph est un système de fichiers distribué : les données sont réparties sur tous les nœuds du cluster, offrant une scalabilité horizontale et une redondance native. La panne d'un nœud entier n'entraîne pas de perte de données. ZFS est un système de fichiers local : chaque nœud gère son stockage indépendamment. La réplication PBS assure la sauvegarde mais pas la continuité synchrone. Ceph est recommandé pour les clusters de production de 3 nœuds ou plus avec des besoins de haute disponibilité du stockage. ZFS est préférable pour les nœuds standalone, les labs ou les environnements où la performance IOPS locale prime sur la redondance inter-nœuds.

    Comment calculer le nombre de disques NVMe pour Ceph dans Proxmox ?

    La règle pratique : nombre d'OSD par nœud = capacité utile souhaitée × 3 (réplicas) ÷ (nombre de nœuds × capacité d'un disque × 0,8). Exemple : 50 To utiles, cluster 3 nœuds, disques NVMe 3,84 To → 50 × 3 ÷ (3 × 3,84 × 0,8) = 16,3 → 17 OSD par nœud. En pratique, 4 à 6 NVMe par nœud couvrent la majorité des besoins PME. Pour les lectures aléatoires intensives, l'ajout d'un SLOG dédié (NVMe Optane ou NVMe avec PLP) réduit la latence d'écriture synchrone.

    L'Hyper-Threading améliore-t-il les performances Proxmox ?

    L'Hyper-Threading (SMT) améliore les performances globales sur des charges multithreadées et légers, mais introduit des risques de sécurité (canaux côté cache, Spectre/MDS). Pour des environnements multitenant ou hébergeant des données sensibles, l'ANSSI recommande la désactivation du SMT (nosmt dans le kernel Proxmox). Pour le dimensionnement, comptez toujours les cœurs physiques, pas les threads logiques : un EPYC 7543 (32 cœurs, 64 threads) offre 32 cœurs physiques pour le calcul du ratio vCPU/pCPU.

    Pour aller plus loin, consultez nos guides sur la sécurisation complète de Proxmox VE, le clustering haute disponibilité, l'optimisation ZFS (ARC, L2ARC, SLOG) et les stratégies de sauvegarde et restauration Proxmox.