Virtualisation de serveurs : choisir son hyperviseur, dimensionner processeur, mémoire et stockage, sauvegarder les machines virtuelles et cloisonner l'administration.
La virtualisation fait tourner plusieurs serveurs logiques sur une même machine physique, chacun avec son système et ses applications. Trois décisions structurent le projet : le type d’hyperviseur installé, la répartition du processeur, de la mémoire et du stockage entre les machines, et la méthode de sauvegarde qui remplace celle des serveurs physiques.
Ce que la virtualisation change réellement dans une petite salle machine
Un serveur physique dédié à une seule application passe l’essentiel de sa vie à ne rien faire. Le contrôleur de domaine, le serveur de fichiers, l’application métier et l’outil de sauvegarde ont chacun leur boîtier, leur alimentation, leur ventilation et leur emplacement dans la baie, alors qu’aucun n’utilise sérieusement les ressources qu’on lui a achetées.
La couche de virtualisation casse ce gaspillage en présentant à chaque système d’exploitation un matériel simulé : un processeur, de la mémoire, un disque, une carte réseau. Le système invité se comporte comme s’il disposait d’une machine à lui, sans savoir qu’il partage un boîtier avec cinq voisins.
Le gain le plus visible tient à la place et à l’électricité. Le gain le plus utile est ailleurs : une machine virtuelle est un ensemble de fichiers. Elle se copie, se déplace vers un autre serveur, se restaure sur un matériel différent de celui d’origine. La restauration d’un serveur physique après panne dépendait du modèle exact des cartes installées ; celle d’une machine virtuelle ne dépend plus de rien de comparable.
L’argument environnemental mérite d’être posé sans exagération. Dans l’actualisation de l’étude sur l’évaluation de l’impact environnemental du numérique en France, menée avec l’Arcep et publiée en janvier 2025, l’ADEME situe le numérique à 4,4 % de l’empreinte carbone nationale et rappelle que la phase de fabrication des équipements pèse largement plus lourd que leur phase d’usage. Acheter trois serveurs au lieu d’un pèse donc surtout par les machines fabriquées, pas seulement par les kilowattheures consommés ensuite.
Hyperviseur de type 1 ou de type 2 : la distinction qui décide de tout
Deux familles de logiciels assurent cette fonction, et elles ne jouent pas dans la même catégorie.
L’hyperviseur de type 1 s’installe directement sur le matériel nu, sans système d’exploitation en dessous. Il est lui-même un système minimal, réduit à la gestion des ressources et des machines invitées. Sa surface d’attaque est réduite, sa consommation propre faible, et rien ne s’interpose entre lui et le processeur. C’est la configuration attendue pour un serveur de production, quelle que soit la taille de la structure.
L’hyperviseur de type 2 s’exécute comme une application au-dessus d’un système classique. Il rend d’excellents services pour tester une configuration sur un poste de travail, faire tourner un ancien logiciel ou monter une maquette. En production, il ajoute une couche entière qui consomme, qui plante et qui se met à jour au mauvais moment.
Le choix du produit vient ensuite, et il engage plus longtemps qu’on ne le croit. Les formats de disques virtuels, les outils de sauvegarde compatibles et les compétences de l’équipe s’alignent tous sur l’hyperviseur retenu. Trois critères tranchent utilement : le modèle de licence et sa trajectoire tarifaire, la compatibilité avec la solution de sauvegarde envisagée, et l’existence d’un chemin de sortie documenté vers un autre produit. Ce dernier point relève de la même logique que toute réversibilité applicative : il se vérifie avant la signature, jamais après.
Dimensionner les ressources sans étrangler les machines
Le dimensionnement est l’endroit où les projets se ratent, presque toujours dans le même ordre.
Le processeur se partage, avec mesure
Les cœurs physiques se distribuent en cœurs virtuels, et la somme des cœurs virtuels attribués peut dépasser le nombre de cœurs réels. Ce surprovisionnement fonctionne parce que les machines ne réclament pas toutes du temps de calcul en même temps. Un serveur de fichiers dort la nuit, la sauvegarde travaille à cette heure-là, l’application métier tourne aux heures de bureau.
Le piège consiste à attribuer généreusement des cœurs virtuels par précaution. Une machine à huit cœurs virtuels attend, pour s’exécuter, que huit unités physiques se libèrent simultanément ; la même machine à deux cœurs démarre son travail bien plus souvent. Attribuez le strict nécessaire, observez l’attente réelle de l’ordonnanceur, puis ajoutez.
La mémoire vive ne se partage pas
La mémoire est la ressource qui plafonne en premier, et celle qui pardonne le moins. Les mécanismes de récupération existent, ils empruntent temporairement de la mémoire aux machines qui n’en font rien, mais ils ne créent aucune capacité supplémentaire. Quand l’hyperviseur manque de mémoire, il déporte des pages sur disque et les performances s’effondrent d’un facteur considérable, sans message d’erreur.
La règle pratique tient en une phrase : la somme des mémoires allouées, plus la consommation propre de l’hyperviseur, plus la mémoire d’une machine supplémentaire en réserve, doit rester sous la capacité installée.
Le stockage décide du ressenti
Une dizaine de systèmes qui écrivent simultanément sur le même jeu de disques produit un flux d’accès désordonné, très différent d’un serveur seul qui lit un gros fichier. Ce n’est pas la capacité en téraoctets qui compte ici, mais le nombre d’opérations par seconde. Un stockage flash change la nature du problème là où des disques mécaniques imposent des compromis permanents. Le raisonnement rejoint celui du choix d’un stockage réseau en entreprise : on dimensionne sur le comportement des accès, pas sur le volume affiché.
| Ressource | Se surprovisionne | Signal de saturation |
|---|---|---|
| Processeur | oui, largement | temps d’attente de l’ordonnanceur qui grimpe |
| Mémoire vive | très peu | recours à la mémoire sur disque |
| Stockage | selon la technologie | latence d’écriture qui s’allonge |
| Réseau | oui | file d’attente sur la carte physique |
Sauvegarder des machines virtuelles, ce n’est pas sauvegarder des serveurs
Le changement de méthode surprend les équipes habituées à installer un agent dans chaque système. La sauvegarde d’un environnement virtualisé s’opère depuis l’hyperviseur, qui copie les disques virtuels entiers sans rien installer dans les machines invitées.
Deux précautions séparent une sauvegarde exploitable d’une illusion de sauvegarde.
La première touche à la cohérence applicative. Copier un disque virtuel pendant qu’une base de données écrit dedans produit un fichier restaurable mais incohérent, comme une photographie prise au milieu d’une transaction. Les outils sérieux dialoguent avec le système invité pour mettre les écritures en pause le temps de la copie. Vérifiez que cette cohérence applicative est bien activée pour les machines qui hébergent une base, pas seulement la copie brute des blocs.
La seconde concerne l’endroit où atterrissent les sauvegardes. Un dépôt de sauvegarde hébergé sur le même stockage que les machines protégées disparaît avec elles. Une copie hors ligne ou hors site reste la seule à survivre au scénario du chiffrement malveillant ou du sinistre du local. L’article 32 du règlement général sur la protection des données impose d’ailleurs une procédure visant à tester et évaluer régulièrement l’efficacité des mesures de sécurité, ce qui transforme l’essai de restauration en obligation. Ces délais de reprise et cette perte de données tolérable se fixent dans le plan de continuité d’activité, pas dans l’interface de l’outil de sauvegarde.
Restaurez pour de vrai, deux fois par an, sur un serveur de test, en chronométrant l’opération. Une machine virtuelle restaurée en quatre heures alors que le plan en prévoyait une raconte quelque chose d’utile avant le jour de l’incident.
L’hyperviseur, cible privilégiée à cloisonner
Compromettre un hyperviseur revient à compromettre toutes les machines qu’il héberge, leurs données et leurs traitements d’un seul coup. L’ANSSI développe ce raisonnement dans son guide de sécurisation d’une infrastructure VMware publié en avril 2024, dont les principes dépassent largement le produit concerné : isoler l’administration de l’infrastructure de celle des machines invitées, séparer les flux d’administration des flux métier, et restreindre les privilèges par zone de confiance.
Trois traductions concrètes pour une petite structure. L’interface d’administration de l’hyperviseur vit sur un réseau séparé, jamais joignable depuis le réseau bureautique courant. Les comptes d’administration de l’hyperviseur ne sont pas ceux qui servent à administrer les serveurs Windows hébergés, sans quoi la compromission d’un compte emporte les deux niveaux. Les mises à jour de l’hyperviseur suivent un calendrier tenu, avec une fenêtre planifiée, parce qu’une correction de sécurité sur cette couche concerne l’ensemble des services de l’entreprise. Ce socle prolonge les mesures décrites dans notre guide de cybersécurité pour les PME.
Le cloisonnement réseau mérite un mot de plus. Les machines virtuelles communiquent entre elles à travers un commutateur logiciel interne, dont le trafic ne sort jamais du serveur physique et n’est donc vu par aucun équipement de filtrage. Deux machines qui ne devraient pas se parler se parlent, et personne ne le voit passer. Des réseaux virtuels distincts par usage règlent la question à la conception.
Concentration du risque et environnement physique
Regrouper huit serveurs sur un boîtier concentre huit services sur un seul point de défaillance. Le raisonnement de disponibilité change donc de nature au moment de la consolidation.
La haute disponibilité répond à ce risque en installant un second serveur capable de redémarrer les machines du premier. Elle suppose du stockage accessible aux deux, un réseau redondé et une licence adaptée, donc un budget qui double presque. La plupart des petites structures s’en passent et acceptent une indisponibilité de quelques heures, à condition que la restauration soit rapide et éprouvée. Ce choix se pose explicitement, en connaissance du délai réel.
L’environnement physique gagne aussi en importance. Un serveur qui portait un service en tolérait beaucoup ; le même boîtier qui en porte huit demande une baie ventilée, un local dont la température reste stable et une alimentation protégée. La liaison entre l’onduleur et l’hyperviseur mérite une vérification particulière : sans elle, la coupure prolongée éteint brutalement toutes les machines invitées au lieu de déclencher leur arrêt ordonné. Un onduleur correctement dimensionné, piloté par le réseau, arrête les machines dans l’ordre inverse de leur démarrage.
Reste l’inventaire. Une machine virtuelle se crée en quelques minutes et se laisse oublier tout aussi vite, avec sa licence, ses mises à jour non appliquées et son compte administrateur d’origine. Ces machines fantômes consomment des ressources et ouvrent des portes. Une ligne par machine virtuelle dans le registre du parc, avec son propriétaire métier et sa date de revue, coupe court à cette dérive.
Par où démarrer
Listez les serveurs physiques en place, relevez leur consommation réelle de processeur et de mémoire pendant une semaine complète, et vous verrez immédiatement lesquels tiennent ensemble sur un même boîtier. Commencez par les services les moins critiques, gardez l’ancien serveur physique éteint mais disponible pendant un mois, puis basculez le reste une fois la sauvegarde des machines virtuelles restaurée avec succès au moins une fois.
