VPS satın alma sayfasında duruyorsunuz ve iki seçenek görüyorsunuz: «KVM sanallaştırma» ve «konteyner». Fiyat farkı az değil ve hiçbiri bu farkın pratikte ne anlama geldiğini açıklamıyor. Sunucunuzda yalnızca bir WordPress sitesi varsa neredeyse hiçbir fark hissetmezsiniz. Çekirdek modülü yüklemek, VPN kurmak veya dosya sistemini mount ile değiştirmek istiyorsanız, fark «biraz daha yavaş»tan «hiç çalışmıyor»a dönüşür. Bu makale tam da o sınır hakkında.
Seçim yapmak zorunda olan birinin gözünden sanallaştırma türleri
Üç ana aile vardır ve her biri farklı bir şeyi feda eder.
- Tam sanallaştırma (KVM, VMware, Xen HVM): Sizin için bağımsız bir çekirdek çalışır. Ek yükü vardır ama tam kontrole sahipsiniz.
- İşletim sistemi düzeyinde sanallaştırma (LXC, OpenVZ, Docker): Ana makinenin çekirdeği herkesle paylaşılır. Ek yük neredeyse sıfır, kontrol neredeyse sıfır.
- Para-sanallaştırma (Xen PV): Bugün paylaşımlı hostingde neredeyse ölmüş durumda. Bir yerde görürseniz, altyapı eski demektir.
Karşılaştırma tablolarında kaybolan nokta: KVM sanal BIOS, sanal disk ve sanal ağ kartıyla tam bir sanal makine oluşturur. Konteyner ise yalnızca bir namespace ve bir cgroup'dur; bir sürece «yalnızsın» der. Bu tek cümle, tüm pratik farkları açıklar.
KVM'nin gerçek ek yükü ne kadar
Sayılar tahmin edilmemeli, ölçülmelidir. vmx özelliğine sahip bir işlemcili ana makinede, sysbench cpu --threads=4 run komutunu fiziksel makinede ve aynı sayıda vCPU'lu bir KVM'de çalıştırmak genellikle %2 ile %5 arasında fark verir. Yoğun I/O işlemlerinde fark daha da artar: uygun virtio-blk ve cache mode ile kayıp %5-10'a ulaşır; emüle edilmiş IDE sürücüsüyle %40'ı bile geçebilir.
Yani KVM'nin ek yükü asıl sorun değil. Asıl sorun oversell'dir. 32 fiziksel çekirdeği olup 64 vCPU satan bir sağlayıcı size yalan söylememiştir, ancak tüm müşteriler aynı anda çalıştığında steal time yükselir. Bunu basit bir komutla görürsünüz:
top -bn1 | head -5
# veya daha kesin:
vmstat 1 5st sütununda 5'in üzerinde bir sayı görürseniz, makineniz ana makinenin CPU'sunu bekliyor demektir. Bu sayı konteynerde de vardır ve aynı anlama gelir. Fark şu ki KVM'de cpu steal'i /proc/stat içinde görebilir ve desteğe gösterebilirsiniz; eski OpenVZ'de bu sayaç bazen hiç raporlanmazdı.
Konteyner nerede işe yarar, nerede yaramaz
Konteyner, çekirdekle işi olmayan yükler için tasarlanmıştır. Bir PHP uygulaması, bir Node.js servisi, Nginx arkasında bir dizi Docker konteyneri: bunların hepsi LXC veya Docker'da mükemmel çalışır ve daha az bellek tüketir, çünkü her konteyner sayfa önbelleği ve iç yapılarıyla birlikte tam bir çekirdeği RAM'de tutmaz.
Ancak çekirdeğe ihtiyaç duyduğunuz anda hikâye biter. Üç gerçek örnek:
- WireGuard kurmak istiyorsunuz.
wireguardmodülüne ve/dev/net/tunaygıtına ihtiyacınız var. Privileged erişimi olmayan bir konteynerdeRTNETLINK answers: Operation not permittedalırsınız. - XFS veya ZFS dosya sistemi oluşturmak istiyorsunuz. Konteyner namespace'inde
mount, yalnızca ana makinenin önceden izin verdiği şeyleri bağlamanıza izin verir. sysctl'i değiştirmek istiyorsunuz, örneğinnet.ipv4.tcp_congestion_control=bbr. KVM'de serbesttir; paylaşımlı konteynerde ya reddedilir ya da herkesi etkiler.
Burada hata yapılır: Konteyner VPS'inde oturup BBR'yi etkinleştirmek isteyen kullanıcı komutu çalıştırır, hata çıktısı görmez ve bir hafta sonra ağ hızının hiç değişmediğini fark eder. Çünkü sysctl -w o ortamda sessizce yok sayılmıştır. Değeri sysctl net.ipv4.tcp_congestion_control ile tekrar okursanız, aynı eski değeri görürsünüz. Değişiklikten sonra her zaman değeri yeniden okuyun.
Karar tablosu: hangi iş için hangisi
| İhtiyacınız | KVM | Konteyner (LXC/Docker) |
|---|---|---|
| Bağımsız çekirdek ve istediğiniz sürüm | Evet | Hayır |
| Çekirdek modülü, VPN, tam iptables | Evet | Sınırlı veya hayır |
| Yüksek yoğunluk ve düşük bellek tüketimi | Daha zayıf | Daha iyi |
| Yeniden başlatma süresi | 10 ila 30 saniye | 1 saniyenin altında |
| Güvenlik izolasyonu | Güçlü | Ana makine yapılandırmasına bağlı |
| Ana makineler arası canlı geçiş | Evet | Daha zor |
Tek bir cümle söylemem gerekirse: Ağ, çekirdek veya düşük seviyeli dosya sistemine dokunan her şey için KVM alın, geri kalanı için konteyner. Fiyat farkına inanın, çünkü gerçek.
İç içe sanallaştırma ve az konuşulan tuzaklar
VPS'inizin içinde Docker çalıştırıyorsanız, aslında iç içe sanallaştırma yapıyorsunuz. KVM'de bu sorunsuz çalışır, yeter ki ana makine nested virtualization'ı etkinleştirmiş olsun. Kontrolü tek satırdır:
grep -c vmx /proc/cpuinfo
# Sıfırdan büyük çıktı, donanım sanallaştırmasının kullanılabilir olduğu anlamına gelirÇıktı sıfırsa Docker çalışır ama daha yavaştır, çünkü yazılımsal qemu kullanır. VPS'te Docker kurulumu; kurulumdan ilk konteyneri çalıştırmaya rehberi bu yolu adım adım ele alıyor.
İkinci tuzak: disk. KVM'de disk genellikle bir qcow2 dosyası veya LVM üzerinde bir volume'dür. cache=writeback ile qcow2 üzerinde çalışıyorsanız ve ana makinenin elektriği kesilirse, son birkaç saniyelik yazmaları kaybedebilirsiniz. Veritabanı için cache=none ile io=native daha doğru seçimdir, her ne kadar daha yavaş olsa da. Bu, varsayılan olarak değil bilinçli olarak yapmanız gereken bir takastır.
Üçüncü tuzak: saat. Sanal makine saatini ana makineden alır ve drift varsa loglar sırasız olur ve kimlik doğrulama token'ları reddedilir. chronyd kurun ve her canlı geçişten sonra bir kez chronyc tracking çalıştırın.
Yük ağırlaştığında önce nereye bakmalı
Sanallaştırma türünü değiştirme konusunda herhangi bir karardan önce, sorunun gerçekten sanallaştırma türünden olduğundan emin olun. Kullanıcının «KVM'ye ihtiyacım var» diye düşündüğü on vakadan dokuzunda gerçek sorun yavaş bir MySQL sorgusu veya kötü yapılandırılmış bir cron'dur. Yüksek sunucu yükünün nedenini teşhis etme; pratik ve adım adım rehber tam da bu sırayı izler: önce load average ve iowait, sonra süreçler ve en son donanım.
Tam çekirdek kontrolüne ve katı izolasyona ihtiyacınız olduğu sonucuna vardıysanız, doğal sonraki adım daha büyük bir VPS değil, bir özel sunucudur. Ve yükünüz değişkense ve kaynakları yukarı aşağı ölçeklemek istiyorsanız, KVM sanallaştırmalı bulut sunucu hem kontrol hem esneklik veren şeydir.
Çok zaman kazandıran pratik bir nokta: İki sanallaştırma türü arasında herhangi bir geçişten önce dosyaları basit kopyalamayla değil rsync ile taşıyın. Temel komut şudur:
rsync -avz --progress --exclude='*.sock' \
/var/www/ user@new-host:/var/www/Tam scp ve rsync ile dosya transferi; sunucu için pratik rehber izinleri koruma ve artımlı transfer seçeneklerini açıklıyor. Ve geçişten sonra SSH erişimini kaybettiyseniz, Sunucuyu yeniden kurma ve rescue moduyla çalışma; erişimi kaybettiğinizde verileri kurtarma kurtarma yolunu gösteriyor.
Sık sorulan sorular
KVM her zaman konteynerden daha hızlı mıdır?
Hayır ve bu yaygın bir yanlış inanıştır. KVM'nin ek yükü daha fazladır, bu yüzden hafif ve çok sayıda yükte konteyner genellikle daha hızlı ve daha ucuz olur. KVM, çekirdek özelliklerine veya katı izolasyona ihtiyaç duyduğunuzda kazanır, ham hızda değil.
VPS'imin KVM mi konteyner mi olduğunu nasıl anlarım?
En hızlı yol systemd-detect-virt'tir. Çıktı kvm ise tam sanallaştırmanız var; lxc, openvz veya docker ise konteynerdesiniz. İkinci yol, /proc/cpuinfo'ya bakıp vmx veya svm bayrağının olmamasıdır ki bu konteyner olduğunuzun işaretidir.
Konteynere Docker kurabilir miyim?
Bazı yapılandırmalarda evet, ancak privileged erişimine ihtiyacınız var ve o erişim güvenlik izolasyonunu neredeyse yok eder. Docker mimarinizin bir parçasıysa, sonradan geçiş yapmak zorunda kalmamak için baştan KVM seçin.
OpenVZ ile LXC arasındaki fark nedir?
OpenVZ özel yamalı bir çekirdek gerektirir ve ana Linux akışından ayrıdır; bu yüzden çekirdek sürümü genellikle eski kalır. LXC standart çekirdek üzerinde çalışır ve aynı cgroup ve namespace araçlarını kullanır. Bugün seçim yapıyorsanız LXC'yi alın.
Sipariş vermeden önce bir kez systemd-detect-virt çalıştırın ve gerçekte neye ihtiyacınız olduğunu görün. Cevap «çekirdek» ise KVM. Cevap «hız ve maliyet» ise konteyner. Bu tek karar, diğer tüm ayarlardan daha fazla deneyiminizi etkiler.