Architecture Proxmox VE 9 : le guide de l'architecte
Une plateforme de virtualisation ne se conçoit pas en choisissant des serveurs : elle se conçoit en répondant à cinq questions, dans l'ordre, et en acceptant ce que chaque réponse interdit ensuite. Voici ces questions, les règles qui en découlent, et le chiffre que chacune met sur votre facture annuelle.
Estimer mon coût →Ce que vous quittez, et ce que vous emportez #
Le changement de modèle de licence de VMware a fait bouger des parcs entiers vers l'open-source. La bascule est réelle, mais elle se joue sur une différence de nature, pas de tarif : chez VMware vous achetez une licence comptée au cœur, avec un minimum facturé par processeur ; chez Proxmox vous achetez une souscription comptée au socket, et le logiciel fonctionne sans elle. Sans souscription vous perdez l'accès au dépôt de mises à jour validées et au support, pas la plateforme.
Ce guide suppose que la décision de principe est prise. Si elle ne l'est pas, le comparatif des options après le rachat et le mode d'emploi de la migration traitent ces deux moments séparément.
Les cinq questions qui décident de tout le reste #
Un architecte qui commence par le catalogue serveurs se trompe d'ordre. Ces cinq réponses contraignent tout ce qui vient après, et elles ne se rattrapent pas par configuration une fois le matériel livré.
| La question | Ce qu'elle décide | Où on y répond |
|---|---|---|
| Combien de machines, et de quelle nature | le nombre de nœuds et le taux de surallocation | le nœud |
| Combien de temps pouvez-vous rester arrêté | le niveau de résilience, et donc le stockage | les cinq niveaux |
| Combien de données pouvez-vous perdre | le mécanisme de réplication ou de sauvegarde | les cinq niveaux |
| Qui a le droit de voir ces données | le lieu d'hébergement et le cloisonnement réseau | où poser la plateforme |
| Qui décroche à trois heures du matin | le niveau de souscription, ou l'infogérance | les souscriptions |
Le nœud : on compte les sockets, pas les serveurs #
La souscription Proxmox se paie par socket processeur physique et par an. Cette phrase décide de votre budget d'exploitation, et elle a une conséquence que beaucoup découvrent après avoir commandé.
Un serveur mono-socket avec un processeur à 96 cœurs coûte une souscription. Deux processeurs de 48 cœurs dans le même châssis en coûtent deux, pour la même puissance de calcul. Le marché vend couramment du mono-socket de 64 à 192 cœurs avec douze canaux mémoire : à performance égale, la facture annuelle peut doubler selon la façon dont vous remplissez le châssis.
- Ne planifiez jamais un nœud au-delà de 80 % de son processeur ni de 80 % de sa mémoire. La marge n'est pas du confort : c'est ce qui absorbe la charge des machines d'un nœud tombé.
- La surallocation du processeur est normale, celle de la mémoire ne l'est pas. Les machines virtuelles n'utilisent pas toutes leur processeur en même temps ; elles occupent en revanche leur mémoire en permanence.
- Les taux de surallocation que nous appliquons : 3 vCPU par cœur physique pour une charge mixte (web, applications, services), 1,5 pour des bases de données ou toute charge sensible à la latence, 4 pour du développement et de la recette.
Ce que le stockage prend avant la première machine virtuelle #
C'est l'erreur de dimensionnement la plus coûteuse, parce qu'elle ne se voit qu'en salle. Le stockage distribué réserve de la mémoire et des cœurs sur chaque nœud, avant qu'une seule machine virtuelle ne démarre, et ce besoin ne dépend pas de la mémoire des machines : il dépend du nombre de disques et de la capacité brute.
| Poste | Ce qu'il réserve, par nœud |
|---|---|
| Proxmox VE lui-même | 2 Go de mémoire |
| ZFS | 1 Go de mémoire par téraoctet de stockage |
| Ceph | 8 Go de mémoire par disque, plus 1 Go par téraoctet brut |
| Ceph, processeur | au moins un cœur dédié par disque (deux si vous montez deux services par NVMe) |
Le plan qui tenait à l'écran et pas en salle #
Un exemple mesuré, parce qu'un ordre de grandeur convainc mieux qu'une règle. Quarante machines de 2 vCPU, 4 Go et 2 To, un serveur de fichiers ordinaire. Un modèle qui couvre le stockage par une marge forfaitaire de 20 % sur la mémoire des machines proposait trois nœuds de 128 Go. À lui seul, le stockage de cette grappe réclame environ 366 Go de mémoire par nœud.
La marge forfaitaire ne pouvait pas marcher : elle est proportionnelle à la mémoire des machines, alors que le besoin réel dépend du nombre de disques et de la capacité. Les deux grandeurs varient indépendamment, et l'écart devient absurde dès qu'on a beaucoup de disque et peu de mémoire.
Calculez ce poste séparément, toujours, avant de choisir la taille des barrettes.
Choisir son stockage : local, répliqué, distribué ou partagé #
Quatre familles, quatre compromis. Le choix se fait sur la perte de données acceptable, pas sur la performance : les quatre sont rapides avec des disques NVMe.
| Famille | Nœuds minimum | Données perdues en cas de panne | Quand la choisir |
|---|---|---|---|
| Local (LVM ou ZFS) | 1 | tout depuis la dernière sauvegarde | un seul serveur, ou des machines reconstruites en minutes |
| ZFS répliqué | 2 | 1 à 15 minutes | petite infrastructure, budget contraint, perte de quelques minutes acceptable |
| Ceph | 3 | aucune | à partir de trois nœuds, quand l'arrêt coûte plus que les disques |
| Baie partagée (iSCSI, Fibre Channel, NFS) | 2 | aucune | une baie existe déjà et elle est amortie |
La règle des 66 % sur Ceph #
Ne remplissez pas un cluster Ceph au-delà des deux tiers de sa capacité utile. Au-delà d'environ 70 %, la reconstruction après la perte d'un disque devient risquée : le cluster doit recopier les données manquantes quelque part, et s'il manque de place pendant qu'il se répare, il s'arrête.
Un cluster Ceph plein n'est pas lent, il est bloqué. Comptez cette réserve dès la commande des disques, pas quand l'alerte arrive.
Les réseaux qui ne se mélangent jamais #
Trois flux, trois natures, trois exigences. Ce qui se décide ici ne se corrige plus par configuration une fois les cartes commandées.
| Zone | Ce qui y passe | Débit courant | Forme |
|---|---|---|---|
| Machines et accès Internet | le trafic des machines virtuelles | 2 × 10 Gbit/s | agrégat LACP |
| Cluster | les messages de présence entre nœuds (corosync) | 2 × 1 Gbit/s suffisent | deux liens séparés, jamais un agrégat |
| Stockage | Ceph, NFS, iSCSI | 2 × 25 ou 2 × 100 Gbit/s | agrégat, sauf iSCSI et Fibre Channel qui veulent du multi-chemin |
Pourquoi le réseau du cluster refuse l'agrégat #
Les nœuds se parlent en permanence pour savoir qui est vivant. Ce dialogue gère sa propre redondance : donnez-lui deux liens indépendants, sur deux cartes différentes, et il bascule seul.
Un agrégat ne protège que d'une panne de câble ou de port. Il ne protège pas d'une erreur de configuration sur le commutateur, qui emporte les deux brins à la fois parce qu'ils sont vus comme un seul lien logique. Or c'est exactement le scénario qui fait redémarrer des nœuds sans explication.
Deux liens, deux cartes, deux commutateurs. Un gigabit par lien suffit : ce trafic est minuscule, mais il est sensible à la latence. Ne le faites jamais passer sur le même câble que le stockage.
Le câblage, et le commutateur qu'il suppose #
Le choix du câble découle de la distance et du débit, et il change le prix du port autant que celui du lien.
- Câble cuivre passif (DAC) : jusqu'à 3 à 5 mètres, le moins cher, aucune optique. Pour relier des nœuds dans la même baie ou vers le commutateur de haut de baie, c'est le choix par défaut.
- Câble optique actif (AOC) : jusqu'à quelques dizaines de mètres, module intégré aux deux extrémités, rien à assembler.
- Fibre et modules séparés : au-delà, et dès que le lien traverse une salle ou un bâtiment. Le module doit alors être accepté par le commutateur, ce qui n'est pas acquis : voir le guide de l'encodage constructeur.
- Jumbo frames (MTU 9000) sur la zone de stockage, activées de bout en bout. Une jumbo frame configurée d'un seul côté ne produit pas une erreur claire, elle produit des pertes intermittentes.
- Agrégation entre deux commutateurs pour que l'agrégat d'un nœud survive à la perte d'un châssis entier.
Le cas où le commutateur disparaît #
En dessous de quatre nœuds, on peut relier les serveurs directement entre eux et se passer du commutateur rapide, dont le prix dépasse souvent celui des cartes. Cette topologie a ses limites, et l'une d'elles est un piège classique : le maillage direct sans commutateur explique jusqu'où elle tient et pourquoi l'anneau se paie cher.
Le pare-feu de l'hyperviseur #
Proxmox embarque un pare-feu à trois étages : le cluster entier, chaque nœud, chaque machine virtuelle. Les règles descendent du niveau supérieur vers le niveau inférieur, et chaque étage peut être activé ou non indépendamment.
- Les alias et les ensembles d'adresses se définissent une fois et se réutilisent. Une règle qui contient une adresse en dur se périme sans prévenir.
- Les groupes de sécurité regroupent un jeu de règles réutilisable : appliquez-le aux machines de même rôle au lieu de recopier les règles sur chacune.
- Le journal des connexions est ce qui rend une règle vérifiable. Sans lui, vous saurez qu'un flux ne passe pas, jamais pourquoi.
- ⚠️ Activer le pare-feu au niveau du cluster sans avoir écrit d'abord la règle qui autorise votre propre réseau d'administration vous enferme dehors. Écrivez la règle, vérifiez-la, activez ensuite.
Durcir le nœud avant de le mettre en salle #
Un hyperviseur compromis emporte toutes les machines qu'il héberge. C'est la raison pour laquelle il ne se protège pas comme un serveur ordinaire.
- L'administration vit dans sa propre zone réseau, séparée de celle des machines virtuelles. Si un attaquant prend une machine, il ne doit pas trouver l'interface d'administration de l'hyperviseur au bout du même câble.
- Créez un compte d'administration séparé. L'installateur n'en crée pas et laisse l'accès au compte root : c'est un défaut à corriger le premier jour.
- Restreignez l'interface web et l'accès distant à une liste précise de réseaux d'administration. Pas au monde entier, même derrière un mot de passe long.
- Appliquez les mises à jour de microcode du processeur. Elles corrigent des failles matérielles que le système ne peut pas contourner seul.
GPU : trois façons de partager une carte, trois renoncements #
Le besoin le plus fréquent aujourd'hui est l'entraînement et l'exécution de modèles d'intelligence artificielle. Trois mécanismes existent, et chacun interdit quelque chose. Tous exigent que la virtualisation des entrées-sorties (IOMMU, VT-d chez Intel, AMD-Vi chez AMD) soit activée dans le BIOS ou l'UEFI de la carte mère.
| Mécanisme | Ce qu'il donne | Ce qu'il interdit |
|---|---|---|
| Passage direct, ou passthrough PCI Express | la carte entière, à une seule machine, performance native | le partage, et la migration à chaud |
| Partage de carte (vGPU, mdev) | une carte découpée en plusieurs cartes virtuelles isolées | les cartes non prévues pour, et souvent une licence en plus |
| Interface VirtIO-GPU | une accélération standardisée à faible surcoût | les bibliothèques de calcul propriétaires |
Ce que le partage de carte change au dimensionnement #
Une carte de seize unités de calcul et 64 Go de mémoire se découpe par exemple en quatre cartes virtuelles de quatre unités et 16 Go. Le même principe existe sur les cartes réseau, où une carte physique expose plusieurs fonctions virtuelles attribuables chacune à une machine.
Ces cartes ont deux conséquences que le calcul de nœuds ignore souvent : elles tirent beaucoup de courant, et elles imposent un régime de refroidissement que toutes les salles ne tiennent pas. Faites chiffrer la puissance et le refroidissement en même temps que les nœuds, pas après. La contrainte de densité, air ou liquide, est traitée dans le guide de l'hébergement GPU.
Les cinq niveaux de résilience, du RPO au RTO #
Deux mots règlent cette section. Le RPO est la quantité de données que vous acceptez de perdre, mesurée en temps : un RPO de quinze minutes signifie qu'un sinistre peut effacer le dernier quart d'heure de travail. Le RTO est le temps que vous acceptez de rester arrêté.
Ces deux chiffres ne sont pas techniques, ils sont contractuels. Faites-les écrire par la direction avant de choisir un stockage : ce sont eux qui décident, pas l'inverse. L'échelle générale, en vocabulaire d'hébergement, est traitée dans le guide du plan de continuité. Le tableau ci-dessous la traduit en mécanismes Proxmox, avec les ordres de grandeur que chacun tient.
| Niveau | Mécanisme | Données perdues | Temps d'arrêt | Coût |
|---|---|---|---|---|
| 0. Sauvegarde seule | serveur de sauvegarde sur site | 24 h | 4 à 24 h | € |
| 1. Haute disponibilité dans le cluster | stockage partagé, redémarrage automatique | aucune | 2 à 10 min | €€ |
| 2. Réplication vers un second nœud ou site | réplication ZFS ou réplication de baie | 1 à 15 min | 15 à 60 min | €€ |
| 3. Reprise sur site distant | sauvegarde distante synchronisée, bascule des adresses | 1 à 24 h | 4 à 8 h | €€€ |
| 4. Continuité multi-site | stockage synchrone entre deux sites proches, site témoin | aucune | moins de 5 min | €€€€ |
Le site témoin, et pourquoi il n'est pas facultatif #
Un cluster décide à la majorité. À deux sites qui se valent, la coupure du lien entre eux crée deux moitiés qui se croient seules survivantes et qui écrivent chacune de leur côté. Les données divergent, et la réconciliation se fait à la main.
Le troisième point de décision, qui n'héberge rien, existe pour trancher. Ce peut être une machine minuscule installée ailleurs. Sur un nombre pair de nœuds, le même rôle est tenu par un composant dédié, léger, qui ne fait que voter.
Ce détail est la différence entre un plan de continuité et deux plateformes qui se contredisent. Le dimensionnement du quorum le traite en détail.
La sauvegarde vit hors du cluster #
Une sauvegarde stockée dans le cluster qu'elle protège n'est pas une sauvegarde. Le serveur de sauvegarde dédié déduplique et compresse : comptez environ deux fois la donnée utile pour conserver une trentaine de jours, une hypothèse volontairement prudente.
- Trois copies, deux supports, une hors site. La règle est ancienne et elle tient toujours.
- ⚠️ Le mode où le serveur distant vient chercher les données change la nature de la protection. Dans le sens habituel, le site pousse vers la copie distante, donc il détient les identifiants de la copie distante. Un attaquant qui prend le site les trouve, et détruit la sauvegarde avec le reste.
- Dans le sens inverse, le serveur distant tire. Le site local ne stocke aucun identifiant du serveur distant. Un attaquant qui prend l'intégralité du site local n'a rien pour atteindre la copie. C'est le vrai argument contre les rançongiciels, et il ne coûte qu'un changement de sens.
- La bande et le stockage objet restent utiles pour la conservation longue et pour la copie réellement déconnectée.
Le réseau virtuel quand le réseau plat ne suffit plus #
Tant que toutes les machines partagent un même plan d'adressage, un pont et des VLAN suffisent. Trois situations font franchir cette limite : plusieurs clients à isoler les uns des autres, un réseau de niveau 2 à étendre entre des nœuds sans toucher au commutateur physique, et une gestion d'adresses à centraliser.
Proxmox répond avec une couche de réseau défini par logiciel (SDN) articulée autour de trois objets : la zone, qui porte la technologie, le réseau virtuel qu'elle contient, et le sous-réseau qui porte l'adressage. Les technologies vont du simple pont au VLAN, au VXLAN et à EVPN avec un contrôleur de routage.
Cette couche exige du réseau physique qu'il tienne des trames plus grandes, puisqu'elle encapsule. Prévoyez-le au moment de commander les commutateurs, pas après.
Souscriptions : la contrainte qui coûte cher quand on l'ignore #
Quatre niveaux existent, du dépôt de mises à jour validées sans ticket jusqu'au support à réponse en deux heures ouvrées. Le prix se compte par socket et par an, à la grille publique de l'éditeur.
⚠️ Dans un cluster, tous les nœuds doivent porter le même niveau. Vous ne pouvez pas mettre une souscription haute sur un nœud et laisser les autres sans rien. Dès qu'un seul nœud en a une, tous doivent en avoir une, et du même niveau. Sinon toutes deviennent invalides, et vous perdez l'accès au dépôt validé jusqu'à régularisation.
C'est la ligne de budget la plus souvent sous-estimée dans une comparaison avec l'existant. Comptez les sockets de tous les nœuds, multipliez, et comparez ensuite.
Où poser la plateforme : chez vous, en datacenter, ou les deux #
Le matériel est le même dans les trois cas. Ce qui change, c'est qui tient l'électricité, le refroidissement, la sécurité physique et le lien, et à quel prix.
| Modèle | Ce qu'il donne | Ce qu'il exige de vous |
|---|---|---|
| Chez vous | aucun loyer, maîtrise totale, latence nulle vers vos postes | une vraie salle : deux arrivées électriques, un onduleur dimensionné, du froid, un contrôle d'accès, et quelqu'un pour intervenir |
| En datacenter | l'électricité, le froid, la sécurité et les opérateurs sont fournis et contractuels | un loyer mensuel, et des mains sur site quand vous n'y êtes pas |
| Hybride | la production dans un site, la sauvegarde dans l'autre | deux liens et une discipline de bascule écrite |
L'hybride le plus utile n'est pas celui qu'on croit #
L'hybride vendu est souvent une moitié de production chez le client et une moitié dans un datacenter. Celui qui protège vraiment est plus simple : la production d'un côté, la copie de sauvegarde de l'autre, le transfert étant déclenché par le site distant, qui vient chercher les données.
Ce montage coûte une baie partielle et un lien. Il couvre le sinistre qui emporte un bâtiment, qui est le scénario contre lequel aucune redondance interne ne peut rien. Et il se met en place sans toucher à la production existante.
Si vous ne devez faire qu'une chose après avoir lu ce guide, faites celle-là.
Deux clusters valent parfois mieux qu'un seul étendu #
Un cluster qui s'étire entre deux bâtiments hérite des deux : la latence du lien devient celle du dialogue entre nœuds, et une coupure de fibre devient une partition. À partir de deux sites, il est souvent plus sain d'exploiter deux clusters indépendants plutôt qu'un seul étendu.
Proxmox fournit pour cela un gestionnaire séparé, conçu explicitement pour piloter plusieurs clusters et des machines qui n'appartiennent à aucun. Il centralise la vue, les comptes et les droits, au lieu de donner un accès nœud par nœud.
⚠️ La migration d'une machine d'un cluster vers un autre reste annoncée comme expérimentale. Côté Proxmox VE elle n'existe qu'en ligne de commande et pas dans l'interface ; elle apparaît en revanche dans l'interface du gestionnaire multi-cluster. Traitez-la comme un outil de transfert planifié, pas comme un mécanisme de bascule automatique : votre plan de reprise doit reposer sur la sauvegarde et la réplication, pas sur elle.
Faire le calcul sur votre parc #
Toutes ces règles se calculent, et le calcul est ci-dessous. Donnez votre nombre de machines et leur taille moyenne : vous obtenez le nombre de nœuds, ce que le stockage réserve sur chacun avant la première machine virtuelle, les souscriptions à la grille publique de l'éditeur et la hauteur à héberger.
Le résultat tient dans l'adresse de la page : vous pouvez la coller dans un ticket ou l'envoyer à votre intégrateur, et le calcul est ouvert sans compte. Notre Architecte Digital reprend le même moteur et va plus loin, avec les niveaux de continuité, la correspondance depuis VMware et la liste de vérification avant commande ; ce dossier-là demande d'ouvrir un compte.
Trouver les mains qui le mettent en place #
Un plan chiffré ne monte pas une baie. Trois façons de livrer existent, et un intégrateur sérieux sait faire les trois : clé en main dans un datacenter, où il commande, installe, recette et vous remet les accès ; chez vous, où il travaille dans votre salle et avec vos contraintes ; en hybride, la production d'un côté et la copie de sauvegarde de l'autre.
Demandez les trois chiffrages plutôt qu'un seul. L'écart entre eux vous dira ce que vous payez vraiment pour la salle, et c'est souvent l'inverse de ce qu'on suppose.
Les prestataires qui interviennent sur ce terrain se déclarent eux-mêmes dans leur espace : ils cochent Intégration et cloud privé dans leur activité, et leur déclaration passe ensuite par une validation. Vous les trouvez dans l'annuaire des intervenants.
⚠️ Une compétence se coche, elle ne se déduit jamais. Personne n'est présenté ici comme sachant faire de la virtualisation parce qu'il fait de l'hébergement managé. Si l'annuaire ne montre encore personne sur votre zone, c'est que personne ne s'y est déclaré, et nous préférons le dire plutôt que de faire semblant.
Questions fréquentes #
Trois si vous voulez de la haute disponibilité, parce qu'un cluster décide à la majorité et qu'à deux il n'y a pas de majorité possible. À deux nœuds, il faut ajouter un troisième point de décision qui n'héberge rien. Un nœud seul reste parfaitement valable si votre plan de reprise est une restauration depuis une sauvegarde et que vous acceptez le temps que cela prend.
La question se tranche sur la perte acceptable. Ceph ne perd rien mais demande trois nœuds et réserve beaucoup de mémoire et de cœurs sur chacun. ZFS répliqué perd entre une et quinze minutes selon la fréquence, tient à deux nœuds et coûte bien moins. Si perdre un quart d'heure de travail est acceptable, ZFS suffit et la différence de prix est considérable.
Oui. Le logiciel est complet et sans bridage. Sans souscription vous utilisez le dépôt de mises à jour non validées et vous n'avez pas de support éditeur. En production, la souscription achète surtout le dépôt validé : des mises à jour qui ont été testées ensemble avant d'être publiées.
Non, si la carte lui est passée en direct : la machine est attachée à un matériel physique précis. Une machine sans carte migre à chaud normalement. C'est la contrainte principale du passage direct, et c'est elle qui justifie le partage de carte quand il est possible.
Deux liens à un gigabit suffisent : ce trafic est très faible en volume. Ce qui compte est la latence et l'indépendance. Deux liens séparés sur deux cartes différentes valent mieux qu'un agrégat rapide, parce que l'agrégat ne protège pas d'une erreur de configuration du commutateur.
Non, l'exploitant fournit l'alimentation secourue et c'est écrit dans son contrat. Chez vous, l'onduleur devient obligatoire, et il faut le dimensionner pour tenir le temps que le groupe démarre ou que les machines s'arrêtent proprement. C'est un des postes qui fait basculer le calcul vers l'hébergement.
En restaurant. Une sauvegarde jamais restaurée est une hypothèse, pas une protection. Programmez une restauration réelle sur un réseau isolé, à intervalle régulier, et chronométrez-la : ce chronomètre est votre temps d'arrêt réel, et il est presque toujours plus long que celui qu'on annonce.
Par l'inventaire et par le choix des adresses, avant tout achat. Puis par une vague de machines non critiques, pour mesurer les gestes en conditions réelles. Le guide de la migration détaille les correspondances, le geste Windows que personne ne documente, et pourquoi les bases de données se migrent autrement que le reste.
Rédigé le 15 septembre 2026.
Passer à la pratique : les datacenters à comparer
Estimer mon coût → Comparer les datacenters