Accueil › Guides › Dimensionner un cluster Proxmox

Dimensionner un cluster Proxmox : les règles qui évitent les mauvaises surprises

Un cluster de virtualisation ne se dimensionne pas en additionnant des serveurs : il se dimensionne en règles. Combien de nœuds pour survivre à une panne, combien de machines virtuelles par cœur physique, quel stockage selon la taille, quels réseaux ne jamais mélanger. Voici ces règles, et pourquoi chacune existe.

Estimer mon coût →

Trois nœuds, pas deux : la règle du quorum #

Un cluster prend ses décisions à la majorité : c'est le quorum. À deux nœuds, il n'y a pas de majorité possible : si l'un tombe ou si le lien entre les deux se coupe, chacun ignore si l'autre est en panne ou simplement injoignable, et le cluster se fige pour éviter que les deux écrivent en même temps. Trois nœuds est donc le plancher de la haute disponibilité. À deux ou quatre nœuds, un témoin de quorum (une petite machine chez un tiers, appelée QDevice) rétablit un nombre de votes impair.

La capacité N+1 : prévoir la panne, pas l'espérer #

La règle la plus rentable du dimensionnement : le cluster doit porter toute la charge avec un nœud arrêté, sans dépasser environ 80 % d'utilisation. Un nœud arrêté, ce n'est pas seulement une panne : c'est aussi chaque mise à jour du système, planifiée et sereine. Un cluster dimensionné au ras de sa capacité transforme la moindre maintenance en négociation.

Le ratio de consolidation : des vCPU aux cœurs réels #

Les machines virtuelles n'utilisent pas tout leur processeur en même temps : on peut donc allouer plus de vCPU qu'il n'y a de cœurs physiques. L'ordre de grandeur d'usage : 3 vCPU par cœur pour de la production généraliste, 4 et plus pour du développement et des tests, mais 1,5 à 2 pour des bases de données ou des applications sensibles à la latence. La mémoire, elle, ne se suralloue jamais en production : la RAM promise doit exister, sinon le système pagine et tout ralentit.

Le stockage suit le nombre de nœuds #

En dessous de 3 nœuds, le stockage local ZFS avec réplication vers l'autre nœud est simple et rapide, mais la réplication est asynchrone : en cas de bascule, on repart de la dernière copie, avec quelques minutes de perte possibles. À partir de 3 nœuds, Ceph transforme les disques des serveurs en un stockage partagé qui garde trois copies de chaque donnée : un nœud peut brûler, rien n'est perdu. En contrepartie, Ceph exige un réseau dédié rapide et des disques de qualité serveur, et il faut lui laisser de l'espace libre pour reconstruire après une panne.

La RAM que le stockage réclame avant la première machine virtuelle #

C'est l'erreur de dimensionnement la plus coûteuse, parce qu'elle ne se voit que des mois plus tard. Quand les disques des serveurs forment le stockage partagé, chaque disque est piloté par un processus qui réclame sa propre mémoire : comptez environ 8 Go de RAM par disque, plus 1 Go par téraoctet de capacité brute, plus 2 Go pour le système de l'hyperviseur, et au moins un cœur processeur dédié par disque. Cette réserve n'est pas une marge de confort : après la panne d'un nœud, les processus survivants portent la reconstruction et leur besoin mémoire augmente. S'il n'y a plus rien à prendre, le système tue le plus gros consommateur, qui est souvent l'un de ces processus, et la grappe tombe entière pendant qu'elle essayait de se réparer. Un serveur de douze disques et vingt téraoctets réserve ainsi près de cent vingt gigaoctets avant d'héberger quoi que ce soit.

Les réseaux qui ne se mélangent jamais #

Un cluster fait passer des flux très différents : le trafic des machines virtuelles, le stockage, la migration à chaud, et le battement de cœur du cluster (corosync) qui vérifie en permanence que chaque nœud est vivant. Ce dernier a besoin d'une latence stable plus que de débit : s'il partage le réseau du stockage et qu'une grosse copie sature le lien, les nœuds se croient mutuellement morts et le cluster bascule pour rien. Attention au raccourci le plus répandu : un VLAN ne suffit pas. Un VLAN sépare logiquement mais partage le câble, donc la file d'attente ; sous charge, le battement de cœur attend son tour comme le reste. Il lui faut deux liens physiquement dédiés, et deux liens à 1 Gbit/s suffisent largement, car il ne demande pas du débit, il demande de ne jamais attendre. Évitez aussi de l'agréger : il gère lui-même ses liens et bascule en millisecondes, alors qu'un agrégat peut garder actif un lien qui perd des paquets.

La sauvegarde vit hors du cluster #

Un stockage répliqué protège contre la panne d'un disque, pas contre une suppression, un chiffrement malveillant ou une erreur humaine : la réplication copie fidèlement la bêtise comme le reste. La sauvegarde vit donc sur une machine séparée du cluster, avec une copie hors site : c'est la règle dite 3-2-1 (trois copies, deux supports, une hors site). Et une sauvegarde jamais restaurée n'est qu'un espoir : le test de restauration se planifie avant la mise en production.

Le même niveau de souscription sur tous les nœuds #

Une règle contractuelle que rien ne laisse deviner, et qui coûte cher quand on l'ignore : dans une grappe, tous les nœuds doivent porter le même niveau de souscription. Dès qu'un nœud en a une, tous doivent en avoir une. Mettre le niveau le plus élevé sur un seul serveur et laisser les autres sans rien ne fait pas économiser : cela rend l'ensemble des souscriptions invalides et ferme l'accès aux mises à jour stabilisées pour tout le cluster. Le nombre de processeurs, lui, peut différer d'un serveur à l'autre : c'est le niveau qui doit être uniforme, pas le gabarit.

Faire le calcul sur votre parc #

Ces règles se calculent : notre Architecte Digital dimensionne votre cluster (nœuds, stockage, sauvegarde, souscriptions à la grille publique de l'éditeur) à partir de votre nombre de machines virtuelles, sort la réserve mémoire et processeur que le stockage prend par nœud, le nombre de disques à commander, et termine par la fiche de besoin d'hébergement, espace, puissance et refroidissement, directement comparable dans le comparateur.

Questions fréquentes #

Pourquoi pas un cluster à 2 nœuds ?

Sans majorité possible, une coupure fige le cluster : chaque nœud ignore si l'autre est mort ou juste injoignable. À 2 nœuds, ajoutez un témoin de quorum (QDevice) sur un site tiers, même une petite machine virtuelle suffit.

Combien de VM par serveur physique ?

Cela dépend du profil : en production généraliste, environ 3 vCPU par cœur physique et jamais plus de mémoire allouée que de mémoire réelle. Les bases de données exigent un ratio plus bas, le développement en tolère un plus haut.

Ceph ou ZFS ?

Moins de 3 nœuds : ZFS local répliqué, simple et rapide, mais réplication asynchrone. 3 nœuds et plus : Ceph fournit un vrai stockage partagé avec trois copies de chaque donnée, au prix d'un réseau dédié rapide et de disques de qualité serveur.

Que devient la sauvegarde si le stockage est déjà répliqué ?

La réplication protège du matériel, pas des erreurs : une suppression ou un rançongiciel se répliquent aussi. Il faut une sauvegarde séparée du cluster, avec une copie hors site, et un test de restauration planifié.

Rédigé le 10 septembre 2026.