Virtualisation : hyperviseurs et machines virtuelles

Avant la virtualisation, chaque application critique vivait sur son propre serveur physique qui dépassait rarement 10 % d'utilisation CPU. Le reste était du matériel coûteux consommant de l'électricité et occupant de l'espace dans le datacenter. L'hyperviseur a changé cette équation en permettant à un seul serveur physique de faire tourner des dizaines de machines virtuelles isolées les unes des autres. Cet article explique ce qu'est exactement un hyperviseur, en quoi diffèrent les architectures de type 1 et de type 2, comment se comparent VMware, KVM, Hyper-V et Proxmox, et quelles décisions de conception font la différence entre une consolidation réussie et un goulot d'étranglement.

Ce qu'est un hyperviseur et comment il isole les charges de travail

Un hyperviseur est la couche logicielle qui abstrait le matériel physique et le présente à plusieurs machines virtuelles comme si chacune disposait de son propre serveur. Son rôle est de répartir le CPU, la mémoire, le stockage et le réseau entre les invités tout en garantissant l'isolation : ce qui se passe dans une machine virtuelle ne doit pas affecter les autres. Cette isolation est la propriété de sécurité fondamentale de la virtualisation et repose sur des extensions matérielles présentes dans les processeurs modernes, qui permettent au code de l'invité de s'exécuter de manière contrôlée sans pénalité significative.

Il convient de distinguer la virtualisation des conteneurs. Une machine virtuelle inclut son propre système d'exploitation complet et s'exécute au-dessus de l'hyperviseur ; un conteneur partage le noyau du système hôte et n'isole que l'espace utilisateur. Les machines virtuelles offrent une isolation plus forte et permettent de faire tourner différents systèmes d'exploitation sur la même machine ; les conteneurs sont plus légers et démarrent plus vite. Ils ne sont pas concurrents : dans les architectures modernes, ils coexistent, les conteneurs s'exécutant à l'intérieur des machines virtuelles.

Hyperviseurs de type 1 et de type 2

Les hyperviseurs se classent selon l'endroit où ils s'exécutent. Le type 1, appelé natif ou bare metal, s'exécute directement sur le matériel sans système d'exploitation hôte intermédiaire : VMware ESXi, Microsoft Hyper-V en mode serveur et le KVM de Linux appartiennent à cette catégorie. Ils sont le choix du datacenter en raison de leurs performances et de leur surface d'attaque réduite. Le type 2, ou hébergé, s'exécute comme une application au-dessus d'un système d'exploitation classique — VMware Workstation, VirtualBox — et convient pour le développement et les tests sur un poste de travail, mais ajoute une couche de surcharge qui le rend inadapté à la production.

Comparatif des plateformes : VMware, KVM, Hyper-V et Proxmox

Le choix de la plateforme détermine le coût, l'écosystème et la dépendance à un fournisseur (vendor lock-in). VMware vSphere est depuis des années la norme en entreprise, avec un écosystème mature pour la gestion, la haute disponibilité et la migration à chaud, bien que les récents changements de son modèle de licence aient poussé de nombreuses organisations à évaluer des alternatives. KVM est l'hyperviseur intégré au noyau Linux, open source, qui sous-tend une large part du cloud public mondial ; combiné à des outils de gestion, il offre des capacités de niveau entreprise sans coût de licence. Hyper-V s'intègre naturellement dans les environnements Microsoft et constitue le choix logique là où Windows Server prédomine déjà. Proxmox VE, basé sur KVM et les conteneurs LXC, a gagné du terrain comme alternative ouverte dotée d'une interface de gestion complète.

Consolidation, surallocation (over-provisioning) et ses limites

La consolidation est la raison économique de la virtualisation : regrouper de nombreuses charges de travail sous-utilisées sur moins de serveurs physiques pour augmenter l'utilisation du matériel et réduire la consommation électrique et l'espace occupé. Le concept clé est la surallocation (over-provisioning), c'est-à-dire attribuer aux machines virtuelles plus de ressources virtuelles que l'hôte n'en possède physiquement, en pariant qu'elles ne réclameront pas toutes leur pic en même temps. Cela fonctionne pour le CPU, car les charges de travail saturent rarement simultanément, mais c'est dangereux pour la mémoire : quand la mémoire physique s'épuise, le système recourt au swap sur disque et les performances s'effondrent. La règle pratique est d'être généreux pour la surallocation du CPU et prudent avec la RAM.

L'autre limite fréquente est le stockage. Concentrer des dizaines de machines virtuelles sur le même sous-système multiplie les opérations d'entrée/sortie par seconde qu'il doit servir ; une conception qui ne dimensionne pas le stockage en IOPS, et pas seulement en capacité, finit par produire des latences qui affectent tous les invités à la fois.

Haute disponibilité et migration à chaud

Virtualiser concentre le risque : si le serveur physique tombe, toutes ses machines virtuelles tombent avec lui. C'est pourquoi la virtualisation de production se conçoit en cluster. La haute disponibilité redémarre automatiquement les machines d'un nœud défaillant sur un autre nœud sain. La migration à chaud — vMotion chez VMware, Live Migration chez Hyper-V — déplace une machine virtuelle d'un hôte à un autre sans l'arrêter, ce qui permet de maintenir le matériel ou d'équilibrer la charge sans interrompre le service. Ces deux capacités dépendent d'un stockage partagé accessible par tous les nœuds et d'un réseau dédié disposant d'une bande passante suffisante.

Bien dimensionner la capacité du cluster signifie respecter la règle de réserver un nœud de marge : si un cluster de quatre nœuds fonctionne à la limite de sa capacité agrégée, la défaillance de l'un d'eux laisse les trois restants sans les ressources nécessaires pour accueillir les machines orphelines, et la haute disponibilité échoue précisément quand on en a le plus besoin. Une planification correcte dimensionne le cluster pour tolérer la perte d'au moins un nœud tout en maintenant le service actif, ce qui, en pratique, signifie ne pas maintenir un niveau d'utilisation supérieur au seuil qui garde cette marge disponible.

Sécurité et segmentation dans les environnements virtualisés

Concentrer les charges de travail concentre aussi la surface d'attaque. Compromettre l'hyperviseur revient à compromettre chaque machine qu'il héberge, c'est pourquoi le plan de gestion doit être isolé sur son propre réseau, accessible uniquement via une authentification forte et jamais exposé à internet. La microsegmentation ramène le contrôle du trafic au niveau de chaque machine virtuelle : au lieu de faire confiance au fait que tout ce qui se trouve à l'intérieur du datacenter est sûr, elle définit ce qui peut communiquer avec quoi, afin qu'un invité compromis ne puisse pas se déplacer latéralement vers le reste. Les normes de gestion de la sécurité de l'information comme l'ISO/IEC 27001, et les recommandations de l'INCIBE, offrent un cadre pour gouverner ces contrôles, le chiffrement des disques virtuels et l'application des correctifs de l'hyperviseur — un élément souvent négligé par crainte d'une interruption de service et que la migration à chaud permet précisément de mettre à jour sans coupure.

Erreurs courantes et bonnes pratiques

L'erreur la plus coûteuse est de suralouer la mémoire comme on le fait pour le CPU, provoquant du swap sur disque en charge. La deuxième est de ne pas séparer le trafic de gestion, de stockage et des invités sur des réseaux différents, ce qui crée de la contention. La troisième est d'oublier que les sauvegardes des machines virtuelles doivent être cohérentes au niveau applicatif : un instantané pris en pleine transaction de base de données peut être inutilisable. La quatrième omission fréquente est de ne pas documenter le dimensionnement ni de surveiller l'utilisation réelle, ce qui empêche de détecter que le cluster manque de ressources avant que les utilisateurs ne s'en aperçoivent.

Questions fréquentes

Machines virtuelles ou conteneurs ?

Ce n'est pas un choix exclusif. Les machines virtuelles isolent mieux et permettent différents systèmes d'exploitation ; les conteneurs sont plus légers et démarrent en quelques secondes. La pratique habituelle consiste à faire tourner des conteneurs à l'intérieur de machines virtuelles, combinant l'isolation de l'une avec l'agilité de l'autre.

Jusqu'où peut-on suralouer le CPU ?

Cela dépend du profil de charge, mais des ratios de plusieurs processeurs virtuels par cœur physique sont courants pour des charges de travail peu sollicitées. La clé est de surveiller le temps que les machines passent à attendre le CPU : si cet indicateur augmente, vous avez dépassé la limite.

Est-il viable de quitter VMware pour une alternative ouverte ?

De plus en plus d'organisations l'envisagent depuis les changements de licence. KVM et Proxmox offrent des capacités comparables pour de nombreux cas, bien que la migration exige de planifier la conversion des disques, de former l'équipe et de valider la haute disponibilité avant de basculer la production.

La virtualisation dégrade-t-elle les performances ?

Avec les hyperviseurs de type 1 et les extensions matérielles, la pénalité est faible pour la plupart des charges de travail. Les problèmes de performance viennent généralement d'un mauvais dimensionnement du stockage ou de la mémoire, pas de l'hyperviseur lui-même.

Conclusion

La virtualisation est passée d'une technologie de réduction des coûts à devenir le socle sur lequel repose pratiquement toute l'infrastructure moderne, du datacenter on-premise au cloud public. Mais consolider ne consiste pas à empiler des machines virtuelles jusqu'à ce que quelque chose casse : cela exige de dimensionner le stockage en IOPS, d'être prudent avec la mémoire, de séparer les réseaux et de concevoir la haute disponibilité en cluster dès le départ. Le choix entre VMware, KVM, Hyper-V ou Proxmox dépend moins de savoir lequel est « le meilleur » que de l'écosystème existant, du budget de licences et de la tolérance à la dépendance envers un fournisseur. Chez Summum Sistemas, nous concevons, dimensionnons et migrons des plateformes de virtualisation avec un jugement technique et un plan de continuité testé avant de toucher à la production.