Le choix entre serveurs bare metal et machines virtuelles ne devrait rarement se résumer à une préférence technologique générale. Dans la majorité des environnements professionnels, la virtualisation permet une meilleure exploitation du matériel, des déploiements rapides, une haute disponibilité et une gestion simplifiée. Cependant, pour des charges exigeant des performances extrêmes, une faible latence, un accès dédié à une GPU, du stockage local ou un isolement strict, l’exécution directe sur des serveurs physiques dédiés peut être justifiée.

Les clés du bare metal et de la virtualisation en 20 secondes

• La virtualisation s’intègre généralement mieux dans les applications d’entreprise, le développement, les services web et les environnements avec de nombreuses petites charges.
• Le bare metal se distingue lorsque l’accès direct à la GPU, NVMe, CPU ou réseaux à très faible latence est essentiel.
• L’impact de l’hyperviseur dépend de la charge et ne peut être résumé par un pourcentage universel.
• Les conteneurs ne remplacent pas automatiquement les machines virtuelles.
• De nombreuses entreprises obtiennent de meilleurs résultats en combinant ces deux modèles.

La bonne question n’est pas de savoir quelle plateforme offre la performance théorique maximale, mais plutôt combien de performance l’application nécessite réellement et quelles fonctionnalités opérationnelles seraient perdues en supprimant l’hyperviseur. Une amélioration limitée de la latence ou des performances pourrait ne pas compenser la perte de fonctions telles que la migration à chaud, les snapshots, la haute disponibilité coordonnée ou la récupération rapide sur un autre nœud.

Inversement, maintenir une charge intensive dans une machine virtuelle uniquement pour uniformiser peut introduire des couches, des limites et des coûts inutiles. La décision doit être basée sur des tests avec des données réelles, plutôt que sur l’idée que le bare metal est toujours plus rapide ou que tout doit être virtualisé.

Ce qui change réellement entre le bare metal et une machine virtuelle

Sur un serveur bare metal, le système d’exploitation s’installe directement sur le matériel. La CPU, la mémoire, les unités NVMe, les cartes réseau et les accélérateurs sont réservés à une seule installation, même si des conteneurs ou processus isolés peuvent s’y exécuter.

Ce modèle offre trois avantages principaux :

• Il n’y a pas de couche de virtualisation du matériel entre le système d’exploitation et les dispositifs.
• Les ressources matérielles ne sont pas partagées avec d’autres machines virtuelles.
• La configuration peut être ajustée très précisément à une charge spécifique.

La virtualisation introduit un hyperviseur qui distribue le matériel entre plusieurs machines virtuelles. Chacune dispose de son propre système d’exploitation et perçoit CPU, mémoire, disques et cartes virtuelles, même si ces ressources proviennent d’un même serveur.

Les hyperviseurs modernes exploitent les extensions de virtualisation d’Intel et AMD pour exécuter une grande partie du code des VM directement dans le processeur. C’est pourquoi, dans de nombreuses applications classiques, la différence de performance CPU par rapport au bare metal peut être faible.

Ce comportement évolue lorsque le nombre d’opérations nécessitant l’intervention de l’hyperviseur augmente, lorsqu’il y a contention entre machines ou lorsque le trafic doit traverser plusieurs couches de stockage et de réseau. La pénalité dépend notamment de :

• La version et la type d’hyperviseur utilisés.
• Les pilotes paravirtuels.
• La surallocation de CPU et de mémoire.
• L’affinité avec les cœurs et l’architecture NUMA.
• Le type de stockage.
• Le réseau virtuel, SR-IOV ou dispositifs dédiés.
• Les mesures de sécurité activées.
• La qualité de la configuration.
• L’activité des autres machines sur le même nœud.

C’est pourquoi il n’existe pas de pourcentage universel de surcharge. Affirmer qu’une machine virtuelle perd toujours 5 %, 10 % ou 15 % simplifie excessivement la problématique. Une application principalement limitée par le CPU peut approcher la performance native, tandis qu’une charge sensible à la latence de stockage peut présenter des différences significatives si l’on compare NVMe local à une baie partagée.

De plus, il ne s’agit pas toujours d’une simple comparaison entre bare metal et virtualisation. Souvent, on confronte deux architectures complètes : un serveur physique avec stockage local versus une plateforme virtualisée avec réplication, stockage en réseau, snapshots et tolérance aux pannes. Une partie de cette différence ne provient pas de l’hyperviseur, mais des services additionnels offerts par le second modèle.

Quand privilégier le bare metal

HPC et calcul intensif

Le calcul haute performance mobilise de manière très exigeante processeurs, mémoire et réseaux. Les simulations scientifiques, la finance, la dynamique des fluides, la génomique ou le rendu distribué peuvent bénéficier d’un accès direct à la CPU, à la mémoire locale et aux accélérateurs à faible latence.

Dans ces contextes, l’affinité des processus, la topologie NUMA, l’accès aux instructions vectorielles, la communication entre nœuds et l’absence de contention sont cruciaux. La virtualisation peut être adaptée pour offrir de hautes performances, mais le bare metal réduit les variables et facilite l’exploitation optimale d’une configuration précise.

Cela ne signifie pas que HPC et virtualisation soient incompatibles. Certaines organisations utilisent des machines virtuelles avec ressources réservées, CPU fixée et dispositifs assignés directement. Le choix dépend du niveau d’isolation, d’automatisation et de portabilité requis.

GPU pour entraînement et inférence

Les GPU représentent l’un des cas où il existe plus d’options intermédiaires.

En bare metal, le système d’exploitation utilise directement le pilote du fabricant et peut accéder à toutes les GPU, leur mémoire et les interconnexions comme NVLink lorsque le design le permet. Ce modèle est souvent adapté pour de grands entraînements, des clusters dédiés ou des tâches nécessitant un contrôle total de la machine.

Le passthrough GPU attribue un accélérateur physique complet à une machine virtuelle. NVIDIA décrit cette méthode comme un accès direct de la VM à la GPU avec performance native. Il garantit l’isolation du système d’exploitation sans partage du dispositif, mais limite certaines fonctions de mobilité et oblige à coordonner le cycle de vie de la VM avec le matériel dédié.

Le vGPU permet de répartir une GPU entre plusieurs machines virtuelles via des composants spécifiques, et nécessite des licences. Par ailleurs, Multi-Instance GPU (MIG) divise certains modèles de NVIDIA en instances isolées avec leurs propres ressources. MIG peut s’utiliser en bare metal, conteneurs ou virtualisation, et l’attribution d’instances à différentes VM s’intègre avec vGPU.

La question ne se limite pas à la performance. L’utilisation et le coût également comptent. Déléguer une GPU entière à une charge intermittente peut être moins efficace que la partager, bien que l’accès dédié offre un meilleur isolement.

Bases de données avec I/O intensif

Une base de données transactionnelle peut bénéficier de disques NVMe locaux, de faibles latences et d’un contrôle direct sur CPU et mémoire. Le bare metal est pertinent lorsque l’application génère beaucoup d’I/O aléatoires, exige des temps de réponse très stables ou utilise presque toutes les ressources du serveur.

Cependant, toutes les bases de données ne gagnent pas automatiquement en éliminant l’hyperviseur. Une instance bien dimensionnée sur un stockage tout-flash peut même offrir de meilleures performances qu’un serveur physique mal configuré. Par ailleurs, des fonctions comme snapshots cohérents, réplication, clustering et récupération après sinistre peuvent représenter des avantages supérieurs à une légère différence en IOPS.

Il est essentiel de comparer ces architectures avec des tests représentatifs : volume de transactions, distribution de lectures/écritures, taille de l’ensemble actif, latence en percentiles élevés et comportement lors de pannes ou de sauvegardes.

Applications sensibles à la latence

Les domaines du trading, des télécommunications, du traitement industriel, des jeux en temps réel ou de certaines plateformes multimédia nécessitent une latence très basse et surtout prévisible.

Dans ces environnements, le bare metal limite une partie de la variabilité introduite par le planificateur de l’hyperviseur et par les charges concurrentes. Il permet aussi d’utiliser des techniques comme l’isolation des cœurs, l’affinité des interruptions, des noyaux ajustés, de grandes pages (huge pages) et un accès direct aux cartes réseau.

La virtualisation demeure viable avec des réservations strictes, le CPU pinning et la Single Root I/O Virtualization (SR-IOV). Cette technologie propose de présenter directement aux VM des fonctions virtuelles d’une carte physique, réduisant l’intervention du switch virtuel. La complexité augmente et certaines fonctions de migration peuvent être limitées.

Isolement physique et obligations contractuelles

Certaines organisations ont besoin que leur charge de travail ne partage pas le serveur avec d’autres clients. La raison peut être une politique interne, une exigence contractuelle, la protection de la propriété intellectuelle ou la réduction de certains risques liés à la multi-location.

Ce n’est pas parce que le RGPD, PCI DSS ou réglementations sanitaires n’imposent pas systématiquement le bare metal. Elles requièrent généralement des mesures proportionnées et des contrôles appropriés, sans nécessairement nécessiter un serveur physique dédié pour chaque client.

L’isolement physique doit être justifié par une analyse de risques et par les obligations spécifiques du projet. Une machine virtuelle bien configurée peut souvent suffire dans de nombreux environnements réglementés.

Licences conditionnées par processeurs ou cœurs

Le coût de licence peut complètement transformer le coût d’une architecture. Certains fabricants calculent leurs licences en fonction des processeurs, cœurs physiques, cœurs virtuels ou capacité accessible par le logiciel.

Il ne faut pas supposer que le bare metal est toujours moins cher. Un serveur physique avec beaucoup de cœurs peut nécessiter une licence pour une capacité supérieure à celle utilisée réellement par l’application. Dans d’autres cas, une virtualisation considérée comme un partitionnement dur permet de limiter le nombre de cœurs à licencier.

Quand la virtualisation reste la meilleure option

La virtualisation l’emporte souvent lorsqu’il s’agit d’opérer de nombreuses charges diverses sur une plateforme commune.

Une entreprise peut consolider serveurs web, annuaires, applications internes, outils de monitoring et environnements de développement sur un cluster partagé. Les réservations et limites permettent d’allouer les ressources selon la priorité de chaque service sans réserver un serveur dédié pour de petites charges.

Elle facilite aussi la maintenance : une VM peut être déplacée vers un autre nœud avant une mise à jour de firmware ou un remplacement de hardware. En cas de défaillance d’un hôte, une plateforme haute disponibilité peut redémarrer ses machines sur d’autres nœuds, pourvu que le stockage et la capacité restante soient en place.

Les snapshots, clones et modèles accélèrent le développement et les tests, en évitant de confondre sauvegarde et restauration. La virtualisation permet aussi de récupérer une machine sur un autre nœud sans reproduire chaque composant du serveur original.

Elle est souvent recommandée pour :

• Les applications d’entreprise classiques.
• Les services avec consommation modérée ou variable.
• Les environnements de développement, d’intégration et de test.
• Les infrastructures avec beaucoup de petites machines.
• Les plateformes nécessitant la migration à chaud.
• Les projets avec déploiements et retraits fréquents.
• La reprise après sinistre entre nœuds ou centres.
• Les services privilégiant l’agilité opérationnelle à la performance maximale.

Le principal risque est la surallocation sans contrôle. Partager augmente l’efficacité, mais peut aussi introduire du bruit de voisinage, des attentes CPU, des pressions mémoire et une latence variable. La plateforme doit être équipée de réserves, de systèmes de monitoring et d’une capacité suffisante pour gérer les pannes.

Conteneurs, Kubernetes et la prétendue « troisième voie »

Les conteneurs sont souvent présentés comme une alternative entre bare metal et machines virtuelles, mais ils appartiennent à une couche différente de l’architecture.

Un conteneur encapsule une application et ses dépendances tout en partageant le noyau du système d’exploitation hôte. Linux utilise ses mécanismes comme namespaces, cgroups, etc., pour isoler processus et ressources. Kubernetes ajoute orchestration, réplications, déploiements, récupération de pods et gestion distribuée.

Un cluster Kubernetes peut être installé directement sur des serveurs physiques ou dans des VM. Ces deux configurations sont courantes.

Kubernetes sur bare metal donne accès direct au CPU, au réseau, au stockage et aux GPU. Il peut convenir pour des plateformes internes, télécommunications, edge computing, HPC ou IA. La contrepartie est que l’organisation doit gérer elle-même le provisioning matériel, la haute disponibilité des nœuds, le remplacement des serveurs et l’intégration avec le stockage et le réseau.

Kubernetes sur VM introduit une couche supplémentaire, mais facilite la création et l’agrandissement des nœuds, la séparation de clusters et leur reprise sur un autre hardware. Pour de nombreuses entreprises, ce trade-off est acceptable compte tenu de la flexibilité apportée.

Les conteneurs ne fournissent pas le même niveau de sécurité qu’une VM, car ils partagent le noyau. Kubernetes propose des mesures de sécurité, des espaces de noms d’utilisateur et des politiques, mais la documentation souligne les défis en termes de sécurité, d’isolation et de voisinage potentiellement bruyant dans des environnements multi-tenant.

Pour des charges non fiables ou présentant des risques variés, les VM offrent une frontière supplémentaire. Il existe aussi des runtimes isolés ou microVM qui cherchent à combiner ces approches.

Le stockage joue souvent un rôle plus déterminant que l’hyperviseur

De nombreuses comparaisons attribuent au hyperviseur une différence qui en réalité provient de l’architecture de stockage.

Un serveur physique avec NVMe local propose une latence faible, un débit élevé et un grand nombre d’opérations par seconde. Cependant, en cas de défaillance du serveur, les données restent liées à ces dispositifs sauf si elles sont répliquées vers un autre nœud.

Une plateforme virtualisée utilise typiquement un stockage partagé ou distribué pour assurer haute disponibilité et migrations. Des solutions basées sur Ceph, des baies SAN ou NFS ajoutent réseau, réplication, métadonnées et cohérence. Ces couches consomment des ressources et peuvent augmenter la latence, mais offrent des fonctionnalités que le disque local seul ne fournit pas.

La décision doit porter sur des architectures comparables :

• NVMe local sans réplication versus NVMe local avec réplication.
• Stockage répliqué dans l’application versus stockage répliqué par la plateforme.
• Même réseau, niveau de protection et politique de synchronisation.
• Performance standard et comportement en cas de panne.

Une base de données en bare metal avec réplication synchrone peut avoir des complexités et des pénalisations différentes d’une VM utilisant un stockage partagé. Il n’y a pas de réponse universelle.

L’approche hybride est souvent la plus pertinente

De nombreuses entreprises optent pour une combinaison des deux modèles.

Une grande base de données peut fonctionner sur des serveurs physiques avec NVMe et réplication entre nœuds, tandis que des frontaux, API, outils internes et systèmes auxiliaires restent virtualisés. Des clusters GPU peuvent utiliser du bare metal connectés via un réseau privé à des services déployés en VM.

Une autre option est d’utiliser des serveurs physiques pour Kubernetes et de laisser en virtualisé les applications plus anciennes nécessitant un système d’exploitation complet.

Ce type de conception hybride permet d’attribuer chaque charge au meilleur environnement pour ses besoins, mais nécessite un réseau bien planifié, une observabilité partagée, des politiques de sécurité cohérentes et des procédures de reprise adaptées aux deux plateformes.

L’approche pratique consiste à commencer par le modèle le plus simple à exploiter, puis à mesurer les performances. Si une charge montre un goulot d’étranglement lié à l’hyperviseur, au stockage virtuel ou au réseau partagé, il faut envisager un passage au bare metal.

Mais, la validation doit aller au-delà d’un simple benchmark synthétique. Il est prudent de mesurer :

• Les performances moyennes et les percentiles de latence.
• Le comportement lors de pics de charge.
• Les performances avec d’autres services actifs.
• Le délai de reprise après une panne.
• Le coût des licences.
• La consommation réelle de CPU, mémoire, disque et GPU.
• Le temps de déploiement et de maintenance.
• Le coût du hardware inutilisé.
• Les besoins en personnel.
• La capacité à évoluer.

En Espagne et en Europe, la localisation des données, la juridiction du fournisseur, la consommation énergétique et la disponibilité du support local pèsent également. Ces facteurs ne déterminent pas en soi le choix entre bare metal et virtualisation, mais influencent celui des fournisseurs et des modèles opérationnels.

Le bare metal offre un contrôle et des performances prévisibles, tandis que la virtualisation simplifie la gestion, permet la consolidation, la migration, l’automatisation et la récupération plus facilement. Les conteneurs apportent la portabilité, mais n’éliminent pas la nécessité de choisir l’infrastructure d’exécution.

La meilleure architecture n’est pas celle qui possède le moins de couches, mais celle qui répond efficacement aux objectifs de performance, disponibilité, sécurité et coût, sans complexité démesurée que l’organisation ne pourrait maintenir.

Questions fréquentes

Le bare metal offre-t-il toujours plus de performance qu’une VM ?

L’accès direct au matériel évite la couche de l’hyperviseur, mais la différence réelle dépend essentiellement de la charge et de l’architecture complète. Dans de nombreux cas, une VM bien configurée peut atteindre une performance proche du natif.

Une GPU doit-elle toujours fonctionner en bare metal ?

Pas nécessairement. Elle peut être attribuée intégralement à une VM via passthrough ou partagée via une vGPU, et avec certains modèles, via MIG. Le bare metal est souvent privilégié lorsque la charge doit maîtriser totalement l’accélérateur et ses interconnexions.

Kubernetes sur bare metal remplace-t-il la virtualisation ?

Pas de manière générale. Kubernetes orchestre des conteneurs et peut fonctionner aussi bien sur serveur physique que sur VM. Le choix dépend des besoins en isolement, gestion du matériel et récupération.

Quelle est la meilleure option pour une base de données ?

Cela dépend du volume d’I/O, de la latence, de la taille, des exigences de disponibilité et de la stratégie de réplication. Les bases de données classiques fonctionnent bien virtualisées ; pour des charges extrêmes, un serveur dédié peut être justifié.