Bare metal of virtualisatie: hoe de juiste architectuur te kiezen voor elke belasting

De keuze tussen bare metal-servers en virtuele machines wordt zelden beslist op basis van een algemene voorkeur voor een technologie. In de meeste zakelijke omgevingen biedt virtualisatie een betere benutting van hardware, snelle implementaties, hoge beschikbaarheid en eenvoudiger beheer. Echter, workloads met extreme prestatiebehoeften op het gebied van latency, GPU-toegang, lokale opslag of isolatie kunnen rechtvaardigen dat men direct op dedicate fysieke servers draait.

De kernpunten van bare metal en virtualisatie in 20 seconden

• Virtualisatie past doorgaans beter bij zakelijke toepassingen, ontwikkelomgevingen, webdiensten en scenario’s met veel kleine workloads.
• Bare metal uitblinkt wanneer direct toegang tot GPU, NVMe, CPU of zeer lage latency-netwerken essentieel is.
• De impact van de hypervisor hangt af van de workload en kan niet met een universeel percentage worden samengevat.
• Containers vervangen niet automatisch virtuele machines.
• Veel organisaties combineren beide modellen voor optimale resultaten.

De juiste vraag is niet welk platform het hoogste theoretische rendement biedt, maar hoeveel prestatie de applicatie daadwerkelijk vereist en welke operationele functies verloren gaan bij het elimineren van de hypervisor. Een beperkte verbetering in latency of prestaties kan niet opwegen tegen het verlies van functies zoals hot migration, snapshots, coördinateerde hoge beschikbaarheid of snelle recovery op een ander knooppunt.

Het tegenovergestelde geldt ook. Het vasthouden aan een hoge werkbelasting op een virtuele machine puur uit uniformiteit kan onnodige complexiteit, overhead en kosten introduceren. De besluitvorming moet gebaseerd zijn op praktische testen met echte gegevens, niet op de veronderstelling dat bare metal altijd sneller is of dat alles virtueel moet draaien.

Wat verandert er eigenlijk tussen bare metal en een virtuele machine?

Bij een bare metal-server wordt het besturingssysteem direct op de hardware geïnstalleerd. De CPU, het geheugen, NVMe-schijven, netwerkkaarten en accelerators worden toegewezen aan één enkele installatie, hoewel binnen die installatie wel containers of geïsoleerde processen kunnen opereren.

Dit model biedt drie duidelijke voordelen:

• Geen hypervisorschijflaag tussen het besturingssysteem en de hardware.
• Fysieke bronnen worden niet gedeeld met andere virtuele machines.
• De configuratie kan zeer precies worden afgestemd op een enkele workload.

Virtualisatie voegt een hypervisor toe die de hardware verdeelt over meerdere virtuele machines. Elke VM draait zijn eigen besturingssysteem en percepeert CPU, geheugen, schijf en virtuele netwerkkaarten, hoewel deze middelen van hetzelfde fysieke apparaat komen.

Moderne hypervisors maken gebruik van Intel- en AMD-virtualisatietechnieken die een groot deel van de VM-code direct op de processor uitvoeren. Daarom is op veel reguliere workloads het prestatieverschil tussen virtueel en bare metal klein.

Het gedrag verandert wanneer er veel operaties plaatsvinden die hypervisor-interventie vereisen, wanneer er contese is tussen VM’s of wanneer dataverkeer meerdere lagen opslag of netwerk moet passeren. De prestatiekosten hangen af van factoren zoals:

• Hypervisor- en versieniveau
• Gebruik van paravirtualiseerde drivers
• Overallocatie van CPU en geheugen
• Nauw verbonden met NUMA-architectuur en processor.kernen
• Type opslag
• Virtuele netwerken, SR-IOV of dedicated apparaten
• Beveiligingsmaatregelen
• Configuratiekwaliteit
• Activiteit van andere VM’s op dezelfde fysieke host

Daarom bestaat er geen universeel percentage voor overhead. Stellen dat een VM altijd 5 %, 10 % of 15 % minder presteert dan native hardware is te simplistisch. Een CPU-intensieve applicatie kan dicht bij native presteren, terwijl latentiegevoelige opslagworkloads duidelijke verschillen laten zien, vooral bij gebruik van lokale NVMe versus gedeelde storage.

Daarnaast wordt er niet altijd slechts een vergelijk gemaakt tussen bare metal en virtualisatie. Vaak worden twee complete architecturen vergeleken: een fysieke server met lokale disks versus een virtualisatieplatform met replicatie, opslagnetwerken, snapshots en failover-capaciteiten. Een deel van het prestatieverschil komt van de extra diensten die het tweede model biedt, niet alleen van de hypervisor zelf.

Wanneer is kiezen voor bare metal zinvol?

HPC en intensieve berekeningen

High-performance computing gebruikt processors, geheugen en netwerken heel intensief. Wetenschappelijke simulaties, financiële modellering, vloeistofdynamica, genomica of gedistribueerde rendering kunnen baat hebben bij directe toegang tot CPU, lokaal geheugen en lage-latentie-accelators.

In deze scenario’s zijn procesaffiniteit, NUMA-topologie, vectorinstructies, communicatie tussen knooppunten en het vermijden van contention cruciaal. Virtualisatie kan afgestemd worden voor hoge prestaties, maar bare metal reduceert variabelen en maakt het gemakkelijker een specifieke configuratie optimaal te benutten.

Dit betekent niet dat HPC en virtualisatie onverenigbaar zijn. Sommige organisaties draaien VM’s met gereserveerde bronnen, vaste CPU’s en directe apparaattoewijzing. De keuze hangt af van de eisen aan isolatie, automatisering en draagbaarheid.

GPU voor training en inferentie

GPU’s vormen een van de gebieden waar tussenoplossingen mogelijk zijn.

Bij bare metal wordt de GPU-direct door het OS beheerd, met volledige toegang tot de GPU, geheugen en interconnecties zoals NVLink indien ondersteund. Dit is geschikt voor grote trainingen, dedicated clusters en workloads die volledige controle nodig hebben over de machine.

GPU passthrough wijst een fysieke GPU volledig toe aan een VM, wat NVIDIA beschrijft als directe toegang met native prestaties. Het biedt OS-isolatie zonder apparaatdeling, maar beperkt sommige functionaliteit en vereist coördinatie tussen VM en hardware.

vGPU verdeelt een GPU over meerdere VM’s en vereist specifieke componenten en licenties. Multi-Instance GPU (MIG) splitst bepaalde NVIDIA-modellen in geïsoleerde instanties met eigen resources. MIG kan op bare metal, containers en virtualisatie worden gebruikt; toewijzing aan VM’s gebeurt via integratie met vGPU.

De keuze gaat niet alleen om prestaties. Belangrijk is ook de efficiëntie en kosten. Het delen van een GPU kan efficiënter zijn dan toewijzen van een hele GPU aan een workload met intermitterend gebruik, hoewel dedicated access betere isolatie biedt.

Databases met intensieve I/O

Een transactionele database profiteert van lokale NVMe-schijven, lage latency en directe controle over CPU en geheugen. Bare metal is aantrekkelijk wanneer een toepassing veel willekeurige I/O genereert, zeer stabiele responstijden vereist of bijna alle serverresources benut.

Niet alle databases profiteren automatisch van eliminatie van hypervisor-overhead. Een goed gedimensioneerde instance op all-flash opslag kan beter presteren dan een slecht geconfigureerd fysiek systeem. Functies zoals consistente snapshots, replicatie, clustering en failover kunnen belangrijker zijn dan een kleine IOPS-verschil.

Een vergelijk moet gebaseerd zijn op representatieve tests, zoals transactievolume, lees- en schrijfspecificaties, grootte van de actieve dataset, hoge-percentiel latency en gedrag bij fouten of back-ups.

Latentiegevoelige toepassingen

Trading, telecommunicatie, industrieel verwerken, real-time games en bepaalde multimedia-platforms vereisen zeer lage en voorspelbare latency.

Hier voorkomt bare metal een deel van de variatie die door de hypervisorplanner en buren wordt geïntroduceerd. Ook kunnen technieken zoals cores isoleren, interrupt affinity, aangepaste kernels, huge pages en directe NIC-toegang worden ingezet.

Virtualisatie blijft een optie met strikte reserveringen, CPU pinning en Single Root I/O Virtualization (SR-IOV). Deze technologie presenteert virtuele functies van een fysieke NIC direct aan VM’s en vermindert virtual switch-interventie, hoewel mogelijk beperkingen op migratie ontstaan.

Fysieke isolatie en contractuele eisen

Sommige organisaties eisen dat workloads niet gedeeld worden met andere klanten, bijvoorbeeld uit interne beleidsregels, contractuele verplichtingen, intellectueel eigendom of risicobeperking.

Dat betekent niet dat regelgeving zoals GDPR, PCI DSS of medische regelgeving standaard bare metal vereisen. Vaak worden proportionele maatregelen en passende controles gevraagd, niet per se een fysiek server per klant.

Fysieke isolatie moet op risicoanalyses en beleidskeuzes gebaseerd zijn. Een goed geconfigureerde VM kan in veel gereguleerde omgevingen voldoende bescherming bieden.

Licenties op basis van processors of cores

Licentieprijzen kunnen de kosten van een architectuur volledig veranderen. Sommige leveranciers rekenen op basis van fysieke processors, cores, virtuele cores of gebruikte capaciteit.

Het is geen vanzelfsprekendheid dat bare metal altijd goedkoper is. Een fysiek server met vele cores kan leiden tot hogere licentiekosten dan de daadwerkelijke burden van de workload. Soms maakt geavanceerde virtualisatie met harde partionering het mogelijk het aantal te licenties cores te beperken.

Oracle publiceert bijvoorbeeld specifieke beleidsregels over partitioneringstechnieken en erkent bepaalde configuraties van Oracle Linux KVM die aan hun voorwaarden voldoen. De keuze moet afgestemd worden met de leverancier en schriftelijk worden vastgelegd in het contract.

Wanneer virtualisatie de beste keuze blijft

Virtualisatie wint vaak wanneer het doel is om veel verschillende workloads op een gedeeld platform te draaien.

Een organisatie kan webservers, directorydiensten, interne applicaties, monitoringtools en ontwikkelomgevingen consolideren op een gedeeld cluster. Reserveringen en limieten maken resource-toewijzing op prioriteit mogelijk zonder een volledig serverpark te reserveren.

Daarnaast vergemakkelijkt virtualisatie het onderhoud. Een VM kan vóór firmware-updates of hardwarewisselingen op een ander knooppunt worden gemigreerd. Bij host-fouten zorgt een high-availability-platform dat VM’s automatisch worden herstart op andere knooppunten, mits opslag en capaciteit in orde zijn.

Snapshots, clones en templates versnellen ontwikkeling en testen, zij het zonder de volledige betrouwbaarheid van back-ups. Hardwareabstractie maakt ook snelle herstelmogelijkheden naar andere knooppunten mogelijk zonder exact replicatie van de originele server.

Virtualisatie past het best bij:

• Algemene zakelijke applicaties
• Services met gematigd of variabel gebruik
• Ontwikkeling, integratie en testomgevingen
• Infrastructuren met veel kleine VM’s
• Platformen die hot migraties vereisen
• Schemas met frequente deployment of decommissioning
• Disaster recovery tussen knooppunten of datacenters
• Services waar operationele wendbaarheid belangrijker is dan maximale prestatiepercentages

Het grootste risico ligt in oncontroleerbare overallocatie. Resource-sharing verhoogt de efficiëntie, maar kan leiden tot “buurmannen-rumoer”, CPU-wachttijden, geheugendruk en variabele latency. Het platform moet over reserveringen, monitoring en voldoende capaciteit beschikken om fouten op te vangen.

Containers, Kubernetes en de denkbeeldige derde weg

Containers worden vaak gepresenteerd als een alternatief tussen bare metal en VM’s, maar behoren tot een andere laag van de infrastructuur.

Een container verpakt een applicatie met haar afhankelijkheden en deelt de kernel van het host OS. Linux gebruikt namespaces, cgroups en andere mechanismen om processen te isoleren en resources te beheren. Kubernetes voegt workloadplanning, herstel, deployment en gedistribueerd beheer toe.

Een Kubernetes-cluster kan direct op fysieke servers draaien of binnen VM’s. Beide opties komen veel voor.

Kubernetes op bare metal biedt directe toegang tot CPU, netwerk, opslag en GPU. Dit is geschikt voor eigen platforms, telecommunicatie, edge computing, HPC en AI. De organisatie moet dan wel zorgen voor hardware provisioning, high availability van nodes, hardware replacement en integratie met opslag en netwerk.

Kubernetes op VM’s voegt een laag toe, maar maakt het makkelijker om nodes te creëren, te schalen en te herstellen op ander hardware. Voor veel bedrijven Wegen de flexibiliteit en comfort op tegen de kleine prestatie- of overheadkosten.

Containers bieden niet hetzelfde veiligheidsniveau als VM’s omdat ze de kernel delen. Kubernetes heeft beveiligingscontexten, namespace-isolatie en beleid om risico’s te beperken, maar waarschuwt zelf voor security-challenges en risico’s op burenrumoer in multi-tenant clusters.

Voor onbetrouwbare klanten of workloads met hogere risiconiveaus kunnen VM’s een extra veiligheidsgrens bieden. Ook bestaan geïsoleerde runtimes en microVM’s die proberen beide benaderingen te combineren.

Opslag bepaalt vaak meer dan de hypervisor

Veel vergelijkingen leggen ten onrechte de nadruk op de hypervisor, terwijl de opslag vaak de echte bepalende factor is.

Een fysieke server met lokale NVMe biedt korte paden, lage latency en hoge IOPS. Maar bij uitval blijven gegevens vaak gebonden aan die disks, tenzij de app replicatie naar een ander node verzorgt.

Virtuele platforms gebruiken doorgaans gedeelde of gedistribueerde opslag voor hoge beschikbaarheid en migratie. Oplossingen zoals Ceph, SAN’s of NFS voegen netwerken, replicatie, metadata en consistentie toe. Deze lagen brengen overhead en kunnen latency verhogen, maar bieden functies die lokale disk niet heeft.

De keuze moet gebaseerd zijn op vergelijkbare architecturen:

• NVMe lokaal zonder replicatie versus NVMe met replicatie
• Applicatie-gebaseerde replicatie versus platformgebaseerde replicatie
• Gelijk netwerk, beschermingsniveau en synchronisatiebeleid
• Normale prestaties en gedrag bij uitval

Een database op bare metal met synchronische replicatie kan complexer en kostbaar zijn dan een VM op gedeelde opslag. Een universeel antwoord bestaat niet; de juiste keuze hangt af van workload-eisen en implementatieconfiguraties.

De hybride architectuur blijkt vaak het meest praktisch

Veel organisaties kiezen uiteindelijk voor een hybride aanpak, waarbij zowel bare metal als virtualisatie worden ingezet.

Zo kan een grote database draaien op fysieke NVMe-servers met replicatie, terwijl front-end, API’s, managementtools en hulpsystemen virtueel blijven. GPU-clusters kunnen op bare metal draaien, verbonden via een beveiligd netwerk met virtuele services.

Ook kan men fysieke servers inzetten voor Kubernetes, terwijl legacy-applicaties die volledige OS-ondersteuning vereisen in VM’s blijven draaien. Dit biedt grote flexibiliteit, maar vereist goede netwerkplanning, gedeeld beheer, veilige policies en herstelprocedures voor beide platformen.

De praktische aanbeveling is te beginnen met het model dat de operationele eenvoud maximaliseert en daarna te meten. Als een workload bottlenecks vertoont die het resultaat van hypervisor, opslag of netwerk lijken te zijn, kan een overstap naar bare metal overwogen worden.

De testen moeten meer brengen dan enkel synthetische benchmarks. Belangrijke meetpunten zijn onder andere:

• Gemiddelde prestaties en latency-percentielen
• Gedrag bij piekbelasting
• Prestaties tijdens gelijktijdige workloads
• Herstelcapaciteit na uitval
• Kosten van licenties
• Reëel gebruik van CPU, geheugen, disk en GPU
• Implementatietijd en onderhoud
• Cost of idle hardware
• Personeelsbehoefte
• Schalingsmogelijkheden

Ook in Europa en Spanje wegen locatiegegevens, jurisdictie, energiegebruik en support beschikbaarheid mee. Deze factoren bepalen niet puur de keuze tussen bare metal en virtualisatie, maar wel de keuze van leverancier en operationeel model.

Bare metal biedt controle en voorspelbare prestatie, terwijl virtualisatie een laag toevoegt die consolidatie, migratie, automatisering en herstel vereenvoudigt. Containers vergroten portabiliteit, maar maken beslissingen over de onderliggende infrastructuur nog steeds noodzakelijk.

De optimale architectuur is niet de minst complexe, maar de die de beste balans vindt tussen prestatie, beschikbaarheid, veiligheid en kosten zonder onnodige complexiteit.

Veelgestelde vragen

Gaat bare metal altijd sneller zijn dan een VM?

Directe hardwaretoegang elimineert de hypervisorlaag, maar het werkelijke prestatieverschil hangt af van de workload en de volledige architectuur. In veel zakelijke toepassingen kan een goed geconfigureerde VM bijna natively presteren.

Moet een GPU altijd op bare metal draaien?

Niet noodzakelijk. Een GPU kan volledig aan een VM worden toegewezen via passthrough of gedeeld via vGPU en MIG. Bare metal is vooral gekozen wanneer volledige controle over het acceleratieapparaat en de interconnects nodig is.

Vervangt Kubernetes op bare metal de virtualisatie?

Niet automatisch. Kubernetes beheert containers en kan op zowel fysieke servers als VM’s draaien. De keuze hangt af van de isolatiebehoefte, hardwarebeheer en herstelopties.

Wat is de beste keuze voor een database?

Dat hangt af van I/O-volume, latency, grootte, beschikbaarheid en replicatiestrategie. Traditionele databases draaien goed op virtualisatie; extreme workloads kunnen een dedicated fysieke server rechtvaardigen.