Logiciel Proxmox – virtualisation et de gestion de serveurs

Proxmox ne se résume pas à un hyperviseur. Il s’agit d’un ensemble cohérent de solutions open source permettant de virtualiser des serveurs, de protéger les données et de sécuriser les flux de messagerie. Cette catégorie regroupe les abonnements destinés à Proxmox Virtual Environment, Proxmox Backup Server et Proxmox Mail Gateway. Ces trois produits interviennent à des niveaux différents de l’infrastructure : exécution des charges de travail, sauvegarde et restauration, puis filtrage de la messagerie.

Le choix d’un abonnement n’est qu’une partie du projet. La topologie des processeurs, la réserve de mémoire, l’architecture de stockage, la séparation des réseaux, la politique de rétention et le comportement attendu en cas de panne déterminent directement la fiabilité de la plateforme. Hardware Direct peut ainsi associer le niveau de support adéquat à un serveur pour Proxmox correctement dimensionné ou à une architecture évolutive issue de notre gamme de serveurs rack.

Proxmox VE – machines virtuelles, conteneurs et cluster dans une même plateforme

Proxmox VE réunit la virtualisation matérielle KVM et les conteneurs LXC dans une interface d’administration commune, accessible depuis le navigateur, la ligne de commande et l’API. Une machine virtuelle exécute son propre système d’exploitation et offre une séparation nette par rapport à l’hôte. Elle convient aux environnements Windows et Linux, aux applications nécessitant un noyau spécifique ainsi qu’aux usages de PCIe passthrough lorsque le processeur, la carte mère et la configuration IOMMU le permettent.

Un conteneur LXC consomme généralement moins de ressources, mais partage le noyau Linux de l’hôte. Il constitue donc une solution efficace pour des services Linux sélectionnés avec discernement : reverse proxy, serveur applicatif, service DNS interne ou outil d’administration, par exemple. Il ne doit pas être considéré comme le remplacement automatique de toute VM, notamment lorsque l’isolation, la compatibilité logicielle ou les exigences de sécurité imposent un système invité complet.

La valeur opérationnelle de Proxmox VE vient surtout de l’unification des tâches d’administration. Les rôles, permissions, réseaux virtuels, stockages, sauvegardes, réplications, migrations, règles de pare-feu et métriques sont gérés depuis un même plan de contrôle. La plateforme peut ainsi héberger des applications ERP, des bases de données, des services d’annuaire, des serveurs de fichiers, des environnements de développement ou des postes virtuels. L’architecture cible doit toutefois être définie avant l’achat du premier hôte : un serveur autonome, un cluster de gestion et une plateforme de haute disponibilité n’ont ni les mêmes besoins matériels ni le même coût d’exploitation.

Abonnements Proxmox VE – dépôt Enterprise, support et escalade maîtrisée

Les niveaux Community, Basic, Standard et Premium ne correspondent pas à des éditions fonctionnelles différentes de Proxmox VE. Les fonctions de cluster, de haute disponibilité, de migration à chaud, de pare-feu, de sauvegarde, de réplication ou d’intégration Ceph restent disponibles quel que soit le niveau choisi. Les différences portent principalement sur l’accès au support de l’éditeur, le nombre de tickets inclus et le délai annoncé pour la première réponse à une demande critique.

• Community donne accès au dépôt Enterprise et au support communautaire, sans ticket auprès de l’équipe de support Proxmox. Ce niveau est pertinent pour un laboratoire, une plateforme de formation, une validation technique ou un service non critique administré par une équipe autonome.
• Basic s’adresse aux petites infrastructures de production ayant besoin d’une voie d’escalade occasionnelle. Il comprend trois tickets de support par an et un délai de première réponse d’un jour ouvré.
• Standard est adapté à une exploitation régulière en production. Il comprend dix tickets par an, un délai de première réponse de quatre heures, l’assistance à distance par SSH ainsi que des possibilités d’activation et de mise à jour pour les environnements hors ligne.
• Premium vise les systèmes dont l’indisponibilité aurait un impact important sur l’activité. Il prévoit un nombre illimité de tickets, un délai de première réponse de deux heures, l’assistance à distance et la prise en charge des environnements isolés.

Le délai de réponse ne doit pas être interprété comme un délai garanti de résolution. Il désigne la première prise en charge d’un ticket critique pendant les horaires de support définis par l’éditeur. Le bon niveau d’abonnement dépend donc du SLA interne, de la compétence de l’équipe, de la procédure d’astreinte et de la durée maximale d’interruption acceptable pour chaque service.

Il faut également distinguer un abonnement Community payant d’une installation sans abonnement. Proxmox VE peut être utilisé sans abonnement, mais le dépôt no-subscription est destiné aux usages qui acceptent un cycle de validation moins conservateur. En production, l’accès au dépôt Enterprise apporte une chaîne de mise à jour plus prévisible, même lorsque l’organisation n’a pas besoin de tickets de support éditeur.

1, 2 ou 4 CPU ? L’abonnement dépend des sockets physiques occupés

Les abonnements Proxmox VE sont calculés selon le nombre de sockets processeur physiquement occupés dans chaque serveur. Le nombre de cœurs, de threads, de machines virtuelles, de conteneurs et de vCPU attribués ne modifie pas la quantité d’abonnements requise. La topologie CPU est donc à la fois un choix technique et économique. Une plateforme monosocket moderne à base d’AMD EPYC peut, par exemple, fournir une densité de cœurs et un nombre de lignes PCIe élevés tout en ne nécessitant qu’un abonnement pour un seul socket.

• Une carte mère bisocket équipée d’un seul processeur nécessite une couverture 1 CPU.
• Un serveur contenant deux processeurs physiques nécessite une couverture 2 CPU, indépendamment du nombre de cœurs de chaque puce.
• Un serveur quadrisocket dont les quatre emplacements sont occupés nécessite une couverture 4 CPU.
• Chaque nœud d’un cluster doit couvrir tous ses sockets occupés, et tous les nœuds du même cluster doivent utiliser un niveau d’abonnement identique.

Un produit 4 CPU ne doit pas être considéré comme un pool flottant que l’on pourrait répartir librement entre quatre serveurs monosocket indépendants. Les clés sont affectées à des hôtes précis. Une commande destinée à plusieurs nœuds doit donc tenir compte de chaque serveur et de sa population réelle de processeurs. Un socket vide ne compte pas, mais l’ajout ultérieur d’un second CPU modifie immédiatement le besoin de couverture.

Proxmox Backup Server – des sauvegardes hors du domaine de panne de la production

Un snapshot de machine virtuelle est utile pour revenir rapidement à un état antérieur, mais il ne constitue pas une sauvegarde indépendante. Lorsque les snapshots et les données de production résident sur le même stockage, une panne de contrôleur, une erreur d’administration, la compromission d’un compte privilégié ou un ransomware peut affecter les deux. Proxmox Backup Server ajoute une couche distincte de protection pour les machines virtuelles, les conteneurs LXC et les systèmes physiques.

PBS transfère les données de manière incrémentale, applique la déduplication et la compression ZSTD, puis permet le chiffrement côté client. Les sommes de contrôle et les tâches de vérification planifiées servent à détecter une corruption silencieuse avant qu’une restauration ne devienne urgente. La synchronisation vers un datastore distant, la restauration au niveau fichier et le live restore de certaines VM améliorent encore les possibilités de reprise. Ces mécanismes limitent la consommation de bande passante et de capacité, mais ils ne remplacent ni une politique de rétention documentée ni des tests réguliers de restauration.

Dans une architecture de production, le serveur de sauvegarde doit être placé, autant que possible, dans un autre domaine de panne : matériel séparé, comptes d’administration distincts et copie supplémentaire sur un autre site pour les données importantes. La capacité doit être estimée à partir du volume protégé, du taux de changement quotidien, de la durée de rétention et de la marge nécessaire aux opérations de vérification et de nettoyage. Le taux de déduplication ne peut pas être traité comme une constante garantie, car il dépend fortement de la nature des données.

L’abonnement Proxmox Backup Server est associé au nombre de serveurs physiques de sauvegarde, sans limite artificielle de capacité de sauvegarde ni de clients protégés. Le dimensionnement reste pourtant déterminant : vitesse d’ingestion, fenêtres de vérification, objectifs de restauration, débit réseau et tolérance aux pannes des disques. Les catégories sauvegarde et équipements de sauvegarde permettent de compléter PBS par une infrastructure adaptée à la rétention prévue.

Proxmox Mail Gateway – une couche de sécurité devant le serveur de messagerie

Proxmox Mail Gateway se déploie comme une passerelle SMTP entre Internet et la plateforme de messagerie réelle. Il analyse les messages entrants et sortants, filtre les spams, virus, chevaux de Troie et tentatives de phishing, puis centralise les règles, la quarantaine, le suivi des messages et les rapports. Cette couche peut être administrée indépendamment du système hébergeant les boîtes aux lettres, qu’il s’agisse de Microsoft Exchange, de Postfix ou d’un service exploité dans un autre centre de données.

PMG n’est pas un serveur de boîtes aux lettres. Il ne remplace pas non plus une configuration correcte de SPF, DKIM et DMARC, la protection des identités, les mises à jour de sécurité ou une procédure de réponse à incident. Son rôle est d’ajouter un point de contrôle placé avant le cœur du système de messagerie, avec des politiques que l’administrateur peut adapter aux domaines, aux expéditeurs, aux destinataires et au type de contenu.

Lorsque la messagerie est critique, l’architecture doit prévoir plusieurs passerelles, des enregistrements MX cohérents, des chemins réseau indépendants lorsque cela est possible et une supervision des files d’attente ainsi que des certificats. L’abonnement PMG est calculé par hôte, avec un nombre illimité d’utilisateurs et de domaines. Une mise en haute disponibilité nécessite donc une couverture pour chaque passerelle installée.

Comment dimensionner le matériel pour Proxmox VE ?

Les exigences minimales de l’éditeur permettent de démarrer une plateforme de test ; elles ne constituent pas une nomenclature pour la production. Un hôte doit être dimensionné en fonction des pointes de charge, de la croissance prévisible, des opérations de maintenance et de la perte éventuelle d’un nœud. Dans un cluster HA, les serveurs restants doivent disposer de suffisamment de ressources pour reprendre les VM du nœud indisponible sans transformer une panne matérielle en dégradation prolongée des performances.

• Processeur. Le nombre de cœurs favorise les charges parallèles, tandis que la fréquence, l’IPC et la génération du CPU restent importants pour les applications sensibles à la latence ou facturées par cœur. La virtualisation matérielle doit être activée. Sur une plateforme bisocket, il faut aussi tenir compte des domaines NUMA lors de l’affectation de grandes VM. La catégorie processeurs serveur permet de comparer densité de cœurs, fréquence et génération ; les processeurs AMD EPYC sont notamment intéressants lorsque la densité monosocket et le nombre de lignes PCIe sont prioritaires.
• Mémoire. Le calcul doit inclure la RAM attribuée aux invités, les services de l’hôte, le cache du système de fichiers, ZFS ou Ceph, ainsi qu’une réserve d’exploitation. Le ballooning peut améliorer l’utilisation globale, mais ne doit pas justifier un surengagement permanent. Des modules ECC compatibles sont disponibles dans la catégorie mémoires RAM ; le peuplement équilibré des canaux est aussi important que la capacité totale.
• Disques système. Le volume Proxmox doit de préférence reposer sur deux SSD de classe entreprise en miroir, et non sur un périphérique USB ou un seul SSD grand public. Le pool système ne porte généralement pas la charge principale des VM, mais sa défaillance affecte tout de même la disponibilité de l’hôte.
• Stockage des charges de travail. Les bases de données et les VM sensibles à la latence ont besoin de supports endurants, d’une profondeur de file suffisante et d’une protection contre la perte d’alimentation. Les disques NVMe peuvent fournir d’excellentes performances à condition de vérifier la topologie PCIe, le refroidissement, l’endurance en écriture et la procédure de remplacement. Le guide sur les disques NVMe dans un serveur aide à replacer le débit nominal dans le contexte des IOPS et de la latence.
• Réseau. L’administration, Corosync, la migration, le stockage et les sauvegardes ont des profils différents. Ils peuvent être séparés physiquement ou au moyen de VLAN correctement conçus, mais les chemins critiques doivent être redondants. Le choix des cartes réseau et des switches doit tenir compte de la latence, du nombre de files, de la compatibilité des transceivers et du comportement en cas de perte d’un lien, pas seulement du débit indiqué sur la fiche technique.
• Alimentation et administration hors bande. Des alimentations redondantes n’apportent une réelle continuité que si elles sont reliées à des chemins électriques distincts. Une alimentation sans coupure, une procédure d’arrêt testée et un contrôleur iDRAC, iLO ou équivalent rendent la maintenance beaucoup plus prévisible. L’article consacré à l’administration IPMI à distance explique pourquoi cette couche reste essentielle même lorsque l’hyperviseur ne répond plus.

Un dimensionnement sérieux part de mesures : utilisation CPU soutenue et en pointe, ensemble de travail en mémoire, ratio lecture/écriture, latence, IOPS, débit séquentiel et taux de changement des données. Une spécification fondée uniquement sur le total des vCPU, la RAM allouée et les téraoctets nominaux masque souvent les contraintes qui déterminent réellement la stabilité de la plateforme. Pour préparer une base matérielle cohérente, le configurateur de serveur permet de structurer le choix du châssis, des CPU, de la mémoire, des disques et des interfaces réseau.

ZFS, Ceph ou RAID matériel – attribuer la redondance à une seule couche

ZFS, Ceph et le RAID matériel peuvent tous contribuer à la résilience du stockage, mais ils le font à des niveaux différents. Une architecture claire désigne une seule couche responsable de la visibilité des disques, du placement des données et de la reconstruction. Empiler plusieurs mécanismes indépendants sans comprendre leurs interactions peut masquer l’état réel des supports, compliquer les remplacements et produire des scénarios de panne difficiles à tester.

• ZFS convient au stockage local et à la réplication entre des nœuds sélectionnés. Il fournit sommes de contrôle, snapshots, compression et redondance gérée par logiciel. ZFS doit voir directement les disques physiques par l’intermédiaire d’un HBA fiable ou d’un véritable mode IT/JBOD, et non des volumes virtuels créés par un contrôleur RAID.
• Ceph distribue les données entre plusieurs nœuds et peut éviter l’ajout d’une baie partagée dédiée. Sa souplesse a un coût : consommation de CPU et de mémoire, besoin de capacité libre pour le rééquilibrage et forte sensibilité à la latence réseau. Une plateforme de production commence généralement par au moins trois nœuds capables de stocker les données, avec un réseau rapide et redondant.
• Le RAID matériel reste pertinent lorsque le contrôleur est volontairement chargé de la redondance, expose une télémétrie utile, dispose d’un cache d’écriture protégé et s’inscrit dans une procédure de remplacement documentée. Dans ce modèle, le système d’exploitation consomme des volumes logiques et ne tente pas de gérer séparément les mêmes disques.
• Une baie SAN ou un NAS peut centraliser les données et simplifier certains scénarios de migration, mais ajoute ses propres contrôleurs, chemins, switches et limites de support. Une baie partagée n’est hautement disponible que si toute la chaîne — contrôleurs, liens, commutation et multipathing — est redondante et testée.

Le bon choix dépend du profil des charges et du modèle d’exploitation, pas d’un classement universel. Un pool ZFS local peut être le choix le plus lisible pour un ou deux hôtes ; Ceph convient à un cluster réellement distribué ; une baie de stockage Dell peut être préférable dans une organisation déjà structurée autour du SAN. Les contrôleurs RAID pour serveurs doivent alors être sélectionnés selon la couche qui portera effectivement la redondance. Pour approfondir les compromis, consultez également l’analyse RAID : protection des données ou dépense inutile ?

Un cluster Proxmox n’est pas automatiquement une architecture haute disponibilité

Regrouper plusieurs nœuds dans un cluster centralise l’administration et autorise des opérations coordonnées, mais ne garantit pas à lui seul la continuité d’un service. La haute disponibilité exige également un quorum fiable, une réserve de calcul suffisante, un stockage récupérable, des réseaux redondants et des ressources HA correctement configurées. Chacun de ces éléments doit être validé dans des scénarios de panne réalistes.

Pour un quorum fiable, Proxmox recommande au moins trois votes. Une architecture à deux nœuds de calcul peut utiliser un QDevice comme troisième voix, mais ce dispositif n’ajoute ni CPU, ni mémoire, ni capacité de stockage. Si un hôte tombe en panne, le nœud restant doit encore être capable d’exécuter les services repris. Corosync a surtout besoin d’une latence faible et stable ; il doit éviter la concurrence imprévisible avec une reconstruction Ceph, une migration à chaud ou un transfert de sauvegarde volumineux.

Le choix du stockage définit le modèle de reprise. Un stockage partagé peut faciliter le redémarrage d’une VM sur un autre nœud, ZFS peut fournir une réplication contrôlée et Ceph peut distribuer les données entre les membres du cluster. Aucun de ces mécanismes ne remplace une sauvegarde indépendante. La haute disponibilité réduit l’interruption provoquée par certaines pannes d’infrastructure ; la sauvegarde protège les données et permet de revenir après une suppression, une corruption, un ransomware ou une erreur d’exploitation.

Un plan de validation utile comprend la perte brutale d’un hôte, la coupure d’un lien réseau, la panne d’un support de stockage, l’échec d’une migration, la perte du quorum et une restauration depuis PBS. Le compte rendu doit indiquer non seulement si les services reviennent, mais aussi le temps nécessaire, les alertes déclenchées et les actions manuelles encore requises. Le guide sur la virtualisation des serveurs en pratique complète cette réflexion par une approche centrée sur l’exploitation.

Choisir le bon produit Proxmox, le bon abonnement et le bon serveur

La première étape consiste à identifier la fonction du produit. Les abonnements Proxmox VE couvrent les nœuds de virtualisation ; les abonnements Proxmox Backup Server couvrent les serveurs physiques de sauvegarde ; les abonnements Proxmox Mail Gateway couvrent les hôtes de passerelle SMTP. Les unités de calcul sont différentes : sockets CPU occupés pour VE, serveurs physiques pour PBS et hôtes pour PMG.

Il faut ensuite évaluer l’impact opérationnel. Un laboratoire interne peut raisonnablement s’appuyer sur les compétences de l’équipe et sur les ressources communautaires. Un système de production portant l’ERP, l’authentification, les bases de données ou des services clients a besoin d’une voie d’escalade documentée. Le niveau adapté dépend de la rapidité avec laquelle l’organisation doit pouvoir mobiliser l’éditeur, pas simplement du nombre de VM.

Enfin, l’abonnement doit être replacé dans l’architecture complète. Un niveau Premium ne compense pas un chemin de stockage unique, une capacité de bascule insuffisante ou des sauvegardes placées dans le même domaine de panne. À l’inverse, une équipe expérimentée, qui exploite un environnement non critique bien documenté et régulièrement testé, peut ne pas avoir besoin du niveau de support le plus élevé. Le support, le matériel et les procédures doivent se renforcer mutuellement.

Hardware Direct est partenaire officiel de Proxmox et peut aider à aligner l’abonnement sur la topologie des serveurs et le modèle d’exploitation. Pour prendre du recul sur la plateforme, l’article expliquant pourquoi choisir une solution open source pour construire une infrastructure serveur présente les principaux arguments techniques et organisationnels. L’objectif n’est pas de maximiser le niveau d’abonnement ou la fiche matérielle, mais d’obtenir une plateforme dont les performances, les modes de panne et les procédures de reprise restent compréhensibles.

Questions fréquentes

Proxmox VE nécessite-t-il une licence payante ?

Non. Proxmox VE est un logiciel open source et peut fonctionner sans abonnement payant. Un abonnement donne accès au dépôt Enterprise et, pour les niveaux Basic, Standard et Premium, au support de l’éditeur. Il ne déverrouille pas une édition distincte disposant de fonctions supplémentaires.

Community offre-t-il moins de fonctions que Basic, Standard ou Premium ?

Non. Le jeu de fonctions techniques ne dépend pas du niveau de support. Community ne comprend pas de tickets auprès de l’éditeur ; sa pertinence en production dépend donc du risque métier, des compétences internes, du SLA et de la capacité de l’équipe à diagnostiquer seule un incident.

Comment calculer le nombre d’abonnements CPU nécessaire ?

Il faut compter les processeurs physiquement installés, c’est-à-dire les sockets occupés dans chaque serveur. Les cœurs, threads, VM et vCPU n’influencent pas la quantité. Une carte mère bisocket avec un seul CPU nécessite une couverture 1 CPU ; après l’ajout du second processeur, elle nécessite une couverture 2 CPU.

Tous les nœuds d’un cluster doivent-ils utiliser le même niveau d’abonnement ?

Oui. Chaque nœud doit couvrir tous ses sockets occupés, et un cluster Proxmox VE doit utiliser un niveau d’abonnement cohérent sur l’ensemble des hôtes. Cette règle facilite également l’homogénéité des dépôts, des mises à jour et des procédures de support.

Un snapshot de VM remplace-t-il une sauvegarde ?

Non. Un snapshot dépend normalement du même stockage que la machine virtuelle et sert surtout de point de retour à court terme. Une sauvegarde doit résider sur un système distinct, suivre sa propre politique de rétention et être validée par des restaurations régulières.

Proxmox Backup Server peut-il fonctionner comme VM dans le même cluster ?

C’est techniquement possible, mais cette VM ne devrait pas constituer l’unique sauvegarde du cluster. Une panne touchant les hôtes, le stockage ou les comptes d’administration pourrait rendre indisponibles en même temps la production et les copies. Un serveur PBS séparé, ou au minimum une copie synchronisée vers un emplacement indépendant, est plus robuste.

Peut-on installer ZFS au-dessus d’un RAID matériel ?

Ce n’est pas l’architecture recommandée. ZFS doit voir directement les disques physiques afin de contrôler leur état, l’ordre des écritures et la redondance. Le contrôleur doit fournir un mode HBA, IT ou JBOD réellement fiable. Le même principe s’applique aux disques utilisés comme OSD Ceph.

Combien de nœuds faut-il pour un cluster Proxmox HA ?

Au moins trois votes sont recommandés pour obtenir un quorum fiable. Un cluster composé de deux nœuds de calcul peut utiliser un QDevice comme troisième voix, mais celui-ci ne fournit aucune capacité de bascule. Le nœud survivant doit toujours disposer des ressources et de l’accès aux données nécessaires pour reprendre les services.

Un réseau 10 GbE est-il obligatoire pour Proxmox ?

Non. Un hôte autonome avec des charges légères peut fonctionner correctement en 1 GbE. Le 10 ou 25 GbE devient important pour un stockage partagé rapide, Ceph, des migrations fréquentes, de grandes sauvegardes ou de nombreuses VM concurrentes. La redondance et la séparation des flux restent importantes quelle que soit la vitesse nominale.

Proxmox Mail Gateway remplace-t-il le serveur de messagerie ?

Non. PMG est une passerelle de sécurité pour le trafic SMTP et ne gère pas les boîtes aux lettres des utilisateurs. Il se place devant Microsoft Exchange, Postfix ou une plateforme de messagerie hébergée afin de filtrer les messages indésirables ou dangereux.

Quand choisir un serveur monosocket plutôt qu’un serveur bisocket ?

Une plateforme monosocket est intéressante lorsqu’un seul CPU fournit suffisamment de cœurs, de canaux mémoire et de lignes PCIe, tout en limitant le coût d’abonnement par socket. Un serveur bisocket se justifie par des besoins supérieurs en mémoire, en I/O ou en calcul, mais impose une planification NUMA et une couverture pour le second processeur.