Cloud privé et plateformes de virtualisation sur serveurs dédiés

Options d'hyperviseur pour Bare Metal

Proxmox VE

Proxmox Virtual Environment, c'est le choix pratique pour la plupart des équipes qui montent un cloud privé sur un seul serveur dédié ou un petit cluster. C'est une solution open source, basée sur Debian, qui vient avec une interface web qui gère à la fois les machines virtuelles KVM et les conteneurs LXC depuis la même interface. L'abonnement entreprise ajoute l'accès au référentiel et des contrats d'assistance, mais la version communautaire est super complète pour une utilisation en production.

Proxmox gère la migration en direct des machines virtuelles entre les nœuds, la configuration du stockage partagé, le clustering haute disponibilité et l'intégration du serveur de sauvegarde Proxmox, qui simplifie vraiment la création de sauvegardes instantanées des machines virtuelles. Pour les équipes qui veulent gérer un cloud privé sans avoir à embaucher un administrateur VMware dédié, Proxmox est le bon point de départ.

VMware vSphere / ESXi

VMware ESXi reste la norme dans les entreprises qui ont déjà une infrastructure VMware, des intégrations certifiées et des équipes avec des certifications VMware. Le modèle de licence a beaucoup changé après que Broadcom a racheté VMware en 2023, ce qui a poussé plein d'entreprises à regarder de plus près les alternatives Proxmox et KVM. Pour les entreprises déjà dans l'écosystème VMware, ESXi sur du matériel dédié reste une bonne option. Pour les équipes qui partent de zéro, Proxmox ou KVM valent le coup d'œil d'abord pour des raisons de coût.

KVM avec libvirt

Linux KVM (Kernel-based Virtual Machine) est la couche hyperviseur sous-jacente à la pile de virtualisation RHEL et à l'infrastructure de nombreux fournisseurs de cloud. libvirt fournit l'API de gestion ; virt-manager ou Cockpit fournissent les interfaces graphiques de base. Pour les équipes à l'aise avec l'administration Linux et les outils d'infrastructure en tant que code (Terraform, Ansible), KVM avec libvirt offre plus de flexibilité que Proxmox, au prix d'une expérience de gestion moins intégrée.

Planification de la densité des machines virtuelles sur 192 Go de RAM

Quand on monte un nœud de cloud privé, la question pratique, c'est de savoir combien de machines virtuelles on peut y mettre. La réponse dépend vraiment des profils de charge de travail des machines virtuelles.

Profil VM	Mémoire vive par machine virtuelle	Machines virtuelles sur un serveur de 192 Go	Notes
Environnement de développement	4GB	Environ 40 machines virtuelles	Garde 16 Go pour les besoins de l'hyperviseur.
Application web VM	8GB	Environ 20 machines virtuelles	Typique des serveurs LAMP/LEMP
VM du serveur de base de données	32GB	Environ 5 machines virtuelles	Besoin en mémoire tampon InnoDB
Charge de travail mixte	8-16 Go en moyenne	10 à 15 machines virtuelles	Estimation réaliste de la production

Ces chiffres partent du principe qu'il n'y a pas de surallocation de mémoire. Proxmox et KVM gèrent tous les deux le ballooning et la surallocation de mémoire, ce qui permet d'attribuer plus de mémoire aux machines virtuelles qu'il n'y en a physiquement en misant sur le fait que les machines virtuelles n'utilisent pas toute leur allocation en même temps. Pour les environnements de développement, une surallocation de 2x est raisonnable. Pour les machines virtuelles de bases de données de production, ne faites jamais de surallocation.

Garde environ 16 à 24 Go de RAM physique en dehors de l'allocation VM pour l'hyperviseur, la mise en cache du stockage (le cache de page du système d'exploitation hôte pour les images disque VM) et tous les services de gestion qui tournent sur l'hôte bare metal.

Taux de sursouscription du processeur

L'AMD EPYC 4545P a 16 cœurs et 32 threads. Les ratios de sursouscription du processeur déterminent combien de vCPU tu peux provisionner par rapport aux threads physiques :

• Rapport 1:1 (32 vCPU au total) : parfait pour les machines virtuelles de production qui ont des charges de travail régulières. Aucune machine virtuelle n'attend jamais le temps CPU.
• Rapport 2:1 (64 vCPU au total) : ça marche bien pour les environnements mixtes où les machines virtuelles de développement et de production coexistent. Les machines virtuelles de développement sont souvent inactives.
• Rapport 4:1 (128 vCPU au total) : parfait pour les environnements de développement avec des charges de travail ponctuelles mais pas simultanées. Pas top pour la production.

Pour Proxmox, la mesure de l'utilisation du processeur sur le tableau de bord de l'hôte montre le vol réel de processeur : quand l'utilisation totale du processeur de toutes les machines virtuelles dépasse 100 % de la capacité de l'hôte, les machines virtuelles commencent à attendre du temps processeur. Surveille ça sur les nouveaux déploiements avant de t'engager sur une densité de machines virtuelles en production.

Configuration de stockage pour les parcs de machines virtuelles

Images disque VM sur NVMe

NVMe comme backend pour les images disque VM change les performances de chaque VM sur l'hôte. Les E/S disque VM passent par la couche hyperviseur, mais le NVMe sous-jacent fait qu'une VM qui fait plein d'opérations d'écriture sur la base de données n'affecte pas vraiment les autres VMs sur le même hôte.

Dans Proxmox, crée un pool de stockage local-lvm pointant vers le NVMe . Ça utilise l'allocation dynamique LVM, qui alloue de l'espace disque à partir du NVMe à la demande plutôt que d'allouer à l'avance la taille totale des disques des machines virtuelles. Un pool de machines virtuelles provisionnées avec des disques de 50 Go chacune peut en réalité n'utiliser que 200 Go NVMe si la plupart des machines virtuelles ont des données clairsemées.

Configuration RAID pour le stockage des machines virtuelles

InMotion utilise mdadm RAID 1 (mise en miroir logicielle) sur les deux NVMe . Ça donne une redondance au pool de stockage de la machine virtuelle : si un NVMe plante, les données de la machine virtuelle ne sont pas perdues en attendant qu'il soit remplacé. Pour un cloud privé qui héberge des machines virtuelles de production, cette protection de base est super importante.

La configuration RAID 1 offre 3,84 To de NVMe utilisable pour les images disque des machines virtuelles. Pour un parc de 15 machines virtuelles avec en moyenne 200 Go de disque provisionné par machine virtuelle, ça fait 3 To de capacité provisionnée. Avec le surprovisionnement LVM-thin, l'utilisation réelle sera généralement de 40 à 60 % de la capacité provisionnée, ce qui laisse une marge confortable.

Serveur de sauvegarde Proxmox

Proxmox Backup Server (PBS) tourne comme un service sur l'hôte hyperviseur ou sur une machine à part et s'occupe des sauvegardes incrémentielles dédupliquées des machines virtuelles. Un environnement de 20 machines virtuelles avec une utilisation moyenne de 100 Go par disque produit environ 2 To de données uniques. Grâce à la déduplication, PBS stocke généralement 3 à 5 sauvegardes quotidiennes dans moins de 3 To d'espace, selon le taux de changement des machines virtuelles.

Le volume de stockage de sauvegarde de 500 Go de Premier Care complète le stockage PBS local pour les copies hors serveur des sauvegardes critiques des machines virtuelles.

Configuration réseau et isolement VLAN

Isoler les groupes de machines virtuelles les uns des autres au niveau de la couche réseau, c'est une exigence essentielle pour un cloud privé, surtout quand les machines virtuelles de développement, de test et de production partagent le même hôte physique.

Dans Proxmox, les ponts réseau (vmbr0, vmbr1, etc.) sont liés aux cartes réseau physiques ou aux VLAN. Créer des ponts séparés pour chaque groupe d'environnements et assigner les machines virtuelles à leur pont respectif permet d'isoler la couche 2. Les machines virtuelles sur le pont de production ne peuvent pas communiquer directement avec celles sur le pont de développement sans passer par un routeur ou un pare-feu virtuel.

Pour les clusters multi-serveurs, un port réseau 10 Gbit/s offre la bande passante inter-nœuds nécessaire pour la migration en direct des machines virtuelles et l'accès au stockage partagé sans entrer en concurrence avec le trafic réseau des machines virtuelles sur une liaison 1 Gbit/s encombrée.

Comparaison des coûts : cloud privé vs machines virtuelles dans le cloud

La comparaison des coûts devient claire quand on compare le prix d'un parc de machines virtuelles dans un cloud privé à celui d'une solution équivalente dans le cloud :

Environnement	Configuration	Coût mensuel
AWS EC2 (10 machines virtuelles t3.large)	2 vCPU, 8 Go chacun	~520 $/mois
AWS EC2 (10 machines virtuelles m5.xlarge)	4 vCPU, 16 Go chacun	Environ 1 380 $ par mois
InMotion Extreme + Proxmox (15 machines virtuelles)	8 à 16 Go chacun, NVMe	349,99 $ par mois
InMotion Advanced + Proxmox (8 machines virtuelles)	4 à 8 Go chacun, NVMe	149,99 $ par mois

Le croisement se fait vite. Une équipe qui utilise plus de 5 machines virtuelles dans le cloud finit par atteindre le point où le cloud privé sur du matériel dédié revient moins cher par machine virtuelle. Avec 15 machines virtuelles sur un serveur Extreme, le coût par machine virtuelle est d'environ 23 $ par mois, contre 52 à 138 $ par machine virtuelle AWS, selon le type d'instance.

Virtualisation gérée ou non gérée

Pour faire tourner une pile d'hyperviseurs complète, il faut avoir un accès root au serveur physique. Les serveurs dédiés gérés par InMotion incluent la gestion du système d'exploitation par l'équipe APS, mais la configuration de l'hyperviseur reste du côté du client. Pour les déploiements Proxmox en particulier, la configuration gérée par InMotion coexiste avec l'administration des machines virtuelles gérée par le client.

Pour les équipes qui veulent que leur serveur physique soit géré (surveillance du matériel, mises à jour du système d'exploitation, configuration réseau) tout en gardant le contrôle de leur propre couche VM, le modèle dédié géré est celui qu'il leur faut. Pour celles qui veulent un accès non géré complet pour configurer le système d'exploitation de base et la pile d'hyperviseurs de manière indépendante, les serveurs bare metal d'InMotion offrent cette base.

Commencer avec Proxmox sur InMotion

• Commandez un serveur dédié Extreme ou Advanced en fonction du nombre de machines virtuelles dont vous avez besoin.
• Demande l'installation de Proxmox VE à InMotion APS quand tu fais ton provisionnement.
• Configurez le pool de stockage local-lvm sur NVMe pour les images disque VM.
• Configurez des ponts réseau et le balisage VLAN pour isoler les environnements.
• Installe Proxmox Backup Server pour faire des sauvegardes automatiques des snapshots de tes machines virtuelles.
• Ajoutez Premier Care pour gérer le système d'exploitation et avoir 500 Go de stockage de sauvegarde hors serveur.

La plupart des équipes qui utilisent Proxmox sur le matériel InMotion trouvent que la densité des machines virtuelles leur permet de doubler l'efficacité de leurs dépenses cloud par rapport au mois précédent. La gestion d'un cloud privé demande du travail, mais c'est beaucoup moins compliqué qu'on pourrait le penser, surtout avec l'interface web unifiée de Proxmox.