Sanallaştırma Rehberi: Fiziksel, Sanal Makine mi Konteyner mi?

Kısa cevap: Sanallaştırma, tek bir fiziksel makinenin kaynaklarını birden fazla bağımsız sisteme bölen katmandır ve karar üç seçenek arasında verilir. Farklı çekirdek, tam izolasyon veya Windows gerekiyorsa sanal makine; aynı çekirdeği paylaşabilen, hızlı açılıp kapanan uygulamalar için konteyner; tek bir yükün donanımın tamamını kullandığı durumlarda fiziksel makine. Çoğu üretim kurulumunda üçü birlikte bulunur.

Sanallaştırma tam olarak ne yapar?

Sanallaştırma, fiziksel donanımın kaynaklarını yazılım katmanıyla bölerek birden fazla bağımsız sistemin aynı makinede çalışmasını sağlar. Faydası üç başlıkta somutlaşır:

• Kaynak verimliliği: Tek bir servis için alınmış bir sunucu genellikle kaynağının küçük bir kısmını kullanır. Sanallaştırma, boşta duran kapasiteyi başka iş yüklerine açar.
• İzolasyon: Bir sistemin çökmesi, dolan diski veya hatalı güncellemesi diğerlerini etkilemez. Servisleri ayırmak, en ucuz güvenilirlik yatırımıdır.
• Taşınabilirlik ve geri alınabilirlik: Sanal makine bir dosyadır. Başka donanıma taşınır, yedeklenir ve en önemlisi snapshot ile geri alınır.

Üçüncü madde tek başına sanallaştırmaya geçmenin en güçlü gerekçesidir. Fiziksel bir makinede riskli bir sürüm yükseltmesi denemek cesaret ister ve geri dönüş yolu genellikle yeniden kurulumdur. Snapshot alınmış bir sanal makinede aynı işlem, iki dakika içinde geri alınabilecek bir denemeye dönüşür. Sanal ortamdaki bu avantajı MikroTik CHR yazısında router tarafında da anlatmıştım; mantık aynıdır.

Tip 1 ve tip 2 hipervizör: hangisi nerede?

Hipervizör, sanal makineleri çalıştıran katmandır ve iki türü vardır.

	Tip 1 (bare metal)	Tip 2 (hosted)
Nerede çalışır	Doğrudan donanım üzerinde	Bir işletim sisteminin üstünde
Örnekler	Proxmox VE, VMware ESXi, Hyper-V Server, XCP-ng	VirtualBox, VMware Workstation, UTM
Performans	Yüksek (araya katman girmez)	Daha düşük
Saldırı yüzeyi	Küçük	Ana işletim sistemi kadar büyük
Kullanım	Üretim sunucusu	Geliştirme, test, masaüstü lab

Üretim için cevap her zaman tip 1’dir. Tip 2 hipervizörler, altlarındaki işletim sisteminin tüm güncelleme, yeniden başlatma ve güvenlik yükünü de taşır: masaüstü işletim sisteminizin bir güncellemesi, üzerindeki tüm sanal makineleri yeniden başlatmayı gerektirebilir.

Bir ara durum kafa karıştırır: Proxmox VE aslında bir Debian kurulumunun üzerine gelir, o hâlde tip 2 değil midir? Değildir. Proxmox’ta sanallaştırma işini çekirdeğin içindeki KVM modülü yapar; Debian katmanı yönetim arayüzü ve araçları taşır, paketlerin arasına girmez. Sanal makine doğrudan donanım destekli sanallaştırma üzerinden çalışır.

Proxmox, VMware, Hyper-V ve XCP-ng: hangisi seçilmeli?

Ölçüt	Proxmox VE	VMware ESXi	Hyper-V	XCP-ng
Lisans	Açık kaynak, destek aboneliği isteğe bağlı	Ticari	Windows Server lisansına bağlı	Açık kaynak
VM + konteyner tek arayüz	Var (KVM + LXC)	Yok (yalnız VM)	Yok (yalnız VM)	Yok
Yedekleme	Dahili + Proxmox Backup Server	Ayrı ürün/üçüncü taraf	Windows araçları	Ayrı araç
Kümeleme	Dahili, küçük ölçekte kolay	Güçlü, ticari katman	Failover cluster	Var
Windows misafir desteği	İyi (VirtIO sürücüleriyle)	Çok iyi	En iyi	İyi
Ekosistem genişliği	Orta	En geniş	Microsoft merkezli	Dar
Öğrenme eşiği	Orta (Linux bilgisi gerekir)	Orta	Windows yöneticisi için düşük	Orta

Seçim kuralım:

• Ağırlıklı Linux iş yükü, maliyet duyarlı, ekip Linux’a hakim: Proxmox VE. Konteyner ve sanal makineyi tek arayüzde yönetmek, küçük ve orta ölçekte gerçek bir avantajdır.
• Ağırlıklı Windows ve Active Directory merkezli ortam: Hyper-V. Lisans zaten alınmışsa ek maliyet çıkarmaz.
• Büyük kurumsal ortam, mevcut VMware yatırımı, ticari destek zorunluluğu: VMware.

Proxmox’a karar verdiyseniz kurulumun tamamı Proxmox VE kurulum rehberinde, ağ tarafı Proxmox ağ yapılandırması yazısında.

Sanal makine mi konteyner mi kullanmalı?

Bu, kümenin en pratik sorusudur. İkisi de “izole çalıştırma” vaat eder ama teknik olarak temelden farklıdır: sanal makine kendi çekirdeğini çalıştırır, konteyner ana sistemin çekirdeğini paylaşır.

Ölçüt	Sanal makine (KVM)	Konteyner (LXC / Docker)
Çekirdek	Kendi çekirdeği	Ana sistemin çekirdeği
Açılış süresi	Onlarca saniye ile dakikalar	Saniyeler
Disk maliyeti	Gigabaytlar	Megabaytlar ile yüzlerce megabayt
Bellek maliyeti	Sabit ayrılır	Yalnız kullanılan kadar
İzolasyon	Güçlü (donanım seviyesinde)	Daha zayıf (çekirdek paylaşımlı)
Farklı işletim sistemi	Var (Windows, BSD, farklı çekirdek)	Yok (aynı çekirdek ailesi)
Çekirdek modülü yükleme	Mümkün	Genellikle mümkün değil
Canlı göç	Var	Sınırlı

Karar için üç soru yeterlidir:

1. Farklı bir işletim sistemi veya çekirdek gerekiyor mu? Evetse sanal makine. Windows, pfSense, farklı çekirdek sürümü gerektiren yükler burada.
2. Güvenlik sınırı ne kadar sert olmalı? Farklı müşterilere ait iş yüklerini aynı makinede çalıştırıyorsanız sanal makine kullanın. Konteyner izolasyonu çekirdek üzerinden atlatılabilir; sanal makinede bunun için hipervizörü aşmak gerekir.
3. Hızlı ölçeklenme ve düşük kaynak önemli mi? Evetse konteyner. Onlarca küçük servisi ayrı sanal makinelerde çalıştırmak bellek israfıdır.

Pratikte doğru cevap genellikle karışımdır: hipervizör üzerinde birkaç sanal makine, birinde uygulama konteynerleri, birinde veritabanı, birinde yönetim araçları. Konteyner tarafındaki seçimi (LXC mi Docker mı) ayrıca LXC, Docker ve sanal makine karşılaştırmasında derinleştirdim; Docker’ın üretim yapılandırması ise Docker Compose üretim rehberinin konusu.

Kaynak planlaması: fazladan tahsis nerede biter?

Sanallaştırmanın en sık yapılan hatası, kaynakları kağıt üzerinde toplamaktır. Üç kaynak üç farklı davranır.

CPU: fazladan tahsis edilebilir. Sanal makineler çekirdeklerini aynı anda tam kullanmaz. Fiziksel çekirdek başına iki ila üç sanal çekirdek makul bir başlangıçtır; yük profiline göre daha yükseğe çıkılabilir. Asıl izlenecek metrik çekirdek sayısı değil, ana sistemdeki CPU bekleme süresidir: sanal makineler çalışmak için sıra bekliyorsa oran fazla demektir.

Bir tuzak: bir sanal makineye ihtiyacından fazla çekirdek vermek, o makineyi hızlandırmaz, yavaşlatabilir. Hipervizör, sanal makinenin tüm çekirdeklerini eşzamanlı olarak planlamak zorundadır; sekiz çekirdekli bir sanal makine, sekiz fiziksel çekirdek aynı anda boşalana kadar bekler. Küçük yükler için iki çekirdek, çoğu durumda sekiz çekirdekten hızlıdır.

Bellek: fazladan tahsis riskli. Bellek gerçekten tükendiğinde ana sistem takas alanına düşer veya süreçleri sonlandırır; sonuç, üzerindeki tüm sanal makineleri etkileyen bir çöküştür. Kural: tüm sanal makinelerin belleği toplamı fiziksel belleğin altında kalmalı ve ana sisteme en az birkaç gigabayt ayrılmalıdır. ZFS kullanıyorsanız önbellek için ayrıca ciddi miktarda bellek ayırmanız gerekir; bu, Proxmox kurulumlarında en sık gözden kaçan kalemdir.

Disk: darboğazın gerçek yeri. Sanallaştırmada performans şikayetlerinin çoğu CPU veya bellekten değil, disk giriş çıkışından gelir. On sanal makine aynı diske yazdığında toplam IOPS bölüşülür. Üretim sanallaştırmasında SSD tercih edilir; dönen disk kullanılacaksa sanal makine sayısı buna göre sınırlanır.

Bu üç kalemi çalışırken izlemek şarttır; eşikler ve araç seçimi için sunucu izleme rehberine bakın.

Sanallaştırmada snapshot ile yedek arasındaki fark nedir?

Bu ayrımı yapmamak, sanallaştırmadaki en pahalı hatadır.

• Snapshot, sanal makinenin belirli bir andaki durumunu aynı depolama üzerinde işaretler. Anlıktır, ucuzdur, riskli bir işlemden önce alınır ve işlem bitince silinir.
• Yedek, sanal makinenin başka bir ortama alınmış tam kopyasıdır.

Kritik sonuç: snapshot yedek değildir. Depolama arızalanırsa snapshot da onunla gider. Snapshot’ı uzun süre tutmak ayrıca performansı düşürür ve depolamayı şişirir; kullan ve sil mantığıyla çalışır.

Doğru kurgu ikisini birlikte kullanır: riskli güncelleme öncesi snapshot, düzenli olarak da farklı bir ortama yedek. Proxmox tarafındaki tam kurulum (zamanlanmış yedek, Proxmox Backup Server, geri yükleme testi) Proxmox yedekleme ve snapshot rehberinde.

Sanallaştırmaya nereden başlanmalı?

Sanallaştırmaya yeni geçiyorsanız önerdiğim sıra:

1. Donanımı doğrulayın. CPU’da donanım destekli sanallaştırma (Intel VT-x veya AMD-V) açık olmalı; BIOS’ta kapalı gelmesi yaygındır. Mevcut bir Linux’ta kontrol: grep -Ec "vmx|svm" /proc/cpuinfo çıktısı sıfırdan büyük olmalı.
2. Hipervizörü kurun. Proxmox VE kurulum rehberi adım adım anlatıyor.
3. Ağı doğru kurun. Köprü, VLAN ve yönetim arayüzü ayrımı baştan yapılmazsa sonradan kesintiyle düzeltilir: Proxmox ağ yapılandırması.
4. İlk sanal makineyi açın ve sertleştirin. Sanal olması güvenlik gerekliliklerini değiştirmez: VPS ilk 30 dakika listesi aynen geçerlidir.
5. Yedeklemeyi kurun ve geri yüklemeyi test edin. Test edilmemiş yedek yedek değildir.
6. Uygulama katmanına geçin: Docker Compose üretim rehberi veya sürekli deploy için Coolify.

Ağ cihazlarını da sanallaştırmayı düşünüyorsanız MikroTik CHR ile Proxmox kurulumu yazısı, router tarafının aynı hipervizör üzerinde nasıl çalıştığını anlatıyor. Tüm sunucu katmanlarının haritası ise Linux sunucu yönetimi yol haritasında.

Sanallaştırmada en sık yapılan hatalar neler?

1. Ana sisteme bellek ayırmamak. Tüm belleği sanal makinelere dağıtmak, hipervizörü ilk yük artışında çökertir.
2. Tek sanal makineye gereğinden çok çekirdek vermek. Planlama gecikmesi yüzünden performans düşer.
3. Snapshot’ı yedek sanmak. Depolama gittiğinde ikisi birlikte gider.
4. Ağı sonradan düşünmek. Köprü ve VLAN yapısını sonradan değiştirmek, çalışan sanal makinelerde kesinti demektir.
5. Yedeklilik olmadan tek hipervizöre her şeyi koymak. Sanallaştırma tek noktadan arızayı yok etmez, yoğunlaştırır. Kritik servislerde ikinci bir makine veya en azından hızlı geri yükleme planı gerekir.
6. Sanal makineyi sertleştirmeyi atlamak. Sanal olmak, internete açık bir sunucuyu daha güvenli yapmaz.

Kaynaklar

• Proxmox VE Administration Guide (KVM, LXC, depolama ve küme yönetimi)
• Linux Kernel: KVM Documentation (donanım destekli sanallaştırma)
• namespaces(7) manual page (konteyner izolasyonunun çekirdek temeli)