Dwa plany VPS na tej samej stronie. Cztery vCPU, 8 GB RAM, 160 GB przestrzeni, niemal identyczna cena. Jeden mówi KVM. Drugi OpenVZ. Żadna ze stron nie wyjaśnia, co zmienia to słowo.
Zmienia to, co wolno Ci uruchomić. Typy wirtualizacji VPS to nie tylko przypis o wydajności. Decydują, czy kontrolujesz jądro, czy Windows jest możliwy i czy Docker działa bez pomocy dostawcy. KVM vs. OpenVZ vs. LXC to najpierw pytanie o możliwości, a dopiero potem o szybkość.
Ten przewodnik obejmuje trzy określenia najistotniejsze dla tej decyzji zakupowej. Xen, VMware, Hyper-V i inne platformy wirtualizacji istnieją, ale są poza tym trójstronnym porównaniem.
TL;DR
- KVM daje każdemu VPS własne jądro gościa. Docker działa normalnie, Windows jest technicznie możliwy, a zwykle możesz ładować moduły jądra lub uruchomić własne jądro. Sam KVM nie gwarantuje jednak dedykowanego CPU ani RAM; zobowiązania dotyczące zasobów nadal zależą od dostawcy i planu.
- OpenVZ plany VPS to zwykle kontenery Linux współdzielące jądro hosta. Docker może działać w OpenVZ 7 tylko wtedy, gdy dostawca używa zgodnego jądra i konfiguracji szablonu. Nie możesz wymienić jądra hosta, a pamięć powyżej RAM obsługiwana jest przez kontrolowany przez dostawcę VSwap, a nie przez zwykły swap dyskowy zarządzany przez gościa.
- LXC również współdzieli jądro hosta, ale opiera się na mechanizmach izolacji głównego jądra Linux. Docker może działać, gdy host włączy wymagane funkcje, choć Proxmox zaleca zagnieżdżanie kontenerów w maszynie wirtualnej QEMU dla obciążeń wymagających maksymalnej izolacji i migracji na żywo.
- Kontenery zwykle łatwiej skalować w trakcie działania. KVM również może obsługiwać hot-plug CPU i pamięci, więc "KVM zawsze wymaga restartu" nie jest bezpieczną regułą zakupową. Zapytaj dostawcę, co jego platforma faktycznie obsługuje.
- Dla statycznej strony lub małego stosu LAMP, który nigdy nie potrzebuje Dockera, Windows ani modyfikacji na poziomie jądra, praktyczna różnica może być niewielka. Izolacja, cykl życia i polityka zasobów wciąż mogą się różnić.
Jedna różnica, z której wynikają wszystkie pozostałe
KVM daje każdemu VPS na hoście własne jądro gościa. Kontenery OpenVZ i LXC korzystają z jądra uruchomionego przez hosta.
KVM to pełne rozwiązanie wirtualizacji dla sprzętu x86 z rozszerzeniami wirtualizacji. Trafił do głównego jądra Linux począwszy od wersji 2.6.20. Każdy gość widzi wirtualny sprzęt i uruchamia własny system operacyjny oraz własne jądro.
Typy kontenerowe działają inaczej. LXC to interfejs przestrzeni użytkownika do mechanizmów izolacji jądra Linux, w tym namespace'y, cgroups, capabilities, seccomp i profile bezpieczeństwa. Celem jest środowisko zbliżone do zwykłej instalacji Linuksa, bez uruchamiania osobnego jądra.
Kontener OpenVZ podąża za tym samym ogólnym modelem współdzielonego jądra, choć OpenVZ używa własnej platformy i własnego stosu jądra. OpenVZ 7 potrafi zarządzać zarówno kontenerami, jak i maszynami wirtualnymi KVM, ale gdy detaliczny plan VPS jest opisany jako "OpenVZ", sprzedawany produkt to zwykle typ kontenerowy.
Wszystkie poniższe różnice w możliwościach z tego wynikają. Moduł jądra trzeba załadować do jądra, które kontrolujesz. Inny system operacyjny wymaga innego jądra. Docker potrzebuje przestrzeni nazw na poziomie jądra, dostępnych tam, gdzie znajduje się samo jądro. Po stronie KVM tej granicy warstwa hiperwizora podąża za architekturą zwykle dzieloną na hiperwizory typu 1 i typu 2.
LXC często pojawia się w środowiskach Proxmox, w tym na serwerach zarządzanych samodzielnie i na niektórych platformach hostingowych. To, czy możesz włączyć zaawansowane funkcje LXC, zależy od tego, kto kontroluje danego hosta.
Co pozwala uruchomić każdy z typów
Osie decydujące o zakupie to kontrola nad jądrem, obsługa systemu operacyjnego gościa, zgodność z Dockerem, zachowanie pamięci, zmiana rozmiaru i polityka zasobów.
| Możliwość | KVM | OpenVZ | LXC |
|---|---|---|---|
| Docker | Tak, natywnie | Warunkowo: tylko OpenVZ 7, a dostawca musi użyć szablonu EZ lub odpowiedniego szablonu własnego oraz wymaganych funkcji jądra hosta | Warunkowo: host musi włączyć zagnieżdżanie oraz keyctl |
| Własne jądro lub ładowalne moduły | Zwykle tak | Nie, przypięte do jądra hosta | Nie, współdzieli jądro hosta |
| Windows jako system gościa | Tak, gdy dostawca obsługuje obraz i ścieżkę licencjonowania | Nie, tylko Linux | Nie, tylko Linux |
| Moduły jądra dla VPN (WireGuard, OpenVPN) | Kontrolowane przez gościa | Zależy od dostawcy: TUN/TAP musi być udostępniony | Zależy od dostawcy: zależy od funkcji jądra włączonych na hoście |
| Kontrola swapu | Kontrolowane przez gościa | VSwap zarządzany przez hosta zamiast zwykłego swapu dyskowego | Polityka hosta, nowoczesny cgroup v2 |
| Zmiana zasobów na żywo, bez restartu | Zależy od platformy, hot-plug CPU i pamięci jest możliwy | Często możliwe | Często możliwe |
| Gwarancja dedykowanych zasobów | Nie jest wrodzona, decyduje polityka dostawcy | Nie jest wrodzona, a gęstość kontenerów ułatwia nadsprzedaż | Nie jest wrodzona |
Który wybrać? KVM to najczystsza odpowiedź, gdy potrzebujesz Windows, własnego jądra, modułów ładowanych przez gościa lub przewidywalnego hosta Dockera. OpenVZ i LXC mogą być wydajnymi środowiskami Linux, ale decyzje na poziomie jądra pozostawiają dostawcy.
To mapa możliwości, a nie benchmark. Nie mówi nic o opóźnieniach pamięci masowej, jakości sieci, generacji CPU, obciążeniu hosta ani polityce przydziału zasobów dostawcy. Dwaj dostawcy stosujący ten sam typ wirtualizacji mogą dostarczyć bardzo różne maszyny.
To na warunkowych komórkach kupujący tracą czas. Kiedyś wdrażałem VPN na kontenerowym VPS, gdzie wymagana funkcja sieciowa po stronie hosta nie była udostępniona. Interfejs nie chciał się podnieść, a naprawa wymagała zgłoszenia do wsparcia, a nie zmiany konfiguracji wewnątrz gościa. Przy planie kontenerowym zapytaj, czy dostawca udostępnia dokładnie to urządzenie lub tę funkcję jądra, której potrzebuje Twój VPN. Przy KVM zwykle kontrolujesz to wewnątrz gościa.
Dlaczego to Docker jest pytaniem, które rozstrzyga większość zakupów
VPS kontenerowy kontra VPS KVM przestaje być abstrakcyjnym porównaniem w chwili, gdy w wymaganiach pojawia się Docker. Sam Docker korzysta z przestrzeni nazw jądra, cgroups, sieci i sterowników pamięci masowej. Wewnątrz KVM te funkcje należą do jądra gościa, które kontrolujesz. Wewnątrz OpenVZ czy LXC zależą ostatecznie od hosta.
Docker na OpenVZ
Wsparcie Dockera na OpenVZ to decyzja o sposobie udostępniania podejmowana ponad Tobą. Pewien artykuł wsparcia SolusVM stwierdza, że Docker może działać w OpenVZ 7 od określonego wydania jądra 3.10, ale mówi też, że Docker nie działa ze standardowymi, prekreowanymi szablonami starego typu. Kontener musi używać szablonu EZ lub odpowiedniego szablonu własnego. Ten sam artykuł wyklucza gości CentOS 8.
Czy zatem Docker działa na OpenVZ? Czasami. Dostawca musi zbudować usługę wokół zgodnego jądra OpenVZ 7 i odpowiedniej ścieżki szablonów. Jeśli strona planu nie mówi tego wprost, zapytaj wsparcie przed zakupem i zachowaj odpowiedź na piśmie.
Gdy konfiguracja hosta jest niezgodna, zmiana flag Dockera wewnątrz VPS nie naprawi źródła problemu. Potrzeba, by dostawca zmienił konfigurację kontenera albo przeniósł Cię na inny typ wirtualizacji.
Docker na LXC
Docker może działać wewnątrz LXC, gdy host udostępnia wymagane funkcje. W Proxmoksie zwykle obejmuje to zagnieżdżanie kontenerów oraz keyctl dla kontenerów nieuprzywilejowanych.
Ważniejszym sygnałem zakupowym jest rekomendacja twórcy platformy. Dokumentacja Proxmoksa mówi, że zagnieżdżanie kontenerów w maszynie wirtualnej QEMU w Proxmoksie pozostaje zalecaną praktyką w zastosowaniach wymagających maksymalnej izolacji i migracji na żywo, zamiast uruchamiać je bezpośrednio w kontenerze systemowym LXC.
Jeśli kontrolujesz hosta LXC, możesz ocenić ten kompromis i testować aktualizacje we własnym tempie. Jeśli wynajmujesz VPS na LXC, to dostawca kontroluje jądro, profil bezpieczeństwa i flagi funkcji zaawansowanych. Potwierdź obsługiwaną konfigurację, zamiast zakładać, że wystarczy dostęp root wewnątrz kontenera.
Docker na KVM
Docker zwykle działa, bo gość Linux kontroluje własne środowisko jądra. Ponad gościem nie ma ani przełącznika zagnieżdżania LXC, ani wymogu szablonu OpenVZ. Nadal potrzebujesz obsługiwanej dystrybucji Linuksa, zgodnego jądra oraz dość RAM i przestrzeni na dane obciążenie.
Posiadanie jądra gościa oznacza też jego utrzymywanie. Na niezarządzanym VPS aktualizacje, reguły zapory, bezpieczeństwo Dockera i kopie zapasowe pozostają Twoim obowiązkiem.
Kluczowy wniosek: Docker nie czyni OpenVZ ani LXC niemożliwymi, ale sprawia, że konfiguracja dostawcy staje się częścią niezawodności Twojej aplikacji. Dla wynajmowanego produkcyjnego hosta Dockera KVM usuwa tę dodatkową zależność.
Czy "4 vCPU" oznacza cztery dedykowane rdzenie CPU
VPS, który wydaje się wolny, choć jego własny monitoring pokazuje bezczynny CPU, to najczęściej opisywany objaw. Umożliwia to wirtualizacja kontenerowa. Rywalizacja o zasoby dzieje się warstwę niżej, niż gość jest w stanie zobaczyć, więc jego własne metryki nie pokazują niczego złego.
Mechanizmem jest sam niski narzut. Kontener kosztuje hosta znacznie mniej niż pełna maszyna wirtualna, więc na tym samym sprzęcie mieści się ich więcej. Taką gęstość tanio się tworzy i trudno wykryć od wewnątrz gościa, co strukturalnie ułatwia nadsprzedaż na OpenVZ bardziej niż na KVM. KVM nie powstrzyma dostawcy przed upychaniem hosta. Rezerwuje jednak realną pamięć i realne udziały CPU na gościa, co nakłada arytmetyczny sufit na to upychanie. Strona diagnostyczna ma własny przewodnik na temat tego, jak rozpoznać, że dostawca stosuje nadsprzedaż.
Pamięć też zachowuje się inaczej. Na OpenVZ nie użyjesz swapu dyskowego jako dodatkowej pamięci, więc liczba RAM na stronie planu to ściana, a nie równia. Gość KVM pod presją pamięci zwalnia. W kontenerze OpenVZ pod presją pamięci procesy są zabijane.
Jest też konsekwencja dla izolacji i to ją najczęściej się lekceważy. Pamięć kontenera jest adresowalna z poziomu hosta w sposób, w jaki pamięć gościa KVM nie jest. Szyfrowanie dysku wewnątrz gościa nadal chroni Cię przed kradzieżą dysku. Nie chroni jednak kluczy działającego kontenera przed maszyną, która go uruchamia. Jeśli Twój model zagrożeń obejmuje operatora hosta, współdzielone jądro to niewłaściwy fundament. Żadna konfiguracja wewnątrz gościa tego nie zmieni.
Kluczowy wniosek: ta sama liczba na stronie planu to inna obietnica w zależności od typu. Na KVM to przydział. Na OpenVZ to sufit, którym się dzielisz.
Gdzie OpenVZ wciąż ma sens i dokąd zmierza
Jeśli prowadzisz statyczną stronę albo mało obciążony stos LAMP, możesz nigdy nie dotknąć możliwości, które OpenVZ ogranicza. Żadnego Windows, żadnego własnego jądra, żadnego modułu ładowanego przez gościa i żadnego produkcyjnego Dockera. Dla tak wąskiego obciążenia dobrze prowadzony kontener OpenVZ wciąż się sprawdzi.
Cykl życia wymaga dziś więcej uwagi niż dekadę temu. OpenVZ 7 opiera się na gałęzi jądra RHEL 7, wersji 3.10. Sam numer wersji nie dowodzi, że utrzymywanemu jądru korporacyjnemu brakuje poprawek bezpieczeństwa, bo dostawcy robią backport łatek. Oznacza natomiast, że warto sprawdzić zgodność z oprogramowaniem oczekującym nowszych interfejsów jądra.
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 oficjalnej polityce cyklu życia.
To nie psuje dziś działającej witryny na OpenVZ. Sprawia jednak, że plan migracji dostawcy staje się istotny, zanim powierzysz mu nowe, długowieczne obciążenie. Zapytaj, która wersja OpenVZ lub Virtuozzo działa, jak dostarczane są poprawki bezpieczeństwa i jaka ścieżka migracji jest dostępna.
Gdy strona planu nie podaje typu wirtualizacji, zapytaj wsparcie, zamiast wnioskować z ceny. Warto mieć tę odpowiedź na piśmie.
Wybór według obciążenia
Zacznij od wymagania, a nie od technologii.
Wybierz KVM, gdy obciążenie potrzebuje własnego jądra
KVM to bezpośredni wybór, gdy potrzebujesz czegokolwiek z poniższych:
- Windows jako system operacyjny gościa
- Własne jądro
- Moduły jądra ładowane przez gościa
- Produkcyjny Docker bez zależności typu kontener w kontenerze
- Wirtualizacja zagnieżdżona, gdy dostawca ją udostępnia
- Swap i strojenie jądra kontrolowane przez gościa
Windows jest rozstrzygający, bo zarówno kontenery OpenVZ, jak i LXC korzystają z linuksowego jądra hosta. Wybór między Linuksem a Windowsem dla samej aplikacji to osobna kwestia, dotycząca zgodności oprogramowania, administracji i licencji. Zobacz porównanie VPS Linux i Windows przy tej decyzji.
Wybierz LXC, gdy chcesz wydajny linuksowy kontener systemowy
LXC jest rozsądny, gdy obciążenie jest wyłącznie linuksowe, nie potrzebuje osobnego jądra i korzysta z niskiego narzutu albo szybkich zmian zarządzanych przez hosta. Jest szczególnie przydatny, gdy sam kontrolujesz hosta Proxmox lub LXC.
W przypadku wynajmowanego VPS na LXC sprawdź wsparcie Dockera, wymagane urządzenia, tryb bezpieczeństwa, zachowanie kopii zapasowych oraz to, czy da się włączyć funkcje zaawansowane.
Rozważ OpenVZ przy prostym, zweryfikowanym obciążeniu linuksowym
OpenVZ wciąż może być akceptowalny dla prostej witryny, małego stosu LAMP, usługi DNS lub równie typowego obciążenia linuksowego, gdy:
- Dostawca dokumentuje wersję platformy.
- Twoje oprogramowanie obsługuje dostępne środowisko jądra.
- Nie potrzebujesz Windows ani modyfikacji jądra.
- Docker jest albo niepotrzebny, albo wyraźnie obsługiwany.
- Dostawca ma wiarygodny plan bezpieczeństwa i migracji.
- Cena albo model operacyjny daje Ci realny powód, by go wybrać.
Nie wybieraj go tylko dlatego, że stare porównanie mówi, iż OpenVZ zawsze jest tańszy. Porównaj aktualny plan, wsparcie, politykę zasobów i opcje migracji.
Jeśli odpowiedź wypadła na KVM, to decyduje ograniczenie, a nie preferencja. Oferowany przez Cloudzy KVM VPS startuje w 60 sekund na AMD EPYC z czystym NVMe, a każda instancja dostaje własne jądro gościa. Moduły jądra się ładują, własne jądra startują, a obsługiwani są zarówno goście Linux, jak i Windows. Docker jest w marketplace jeśli wolisz nie instalować go samodzielnie.
Często zadawane pytania
Czy mogę uruchomić Dockera na VPS z OpenVZ?
Tylko wtedy, gdy dostawca skonfigurował zgodne środowisko OpenVZ 7. SolusVM dokumentuje wsparcie na dostatecznie nowych jądrach OpenVZ 7 z szablonami EZ lub odpowiednimi własnymi, podczas gdy standardowe szablony starego typu nie działają. Traktuj Dockera jako nieobsługiwanego, dopóki dostawca nie potwierdzi dokładnej konfiguracji.
Czy OpenVZ może uruchomić Windows?
Nie, nie jako kontener OpenVZ. Kontener współdzieli linuksowe jądro hosta. KVM może uruchomić gościa z Windows, bo maszyna wirtualna startuje własne jądro systemu operacyjnego, choć dostawca i tak musi obsługiwać obraz, ISO oraz ścieżkę licencjonowania.
Czy LXC to to samo co Docker?
Nie. LXC służy zwykle do kontenerów systemowych, które przypominają lekkie maszyny linuksowe z systemem init i wieloma procesami. Docker to platforma kontenerów aplikacyjnych zbudowana wokół obrazów i pojedynczych usług. Oba korzystają z funkcji jądra Linux, takich jak przestrzenie nazw i cgroups, i dlatego terminy bywają mylone.
Czym jest VPS na LXC?
VPS na LXC to linuksowy kontener systemowy hostowany przez LXC albo platformę opartą na LXC, taką jak Proxmox. Wygląda i zachowuje się bardzo podobnie do małego serwera Linux, ale współdzieli jądro hosta zamiast uruchamiać własne. Dzięki temu jest lekki, ale ma ograniczoną kontrolę na poziomie jądra.
Jak sprawdzić, jakiego typu wirtualizacji używa dostawca?
Sprawdź stronę planu albo zapytaj wsparcie. Wewnątrz instancji Linux to polecenie często rozpoznaje środowisko:
systemd-detect-virtMoże zwrócić wartości takie jak kvm, openvz, lub lxc. Wykrywanie od wewnątrz gościa jest przydatne, ale przed zakupem lepszym źródłem pozostaje pisemna specyfikacja dostawcy.
Czy KVM gwarantuje dedykowany CPU i RAM?
Nie. KVM obsługuje nadsubskrypcję CPU i pamięci. Dostawca może oferować zasoby zarezerwowane, współdzielone albo mieszankę obu. Szukaj wyraźnych sformułowań w rodzaju dedykowany RAM, przypięty CPU, zarezerwowany vCPU lub brak nadsubskrypcji, zamiast zakładać, że gwarantuje to hiperwizor.
Czy KVM zawsze jest lepszym wyborem?
Nie. KVM to jedyny wybór dla Dockera, własnych jąder i Windows, ale przy obciążeniu, które nigdy żadnej z tych rzeczy nie dotyka, praktyczna różnica jest niemal niewidoczna.
Dyskusja
Komentarze
Zaloguj się, aby dołączyć do dyskusji.