To VPS-planer, samme side. Fire vCPU, 8 GB RAM, 160 GB lagerplads, næsten samme pris. Den ene siger KVM. Den anden siger OpenVZ. Ingen af siderne forklarer, hvad det ord ændrer.
Det ændrer, hvad du har lov til at køre. Virtualiseringstyper på en VPS er ikke bare en fodnote om ydeevne. De afgør, om du styrer kernen, om Windows er muligt, og om Docker virker uden hjælp fra udbyderen. KVM vs. OpenVZ vs. LXC er først et spørgsmål om muligheder og derefter et spørgsmål om hastighed.
Denne guide dækker de tre betegnelser, der er mest relevante for denne købsbeslutning. Xen, VMware, Hyper-V og andre virtualiseringsplatforme findes, men de ligger uden for denne trevejssammenligning.
TL;DR
- KVM giver hver VPS sin egen gæstekerne. Docker kører normalt, Windows er teknisk muligt, og du kan som regel indlæse kernemoduler eller boote en tilpasset kerne. KVM alene garanterer dog hverken dedikeret CPU eller RAM; ressourcetilsagn afhænger stadig af udbyderen og planen.
- OpenVZ VPS-planer er normalt Linux-containere, der deler værtens kerne. Docker kan kun køre i OpenVZ 7, når udbyderen bruger en kompatibel kerne og skabelonkonfiguration. Du kan ikke udskifte værtens kerne, og hukommelse ud over RAM håndteres gennem udbyderstyret VSwap frem for almindelig disk-swap styret af gæsten.
- LXC deler også værtens kerne, men er bygget op om containment-funktionerne i mainline-Linux. Docker kan køre, når værten aktiverer de nødvendige funktioner, selvom Proxmox anbefaler at indlejre containere i en QEMU-virtuel maskine til workloads, der kræver maksimal isolation og live-migrering.
- Containere er som regel nemmere at ændre størrelse på, mens de kører. KVM kan også understøtte hot-plug af CPU og hukommelse, så "KVM kræver altid en genstart" er ikke en sikker købsregel. Spørg udbyderen, hvad platformen reelt understøtter.
- For et statisk website eller en lille LAMP-stak, der aldrig har brug for Docker, Windows eller tilpasning på kerneniveau, kan den praktiske forskel være lille. Isolation, livscyklus og ressourcepolitik kan stadig være forskellige.
Den ene forskel, der skaber alle de andre
KVM giver hver VPS på værten sin egen gæstekerne. OpenVZ- og LXC-containere bruger den kerne, værten har bootet.
KVM er en fuld virtualiseringsløsning til x86-hardware med virtualiseringsudvidelser. Det blev integreret i mainline-Linux-kernen fra version 2.6.20. Hver gæst ser virtuel hardware og booter sit eget styresystem og sin egen kerne.
Containertyperne fungerer anderledes. LXC er en userspace-grænseflade til Linux-kernens containment-funktioner, herunder namespaces, cgroups, capabilities, seccomp og sikkerhedsprofiler. Målet er et miljø tæt på en almindelig Linux-installation uden at boote en separat kerne.
En OpenVZ-container følger den samme overordnede model med delt kerne, selvom OpenVZ bruger sin egen platform og kernestak. OpenVZ 7 kan håndtere både containere og KVM-virtuelle maskiner, men når en almindelig VPS-plan er mærket "OpenVZ", er produktet, der sælges, normalt containertypen.
Alle forskelle i muligheder herunder følger af det. Et kernemodul skal indlæses i en kerne, du styrer. Et andet styresystem kræver en anden kerne. Docker har brug for namespacing på kerneniveau, og det skal være tilgængeligt dér, hvor kernen selv ligger. På KVM-siden af den grænse følger hypervisorlaget en arkitektur, der almindeligvis inddeles i type 1- og type 2-hypervisorer.
LXC optræder ofte i Proxmox-miljøer, herunder selvadministrerede servere og visse hostingplatforme. Om du kan aktivere avancerede LXC-funktioner afhænger af, hvem der styrer den vært.
Hvad hver type lader dig køre
De akser, der afgør købet, er kontrol over kernen, understøttelse af gæstestyresystem, Docker-kompatibilitet, hukommelsesadfærd, ændring af størrelse og ressourcepolitik.
| Evne | KVM | OpenVZ | LXC |
|---|---|---|---|
| Docker | Ja, nativt | Betinget: kun OpenVZ 7, og udbyderen skal bruge en EZ-skabelon eller en egnet tilpasset skabelon plus de nødvendige kernefunktioner på værten | Betinget: værten skal aktivere nesting og keyctl |
| Tilpasset kerne eller indlæsbare moduler | Som regel ja | Nej, låst til værtens kerne | Nej, deler værtens kerne |
| Windows som gæstestyresystem | Ja, når udbyderen understøtter imaget og licensvejen | Nej, kun Linux | Nej, kun Linux |
| VPN-kernemoduler (WireGuard, OpenVPN) | Styret af gæsten | Afhænger af udbyderen: TUN/TAP skal være eksponeret | Afhænger af udbyderen: afhænger af de kernefunktioner, værten aktiverer |
| Swapstyring | Styret af gæsten | Værtsstyret VSwap frem for almindelig disk-swap | Værtens politik, moderne cgroup v2 |
| Ændring af ressourcer under drift, uden genstart | Afhænger af platformen, hot-plug af CPU og hukommelse er muligt | Ofte muligt | Ofte muligt |
| Garanti for dedikerede ressourcer | Ikke indbygget, udbyderens politik afgør det | Ikke indbygget, og containertætheden gør oversalg lettere | Ikke indbygget |
Hvad skal du vælge? KVM er det klareste svar, når du har brug for Windows, en tilpasset kerne, gæsteindlæste moduler eller en forudsigelig Docker-vært. OpenVZ og LXC kan være effektive Linux-miljøer, men de overlader beslutninger på kerneniveau til udbyderen.
Dette er et kort over muligheder, ikke en benchmark. Det siger intet om lagerforsinkelse, netværkskvalitet, CPU-generation, værtens belastning eller udbyderens politik for ressourcetildeling. To udbydere med samme virtualiseringstype kan levere vidt forskellige maskiner.
Det er ved de betingede felter, at købere spilder tid. Jeg satte engang en VPN op på en container-VPS, hvor den nødvendige netværksfunktion på værtssiden ikke var eksponeret. Grænsefladen ville ikke komme op, og løsningen krævede en supportsag frem for en konfigurationsændring inde i gæsten. Ved en containerplan skal du spørge, om udbyderen eksponerer præcis den enhed eller kernefunktion, din VPN har brug for. Med KVM styrer du normalt det inde i gæsten.
Hvorfor Docker er det spørgsmål, der afgør de fleste køb
Container-VPS mod KVM-VPS holder op med at være en abstrakt sammenligning i det øjeblik, Docker dukker op i dine krav. Docker bruger selv kerne-namespaces, cgroups, netværk og lagerdrivere. Inde i KVM tilhører de funktioner den gæstekerne, du styrer. Inde i OpenVZ eller LXC afhænger de i sidste ende af værten.
Docker på OpenVZ
Docker-understøttelse på OpenVZ er en provisioneringsbeslutning, der træffes over dig. En supportartikel fra SolusVM anfører, at Docker kan køre inde i OpenVZ 7 fra en bestemt 3.10-baseret kerneudgivelse og frem, men siger også, at Docker ikke virker med de almindelige, ældre forudoprettede skabeloner. Containeren skal bruge en EZ-skabelon eller en egnet tilpasset skabelon. Samme supportartikel udelukker CentOS 8-gæster.
Virker Docker så på OpenVZ? Nogle gange. Udbyderen skal have bygget tjenesten op omkring en kompatibel OpenVZ 7-kerne og en egnet skabelonvej. Hvis planens side ikke siger det tydeligt, så spørg supporten inden køb, og gem svaret skriftligt.
Når værtens konfiguration er inkompatibel, løser det ikke det underliggende problem at ændre Docker-flag inde i din VPS. Udbyderen skal ændre containerkonfigurationen eller flytte dig til en anden virtualiseringstype.
Docker på LXC
Docker kan køre inde i LXC, når værten eksponerer de nødvendige funktioner. I Proxmox omfatter det typisk container-nesting og keyctl til uprivilegerede containere.
Det vigtigere købssignal er anbefalingen fra dem, der ejer platformen. Proxmox' dokumentation siger, at det fortsat er anbefalet praksis at indlejre containere i en Proxmox QEMU-VM til brugsscenarier, der kræver maksimal isolation og mulighed for live-migrering, frem for at køre dem direkte i en LXC-systemcontainer.
Hvis du styrer LXC-værten, kan du vurdere den afvejning og teste opgraderinger i dit eget tempo. Lejer du en LXC-VPS, styrer udbyderen kernen, sikkerhedsprofilen og de avancerede feature flags. Få bekræftet den understøttede konfiguration i stedet for at antage, at root-adgang inde i containeren er nok.
Docker på KVM
Docker virker normalt, fordi Linux-gæsten styrer sit eget kernemiljø. Over gæsten findes hverken en LXC-nestingkontakt eller et OpenVZ-skabelonkrav. Du har stadig brug for en understøttet Linux-distribution, en kompatibel kerne og nok RAM og lagerplads til opgaven.
At eje gæstekernen betyder også at vedligeholde den. På en unmanaged VPS er opdateringer, firewallregler, Docker-sikkerhed og backups fortsat dit ansvar.
Vigtigste pointe: Docker gør ikke OpenVZ eller LXC umulige, men gør udbyderens konfiguration til en del af din applikations pålidelighed. For en lejet Docker-vært i produktion fjerner KVM den ekstra afhængighed.
Om "4 vCPU" betyder fire dedikerede CPU-kerner
En VPS, der føles langsom, mens dens egen overvågning viser inaktiv CPU, er det symptom, folk oftest beskriver. Containervirtualisering er det, der gør det muligt. Kampen om ressourcer foregår et lag under det, gæsten kan se, så gæstens egne målinger viser intet galt.
Mekanismen er selve det lave overhead. En container koster værten langt mindre end en fuld virtuel maskine, så der er plads til flere containere på samme hardware. Den tæthed er billig at skabe og svær at opdage inde fra gæsten, hvilket gør oversalg strukturelt lettere på OpenVZ end på KVM. KVM forhindrer ikke en udbyder i at stuve en vært fuld. Men det binder reel hukommelse og reelle CPU-andele pr. gæst, hvilket sætter et regnemæssigt loft over, hvor langt man kan stuve. Diagnosesiden har sin egen gennemgang af, hvordan du afgør, om din udbyder oversælger.
Hukommelsen opfører sig også anderledes. På OpenVZ kan du ikke bruge disk-swap som ekstra hukommelse, så RAM-tallet på planens side er en mur og ikke en skråning. En KVM-gæst under hukommelsespres bliver langsommere. I en OpenVZ-container under hukommelsespres bliver processer dræbt.
Der er også en konsekvens for isolationen, og det er den, folk undervurderer. En containers hukommelse kan adresseres fra værten på en måde, en KVM-gæsts ikke kan. Diskkryptering inde i gæsten beskytter dig stadig mod en stjålet disk. Den beskytter ikke en kørende containers nøgler mod den maskine, der kører den. Hvis din trusselsmodel omfatter værtens operatør, er en delt kerne det forkerte fundament. Ingen konfiguration inde i gæsten ændrer det.
Vigtigste pointe: det samme tal på en plans side er et forskelligt løfte alt efter typen. På KVM er det en tildeling. På OpenVZ er det et loft, du deler.
Hvor OpenVZ stadig giver mening, og hvor det er på vej hen
Kører du et statisk website eller en LAMP-stak med lav trafik, rører du måske aldrig de muligheder, OpenVZ begrænser. Ingen Windows, ingen tilpasset kerne, intet gæsteindlæst modul og intet krav om Docker i produktion. Til den snævre opgave kan en velkørt OpenVZ-container stadig klare arbejdet.
Livscyklussen kræver mere opmærksomhed end for ti år siden. OpenVZ 7 bygger på kernegrenen fra RHEL 7, version 3.10. Versionsnummeret alene beviser ikke, at en vedligeholdt enterprise-kerne mangler sikkerhedsrettelser, for leverandører backporter patches. Men det betyder, at du bør kontrollere kompatibiliteten med software, der forventer nyere kernegrænseflader.
The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the den officielle livscykluspolitik.
Det ødelægger ikke et OpenVZ-site, der fungerer i dag. Men det gør udbyderens migrationsplan relevant, før du betror den en ny, langlivet arbejdsbyrde. Spørg, hvilken OpenVZ- eller Virtuozzo-version der kører, hvordan sikkerhedsrettelser leveres, og hvilken migrationsvej der findes.
Når en plans side ikke nævner virtualiseringstypen, så spørg supporten frem for at udlede den af prisen. Svaret er værd at have på skrift.
Vælg ud fra din arbejdsbyrde
Tag udgangspunkt i kravet frem for i teknologien.
Vælg KVM, når arbejdsbyrden kræver sin egen kerne
KVM er det direkte valg, når du har brug for noget af følgende:
- Windows som gæstestyresystem
- En tilpasset kerne
- Kernemoduler indlæst af gæsten
- Docker i produktion uden afhængigheder af container-i-container
- Indlejret virtualisering, når udbyderen eksponerer den
- Gæstestyret swap og kernetuning
Windows er afgørende, fordi både OpenVZ- og LXC-containere bruger en Linux-værtskerne. Valget mellem Linux og Windows til selve applikationen er et andet spørgsmål, der handler om softwarekompatibilitet, administration og licensering. Se sammenligningen af Linux- og Windows-VPS til den beslutning.
Vælg LXC, når du vil have en effektiv Linux-systemcontainer
LXC er fornuftigt, når arbejdsbyrden kun er Linux, ikke har brug for en separat kerne og drager fordel af lavt overhead eller hurtige, værtsstyrede ændringer. Det er især nyttigt, når du selv styrer Proxmox- eller LXC-værten.
Ved en lejet LXC-VPS skal du bekræfte Docker-understøttelse, nødvendige enheder, sikkerhedstilstand, backup-adfærd og om avancerede funktioner kan aktiveres.
Overvej OpenVZ til en enkel, verificeret Linux-arbejdsbyrde
OpenVZ kan stadig være acceptabelt til et simpelt website, en lille LAMP-stak, en DNS-tjeneste eller en tilsvarende konventionel Linux-arbejdsbyrde, når:
- Udbyderen dokumenterer platformsversionen.
- Din software understøtter det tilgængelige kernemiljø.
- Du har ikke brug for Windows eller kernetilpasning.
- Docker er enten unødvendigt eller udtrykkeligt understøttet.
- Udbyderen har en troværdig sikkerheds- og migrationsplan.
- Prisen eller driftsmodellen giver dig en reel grund til at vælge det.
Vælg det ikke bare, fordi en gammel sammenligning siger, at OpenVZ altid er billigere. Sammenlign den aktuelle plan, supporten, ressourcepolitikken og migrationsmulighederne.
Hvis dit svar landede på KVM, er det kravet, der afgør det, ikke en præference. KVM VPS fra Cloudzy booter på 60 sekunder på AMD EPYC med ren NVMe, og hver instans får sin egen gæstekerne. Kernemoduler indlæses, tilpassede kerner booter, og både Linux- og Windows-gæster understøttes. Docker findes i marketplace hvis du hellere vil slippe for at installere det selv.
Ofte stillede spørgsmål
Kan jeg køre Docker på en OpenVZ-VPS?
Kun hvis udbyderen har konfigureret et kompatibelt OpenVZ 7-miljø. SolusVM dokumenterer understøttelse på tilstrækkeligt nye OpenVZ 7-kerner med EZ- eller egnede tilpassede skabeloner, mens de almindelige ældre skabeloner ikke virker. Betragt Docker som ikke understøttet, indtil udbyderen bekræfter den præcise opsætning.
Kan OpenVZ køre Windows?
Nej, ikke som en OpenVZ-container. Containeren deler værtens Linux-kerne. KVM kan køre en Windows-gæst, fordi den virtuelle maskine booter sin egen styresystemkerne, men udbyderen skal stadig understøtte imaget, ISO'en og licensvejen.
Er LXC det samme som Docker?
Nej. LXC bruges typisk til systemcontainere, der minder om lette Linux-maskiner med et init-system og flere processer. Docker er en platform til applikationscontainere bygget op om images og enkeltstående tjenester. Begge bruger Linux-kernefunktioner som namespaces og cgroups, og derfor forveksles begreberne nogle gange.
Hvad er en LXC-VPS?
En LXC-VPS er en Linux-systemcontainer, der hostes via LXC eller en LXC-baseret platform som Proxmox. Den ligner og opfører sig meget som en lille Linux-server, men den deler værtens kerne i stedet for at boote sin egen. Det gør den letvægts, men begrænser samtidig kontrollen på kerneniveau.
Hvordan finder jeg ud af, hvilken virtualiseringstype en udbyder bruger?
Tjek planens side, eller spørg supporten. Inde i en Linux-instans identificerer denne kommando ofte miljøet:
systemd-detect-virtDen kan rapportere værdier som kvm, openvz, eller lxc. Detektion inde fra gæsten er nyttig, men udbyderens skriftlige specifikation er stadig den bedre kilde inden købet.
Garanterer KVM dedikeret CPU og RAM?
Nej. KVM understøtter overcommit af CPU og hukommelse. En udbyder kan tilbyde reserverede ressourcer, delte ressourcer eller en blanding. Se efter eksplicitte formuleringer som dedikeret RAM, pinned CPU, reserveret vCPU eller ingen overcommit i stedet for at antage, at hypervisoren garanterer det.
Er KVM altid det bedste valg?
Nej. KVM er det eneste valg til Docker, tilpassede kerner og Windows, men for en arbejdsbyrde, der aldrig rører noget af det, er den praktiske forskel næsten usynlig.
Diskussion
Kommentarer
Log ind for at deltage i diskussionen.