Két VPS-csomag, ugyanazon az oldalon. Négy vCPU, 8 GB RAM, 160 GB tárhely, szinte azonos ár. Az egyiken KVM áll. A másikon OpenVZ. Egyik oldal sem magyarázza el, mit változtat ez a szó.
Azt változtatja meg, mit futtathat. A VPS virtualizációs típusai nem pusztán teljesítménnyel kapcsolatos lábjegyzetek. Eldöntik, hogy Ön uralja-e a kernelt, lehetséges-e a Windows, és működik-e a Docker a szolgáltató segítsége nélkül. A KVM, az OpenVZ és az LXC összevetése előbb képességkérdés, csak azután sebességkérdés.
Ez az útmutató a vásárlási döntés szempontjából legfontosabb három megnevezést tárgyalja. A Xen, a VMware, a Hyper-V és más virtualizációs platformok is léteznek, de kívül esnek ezen a hármas összehasonlításon.
Röviden
- KVM minden VPS-nek saját vendégkernelt ad. A Docker rendesen fut, a Windows technikailag lehetséges, és általában betölthet kernelmodulokat vagy indíthat egyedi kernelt. A KVM önmagában viszont nem garantál dedikált CPU-t vagy RAM-ot; az erőforrás-vállalások továbbra is a szolgáltatótól és a csomagtól függenek.
- OpenVZ a VPS-csomagok általában a gazdakernelt megosztó Linux-konténerek. A Docker OpenVZ 7 alatt csak akkor futhat, ha a szolgáltató kompatibilis kernelt és sablonkonfigurációt használ. A gazdakernelt nem cserélheti le, a RAM-on túli memóriát pedig a szolgáltató által vezérelt VSwap kezeli, nem a vendég által kezelt szokásos lemezes swap.
- LXC szintén megosztja a gazdakernelt, de a fő Linux-kernel elszigetelési funkcióira épül. A Docker futhat, ha a gazdagép engedélyezi a szükséges funkciókat, bár a Proxmox azt ajánlja, hogy a maximális elszigetelést és élő migrációt igénylő terheléseknél a konténereket QEMU virtuális gépbe ágyazzuk.
- A konténerek méretét általában könnyebb futás közben módosítani. A KVM is támogathatja a CPU és a memória hot-plugot, ezért a "KVM mindig újraindítást igényel" nem megbízható vásárlási szabály. Kérdezze meg a szolgáltatót, mit támogat valójában a platformja.
- Egy statikus oldalnál vagy egy kis LAMP-stacknél, amelynek soha nincs szüksége Dockerre, Windowsra vagy kernelszintű testreszabásra, a gyakorlati különbség csekély lehet. Az elszigetelés, az életciklus és az erőforrás-politika azonban továbbra is eltérhet.
Az az egyetlen különbség, amelyből az összes többi következik
A KVM a gazdagépen futó minden VPS-nek saját vendégkernelt ad. Az OpenVZ- és LXC-konténerek a gazdagép által elindított kernelt használják.
A KVM teljes körű virtualizációs megoldás x86-os hardverhez virtualizációs kiterjesztésekkel. A 2.6.20-as verziótól bekerült a fő Linux-kernelbe. Minden vendég virtuális hardvert lát, és saját operációs rendszert és kernelt indít.
A konténeres típusok másképp működnek. Az LXC egy felhasználói téri felület a Linux-kernel elszigetelési funkcióihoz, köztük a névterek, a cgroupok, a capabilities, a seccomp és a biztonsági profilok. Célja, hogy a szokásos Linux-telepítéshez közeli környezetet adjon anélkül, hogy külön kernelt indítana.
Az OpenVZ-konténer ugyanazt az általános, megosztott kerneles modellt követi, bár az OpenVZ saját platformot és saját kernelréteget használ. Az OpenVZ 7 konténereket és KVM virtuális gépeket is tud kezelni, de ha egy kereskedelmi VPS-csomagon "OpenVZ" szerepel, általában a konténeres típust adják el.
Az alábbi képességbeli különbségek mind ebből következnek. Egy kernelmodult olyan kernelbe kell betölteni, amelyet Ön irányít. Egy másik operációs rendszerhez másik kernel kell. A Dockernek kernelszintű névterekre van szüksége, amelyeknek ott kell rendelkezésre állniuk, ahol maga a kernel van. Ennek a határnak a KVM-oldalán a hipervizorréteg olyan architektúrát követ, amelyet általában így osztanak fel: 1-es és 2-es típusú hipervizorok.
Az LXC gyakran bukkan fel Proxmox-környezetekben, köztük saját kezelésű kiszolgálókon és egyes tárhelyplatformokon. Hogy be tudja-e kapcsolni a fejlett LXC-funkciókat, attól függ, ki felügyeli az adott gazdagépet.
Mit futtathat az egyes típusokkal
A vásárlást meghatározó szempontok: a kernel feletti kontroll, a vendég operációs rendszer támogatása, a Docker-kompatibilitás, a memória viselkedése, az átméretezés és az erőforrás-politika.
| Képesség | KVM | OpenVZ | LXC |
|---|---|---|---|
| Docker | Igen, natívan | Feltételes: csak OpenVZ 7, és a szolgáltatónak EZ sablont vagy megfelelő egyedi sablont kell használnia a szükséges gazdakernel-funkciókkal együtt | Feltételes: a gazdagépnek engedélyeznie kell a beágyazást és a keyctl |
| Egyedi kernel vagy betölthető modulok | Általában igen | Nem, a gazdakernelhez kötve | Nem, megosztja a gazdakernelt |
| Windows vendég operációs rendszerként | Igen, ha a szolgáltató támogatja a lemezképet és a licencelési utat | Nem, csak Linux | Nem, csak Linux |
| VPN-kernelmodulok (WireGuard, OpenVPN) | A vendég vezérli | Szolgáltatófüggő: a TUN/TAP-nak elérhetőnek kell lennie | Szolgáltatófüggő: a gazdagépen engedélyezett kernelfunkcióktól függ |
| A swap vezérlése | A vendég vezérli | A gazdagép által kezelt VSwap a szokásos lemezes swap helyett | Gazdagép-szabályzat, modern cgroup v2 |
| Erőforrás-átméretezés menet közben, újraindítás nélkül | Platformfüggő, a CPU és a memória hot-plugja lehetséges | Gyakran lehetséges | Gyakran lehetséges |
| Dedikált erőforrás garanciája | Nem eleve adott, a szolgáltató szabályzata dönt | Nem eleve adott, és a konténersűrűség megkönnyíti a túlértékesítést | Nem eleve adott |
Melyiket válassza? A KVM a legtisztább válasz, ha Windowsra, egyedi kernelre, a vendég által betöltött modulokra vagy kiszámítható Docker-gazdagépre van szüksége. Az OpenVZ és az LXC hatékony Linux-környezet lehet, de a kernelszintű döntéseket a szolgáltatóra hagyják.
Ez képességtérkép, nem teljesítménymérés. Semmit nem mond a tároló késleltetéséről, a hálózat minőségéről, a CPU generációjáról, a gazdagép kihasználtságáról vagy a szolgáltató erőforrás-kiosztási szabályzatáról. Két szolgáltató ugyanazzal a virtualizációs típussal nagyon eltérő gépeket adhat.
A vevők a feltételes celláknál veszítik el az időt. Egyszer olyan konténeres VPS-en állítottam be VPN-t, ahol a szükséges hálózati funkció a gazdagép oldalán nem volt elérhetővé téve. Az interfész nem jött fel, és a javításhoz támogatási jegy kellett, nem pedig konfigurációmódosítás a vendégen belül. Konténeres csomagnál kérdezze meg, hogy a szolgáltató pontosan azt az eszközt vagy kernelfunkciót elérhetővé teszi-e, amelyre a VPN-nek szüksége van. KVM esetén ezt rendszerint Ön szabályozza a vendégen belül.
Miért a Docker az a kérdés, amely a legtöbb vásárlást eldönti
A konténeres VPS és a KVM VPS összevetése abban a pillanatban megszűnik elvont kérdés lenni, amint a Docker megjelenik a követelmények között. Maga a Docker kernel-névtereket, cgroupokat, hálózatot és tárolóillesztőket használ. KVM alatt ezek a funkciók az Ön által irányított vendégkernelhez tartoznak. OpenVZ vagy LXC alatt végső soron a gazdagéptől függenek.
Docker OpenVZ alatt
A Docker támogatása OpenVZ alatt olyan kiszolgálási döntés, amelyet Ön felett hoznak meg. Egy SolusVM támogatási cikk azt írja, hogy a Docker egy adott 3.10-es kernelkiadástól kezdve futhat OpenVZ 7 alatt, de azt is közli, hogy a Docker nem működik a szokásos, régi típusú, előre elkészített sablonokkal. A konténernek EZ sablont vagy megfelelő egyedi sablont kell használnia. Ugyanez a cikk kizárja a CentOS 8 vendégeket.
Működik tehát a Docker OpenVZ alatt? Néha. A szolgáltatónak kompatibilis OpenVZ 7 kernel és megfelelő sablonút köré kellett építenie a szolgáltatást. Ha a csomag oldala ezt nem mondja ki egyértelműen, vásárlás előtt kérdezze meg a támogatást, és kérje írásban a választ.
Ha a gazdagép konfigurációja nem kompatibilis, a Docker kapcsolóinak módosítása a VPS-en belül nem oldja meg a valódi problémát. A szolgáltatónak kell megváltoztatnia a konténer konfigurációját, vagy át kell tennie Önt másik virtualizációs típusra.
Docker LXC alatt
A Docker futhat LXC-n belül, ha a gazdagép elérhetővé teszi a szükséges funkciókat. Proxmoxban ide tartozik jellemzően a konténerbeágyazás és a keyctl a jogosultság nélküli konténerekhez.
A fontosabb vásárlási jelzés a platform gazdájának ajánlása. A Proxmox dokumentációja szerint a konténerek Proxmox QEMU virtuális gépbe ágyazása továbbra is ajánlott gyakorlat azoknál a felhasználási eseteknél, amelyek maximális elszigetelést és élő migrációt kívánnak, ahelyett hogy közvetlenül egy LXC rendszerkonténerben futnának.
Ha Ön felügyeli az LXC gazdagépet, mérlegelheti ezt a kompromisszumot, és saját ütemében tesztelheti a frissítéseket. Ha LXC VPS-t bérel, a kernelt, a biztonsági profilt és a fejlett funkciókapcsolókat a szolgáltató felügyeli. Erősíttesse meg a támogatott konfigurációt, ahelyett hogy feltételezné: elég a konténeren belüli root hozzáférés.
Docker KVM alatt
A Docker rendszerint működik, mert a Linux vendég maga vezérli a saját kernelkörnyezetét. A vendég fölött nincs LXC-beágyazási kapcsoló és nincs OpenVZ-sablonkövetelmény. Továbbra is szükség van támogatott Linux-disztribúcióra, kompatibilis kernelre, valamint elegendő memóriára és tárhelyre a terheléshez.
A vendégkernel birtoklása azzal is jár, hogy karban kell tartani. Nem menedzselt VPS-en a frissítések, a tűzfalszabályok, a Docker biztonsága és a mentések továbbra is az Ön felelőssége.
Fő tanulság: A Docker nem teszi lehetetlenné az OpenVZ-t vagy az LXC-t, de a szolgáltató konfigurációját az alkalmazás megbízhatóságának részévé teszi. Bérelt, éles Docker-gazdagép esetén a KVM megszünteti ezt a többletfüggőséget.
Vajon a "4 vCPU" négy dedikált CPU-magot jelent-e
A leggyakrabban leírt tünet az a VPS, amely lassúnak érződik, miközben a saját monitorozása tétlen processzort mutat. Ezt a konténeres virtualizáció teszi lehetővé. Az erőforrás-verseny egy réteggel az alatt zajlik, ameddig a vendég ellát, ezért a saját mérőszámai semmi rendellenest nem jeleznek.
Maga a csekély többletterhelés a mechanizmus. Egy konténer sokkal kevesebbe kerül a gazdagépnek, mint egy teljes virtuális gép, így ugyanarra a hardverre több fér el. Ezt a sűrűséget olcsó előállítani és a vendégen belülről nehéz észrevenni, ami szerkezetileg könnyebbé teszi a túlértékesítést OpenVZ alatt, mint KVM alatt. A KVM nem akadályozza meg a szolgáltatót abban, hogy telezsúfoljon egy gazdagépet. Vendégenként viszont valódi memóriát és valódi CPU-részesedést köt le, ami számtani felső korlátot szab a zsúfolásnak. A diagnosztikai oldalnak külön leírása van arról, hogyan állapítható meg, hogy a szolgáltató túlértékesít-e.
A memória is másként viselkedik. OpenVZ alatt nem használhatja a lemezes swapet további memóriaként, így a csomag oldalán szereplő RAM-érték fal, nem pedig lejtő. Egy KVM vendég memórianyomás alatt lelassul. Egy OpenVZ-konténernél memórianyomás alatt folyamatokat lőnek ki.
Van egy elszigetelési következmény is, és épp ezt becsülik alá a legtöbben. Egy konténer memóriája a gazdagépről megcímezhető, egy KVM vendégé nem. A vendégen belüli lemeztitkosítás továbbra is véd az ellopott lemez ellen. Egy futó konténer kulcsait viszont nem védi meg attól a géptől, amelyik futtatja. Ha a fenyegetésmodelljébe beletartozik a gazdagép üzemeltetője, a megosztott kernel rossz alap. Ezen a vendégen belüli semmilyen beállítás nem változtat.
Fő tanulság: ugyanaz a szám a csomag oldalán típusonként más ígéretet jelent. KVM-en kiosztás. OpenVZ-n olyan plafon, amelyen osztozik.
Hol van még értelme az OpenVZ-nek, és merre tart
Ha statikus oldalt vagy kis forgalmú LAMP-stacket üzemeltet, talán soha nem érinti azokat a képességeket, amelyeket az OpenVZ korlátoz. Nincs Windows, nincs egyedi kernel, nincs vendég által betöltött modul, és nincs éles Docker-igény. Ilyen szűk terhelésre egy jól üzemeltetett OpenVZ-konténer még mindig megteszi.
Az életciklus ma több figyelmet kíván, mint egy évtizede. Az OpenVZ 7 a RHEL 7 kernelágára, a 3.10-es verzióra épül. A verziószám önmagában nem bizonyítja, hogy egy karbantartott vállalati kernelből hiányoznak a biztonsági javítások, hiszen a gyártók visszaportolják a foltokat. Azt viszont jelenti, hogy érdemes ellenőrizni a kompatibilitást olyan szoftverekkel, amelyek újabb kernelfelületeket várnak.
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 hivatalos életciklus-szabályzatban.
Ez ma nem töri el a működő OpenVZ-oldalt. Azt viszont fontossá teszi, hogy ismerje a szolgáltató migrációs tervét, mielőtt új, hosszú életű terhelést bíz rá. Kérdezze meg, melyik OpenVZ- vagy Virtuozzo-verzió fut, hogyan érkeznek a biztonsági javítások, és milyen migrációs út áll rendelkezésre.
Ha egy csomag oldala nem nevezi meg a virtualizáció típusát, kérdezze meg a támogatást, ahelyett hogy az árból következtetne rá. A választ érdemes írásban megőrizni.
Választás a terhelés alapján
A követelményből induljon ki, ne a technológiából.
Válassza a KVM-et, ha a terhelésnek saját kernelre van szüksége
A KVM a kézenfekvő választás, ha bármelyikre szüksége van az alábbiak közül:
- Windows mint vendég operációs rendszer
- Egyedi kernel
- A vendég által betöltött kernelmodulok
- Éles Docker konténer a konténerben típusú függőségek nélkül
- Beágyazott virtualizáció, ha a szolgáltató elérhetővé teszi
- A vendég által vezérelt swap és kernelhangolás
A Windows dönt, mert az OpenVZ- és az LXC-konténerek egyaránt Linux gazdakernelt használnak. Az, hogy magához az alkalmazáshoz Linuxot vagy Windowst választ, külön kérdés: szoftverkompatibilitásról, üzemeltetésről és licencelésről szól. Lásd a Linux és Windows VPS összehasonlítását ehhez a döntéshez.
Válassza az LXC-t, ha hatékony Linux rendszerkonténert szeretne
Az LXC ésszerű, ha a terhelés kizárólag Linux, nincs szüksége külön kernelre, és hasznot húz a kis többletterhelésből vagy a gyors, gazdagép által kezelt változtatásokból. Különösen akkor hasznos, ha a Proxmox- vagy LXC-gazdagépet Ön maga felügyeli.
Bérelt LXC VPS esetén ellenőrizze a Docker támogatását, a szükséges eszközöket, a biztonsági módot, a mentések működését, és azt, hogy engedélyezhetők-e a fejlett funkciók.
Fontolja meg az OpenVZ-t egyszerű, ellenőrzött Linux-terheléshez
Az OpenVZ továbbra is elfogadható lehet egyszerű weboldalhoz, kis LAMP-stackhez, DNS-szolgáltatáshoz vagy hasonlóan hagyományos Linux-terheléshez, ha:
- A szolgáltató dokumentálja a platform verzióját.
- A szoftvere támogatja az elérhető kernelkörnyezetet.
- Nincs szüksége Windowsra vagy kerneltestreszabásra.
- A Docker vagy szükségtelen, vagy kifejezetten támogatott.
- A szolgáltatónak hihető biztonsági és migrációs terve van.
- Az ár vagy az üzemeltetési modell valódi okot ad rá, hogy ezt válassza.
Ne csupán azért válassza, mert egy régi összehasonlítás szerint az OpenVZ mindig olcsóbb. Vesse össze az aktuális csomagot, a támogatást, az erőforrás-szabályzatot és a migrációs lehetőségeket.
Ha a válasza a KVM-re esett, akkor a korlát dönt, nem az ízlés. A Cloudzy KVM VPS 60 másodperc alatt indul AMD EPYC alapon, tiszta NVMe-vel, és minden példány saját vendégkernelt kap. A kernelmodulok betöltődnek, az egyedi kernelek elindulnak, és Linux és Windows vendég egyaránt támogatott. A Docker elérhető a marketplace-en ha inkább nem maga telepítené.
Gyakran ismételt kérdések
Futtathatok Dockert OpenVZ VPS-en?
Csak akkor, ha a szolgáltató kompatibilis OpenVZ 7 környezetet állított be. A SolusVM kellően friss OpenVZ 7 kerneleken, EZ vagy megfelelő egyedi sablonokkal dokumentálja a támogatást, a szokásos régi sablonok viszont nem működnek. Amíg a szolgáltató nem erősíti meg a pontos beállítást, tekintse a Dockert nem támogatottnak.
Futtathat az OpenVZ Windowst?
Nem, OpenVZ-konténerként nem. A konténer a gazdagép Linux-kernelét osztja meg. A KVM tud Windows vendéget futtatni, mert a virtuális gép saját operációsrendszer-kernelt indít, ám a szolgáltatónak akkor is támogatnia kell a lemezképet, az ISO-t és a licencelési utat.
Az LXC ugyanaz, mint a Docker?
Nem. Az LXC-t jellemzően rendszerkonténerekhez használják, amelyek könnyű Linux-gépekre hasonlítanak init rendszerrel és több folyamattal. A Docker alkalmazáskonténer-platform, amely lemezképek és önálló szolgáltatások köré épül. Mindkettő olyan Linux-kernelfunkciókat használ, mint a névterek és a cgroupok, ezért keverik néha a két fogalmat.
Mi az az LXC VPS?
Az LXC VPS egy Linux rendszerkonténer, amelyet LXC vagy egy LXC-alapú platform, például a Proxmox szolgál ki. Nagyon úgy néz ki és úgy viselkedik, mint egy kis Linux-szerver, de a gazdakernelt osztja meg ahelyett, hogy sajátot indítana. Ettől könnyűsúlyú, ugyanakkor korlátozott a kernelszintű irányítás.
Honnan tudom, melyik virtualizációs típust használja a szolgáltató?
Nézze meg a csomag oldalát, vagy kérdezze a támogatást. Egy Linux-példányon belül ez a parancs gyakran azonosítja a környezetet:
systemd-detect-virtOlyan értékeket adhat vissza, mint kvm, openvz, vagy lxc. A vendégen belüli felismerés hasznos, de vásárlás előtt továbbra is a szolgáltató írásos specifikációja a jobb forrás.
Garantál a KVM dedikált CPU-t és RAM-ot?
Nem. A KVM támogatja a CPU és a memória túlfoglalását. Egy szolgáltató kínálhat fenntartott erőforrásokat, megosztottakat vagy a kettő keverékét. Keressen kifejezett megfogalmazásokat, például dedikált RAM, rögzített CPU, fenntartott vCPU vagy nincs túlfoglalás, ahelyett hogy feltételezné: a hipervizor garantálja.
Mindig a KVM a jobb választás?
Nem. A KVM az egyetlen választás a Dockerhez, az egyedi kernelekhez és a Windowshoz, de olyan terhelésnél, amely ezek egyikét sem érinti, a gyakorlati különbség szinte észrevehetetlen.
Beszélgetés
Hozzászólások
Jelentkezzen be a beszélgetéshez.