KVM, OpenVZ ve LXC karşılaştırması: VPS sanallaştırma türünüz gerçekte neye izin veriyor

Aynı sayfada iki VPS planı. Dört vCPU, 8 GB RAM, 160 GB depolama, neredeyse aynı fiyat. Biri KVM diyor. Diğeri OpenVZ. İki sayfada da bu kelimenin neyi değiştirdiği yazmıyor.

Neyi çalıştırmanıza izin verildiğini değiştirir. VPS sanallaştırma türleri yalnızca performansla ilgili bir dipnot değildir. Çekirdeği sizin kontrol edip etmediğinizi, Windows'un mümkün olup olmadığını ve Docker'ın sağlayıcının yardımı olmadan çalışıp çalışmadığını belirler. KVM, OpenVZ ve LXC karşılaştırması, bir hız sorusundan önce bir yetenek sorusudur.

Bu rehber, bu satın alma kararı için en önemli üç etiketi ele alıyor. Xen, VMware, Hyper-V ve diğer sanallaştırma platformları da var, ancak bu üçlü karşılaştırmanın dışında kalıyorlar.

Özetle

• KVM her VPS'e kendi konuk çekirdeğini verir. Docker normal şekilde çalışır, Windows teknik olarak mümkündür ve genellikle çekirdek modülleri yükleyebilir veya özel bir çekirdek başlatabilirsiniz. Ancak KVM tek başına adanmış CPU veya RAM garanti etmez; kaynak taahhütleri yine sağlayıcıya ve plana bağlıdır.
• OpenVZ VPS planları normalde ana makinenin çekirdeğini paylaşan Linux konteynerleridir. Docker, OpenVZ 7'de yalnızca sağlayıcı uyumlu bir çekirdek ve şablon yapılandırması kullandığında çalışabilir. Ana makine çekirdeğini değiştiremezsiniz ve RAM'in ötesindeki bellek, konuğun yönettiği sıradan disk takas alanı yerine sağlayıcının denetlediği VSwap üzerinden işlenir.
• LXC o da ana makinenin çekirdeğini paylaşır, ancak ana hat Linux çekirdeğinin kapsama özellikleri üzerine kuruludur. Ana makine gerekli özellikleri etkinleştirdiğinde Docker çalışabilir; yine de Proxmox, en yüksek yalıtım ve canlı geçiş gerektiren iş yükleri için konteynerleri bir QEMU sanal makinesi içinde iç içe çalıştırmayı önerir.
• Konteynerlerin boyutunu çalışırken değiştirmek genellikle daha kolaydır. KVM de CPU ve bellek için hot-plug destekleyebilir, dolayısıyla "KVM her zaman yeniden başlatma gerektirir" güvenli bir satın alma kuralı değildir. Sağlayıcıya platformunun gerçekte neyi desteklediğini sorun.
• Docker, Windows veya çekirdek düzeyinde özelleştirme gerektirmeyen statik bir site ya da küçük bir LAMP yığını için pratikteki fark küçük olabilir. Yine de yalıtım, yaşam döngüsü ve kaynak politikası farklılık gösterebilir.

Diğer tüm farkları doğuran tek fark

KVM, ana makinedeki her VPS'e kendi konuk çekirdeğini verir. OpenVZ ve LXC konteynerleri ise ana makinenin başlattığı çekirdeği kullanır.

KVM, x86 donanımı için eksiksiz bir sanallaştırma çözümüdür sanallaştırma uzantılarına sahip. 2.6.20 sürümünden itibaren ana hat Linux çekirdeğine dahil edildi. Her konuk sanal donanım görür ve kendi işletim sistemini ve çekirdeğini başlatır.

Konteyner türleri farklı çalışır. LXC bir Linux çekirdeğinin kapsama özellikleri için bir kullanıcı alanı arayüzüdür; bunlara ad alanları, cgroup'lar, capabilities, seccomp ve güvenlik profilleri dahildir. Amacı, ayrı bir çekirdek başlatmadan normal bir Linux kurulumuna yakın bir ortam sunmaktır.

Bir OpenVZ konteyneri aynı genel paylaşılan çekirdek modelini izler; ancak OpenVZ kendi platformunu ve çekirdek yığınını kullanır. OpenVZ 7 hem konteynerleri hem de KVM sanal makinelerini yönetebilir, fakat perakende bir VPS planında "OpenVZ" yazıyorsa satılan ürün normalde konteyner türüdür.

Aşağıdaki tüm yetenek farkları bundan doğar. Bir çekirdek modülünün, sizin denetimimizdeki bir çekirdeğe yüklenmesi gerekir. Farklı bir işletim sistemi farklı bir çekirdek ister. Docker, çekirdek düzeyinde ad alanlarına ihtiyaç duyar ve bunun çekirdeğin bulunduğu yerde mevcut olması gerekir. Bu sınırın KVM tarafında hipervizör katmanı, genellikle şu şekilde ayrılan bir mimariyi izler: Tip 1 ve Tip 2 hipervizörler.

LXC sıklıkla Proxmox ortamlarında karşımıza çıkar; buna kendi yönettiğiniz sunucular ve bazı barındırma platformları dahildir. Gelişmiş LXC özelliklerini etkinleştirip etkinleştiremeyeceğiniz, o ana makineyi kimin denetlediğine bağlıdır.

OKU

KVM vs. OpenVZ 2022: Sanallaştırma Ustası Hangisi?

Her tür neyi çalıştırmanıza izin verir

Satın alma kararını belirleyen eksenler şunlardır: çekirdek denetimi, konuk işletim sistemi desteği, Docker uyumluluğu, bellek davranışı, yeniden boyutlandırma ve kaynak politikası.

Hangisini seçmelisiniz? Windows, özel bir çekirdek, konuk tarafından yüklenen modüller ya da öngörülebilir bir Docker sunucusu gerektiğinde en net yanıt KVM'dir. OpenVZ ve LXC verimli Linux ortamları olabilir, ancak çekirdek düzeyindeki kararları sağlayıcıya bırakırlar.

Bu bir yetenek haritasıdır, bir kıyaslama testi değil. Depolama gecikmesi, ağ kalitesi, CPU kuşağı, ana makine doluluğu veya sağlayıcının kaynak tahsis politikası hakkında hiçbir şey söylemez. Aynı sanallaştırma türünü kullanan iki sağlayıcı çok farklı makineler verebilir.

Alıcılar zamanı koşullu hücrelerde kaybeder. Bir keresinde, ana makine tarafında gereken ağ özelliğinin açılmadığı bir konteyner VPS'inde VPN kurmuştum. Arayüz bir türlü ayağa kalkmadı ve çözüm, konuk içinde bir yapılandırma değişikliği yerine destek talebi gerektirdi. Konteyner planında, sağlayıcının VPN'inizin ihtiyaç duyduğu aygıtı veya çekirdek özelliğini tam olarak açıp açmadığını sorun. KVM'de bunu normalde konuk içinden siz denetlersiniz.

Çoğu satın alma kararını neden Docker sorusu belirler

Docker gereksinimlerinizde belirdiği anda, konteyner VPS ile KVM VPS karşılaştırması soyut olmaktan çıkar. Docker'ın kendisi çekirdek ad alanlarını, cgroup'ları, ağ ve depolama sürücülerini kullanır. KVM içinde bu özellikler sizin denetlediğiniz konuk çekirdeğine aittir. OpenVZ veya LXC içinde ise sonuçta ana makineye bağlıdır.

OpenVZ üzerinde Docker

OpenVZ üzerinde Docker desteği, sizin üstünüzde alınan bir hazırlama kararıdır. Bir SolusVM destek makalesi Docker'ın belirli bir 3.10 tabanlı çekirdek sürümünden itibaren OpenVZ 7 içinde çalışabileceğini belirtir, ancak Docker'ın standart eski hazır şablonlarla çalışmadığını da söyler. Konteynerin bir EZ şablonu ya da uygun bir özel şablon kullanması gerekir. Aynı destek makalesi CentOS 8 konuklarını kapsam dışı bırakır.

Peki Docker OpenVZ'de çalışır mı? Bazen. Sağlayıcının hizmeti uyumlu bir OpenVZ 7 çekirdeği ve uygun bir şablon yolu üzerine kurmuş olması gerekir. Plan sayfası bunu açıkça belirtmiyorsa, satın almadan önce desteğe sorun ve yanıtı yazılı olarak saklayın.

Ana makine yapılandırması uyumsuzsa, VPS içinde Docker bayraklarını değiştirmek asıl sorunu çözmez. Sağlayıcının konteyner yapılandırmasını değiştirmesi ya da sizi farklı bir sanallaştırma türüne taşıması gerekir.

LXC üzerinde Docker

Ana makine gerekli özellikleri açtığında Docker LXC içinde çalışabilir. Proxmox'ta buna genellikle konteyner iç içe çalıştırma ve keyctl ayrıcalıksız konteynerler için gereklidir.

Daha önemli satın alma sinyali, platform sahibinin tavsiyesidir. Proxmox belgeleri şunu söylüyor: konteynerleri bir Proxmox QEMU sanal makinesi içinde iç içe çalıştırmak hâlâ önerilen bir uygulamadır en yüksek yalıtımı ve canlı geçiş yeteneğini gerektiren kullanım senaryolarında; onları doğrudan bir LXC sistem konteynerinde çalıştırmak yerine.

LXC ana makinesini siz denetliyorsanız, bu ödünleşimi değerlendirip yükseltmeleri kendi takviminizde test edebilirsiniz. Bir LXC VPS kiralıyorsanız çekirdeği, güvenlik profilini ve gelişmiş özellik bayraklarını sağlayıcı denetler. Konteyner içindeki root erişiminin yeterli olduğunu varsaymak yerine, desteklenen yapılandırmayı teyit ettirin.

KVM üzerinde Docker

Docker normalde çalışır, çünkü Linux konuk kendi çekirdek ortamını denetler. Konuğun üstünde ne bir LXC iç içe çalıştırma anahtarı ne de bir OpenVZ şablon koşulu vardır. Yine de desteklenen bir Linux dağıtımına, uyumlu bir çekirdeğe ve iş yükü için yeterli RAM ile depolamaya ihtiyacınız olur.

Konuk çekirdeğine sahip olmak, onu bakımını üstlenmek anlamına da gelir. Yönetilmeyen bir VPS'te güncellemeler, güvenlik duvarı kuralları, Docker güvenliği ve yedekler sizin sorumluluğunuzda kalır.

Temel çıkarım: Docker, OpenVZ veya LXC'yi imkânsız kılmaz; ama sağlayıcının yapılandırmasını uygulamanızın güvenilirliğinin bir parçası hâline getirir. Kiralık bir üretim Docker sunucusu için KVM bu ek bağımlılığı ortadan kaldırır.

"4 vCPU" dört adanmış CPU çekirdeği anlamına gelir mi

Kendi izleme araçları CPU'yu boşta gösterirken yavaş hissettiren bir VPS, insanların en sık anlattığı belirtidir. Bunu mümkün kılan şey konteyner sanallaştırmasıdır. Kaynak çekişmesi, konuğun görebildiği katmanın bir altında yaşanır; bu yüzden konuğun kendi ölçümleri hiçbir sorun göstermez.

Mekanizmanın kendisi düşük ek yüktür. Bir konteyner ana makineye tam bir sanal makineden çok daha aza mal olur, dolayısıyla aynı donanıma daha fazla konteyner sığar. Bu yoğunluğu oluşturmak ucuzdur ve konuk içinden fark etmek zordur; bu da aşırı satışı OpenVZ'de KVM'e kıyasla yapısal olarak kolaylaştırır. KVM, bir sağlayıcının ana makineyi tıka basa doldurmasını engellemez. Ama konuk başına gerçek bellek ve gerçek CPU payı ayırır, bu da doldurmaya aritmetik bir tavan koyar. Teşhis tarafının kendi rehberi var: sağlayıcınızın aşırı satış yapıp yapmadığını nasıl anlarsınız.

Bellek de farklı davranır. OpenVZ'de disk takas alanını ek bellek olarak kullanamazsınız, dolayısıyla plan sayfasındaki RAM rakamı bir yokuş değil, bir duvardır. Bellek baskısı altındaki bir KVM konuğu yavaşlar. Bellek baskısı altındaki bir OpenVZ konteynerinde ise süreçler öldürülür.

Yalıtım açısından da bir sonucu var ve en çok hafife alınan da bu. Bir konteynerin belleği, KVM konuğunun belleğinden farklı olarak ana makineden adreslenebilir. Konuk içindeki disk şifrelemesi sizi hâlâ çalınmış bir diske karşı korur. Ancak çalışan bir konteynerin anahtarlarını, onu çalıştıran makineye karşı korumaz. Tehdit modelinize ana makine işletmecisi de dahilse, paylaşılan çekirdek yanlış zemindir. Konuk içindeki hiçbir yapılandırma bunu değiştirmez.

Temel çıkarım: bir plan sayfasındaki aynı rakam, türe göre farklı bir söz anlamına gelir. KVM'de bir tahsistir. OpenVZ'de ise paylaştığınız bir tavandır.

OpenVZ hâlâ nerede anlamlı ve nereye gidiyor

Statik bir site ya da düşük trafikli bir LAMP yığını çalıştırıyorsanız, OpenVZ'nin kısıtladığı yeteneklere hiç dokunmayabilirsiniz. Windows yok, özel çekirdek yok, konuk tarafından yüklenen modül yok, üretimde Docker gereksinimi yok. Bu dar iş yükü için iyi işletilen bir OpenVZ konteyneri hâlâ işi görür.

Yaşam döngüsü, on yıl öncesine göre daha fazla dikkat gerektiriyor. OpenVZ 7, RHEL 7'nin çekirdek dalına, yani 3.10 sürümüne dayanır. Sürüm numarası tek başına, bakımı yapılan bir kurumsal çekirdekte güvenlik düzeltmelerinin eksik olduğunu kanıtlamaz; çünkü üreticiler yamaları geriye taşır. Ama daha yeni çekirdek arayüzleri bekleyen yazılımlarla uyumluluğu doğrulamanız gerektiği anlamına gelir.

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 resmî yaşam döngüsü politikası.

Bu, bugün çalışan bir OpenVZ sitesini bozmaz. Ancak yeni ve uzun ömürlü bir iş yükünü oraya emanet etmeden önce sağlayıcının göç planını önemli hâle getirir. Hangi OpenVZ veya Virtuozzo sürümünün çalıştığını, güvenlik düzeltmelerinin nasıl ulaştırıldığını ve hangi göç yolunun mevcut olduğunu sorun.

Bir plan sayfası sanallaştırma türünü belirtmiyorsa, fiyattan çıkarım yapmak yerine desteğe sorun. Bu yanıtı yazılı almak değerlidir.

İş yüküne göre seçim

Teknolojiden değil, gereksinimden yola çıkın.

İş yükü kendi çekirdeğine ihtiyaç duyduğunda KVM'i seçin

Aşağıdakilerden herhangi birine ihtiyacınız varsa doğrudan tercih KVM'dir:

• Konuk işletim sistemi olarak Windows
• Özel bir çekirdek
• Konuk tarafından yüklenen çekirdek modülleri
• Konteyner içinde konteyner bağımlılıkları olmadan üretimde Docker
• Sağlayıcının açtığı durumlarda iç içe sanallaştırma
• Konuk denetiminde takas alanı ve çekirdek ayarı

Windows belirleyicidir, çünkü hem OpenVZ hem de LXC konteynerleri bir Linux ana çekirdeği kullanır. Uygulamanın kendisi için Linux ile Windows arasında seçim yapmak ise yazılım uyumluluğu, yönetim ve lisanslamayı ilgilendiren ayrı bir konudur. Şuna bakın: Linux ile Windows VPS karşılaştırması bu karar için.

Verimli bir Linux sistem konteyneri istiyorsanız LXC'yi seçin

İş yükü yalnızca Linux ise, ayrı bir çekirdeğe ihtiyaç duymuyorsa ve düşük ek yükten ya da ana makine tarafından yönetilen hızlı değişikliklerden fayda sağlıyorsa LXC mantıklıdır. Özellikle Proxmox veya LXC ana makinesini kendiniz denetliyorsanız işe yarar.

Kiralık bir LXC VPS için Docker desteğini, gereken aygıtları, güvenlik modunu, yedekleme davranışını ve gelişmiş özelliklerin etkinleştirilip etkinleştirilemeyeceğini doğrulayın.

Basit ve doğrulanmış bir Linux iş yükü için OpenVZ'yi değerlendirin

OpenVZ; temel bir web sitesi, küçük bir LAMP yığını, bir DNS hizmeti veya benzer biçimde sıradan bir Linux iş yükü için şu koşullarda hâlâ kabul edilebilir:

• Sağlayıcı platform sürümünü belgeliyorsa.
• Yazılımınız mevcut çekirdek ortamını destekliyorsa.
• Windows'a veya çekirdek özelleştirmesine ihtiyacınız yoksa.
• Docker ya gereksizse ya da açıkça destekleniyorsa.
• Sağlayıcının inandırıcı bir güvenlik ve göç planı varsa.
• Fiyat ya da işletim modeli, onu seçmeniz için gerçek bir neden sunuyorsa.

Yalnızca eski bir karşılaştırma OpenVZ'nin her zaman daha ucuz olduğunu söylüyor diye onu seçmeyin. Güncel planı, desteği, kaynak politikasını ve göç seçeneklerini karşılaştırın.

Yanıtınız KVM’de karar kıldıysa, bunu belirleyen bir tercih değil, kısıttır. Cloudzy’nin sunduğu KVM VPS 60 saniyede AMD EPYC ve saf NVMe üzerinde açılır ve her örnek kendi konuk çekirdeğini alır. Çekirdek modülleri yüklenir, özel çekirdekler başlar ve hem Linux hem Windows konukları desteklenir. Docker, pazar yerinde mevcuttur kendiniz kurmak istemiyorsanız.

Sıkça Sorulan Sorular

systemd-detect-virt