Serveurs dédiés Proxmox VE

Un serveur dédié Proxmox est une machine physique mono-locataire qui exécute Proxmox VE — la plateforme de virtualisation open-source basée sur Debian — directement sur le matériel. Plutôt que de louer une part de l’hyperviseur de quelqu’un d’autre, vous obtenez toute la machine : une interface web et une API REST pour lancer des machines virtuelles KVM et des conteneurs LXC, un accès root complet sur l’hôte, et chaque cœur et gigaoctet de RAM ECC à allouer comme bon vous semble.

La raison la plus forte de la faire tourner ici, c’est l’économie et la propriété. Proxmox VE est publié sous licence GNU AGPLv3 et est libre d’exécution en production, sans licence d’hyperviseur par socket ni par cœur — un abonnement payant achète le canal de mises à jour entreprise et le support, pas les fonctionnalités. Déployez-le sous forme d’image prête à l’emploi sur du matériel EPYC ECC en moins d’une minute, et tout l’hôte de virtualisation est à vous — pas de facture par cœur à la VMware, et aucun hyperviseur partagé entre vous et le métal.

Vous débutez avec les hyperviseurs ? Consultez notre guide de l’hyperviseur bare metal.

Ce qu’est réellement Proxmox VE

Proxmox VE est une plateforme de virtualisation complète, pas simplement une distribution Linux de plus. Elle superpose une stack de gestion par-dessus Debian — la version actuelle, Proxmox VE 9.2, est bâtie sur Debian 13 « Trixie » — et vous offre deux technologies de virtualisation sous un même toit : l’hyperviseur KVM pour les machines virtuelles complètes et LXC pour les conteneurs système. Vous pilotez les deux depuis une seule interface web sur le port 8006, ou depuis une API REST et les outils en ligne de commande pvesh / qm / pct si vous préférez automatiser.

Parce que toute la plateforme est open-source, tout est présent sur l’hôte et rien n’est retenu derrière un palier de licence. Le clustering intégré, la migration à chaud, le stockage défini par logiciel avec ZFS et Ceph, un pare-feu intégré et un framework de sauvegarde sont tous livrés dans le téléchargement gratuit. Sur une machine Serverside, vous disposez d’un accès root complet sur cet hôte : la version que vous exécutez, les dépôts que vous activez et la cadence des mises à jour relèvent entièrement de votre choix — l’appliance est à vous d’exploiter, pas une part infogérée dont vous louez l’accès.

Dépôts avec ou sans abonnement

C’est la partie qui piège les opérateurs Proxmox débutants, et il vaut la peine de la clarifier. Proxmox VE est livré avec le dépôt APT Enterprise activé, qui nécessite une clé d’abonnement payante pour être consulté. Sans clé, les mises à jour apt échouent sur ce dépôt — la première chose que la plupart des gens font sur une machine neuve est donc de basculer vers le dépôt gratuit no-subscription à la place. Sur Proxmox VE 9, les deux sont définis dans le format moderne deb822 .sources sous /etc/apt/sources.list.d/, et vous désactivez celui que vous n’utilisez pas plutôt que de le supprimer.

Les deux dépôts diffèrent par les tests et le support, pas par les fonctionnalités. La recommandation de Proxmox elle-même est que le dépôt no-subscription « can be used for testing and non-production use » et est « not recommended on production servers », car ses paquets ne sont pas aussi rigoureusement validés que le canal entreprise. Un abonnement est facturé par socket CPU occupé et par an — un socket compte une fois quel que soit le nombre de cœurs — et débloque le dépôt entreprise stable ainsi que des tickets de support avec un SLA. Il ne débloque aucune fonctionnalité : chaque capacité est déjà dans le téléchargement gratuit.

Quel que soit le dépôt que vous choisissez, un hôte sans abonnement actif affiche le fameux message « No valid subscription » à la connexion à l’interface web. C’est un rappel, pas une limitation — la plateforme est pleinement fonctionnelle dans les deux cas. Parce que vous possédez le root sur une machine Serverside, c’est vous qui décidez d’acheter un abonnement pour le canal entreprise et le support, ou de faire tourner le dépôt no-subscription et de gérer les mises à jour vous-même.

VM et conteneurs LXC — quand utiliser l’un ou l’autre

Proxmox vous offre deux façons de découper un hôte, et bien choisir constitue l’essentiel du savoir-faire. Une machine virtuelle KVM, c’est de la virtualisation matérielle complète : elle démarre son propre noyau, exécute n’importe quel système d’exploitation — Windows, les BSD, n’importe quel Linux — et est fortement isolée de ses voisins et de l’hôte. Cette isolation et cette indépendance vis-à-vis de l’OS expliquent pourquoi les VM sont le bon choix pour tout ce en quoi vous n’avez pas pleinement confiance, tout ce qui n’est pas Linux, et tout ce que vous voulez migrer à chaud entre nœuds du cluster sans interruption.

Un conteneur LXC est un conteneur système : il partage le noyau de l’hôte et exécute un userland Linux par-dessus. Cela le rend bien plus léger qu’une VM — il démarre en une fraction de seconde, ne porte quasiment aucune surcharge mémoire, et vous permet de faire tenir bien plus de charges de travail sur le même matériel. La contrepartie, c’est qu’il doit être Linux et que l’isolation est plus faible qu’une VM complète, puisque chaque conteneur s’appuie sur l’unique noyau partagé.

En pratique, la plupart des hôtes Proxmox font tourner un mélange : LXC pour le parc dense de services Linux où l’efficacité compte — reverse proxies, outillage interne, applications auto-hébergées — et des VM KVM pour les invités Windows, tout ce qui nécessite un noyau différent, et les charges de travail exigeant une isolation ferme ou la migration à chaud. Une machine à 32 cœurs et 512 Go a largement de quoi faire tourner les deux schémas à la fois.

Stockage : ZFS, Ceph et LVM-thin sur bare metal

Proxmox VE prend en charge plusieurs backends de stockage, et le fait de tourner sur du bare metal est précisément ce qui vous laisse choisir le bon plutôt que d’hériter de ce qu’un hébergeur cloud vous impose. Sur un nœud unique, les deux stockages par défaut que vous rencontrez sont local — un stockage de type répertoire pour les images ISO, les templates de conteneurs et les sauvegardes — et local-lvm, un pool LVM-thin contenant les disques de VM et les volumes racine de conteneurs. Si vous installez sur ZFS à la place, ce stockage bloc devient local-zfs.

ZFS est le choix populaire sur un nœud unique car il apporte à votre stockage de VM des snapshots instantanés, une réplication au niveau bloc entre nœuds, une intégrité des données vérifiée par checksums, et la compression. Le coût, c’est la RAM : ZFS veut environ 2 Go de mémoire de base plus environ 1 Go de cache ARC par téraoctet de pool. Les installations Proxmox récentes plafonnent l’ARC à 10 % de la RAM installée par défaut, mais cette règle empirique explique pourquoi les hôtes de virtualisation veulent beaucoup de mémoire — ce qui est exactement pourquoi nos configurations d’exemple démarrent avec 384 Go et 512 Go de DDR5.

Ceph est à l’autre bout de l’échelle : une couche de stockage distribuée et auto-réparatrice qui mutualise les disques d’un cluster de sorte que n’importe quel nœud puisse faire tourner n’importe quelle VM, intégrée directement dans l’interface web Proxmox. Elle est authentiquement hyper-convergée et authentiquement exigeante — Proxmox recommande au moins trois nœuds et un réseau dédié de 10 Gbps ou plus pour le trafic Ceph, montant à 25 Gbps et au-delà pour les pools adossés au NVMe. C’est là que la possession du bare metal paie : du vrai NVMe sur l’hôte et un uplink privé rapide entre vos serveurs sont ce qui fait performer le stockage répliqué et en cluster, plutôt qu’un disque virtualisé sur un backend partagé.

Clustering, quorum et HA

Plusieurs hôtes Proxmox peuvent être réunis en un seul cluster, géré comme un tout. En coulisses, corosync gère la messagerie entre nœuds et pmxcfs — le Proxmox Cluster File System — maintient /etc/pve synchronisé sur tous, si bien que chaque nœud voit les mêmes VM, le même stockage et la même configuration. À partir de là, vous obtenez la migration à chaud et, avec un stockage partagé ou répliqué, une haute disponibilité qui redémarre les invités ailleurs lorsqu’un nœud tombe.

Le piège que tout opérateur de cluster apprend, c’est le quorum. Un cluster n’agit que lorsqu’une majorité de nœuds peut voter, d’où la recommandation d’un nombre impair de nœuds et le fait que trois soit le minimum pratique pour une HA fiable. Un cluster à deux nœuds ne peut pas tenir le quorum seul si un nœud tombe — la solution est un QDevice, un arbitre externe léger qui fournit une voix décisive afin qu’un cluster à deux nœuds (ou à nombre pair) survive à une défaillance unique.

C’est là que posséder le réseau compte autant que posséder le matériel. Corosync est sensible à la latence et la réplication Ceph est gourmande en bande passante, et ni l’un ni l’autre n’ont leur place sur votre interface publique. Vous pouvez mettre en place un réseau privé virtuel entre vos serveurs Serverside afin que la messagerie de cluster, la réplication de stockage et le trafic de migration à chaud empruntent tous un lien privé, en gardant le plan de gestion et de réplication entièrement hors de l’internet public tandis que l’uplink rapide porte la charge.

Déployer Proxmox VE sur Serverside

Proxmox VE est une image de déploiement de premier ordre dans notre catalogue d’OS, si bien qu’un hyperviseur neuf est installé sur le bare metal et accessible via son interface web en moins d’une minute — aucun ISO à monter, aucun installateur à cliquer avant de pouvoir créer une VM. À partir de là, l’hôte est entièrement à vous : un accès root complet signifie que vous choisissez quel dépôt exécuter, quand mettre à niveau, s’il faut acheter un abonnement, et comment organiser votre cluster, sans rien de verrouillé de notre côté.

Si vous préférez construire l’hôte vous-même, vous le pouvez. Une configuration iPXE personnalisée vous permet de démarrer par le réseau votre propre build Proxmox ou une version épinglée sur le métal, et le montage d’ISO plug-and-play avec accès à la console KVM est toujours là en solution de repli — montez l’installateur Proxmox, suivez son démarrage depuis la console et choisissez votre propre agencement ZFS. Dans les deux cas, la périphérie réseau se place devant l’hyperviseur : une mitigation DDoS inline et permanente sur notre réseau de plus de 2 Tbit/s filtre les attaques avant qu’elles n’atteignent votre plan de gestion sur le port 8006, et des règles de pare-feu en self-service vous permettent de restreindre qui peut y accéder.

Démarrez votre propre build Proxmox avec un iPXE personnalisé

Vous n’êtes pas limité à notre image de série. Les configurations iPXE personnalisées vous permettent de chaîner le démarrage d’un build ou d’un installateur Proxmox que vous contrôlez directement sur le matériel, de sorte que l’hôte se présente exactement comme vous l’avez spécifié plutôt qu’à partir d’un template que vous n’avez pas choisi.

C’est la voie pour les équipes qui épinglent une combinaison Proxmox et noyau précise sur tout un parc, ou qui intègrent les étapes post-installation — sélection du dépôt, agencement du stockage, jonction au cluster — dans une seule définition de démarrage reproductible. Nous vous remettons le métal et restons en dehors de la chaîne de démarrage.