KVM kaputun altında nasıl çalışır
KVM, /dev/kvm karakter aygıtını açığa çıkararak Linux çekirdeğini Tip-1 hipervizöre dönüştürür. Bir kullanıcı alanı işlemi (genellikle QEMU) bu aygıtı açar, çekirdekten sanal bir CPU oluşturmasını ister ve ardından donanım sanallaştırma uzantılarını kullanarak konuk talimatlarını doğrudan fiziksel CPU'da çalıştırır. Çekirdek ayrıcalıklı olayları yönetir; diğer her şey yerel hızda yürütülür.
Üç bileşen KVM'yi çalıştırır. İlk olarak, kvm.ko çekirdek modülü CPU ve bellek sanallaştırmasını yönetir ve /dev/kvm arayüzünü açığa çıkarır. İkinci olarak, mimariye özel bir modül — Intel VT-x için kvm-intel.ko veya AMD-V için kvm-amd.ko — genel KVM API ile temel CPU'nun sanallaştırma talimatları arasında çeviri yapar. Üçüncü olarak, QEMU, cloud-hypervisor veya Firecracker gibi bir kullanıcı alanı hipervizör süreci aygıt emülasyonunu sağlar: sanal diskler, NIC'ler, USB denetleyicileri ve BIOS veya UEFI bellenimi. Linux çekirdeği hipervizör olduğundan, her Linux zamanlayıcı, bellek yöneticisi ve güvenlik özelliği VM'lere yerel işlemlere uygulandığı şekilde uygulanır. KVM konuğu, çekirdeğin bakış açısından sadece ağır bir süreçtir, bu nedenle top, perf ve cgroups gibi araçlar üzerinde değişiklik yapılmadan çalışır.
KVM ile OpenVZ ile VMware ESXi ile Hyper-V
KVM, her VM için ayrı bir konuk çekirdeği ile tam donanım sanallaştırması sağlar. OpenVZ, her konteynerin ana bilgisayar çekirdeğini paylaştığı işletim sistemi düzeyinde konteynerleştirme kullanır. VMware ESXi, kendi çekirdeğine (VMkernel) sahip tescilli bir bare-metal Tip-1 hipervizördür. Hyper-V, Microsoft'un Windows tabanlı Tip-1 hipervizörüdür. Yalnızca KVM, ESXi ve Hyper-V size gerçek, izole bir konuk çekirdeği verir.
OpenVZ (ve halefi Virtuozzo) bir konteyner teknolojisidir, hipervizör değildir. Her OpenVZ konteyneri ana bilgisayarın Linux çekirdeğini paylaşır, bu da farklı bir çekirdek sürümü çalıştıramayacağınız, özel çekirdek modülleri yükleyemeyeceğiniz ve Linux olmayan bir işletim sistemi çalıştıramayacağınız anlamına gelir. Ödün, yoğunluktur: VM başına çekirdek ek yükü olmadığından, bir OpenVZ ana bilgisayarı aynı donanıma daha fazla konteyner sıkıştırabilir, bu da düşük seviyeli paylaşımlı VPS planlarının sıklıkla kullanmasının nedenidir. VMware ESXi, Tip-1 sanallaştırma için kurumsal standarttır ancak tarihsel olarak emtia VPS hosting'inden fiyatını çıkaran soket başına lisanslama ile kapalı kaynak bir ürün olarak gönderilir. Hyper-V, Windows sunucu ortamlarında baskındır ve Active Directory ile System Center'a sıkı bir şekilde entegre olur ancak Linux ağırlıklı hosting filoları için daha az yaygın bir seçimdir. KVM, açık kaynak olduğu, çekirdek ana hatlı olduğu, x86_64 veya aarch64'te çalışan herhangi bir konuk işletim sistemini desteklediği ve olgun bir yönetim ekosistemine (libvirt, oVirt, Proxmox, OpenStack Nova) sahip olduğu için modern VPS hosting için varsayılan haline gelmiştir.
VPS için KVM neden modern varsayılan
KVM, her müşteriye VMware tarzı lisanslama ödemeden gerçek, izole bir çekirdek verdiği için baskın VPS teknolojisi haline geldi. Linux, Windows, BSD ve Solaris konuklarını destekler, emtia x86_64 ve ARM donanımında çalışır ve her büyük bulut orkestrasyon yığınına entegre edilmiştir — OpenStack, Proxmox VE, KubeVirt aracılığıyla Kubernetes ve AWS Nitro'nun tümü buna dayanır.
Üç güç KVM'yi standart yapmak için bir araya geldi. İlk olarak, donanım sanallaştırma uzantıları evrensel hale geldi: Intel VT-x 2006'da Core 2 yongalarda ve AMD-V erken Athlon 64'lerde piyasaya sürüldü, böylece 2010'ların başına kadar neredeyse her sunucu CPU'su KVM'yi yerel hıza yakın çalıştırabildi. İkinci olarak, Linux topluluğu Xen tarzı paravirtualizasyonu ana hatta benimsemeyi reddetti, ancak 2007'de KVM'yi ana hatladı ve her dağıtıma anında yerleşik bir hipervizör verdi. Üçüncü olarak, kamu bulutu ekosistemi yoğun yatırım yaptı: Google Cloud Engine KVM üzerinde başlatıldı, AWS Xen'den KVM tabanlı Nitro mimarisine geçti ve OpenStack referans hipervizör olarak KVM'yi standartlaştırdı. Daha küçük VPS sağlayıcıları bu yerçekiminden yararlanır çünkü hyperscaler filolarını çalıştıran aynı araç seti — libvirt, virtio sürücüleri, cloud-init — tek bir emtia sunucu rafında da çalışır.
Gerçek performans özellikleri: CPU steal, IO ve ek yük
Düzgün şekilde sağlanan bir KVM ana bilgisayarda, bare metal'e karşı tek haneli yüzde CPU ek yükü, yerel ağ yollarına eklenen milisaniye altı ağ gecikmesi ve virtio-blk veya virtio-scsi paravirtualize bir sürücü ile kullanıldığında yerel disk IOPS'unun %80-95'ini bekleyin. %5'in üzerinde sürekli CPU steal süresi, ana bilgisayar aşırı taahhüdünün ve güçlü bir yükseltme sinyalinin kanonik işaretidir.
Üretimde bir KVM konuğu için üç sayı önemlidir. /proc/stat'ta sekizinci alan olarak açığa çıkan CPU steal süresi, sanal CPU'nun çalışmaya hazır olduğu ancak fiziksel CPU'nun diğer konukları yürütmekle meşgul olduğu sürenin yüzdesini ölçer. %1-2'nin altındaki herhangi bir şey normal arka plan gürültüsüdür; %5'in üzerindeki sürekli değerler, ana bilgisayarın aşırı taahhüt edildiği ve iş yükünüzün kısıtlandığı anlamına gelir. iostat ve top gibi araçlarla yüzeye çıkan IO wait, CPU'nun disk veya ağda bloke olarak geçirdiği sürenin yüzdesini ölçer. Virtio paravirtualize sürücüleri ve modern NVMe yedekleme depolama ile, CPU yoğun olması gereken bir iş yükünde %20'nin üzerinde sürekli IO wait, disk alt sisteminin doyduğunun güçlü bir işaretidir. virtio-net üzerindeki ağ verimliliği, fiziksel NIC'in hat hızının %80-95'ine ulaşmalıdır; bunun önemli ölçüde altındaki herhangi bir şey, yanlış yapılandırılmış bir offload veya eski bir öykünmeli e1000 sürücüsünü işaret eder.
KVM ne ZAMAN kullanılmamalı
KVM üç durumda yanlış seçimdir: VM başına çekirdek ek yükünün baskın olduğu ultra yüksek yoğunluklu konteynerleştirilmiş iş yükleri, Hyper-V'nin SPLA fiyatlandırmasının önemli ölçüde daha ucuz olduğu Windows lisanslamasına duyarlı kurulumlar ve SR-IOV veya GPU geçişinin belirli NIC veya GPU modelinizde kötü desteklendiği belirli düşük gecikmeli donanım geçişi senaryoları.
Çekirdek izolasyonu gerektirmeyen konteynerleştirilmiş mikro hizmetler için, doğrudan bare metal üzerinde çalışan Linux konteynerleri (Docker, Podman, Kubernetes), her konteynerin yalnızca ad alanları ve cgroup'lara sahip bir süreç grubu olduğundan herhangi bir KVM tabanlı VPS'i 3-5 kat geçecektir. Yoğunluğa duyarlı düşük maliyetli VPS sağlayıcıları aynı nedenle tarihsel olarak OpenVZ'yi seçmiştir. Windows ağırlıklı kurulumlar — özellikle SPLA aracılığıyla satın alınan Windows Server lisanslarını çalıştıranlar — Microsoft'un rakip hipervizörlerde konuk lisanslarını fiyatlandırma şekli nedeniyle bazen Hyper-V'de KVM'den önemli ölçüde daha az öderler. Son olarak, belirli donanım geçişi senaryoları KVM'de hâlâ acılıdır: GPU geçişi IOMMU gruplarının temiz bir şekilde izole edilmesini gerektirir, bazı tüketici NIC'lerinin SR-IOV desteği yoktur ve NVMe sürücülerinin PCIe geçişi bazen sıfırlama hatası geçici çözümlerini tetikler. Genel amaçlı Linux VPS iş yüklerinin %95'i için bunların hiçbiri geçerli değildir ve KVM doğru varsayılandır.
Bir VPS'in gerçekten KVM tabanlı olduğu nasıl doğrulanır
Bir Linux konuğu içinde `systemd-detect-virt` çalıştırın — `kvm` yazdırmalıdır. `lscpu` ('Hypervisor vendor' satırı 'KVM' olmalıdır) ve `dmesg | grep -i kvm` ile çapraz kontrol edin. Bunun yerine 'OpenVZ', 'lxc' veya 'VMware' görüyorsanız, sağlayıcınız pazarlama aksini iddia etse bile farklı bir teknoloji kullanıyor demektir.
Sözleşme imzalamadan önce, bir deneme VPS'inde küçük bir tanılama bataryası çalıştırın. Kanonik algılama çıktısı için `systemd-detect-virt` çalıştırın. Donanım sanallaştırma uzantılarının geçirildiğini onaylamak için `cat /proc/cpuinfo | grep -E 'vmx|svm'` çalıştırın (bazı sağlayıcılar bunları sıyırır, iç içe sanallaştırmayı bozar). Paylaşılan bir ana bilgisayar çekirdeği yerine konuk-özel bir çekirdek gördüğünüzü doğrulamak için `uname -r` çalıştırın — gerçek bir KVM VPS'inde `apt install linux-image-...` veya `dnf install kernel-...` aracılığıyla farklı bir çekirdek kurabilir ve içine yeniden başlatabilirsiniz. OpenVZ'de yapamazsınız. Son olarak `/proc/user_beancounters`'ı kontrol edin — bu dosya varsa, pazarlama metni ne derse desin ana bilgisayar OpenVZ çalıştırıyor demektir.