Virtuele machine, container of bare metal? De passende vorm volgt uit de toepassing, de ondersteuning door de leverancier en de mensen die haar blijvend beheren. Een container maakt een oud ERP niet automatisch onderhoudbaar. Een fysieke server is niet automatisch sneller. Een VM is geen excuus om back-ups en updates te verwaarlozen. DAXS begint daarom bij de concrete workload: besturingssysteem, afhankelijkheden, data, herstel en meetbare belasting.
Deze vergelijking beantwoordt de vraag waar een dienst het best draait. Als applicatiecontainers al zijn gekozen, volgt een andere vraag: Docker Compose of Kubernetes voor het beheer? Neem deze twee beslissingen afzonderlijk.
Wat wordt eigenlijk van elkaar gescheiden?
Een virtuele machine krijgt virtuele hardware en een eigen gastbesturingssysteem. Zo kan een Windows Server-gast naast Linux-gasten op dezelfde hypervisor draaien. De VM is een afgebakende eenheid voor OS-patches, snapshots en herstel; de toepassing moet nog steeds consistent worden geback-upt. Proxmox VE gebruikt hiervoor KVM.
Een container deelt de kernel van de host. Onderscheid twee vormen: een Proxmox LXC-container is een licht Linux-systeem, terwijl een OCI-applicatiecontainer doorgaans één toepassing met afhankelijkheden verpakt. Geen van beide is een Windows-VM of biedt een aparte kernelisolatie. OCI vereist ook een onderhouden imagebuild, registry, beveiligingsupdates en een bewuste oplossing voor persistente data. Een Linux-VM als containerhost kan een nuttige grens vormen voor beheer, back-up en rechten; dat is niet in elk scenario technisch verplicht.
Bare Metal draait besturingssysteem en toepassing rechtstreeks op een fysieke server. Dat kan passen bij leveranciersbindingen, speciale hardware of aangetoonde latentie-eisen. Het vermindert wel de consolidatie op die host en maakt onderhoudsvensters, onderdelen en herstel sterker afhankelijk van de fysieke machine. Ook hier bepalen metingen en supportafspraken de keuze, geen algemene prestatieclaim.
Vijf typische workloads en hun eerste beoordelingsroute
De volgende routes zijn startpunten voor een test, geen algemene productgoedkeuringen. Leveranciersdocumentatie, de licentieovereenkomst en een hersteltest maken de beslissing betrouwbaar.
| Toepassing | Beoordelingsroute | Kritische vraag |
|---|---|---|
| Windows-ERP met database en leverancierssupport | VM als logisch vertrekpunt | Welke combinatie van gast-OS, hypervisor, SQL en licenties is daadwerkelijk ondersteund? |
| Eigen Linux-webdienst met reproduceerbare build | OCI-applicatiecontainer, eventueel op een Linux-VM | Wie bouwt en actualiseert images, controleert kwetsbaarheden en beheert registry, secrets en logs? |
| Linux-appliance van een leverancier | Onderzoek eerst een ondersteunde VM | Accepteert de leverancier virtualisatie, virtuele apparaten en de beoogde back-up-/herstelroute? |
| Database met hoge schrijfbelasting | VM of bare metal op basis van metingen; containers alleen met geteste persistentie | Hoe gedragen p95-/p99-latentie, IOPS, replicatie en consistent herstel zich tijdens piekbelasting? |
| Dienst met dongle, speciale kaart of directe apparaattoegang | Test VM-passthrough; overweeg bare metal | Blijven leverancierssupport, apparaattoewijzing en herstel mogelijk na vervanging van een host? |
Een databasecontainer is niet op voorhand verkeerd. Het beschrijfbare containerbestandssysteem is echter niet de plek voor data die na vervanging moet blijven bestaan. Plan volumes, consistentie, back-up en herstel expliciet. Omgekeerd maakt een VM van een ongeteste databaseback-up geen betrouwbaar herstel.
Zes controles voor de beslissing
- Leverancier en licentie: Controleer ondersteunde systemen, hypervisors, containerruntimes en hardwarebindingen schriftelijk. Windows Server-rechten hangen onder meer af van editie, gelicentieerde cores, aantal virtuele omgevingen en contractvorm; “één VM” betekent geen vast tarief.
- Isolatie en rechten: Welke dienst mag een andere beïnvloeden? Containers hebben namespaces en resourcelimieten, maar delen de hostkernel. Runtime, privileges, mounts, netwerk en updates horen bij de beveiligingscontrole.
- Prestaties meten: Meet CPU-, RAM- en I/O-belasting, p95-/p99-latentie, pieken en batchvensters met echte data. Bare metal kiezen vanwege veronderstelde “virtualisatieoverhead” kan dure capaciteit vastleggen zonder het werkelijke opslag- of netwerkprobleem op te lossen.
- Data en herstel: Definieer RPO en RTO per dienst. Oefen een volledige restore op een andere host, inclusief database, configuratie, inloggegevens en afhankelijkheden.
- Wijzigingen en personeel: Wie patcht gast-OS of hostkernel? Wie bouwt containerimages opnieuw? Wie kan ’s nachts een mislukte rollback of hardwarevervanging afhandelen? Beschikbare vaardigheden beperken hoeveel platforms zinvol parallel beheerd kunnen worden.
- Storingsdomein: Beoordeel host, opslag, netwerk en back-up afzonderlijk. Eén bare-metalserver of meerdere containers op één host worden door hun naam niet hoog beschikbaar.
Vergelijk inspanning voordat u besparingen claimt
Vergelijk over drie of vijf jaar in elke kolom dezelfde toepassing met dezelfde belasting en hetzelfde hersteldoel. Noteer migratie en opbouw, hardware en onderdelen, OS- en toepassingsrechten, hypervisor- of runtimesupport, energie, back-up, monitoring en jaarlijkse personeelsuren. Voor OCI komen bijvoorbeeld buildpipeline, registry, imageonderhoud en eventueel orkestratie erbij. Bare metal kan vervangende hardware en een ander onderhoudsvenster vereisen. Bij VM’s tellen hostcapaciteit en gastbesturingssystemen. Een bestaand cluster is voor een nieuwe dienst alleen “gratis” als reserves, licenties en beheermiddelen werkelijk beschikbaar zijn.
De controleerbare basisformule is: totale kosten over n jaar = eenmalige opbouw en migratie + n × (jaarlijkse licenties + support + energie + back-up + beheeruren × intern uurtarief) + geplande vernieuwing. n is drie of vijf. Zonder concrete offertes, belastingmetingen en supportvoorwaarden heeft geen vorm een algemeen kostenvoordeel. Toon ook de kosten van niet-gehaalde RPO/RTO-doelen in plaats van die buiten de berekening te houden.
Hoe DAXS de uitvoeringsvorm zou kiezen
DAXS zou eerst een korte toepassingslijst opstellen met eigenaar, datastromen, leverancierssupport, afhankelijkheden en hersteldoel. Daarna volgt een korte technische test van twee realistische kandidaten: productieachtige belasting, patches en upgrades, uitval van host of apparaat en herstel op een andere machine. Het resultaat is een onderbouwde keuze per toepassing, geen verplichting om alle diensten op één platform te zetten.
Bestaande Windows- en Linux-VM’s zijn vaak stap voor stap te beoordelen; Proxmox in het bedrijf beschrijft de virtualisatiebasis. Als containers geschikt zijn, helpt de vergelijking van Docker Compose en Kubernetes bij de volgende stap. Voor een concrete workload kan DAXS via Contact goedkeuringen, metingen en herstel samen vertalen naar een beheerbesluit.
Bronnen: Proxmox VE: KVM en LXC · Docker Engine: beveiligingsmodel · Docker Engine: persistente data · Microsoft: Windows Server Virtualization Licensing Guidance.
