Virtuel maskine, container eller bare metal? Den rette driftsform følger af applikationen, leverandørens understøttelse og de mennesker, der skal drive den på længere sigt. En container gør ikke automatisk et gammelt ERP vedligeholdeligt. En fysisk server er ikke automatisk hurtigere. En VM er ingen undskyldning for at forsømme backup og opdateringer. DAXS begynder derfor med den konkrete workload: operativsystem, afhængigheder, data, genstart og målbar belastning.
Sammenligningen besvarer spørgsmålet om, hvor en tjeneste bør køre. Hvis applikationscontainere allerede er valgt, følger et andet spørgsmål: Docker Compose eller Kubernetes til driften? De to beslutninger bør træffes hver for sig.
Hvad bliver egentlig adskilt?
En virtuel maskine får virtuel hardware og sit eget gæsteoperativsystem. Det tillader eksempelvis en Windows Server-gæst ved siden af Linux-gæster på samme hypervisor. VM’en er en afgrænset enhed til systempatches, snapshots og gendannelse; applikationen kræver stadig konsistent backup. Proxmox VE anvender KVM til denne vej.
En container deler værtens kerne. Skeln mellem to former: en Proxmox LXC-container er et let Linux-system, mens en OCI-applikationscontainer typisk pakker én applikation med afhængigheder. Ingen af dem er en Windows-VM eller erstatter isolation med egen kerne. OCI kræver også vedligeholdt imagebuild, registry, sikkerhedsopdateringer og en bevidst løsning til persistente data. En Linux-VM som containervært kan give en nyttig grænse for drift, backup og rettigheder; det er ikke teknisk obligatorisk i alle scenarier.
Bare Metal kører operativsystem og applikation direkte på en fysisk server. Det kan passe til leverandørbindinger, specialhardware eller dokumenterede latenskrav. Det reducerer dog konsolideringen på værten og binder vedligeholdelsesvinduer, reservedele og genstart mere til den fysiske maskine. Også her afgør målinger og supportaftaler valget frem for generelle ydelsespåstande.
Fem typiske workloads og deres første vurderingsspor
Disse spor er udgangspunkter for test, ikke generelle produktgodkendelser. Leverandørdokumentation, licensaftale og en gendannelsestest skal gøre beslutningen holdbar.
| Applikation | Vurderingsspor | Kritisk spørgsmål |
|---|---|---|
| Windows-ERP med database og leverandørsupport | VM som naturligt udgangspunkt | Hvilken kombination af gæste-OS, hypervisor, SQL og licenser er faktisk understøttet? |
| Egen Linux-webtjeneste med reproducerbart build | OCI-applikationscontainer, eventuelt på en Linux-VM | Hvem bygger og opdaterer images, undersøger sårbarheder og driver registry, secrets og logs? |
| En leverandørs Linux-appliance | Undersøg først en understøttet VM | Accepterer leverandøren virtualisering, virtuelle enheder og den planlagte backup-/gendannelsesvej? |
| Database med høj skrivebelastning | VM eller bare metal ud fra målinger; containere kun med testet persistens | Hvordan opfører p95-/p99-latens, IOPS, replikering og konsistent gendannelse sig ved spidsbelastning? |
| Tjeneste med dongle, specialkort eller direkte enhedsadgang | Test VM-passthrough; overvej bare metal | Kan leverandørsupport, enhedstildeling og genstart opretholdes efter udskiftning af en vært? |
En databasecontainer er ikke grundlæggende forkert. Dens skrivbare containerfilsystem er dog ikke stedet for data, der skal overleve udskiftning. Planlæg volumes, konsistens, backup og gendannelse eksplicit. Omvendt gør en VM ikke en utestet databasebackup til pålidelig genstart.
Seks kontroller før beslutningen
- Leverandør og licens: Kontrollér understøttede systemer, hypervisorer, containerruntimes og hardwarebindinger skriftligt. Windows Server-rettigheder afhænger blandt andet af udgave, licenserede kerner, antal virtuelle miljøer og aftaleform; “én VM” giver ikke en fast pris.
- Isolation og rettigheder: Hvilken tjeneste må påvirke en anden? Containere har namespaces og ressourcegrænser, men deler værtens kerne. Runtime, privilegier, mounts, netværk og opdateringer hører med i sikkerhedsvurderingen.
- Mål ydelsen: Registrér CPU-, RAM- og I/O-belastning, p95-/p99-latens, spidser og batchvinduer med reelle data. At vælge bare metal alene på grund af formodet “virtualiseringsoverhead” kan binde dyr kapacitet uden at løse det egentlige lager- eller netværksproblem.
- Data og gendannelse: Definér RPO og RTO pr. tjeneste. Øv en fuld gendannelse på en anden vært med database, konfiguration, adgangsoplysninger og afhængigheder.
- Ændringer og personale: Hvem patcher gæste-OS eller værtskerne? Hvem genbygger images? Hvem kan håndtere et mislykket rollback eller hardwareudskiftning om natten? Kompetencerne begrænser antallet af platforme, der meningsfuldt kan drives parallelt.
- Fejldomæne: Vurder vært, lager, netværk og backup hver for sig. Hverken én bare-metal-server eller flere containere på én vært bliver højt tilgængelige på grund af navnet.
Sammenlign indsatsen før påstande om besparelser
Over tre eller fem år skal hver kolonne indeholde samme applikation, belastning og genstartsmål. Medregn migration og opbygning, hardware med reservedele, system- og applikationsrettigheder, hypervisor- eller runtimesupport, energi, backup, overvågning og årlige personaletimer. OCI tilføjer eksempelvis buildpipeline, registry, imagepleje og eventuel orkestrering. Bare metal kan kræve erstatningshardware og et andet vedligeholdelsesvindue. For VM’er tæller værtskapacitet og gæstesystemer. En eksisterende klynge er kun “gratis” for den nye tjeneste, hvis reserve, licenser og driftsressourcer faktisk er til rådighed.
Den kontrollerbare grundformel er: samlet omkostning over n år = engangsopbygning og migration + n × (årlige licenser + support + energi + backup + driftstimer × intern timepris) + planlagt fornyelse. n er tre eller fem. Uden konkrete tilbud, belastningsmålinger og supportvilkår har ingen driftsform en generel omkostningsfordel. Vis også prisen for ikke at nå RPO/RTO frem for at holde den uden for beregningen.
Hvordan DAXS ville vælge driftsformen
DAXS ville først lave en kort applikationsliste med ejer, dataflow, leverandørsupport, afhængigheder og gendannelsesmål. To realistiske kandidater gennemgår derpå en kort teknisk test: produktionsnær belastning, patches og opgraderinger, værts- eller enhedsfejl og gendannelse på en anden maskine. Resultatet er en begrundet beslutning pr. applikation, ingen regel om at flytte alt til én platform.
Eksisterende Windows- og Linux-VM’er kan ofte vurderes trinvist; Proxmox i virksomheden beskriver virtualiseringsgrundlaget. Hvis containere passer, hjælper sammenligningen af Docker Compose og Kubernetes med næste skridt. For en konkret workload kan DAXS via Kontakt samle godkendelser, målinger og gendannelse i en driftsbeslutning.
Kilder: Proxmox VE: KVM og LXC · Docker Engine: sikkerhedsmodel · Docker Engine: persistente data · Microsoft: Windows Server Virtualization Licensing Guidance.
