- KVM ve OpenVZ farkı VPS seçimini nasıl değiştirir?
- Sanallaştırma katmanında ne değişiyor?
- KVM'nin çalışma biçimi
- OpenVZ'nin hafifliği nerede işe yarar?
- Kaynak yönetimi ve performans
- Güvenlikte kernel ortaklığının etkisi
- Docker, VPN ve kernel modülleri
- Kullanım senaryosuna göre seçim
- Kaynak garantisi, host arızası ve operasyon
- Satın almadan önce sorulacak sorular
- Kurulumdan sonra modeli kontrol etmek
- Ben olsam hangisini seçerim?
- Sık Sorulan Sorular
KVM ve OpenVZ farkı VPS seçimini nasıl değiştirir?
Gece vardiyasında yeni bir VPS açarken ilk baktığım yer çoğu zaman fiyat veya RAM miktarı olmuyor. Önce sanallaştırma modelini kontrol ediyorum. Çünkü ürün sayfasındaki küçük bir “KVM” ya da “OpenVZ” ifadesi, sunucunun hangi kernel’i çalıştıracağından Docker kurulumuna kadar birçok şeyi belirliyor.
İki modelde de SSH erişimi alır, Linux komutları çalıştırır ve servislerinizi barındırırsınız. Benim için KVM ve OpenVZ farkı en anlaşılır şekilde “sanal makine mi, işletim sistemi konteyneri mi?” sorusuyla açıklanabilir. KVM, fiziksel sunucunun donanımını sanal makineye sunar. OpenVZ ise aynı Linux kernel’ini kullanan izole kullanıcı alanları oluşturur.
Bu ayrım yalnızca teorik değildir. İşletim sistemi seçimi, kernel modülleri, kaynak limitleri, izolasyon, disk davranışı ve VPS’i başka bir ortama taşıma yöntemi doğrudan etkilenir. Sadece WordPress çalıştıracağınızı düşünüyorsanız bile sağlayıcının kaynak politikasını ve desteklediği özellikleri bilmeden karar vermek ileride can sıkabilir.
Sanallaştırma katmanında ne değişiyor?
Fiziksel bir sunucunun üzerinde bir hypervisor çalıştığını düşünün. Bu katman, aynı donanımın birden fazla sanal ortama bölünmesini sağlar. KVM modelinde her VPS, kendi sanal donanımına sahip bir sanal makinedir. Sanal makinenin içinde ayrı bir Linux kernel’i açılır; VPS’i yeniden başlatmanız host üzerindeki diğer makinelerin kernel’ini etkilemez.
OpenVZ’de model farklıdır. VPS’ler, ev sahibi sistemin Linux kernel’ini paylaşan konteynerlerdir. Her konteynerin kendi dosya sistemi, süreç alanı, ağ yapılandırması ve kullanıcıları bulunur. Kernel ise host’a aittir.
OpenVZ, LXC veya Docker ile birebir aynı teknoloji değildir. Ortak fikir, işletim sistemi seviyesinde izolasyondur. Bu nedenle “konteyner” kelimesini gördüğünüzde doğrudan Docker özelliklerini varsaymayın.
OpenVZ adı özellikle eski hosting altyapılarında yaygındı. Bazı sağlayıcılar bugün Virtuozzo tabanlı konteynerleri de bu adla pazarlayabiliyor. Ürün başlığından çok, kullanılan sürümü, kernel yaklaşımını ve kaynak limitlerini sormak daha sağlıklı olur. “OpenVZ” tek başına kaynak veya güvenlik garantisi değildir.
KVM’nin çalışma biçimi
KVM, Linux kernel’ine entegre bir sanallaştırma altyapısıdır. QEMU ile birlikte kullanıldığında sanal makineye CPU, RAM, disk, ağ kartı ve BIOS veya UEFI ortamı sunabilir. Fiziksel işlemcide Intel VT-x ya da AMD-V desteği gerekir; yeni sunucularda bu özellik genellikle mevcut olur.
VPS’in içine girdiğinizde gerçek bir makineye yakın bir görünümle karşılaşırsınız. Kendi kernel’inizi çalıştırabilir, initramfs oluşturabilir, desteklenen kernel modüllerini yükleyebilir ve dağıtım seçimini sağlayıcının birkaç hazır imajıyla sınırlamak zorunda kalmazsınız. Sanal donanımın izin vermediği özel işlemler yine mümkün olmayabilir, fakat konteyner modeline göre hareket alanınız daha geniştir.
KVM’nin bir maliyeti var: Her VPS için ayrı kernel ve kullanıcı alanı çalışır. Aynı fiziksel host üzerinde daha az sanal makine bulunabilir. Buna karşılık kaynak sınırlarını anlamak ve işletim sistemi davranışını diğer müşterilerden ayırmak daha kolaydır.
KVM pratikte ne kazandırır?
- Linux dağıtımı ve kernel sürümü konusunda daha fazla özgürlük sağlar.
- Windows Server gibi Linux dışı işletim sistemleri için uygun bir temel sunar.
- Docker, Kubernetes ve kernel özelliklerine ihtiyaç duyan araçlarda daha az sürpriz çıkarır.
- Bir VPS’in kernel panic veya kernel güncellemesi, diğer VPS’lerin kernel’ini doğrudan etkilemez.
- Sanal CPU, RAM ve disk kaynakları sağlayıcının politikasına bağlı olmakla birlikte daha anlaşılır biçimde tanımlanabilir.
Bu, KVM’nin fiziksel sunucu kadar hızlı olduğu anlamına gelmez. Aynı host üzerinde ciddi CPU overselling veya yoğun disk I/O varsa KVM VPS de yavaşlar. Sanallaştırma türü, kötü kaynak planlamasını düzeltmez.
OpenVZ’nin hafifliği nerede işe yarar?
OpenVZ ayrı bir kernel çalıştırmadığı için daha hafif bir modeldir. Yeni bir konteyner hızlı başlatılabilir; CPU ve bellek paylaşımı da düşük ek yükle yürütülebilir. Sağlayıcı aynı fiziksel host’a daha fazla müşteri yerleştirebilir. Kaynak planlaması düzgün yapılmışsa bu yoğunluk uygun fiyat olarak müşteriye yansıyabilir.
Paylaşılan kernel bazı kapıları kapatır. Kernel güncellemesini VPS içinden bağımsız yapamazsınız. Kullanacağınız modüllerin host kernel’inde bulunması gerekir. Özel firewall modülleri, FUSE, bazı VPN yapılandırmaları veya düşük seviyeli ağ özellikleri için sağlayıcının desteğine ihtiyaç duyabilirsiniz.
Eski OpenVZ sürümlerinde bellek ve işlemci limitleri standart Linux kaynakları gibi görünmeyebiliyordu. free -h çıktısı belleği gösterse bile gerçekten kullanılabilir miktar, konteyner limitlerine bağlı kalabiliyordu. Eski sistemlerde /proc/user_beancounters dosyası bu limitleri anlamak için önemli bir kontrol noktasıydı.
free -h
cat /proc/user_beancounters 2>/dev/null || true
systemd-detect-virt
Son komut her ortamda kusursuz sonuç vermez; hızlı bir ipucu olarak kullanırım. openvz, lxc veya kvm gibi bir değer görürseniz bunu sağlayıcının ürün açıklamasıyla karşılaştırın. İki bilgi uyuşmuyorsa destek bileti açmadan üretim yükünü taşımam.
Kaynak yönetimi ve performans
“KVM hızlı, OpenVZ yavaş” cümlesi gerçeği fazla basitleştirir. Küçük ve sabit yük altında bir OpenVZ konteyneri, aynı donanım üzerindeki KVM sanal makineden daha az ek yükle çalışabilir. Basit bir web sunucusu, küçük bir API veya düşük trafikli DNS hizmetinde bu farkı hiç fark etmeyebilirsiniz.
Yük arttığında kaynak politikası belirleyici hale gelir. KVM tarafında sanal makineye tanımlanan CPU çekirdekleri, RAM miktarı ve disk I/O sınırları önemlidir. OpenVZ tarafında burst RAM, user beancounters, CPU ağırlığı ve sağlayıcının overselling politikası devreye girebilir.
Paket sayfasındaki “4 GB RAM” ifadesini tek başına performans ölçüsü saymayın. RAM sürekli kullanılabilir bir limit mi, burst olarak mı tanımlanıyor, bunu bilmek gerekir. Bu soruyu sormadan birkaç ay önce bir test VPS’i seçmiştim; rakam doğruydu ama limit modelini yanlış anlamıştım.
Disk performansı da benzer bir hikâyedir. KVM’de sanal disk imajı, OpenVZ’de ise farklı bir dosya sistemi katmanı kullanılıyor olabilir. Fiziksel SSD veya NVMe’nin kalitesi, RAID düzeni, I/O scheduler ve komşu VPS’lerin davranışı çoğu zaman sanallaştırma isminden daha belirleyicidir.
| Kriter | KVM | OpenVZ |
|---|---|---|
| Sanallaştırma modeli | Donanım seviyesine yakın tam sanal makine | İşletim sistemi seviyesinde konteyner |
| Kernel | VPS kendi kernel’ini çalıştırır | Host kernel’i paylaşılır |
| İşletim sistemi | Linux dağıtımları ve çoğu senaryoda Windows | Host kernel’iyle uyumlu Linux ortamları |
| Kaynak yoğunluğu | Daha yüksek sanallaştırma maliyeti | Genellikle daha düşük maliyet ve yüksek yoğunluk |
| İzolasyon | Güçlü sanal makine izolasyonu | Kernel ortaklığı nedeniyle daha sınırlı izolasyon |
| Kernel modülleri | Daha geniş hareket alanı | Host desteğine bağımlı |
| Taşınabilirlik | İmaj ve dağıtım seçenekleri geniş | Aynı ekosisteme ve sürüme daha bağımlı |
Güvenlikte kernel ortaklığının etkisi
İki modelde de VPS kullanıcıları birbirinden izole edilmeye çalışılır. KVM’de ayrım sanal makine katmanında gerçekleşir. Bir müşterinin süreçleri, ağ arayüzleri ve kernel’i diğer müşterinin ortamından daha uzaktadır. OpenVZ’de güvenlik mekanizmaları güçlü olabilir, fakat bütün konteynerler aynı host kernel’ine güvenir.
“OpenVZ güvensizdir” demek doğru olmaz. Güncel ve bakımlı bir konteyner altyapısı, eski ve yanlış yapılandırılmış bir KVM host’undan daha iyi işletilebilir. Host güncellemeleri, hypervisor yamaları, ağ filtreleri, yedekleme ve izleme birlikte değerlendirilmelidir.
Sağlayıcının host kernel’ini ne sıklıkla güncellediğini sormak, ürün adını tartışmaktan daha faydalı olabilir. VPS’in içinde ise SSH anahtarı, root giriş politikası, nftables, güncellemeler ve servis bazlı erişim kontrolleri yine sizin sorumluluğunuzdadır.
SSH portunu değiştirmek güvenlik planı değildir; yalnızca log gürültüsünü azaltan küçük bir önlemdir. Linux Sunucu Güvenliği için Zorunlu 10 Temel Adım yazısındaki temel kontroller sanallaştırma türünden bağımsız olarak geçerlidir.
Docker, VPN ve kernel modülleri
VPS seçiminde sonradan sorun çıkaran başlıklardan biri Docker’dır. Docker’ın ihtiyaç duyduğu kernel özellikleri host tarafından sağlanmalıdır. KVM’de kendi Linux kernel’iniz bulunduğu için Docker kurulumu ve cgroup davranışı daha öngörülebilirdir. OpenVZ’de sağlayıcının Docker desteğini özellikle doğrulamak gerekir.
Docker kuruluyor diye bütün özelliklerin çalışacağını varsaymayın. Overlay filesystem, iptables veya nftables entegrasyonu, AppArmor ve cgroup sürümü farklı sınırlara sahip olabilir. Basit bir Nginx konteyneri açılır, fakat asıl sınav kendi imajınızın ağ ve depolama ihtiyaçlarında çıkar.
WireGuard veya OpenVPN gibi VPN hizmetlerinde de birkaç kontrol gerekir: TUN/TAP aygıtı açık mı, gerekli kernel modülü mevcut mu, UDP trafiği kısıtlanıyor mu? OpenVZ üzerinde bunlar desteklenebilir. Satın almadan önce yazılı teyit almak daha güvenlidir.
Evde Raspberry Pi 4 üzerinde WireGuard kullandığım için bu ayrıntıyı özellikle kontrol ederim. Tünelin kurulması yetmez; yönlendirme, DNS ve MTU davranışı da test edilmelidir.
Kullanım senaryosuna göre seçim
Küçük web sitesi ve basit uygulamalar
Tek bir WordPress sitesi, küçük bir Laravel uygulaması veya düşük trafikli kişisel servis için iyi yapılandırılmış OpenVZ yeterli olabilir. Sağlayıcının CPU paylaşımını, disk tipini ve yedekleme politikasını öğrenmek gerekir. Ucuz olması tek başına kötü olduğu anlamına gelmez; kaynakların nasıl tahsis edildiğini bilmeden karar vermeyin.
WordPress performansında sanallaştırma tipinden önce PHP-FPM süreç sayısı, veritabanı sorguları, sayfa önbelleği ve disk I/O öne çıkar. TTFB’yi milisaniye milisaniye tartışıp cache kurmamak, sorunu sanallaştırma teknolojisine havale etmektir.
Docker, Kubernetes ve geliştirme ortamları
Docker ile birden fazla servis çalıştıracaksanız KVM daha rahat bir başlangıçtır. Kubernetes, servis mesh’leri, özel ağ kuralları veya kernel’e yakın çalışan araçlarda da bağımsız kernel fark yaratır. OpenVZ’yi deneme amacıyla kullanabilirsiniz, fakat kapalı özellikleri baştan listeleyin.
Yeni VPS kurulumlarını tekrarlanabilir hale getirmek istiyorsanız cloud-init ve Ansible yardımcı olur. Cloud-Init Nedir? VPS Kurulumunu Otomatikleştirme yazısındaki yaklaşım elle yapılan kurulum hatalarını azaltır. İmajın sağlayıcının altyapısında gerçekten cloud-init desteklediğini de ayrıca kontrol edin.
VPN, özel kernel ve düşük seviyeli ağ ihtiyaçları
VPN gateway, özel firewall, eBPF tabanlı gözlemleme, kernel modülü veya kendi initramfs’inizi kullanma gibi ihtiyaçlarda KVM seçin. Bu servislerin bazıları OpenVZ üzerinde çalışabilir; fakat “çalışabilir” ile “sorunsuz ve desteklenen biçimde çalışır” arasında uzun bir mesafe var.
Windows veya farklı Linux dağıtımları
Windows Server çalıştırmak istiyorsanız pratikte KVM gerekir. OpenVZ’nin paylaşılan Linux kernel modeli Windows için uygun değildir. Alpine, Debian, Ubuntu veya Rocky Linux gibi farklı dağıtımları denemek isteyenler için de KVM daha esnek davranır.
Oyun sunucuları
Oyun sunucularında tek çekirdek performansı, ağ gecikmesi ve disk davranışı daha önemlidir. KVM genellikle daha öngörülebilir bir ortam sunar, fakat gerçek karar için aynı veri merkezinde test yapmak gerekir. VPS’te Minecraft Sunucusu Nasıl Kurulur? rehberindeki kurulum adımlarından önce Java sürümünü, oyuncu sayısını ve yedekleme planını da hesaba katın.
Proxmox laboratuvarımda oyun sunucusu test ederken sanallaştırma tipinden çok aynı fiziksel NVMe üzerindeki diğer işlerin etkisini gördüm. Bu nedenle sağlayıcıya “KVM mi?” sorusunun yanında “Disk I/O nasıl izleniyor ve komşu VPS izolasyonu nasıl yapılıyor?” sorusunu da yöneltirim.
Kaynak garantisi, host arızası ve operasyon
Bir müşteri ortamında yanlış sunucuya işlem yapmaya ramak kala terminal prompt’unda görünen hostname beni durdurmuştu. O günden beri üretim shell’lerinde hostname’i belirgin gösteriyorum ve yıkıcı komutlardan önce hostname çıktısını kontrol ediyorum. Sanallaştırma seçimi kadar operasyon disiplini de önemlidir.
KVM veya OpenVZ kullanmanız, fiziksel host arızasını ortadan kaldırmaz. Snapshot’ın ayrı depolamada tutulup tutulmadığı, yedeklerin hangi sıklıkta alındığı, canlı taşımanın desteklenip desteklenmediği ve arıza sırasında kimin ne yaptığı daha somut sorulardır.
Kaynak garantisi de burada devreye girer. Dedicated vCPU, paylaşımlı CPU, burst RAM ve IOPS limiti aynı şey değildir. Ürün sayfasında bu terimler açık değilse destek ekibinden yazılı açıklama isteyin.
Satın almadan önce sorulacak sorular
- VPS gerçekten KVM mi, yoksa Virtuozzo tabanlı bir konteyner mi?
- CPU çekirdekleri paylaşımlı mı, dedicated vCPU garantisi var mı?
- RAM burst olarak mı tanımlanıyor, yoksa sürekli kullanılabilir limit mi?
- Disk NVMe mi, IOPS limiti veya trafik kotası bulunuyor mu?
- Docker, WireGuard, TUN/TAP, FUSE ve özel kernel modülleri destekleniyor mu?
- Snapshot canlı alınabiliyor mu ve snapshot yedek yerine geçiyor mu?
- Host arızasında hangi kurtarma ve taşıma prosedürü uygulanıyor?
- IPv4, IPv6, ters DNS ve ek ağ adresleri için hangi kısıtlar var?
Yanıtları mümkünse destek biletiyle alın. Satış sayfasındaki genel bir “tam root erişimi” ifadesi, paylaşılan kernel üzerinde her işlemi yapabileceğiniz anlamına gelmez. Root yetkisi dosya sisteminde geniş yetki verir; host kernel’ini vermez.
Kurulumdan sonra modeli kontrol etmek
Sağlayıcının söylediğini kendi VPS’inizde kontrol etmek faydalıdır. Aşağıdaki komutlar kesin bir denetim değil, hızlı teşhis içindir:
hostnamectl
systemd-detect-virt
lscpu | grep -E 'Hypervisor vendor|Virtualization type'
ls -l /dev/kvm 2>/dev/null || true
cat /proc/version
hostnamectl işletim sistemi ve kernel bilgisini, systemd-detect-virt ise systemd’nin algıladığı sanallaştırma ortamını gösterir. /dev/kvm dosyasının bulunması VPS’in KVM üzerinde çalıştığını tek başına kanıtlamaz; nested virtualization açık bir sanal makine de bu dosyayı görebilir.
Ben bir testte yalnızca /dev/kvm dosyasını gördüğüm için yanlış sonuca varmıştım. Host bilgisi, sağlayıcı açıklaması ve diğer komutlar aynı şeyi göstermeden karar vermemek gerektiğini orada öğrendim.
Kaynak davranışını ölçmek için üretim verisi olmayan bir VPS’te kısa ve kontrollü testler yapabilirsiniz. Yoğun fio testleri komşu müşterileri etkileyebilir ve bazı sağlayıcıların kullanım koşullarını ihlal edebilir. CPU steal time, load average, disk latency ve ağ gecikmesini Uptime Kuma veya Prometheus ile birkaç gün izlemek, tek seferlik benchmark’tan daha anlamlıdır.
Ben olsam hangisini seçerim?
Genel amaçlı yeni bir VPS alıyorsam KVM’yi tercih ederim. Kendi kernel’imi güncelleme, Docker çalıştırma, gerektiğinde dağıtım değiştirme ve kaynak davranışını daha bağımsız gözlemleme ihtimali bu tercihi haklı çıkarıyor.
Yalnızca birkaç küçük web sitesi barındıracaksam, kısıtları belgelenmiş ve iyi işletilen bir OpenVZ veya Virtuozzo sağlayıcısını da elemem. Fiyat avantajı belirginse bu model mantıklı olabilir.
Windows, Kubernetes, VPN gateway, özel kernel ayarı veya daha bağımsız bir kurtarma süreci için KVM daha doğru zemindir. Yüksek erişilebilirlik gerekiyorsa iki modelin de üzerine yedek, izleme ve mümkünse ikinci bir sağlayıcı planı eklemek gerekir.
VPS kavramını yeni öğreniyorsanız VPS Nedir, Ne İşe Yarar? Başlangıç Seviyesi Detaylı Rehber ile temel ayrımları yerine oturtabilirsiniz. Fiziksel kaynak üzerinde daha fazla kontrol arıyorsanız Bare Metal Sunucu ile VPS Arasındaki Teknik Farklar da sonraki karar için iyi bir karşılaştırma noktasıdır.
Benim karar formülüm basit: Özel bir kısıt yoksa KVM; kısıtları açıkça belgelenmiş ve basit yükte maliyet avantajı belirginse OpenVZ. Satın almadan önce soracağınız birkaç teknik soru, sonradan VPS taşımaktan daha ucuzdur.
Sık Sorulan Sorular
KVM mi OpenVZ mi daha hızlıdır?
Tek bir cevap yoktur. Hafif ve sabit yüklerde OpenVZ, daha düşük sanallaştırma maliyeti sayesinde hızlı hissedilebilir. KVM ise kaynakları ve işletim sistemi ortamını daha bağımsız sunar. Gerçek performansı host’un işlemcisi, diskleri, overselling politikası ve ağ kalitesi belirler.
OpenVZ üzerinde Docker çalışır mı?
Bazı OpenVZ veya Virtuozzo altyapılarında Docker desteklenir, bazılarında gerekli kernel özellikleri kapalıdır. Satın almadan önce Docker, cgroup sürümü, overlay filesystem ve iptables veya nftables desteğini sağlayıcıdan yazılı olarak doğrulayın.
KVM VPS üzerinde Windows kurulabilir mi?
KVM, sanal makineye bağımsız sanal donanım sunduğu için Windows kurulumu için uygun seçenektir. Windows lisansı, ISO yükleme yöntemi, UEFI desteği, sürücüler ve sağlayıcının lisans politikasını ayrıca kontrol etmeniz gerekir.
OpenVZ güvenli değil mi?
Güncel ve doğru yapılandırılmış bir OpenVZ altyapısı güvenli olabilir; ancak konteynerler aynı host kernel’ini paylaşır. Bu nedenle kernel güncellemeleri, host güvenliği ve sağlayıcının izolasyon politikası hakkında KVM’ye kıyasla daha fazla soru sormak gerekir.
Türkçe
English
فارسی
Русский