VMware ve Proxmox Karşılaştırması

VMware ve Proxmox karşılaştırması son yıllarda teknik bir merak olmaktan çıkıp bütçe toplantılarının konusu hâline geldi. VMware'in lisans modelinin yeniden yapılandırılması, yıllardır vSphere kullanan ekipleri "aynı işi başka nasıl yaparız" sorusuna itti ve akla gelen ilk isim genellikle Proxmox VE oldu. Ancak bu iki platformu yan yana koymak, elma ile elmayı karşılaştırmak değil; mimarileri, ekosistemleri ve seni bekleyen operasyonel yük birbirinden hayli farklı.

Bu yazıda pazarlama başlıklarına girmeden, iki platformu gerçekten ayıran noktaları anlatacağım: mimari fark, lisans ve maliyet, küme özelliklerinin gerçekte ne kadarını aldığın, depolama yaklaşımları, yedekleme, otomasyon ve — pratikte en çok sorulan — mevcut VMware sanal makinelerini Proxmox'a taşıma adımları. Sonunda hangi durumda hangisinin daha doğru olduğunu net bir listeye bağlayacağım.

İki Platformun Temel Mimarisi#

VMware ESXi, sıfırdan hipervizör olmak için yazılmış kapalı kaynaklı bir çekirdektir (VMkernel). Altında bir Linux dağıtımı yoktur; içine paket kuramaz, genel amaçlı bir sistem gibi kullanamazsın. Bu, yüzey alanını küçük ve davranışını öngörülebilir tutar ama esnekliği de kısıtlar. Yönetim tek host'ta Host Client, birden fazla host'ta ise ayrı bir sunucu olan vCenter üzerinden yapılır.

Proxmox VE ise bir Debian kurulumunun üzerine oturur. Sanallaştırmayı Linux çekirdeğinin kendi hipervizörü olan KVM ile, konteynerleri ise LXC ile yapar. Yani altında tam bir Linux sistemi vardır: SSH ile girer, apt ile paket kurar, kendi izleme ajanını çalıştırırsın. Web arayüzü her düğümün 8006 portunda çalışır ve — burası kritik fark — küme yönetimi için ayrı bir merkezî sunucu gerekmez. Düğümler corosync ile birbirine bağlanır ve hangi düğümün arayüzüne girersen gir tüm kümeyi yönetirsin.

Bu tek mimari farkın pratik sonucu büyüktür. VMware'de merkezî yönetim ayrı lisanslanan, ayrı kaynak tüketen, ayrı yedeklenen bir bileşendir; ne zaman gerektiğini vCenter nedir, ne zaman gerekir yazısında ayrıntılı anlattım. Proxmox'ta ise küme yeteneği zaten kurduğun yazılımın içindedir.

Lisanslama ve Gerçek Maliyet#

Maliyet karşılaştırmasında en sık yapılan hata, Proxmox'u "bedava" saymaktır. Doğrusu şu: Proxmox VE'nin tüm özellikleri lisanstan bağımsız olarak açıktır — canlı göç, küme, HA, yedekleme, hepsi. Abonelik satın aldığında aldığın şey kurumsal yazılım deposuna (enterprise repo) erişim ve üretici desteğidir. Abonelik almazsan no-subscription deposunu kullanır, güncellemeleri yine alırsın; arayüzde bir hatırlatma penceresi çıkar ve destek talebi açamazsın. Yani özellik kilidi yoktur, destek ve güncelleme kanalı farklıdır.

VMware tarafında ise durum tersidir: lisans seviyesi doğrudan hangi özellikleri kullanabileceğini belirler. Dağıtık sanal switch, gelişmiş kaynak yönetimi ve bazı depolama özellikleri üst paketlerde açılır; vCenter ayrıca lisanslanır. Buna karşılık aldığın şey de gerçektir: geniş bir uyumluluk listesi, kurumsal destek zinciri ve neredeyse her yedekleme/izleme/otomasyon ürününün ilk gün desteklediği bir platform.

Son satırı hafife alma. Bir platformun toplam maliyeti lisans bedeli değil, onu işletecek kişinin zamanıdır. VMware bilen bir sistem yöneticisi bulmak Türkiye'de belirgin biçimde daha kolaydır.

Özellik Karşılaştırması#

İki platformun günlük operasyonda karşına çıkan yeteneklerini yan yana koyalım:

Tabloda dikkat çeken iki satır var. Birincisi, otomatik yük dengeleme VMware'in net üstünlüğüdür; Proxmox'ta karşılığı topluluk betikleri ya da elle müdahaledir. İkincisi, donanım uyumluluğu Proxmox'un net üstünlüğüdür: altında standart bir Linux çekirdeği olduğu için, Linux'un tanıdığı hemen her ağ kartı ve depolama denetleyicisi çalışır. ESXi'de aynı donanım "desteklenmiyor" diye kurulumu durdurabilir; bu konuya VMware ESXi kurulumu yazısında ayrıntısıyla değindim.

Depolama Yaklaşımları#

VMware, yerel ve paylaşımlı disklerde kendi dosya sistemi olan VMFS'i kullanır; yazılımsal dağıtık depolama için vSAN'ı ayrı bir ürün olarak konumlar. Yaklaşım tektip ve öngörülebilirdir.

Proxmox ise Linux'un tüm depolama seçeneklerini önüne serer ve seçimi sana bırakır: LVM-thin, ZFS, Ceph RBD, NFS, iSCSI, doğrudan dizin. Bu esneklik güçlü ama aynı zamanda sorumluluk demektir, çünkü seçtiğin depolama snapshot davranışını doğrudan belirler. Örneğin ZFS ve LVM-thin üzerinde anlık snapshot alabilirsin; ham LVM üzerinde alamazsın. Depolama durumunu komut satırından şöyle görürsün:

# Tanımlı depolama havuzlarını ve doluluklarını listele
pvesm status

# ZFS havuzunun sağlığını kontrol et
zpool status -v

# Bir sanal makinenin disklerini göster
qm config 100 | grep -E "scsi|virtio|ide"

ZFS seçersen kontrol toplamları, sıkıştırma ve ucuz snapshot'lar hediye gelir ama bellek ister; Ceph seçersen üç düğümden başlayan gerçek bir dağıtık depolama kurarsın ama ağ tasarımını ciddiye alman gerekir. Disklerin fiziksel sağlığını izlemek her iki platformda da senin işin; SMART ve RAID ile disk arızası tespiti yazısındaki kontrolleri hipervizör düğümlerinde de düzenli çalıştır.

Yedekleme Farkı#

Bu, iki platform arasındaki en somut ayrımlardan biri. VMware'in kutudan çıkan bir yedekleme çözümü yoktur; sanal makineleri yedeklemek için üçüncü taraf bir ürün alırsın ve bu ürün genellikle lisans bedelinin ciddi bir kısmını oluşturur.

Proxmox'ta vzdump zaten kuruludur ve zamanlanmış yedekleri arayüzden tanımlarsın. Ayrıca ücretsiz olan Proxmox Backup Server ile artımlı, tekilleştirilmiş (deduplicated) ve doğrulanabilir yedekler alırsın:

# Tek bir VM'i snapshot modunda yedekle
vzdump 100 --storage yedek --mode snapshot --compress zstd

# Tüm kümedeki makineleri yedekle, iki gün öncesinden eskileri temizle
vzdump --all --storage yedek --mode snapshot --prune-backups keep-daily=7

# Yedekten geri dönme
qmrestore /var/lib/vz/dump/vzdump-qemu-100.vma.zst 150

Burada kritik bir kavram karışıklığını netleştireyim: snapshot yedek değildir, hiçbir platformda. Snapshot aynı depolama üzerinde bir zaman noktası tutar; disk ölürse snapshot da ölür. Ayrıntısı için sanal makine snapshot yönetimi yazısına bak. Yedekleme sürecini tamamen dışarı vermek istersen yedekleme hizmetimiz de bu boşluğu doldurur.

Otomasyon ve Yönetim Deneyimi#

VMware'in API'si olgun ve neredeyse her otomasyon aracı tarafından destekleniyor; PowerCLI ile yıllardır yazılmış hazır betik havuzu çok geniş. Proxmox ise REST API'sini ve pvesh aracını sunar; Terraform ve Ansible tarafında sağlayıcılar mevcut ama topluluk kaynaklı oldukları için sürüm geçişlerinde daha dikkatli olman gerekir.

Günlük komutlar tarafında Proxmox, Linux'a alışkın bir yönetici için çok tanıdıktır:

# Sanal makineleri listele
qm list

# Bir makineyi başlat / durdur
qm start 100
qm shutdown 100

# LXC konteynerleri
pct list

# Küme durumu ve düğüm sağlığı
pvecm status

# API üzerinden düğüm bilgisi
pvesh get /nodes

Sunucu yapılandırmasını kod olarak yönetiyorsan iki platform da bunu destekler; Ansible tarafında nasıl kurgulayacağını Ansible ile sunucu otomasyonu yazısında bulabilirsin.

Hangi Durumda Hangisi#

Proxmox'a yönel eğer: bütçe baskın kriterse; ekibin Linux'a hâkimse; donanımın ESXi'nin uyumluluk listesinde değilse; konteyner ve sanal makineyi aynı platformda çalıştırmak istiyorsan; yedeklemeyi ek lisans almadan çözmek istiyorsan; ya da kurduğun sistem üzerinde tam kontrol istiyorsan.

VMware'de kal ya da VMware'i seç eğer: mevcut yatırımın ve ekip bilgin zaten oradaysa; kurumsal destek sözleşmesi bir gereklilikse; kullandığın yedekleme, izleme veya güvenlik ürünleri yalnızca vSphere ile entegre çalışıyorsa; büyük ölçekte otomatik yük dengelemeye (DRS) ihtiyacın varsa; ya da denetim/uyumluluk süreçlerin belirli bir platformu şart koşuyorsa.

Üçüncü bir yol da var: sanallaştırma katmanını hiç işletmemek. Kaynağı hazır alıp hipervizör bakımını dışarıda bırakmak istiyorsan bulut sunucu ve VDS paketleri bu işi çözer. İkisi arasındaki farkı merak ediyorsan bulut sunucu mu VDS mi yazısı karar vermene yardımcı olur.

VMware'den Proxmox'a Taşıma#

Geçiş yapmaya karar verdiysen sıra doğru olduğunda iş şaşırtıcı derecede düzgün ilerler. Kritik nokta, sanal makineyi kapatmadan önce misafir işletim sistemini hazırlamaktır:

1. Windows makinelerde önce VirtIO sürücülerini kur; aksi hâlde disk denetleyicisi değişince makine mavi ekranla açılmaz.
2. VMware Tools'u kaldır. Linux'ta open-vm-tools paketini kaldırıp qemu-guest-agent kur.
3. Ağ yapılandırmasını not al; MAC adresi değişeceği için sabit IP tanımları yeni arayüz adına taşınmalı.
4. Makineyi düzgün kapat ve ESXi datastore'undan .vmdk dosyalarını Proxmox düğümüne kopyala.
5. Proxmox'ta boş bir sanal makine oluştur (disk ekleme), sonra diski içeri al:

# VMDK'yı doğrudan hedef VM'e ve depolama havuzuna aktar
qm importdisk 150 /root/tasima/sunucu-flat.vmdk local-lvm --format qcow2

# İçeri alınan diski SCSI denetleyiciye bağla (VirtIO SCSI önerilir)
qm set 150 --scsihw virtio-scsi-single --scsi0 local-lvm:vm-150-disk-0

# Boot sırasına ekle ve makineyi aç
qm set 150 --boot order=scsi0
qm start 150

6. Açılıştan sonra sürücüleri, ağ arayüz adını ve servisleri doğrula; misafir ajanın çalıştığını qm agent 150 ping ile kontrol et.

Taşımayı bir seferde değil, önce test makineleriyle yapmanı öneririm. Aynı mantık web sitesi taşımalarında da geçerlidir; sunucu değişikliğinde DNS tarafında ne olacağını DNS değişti, site eski sunucuda açılıyor yazısında anlattım.

Sıkça Sorulan Sorular#

Proxmox gerçekten ücretsiz mi#

Evet, Proxmox VE'nin tüm özellikleri lisans satın almadan kullanılabilir; küme, canlı göç, HA ve yedekleme dahil hiçbir özellik kilitli değildir. Abonelik satın aldığında aldığın şey kurumsal güncelleme deposuna erişim ve üretici desteğidir. Üretim ortamında abonelik almak, daha yavaş ve daha çok test edilmiş bir güncelleme kanalına geçmek anlamına geldiği için genellikle mantıklıdır.

Proxmox üretim ortamı için yeterince kararlı mı#

Evet. KVM ve LXC, Linux çekirdeğinin uzun yıllardır üretimde kullanılan bileşenleridir; Proxmox bunların üzerine bir yönetim katmanı koyar. Kararlılık sorunu genellikle platformdan değil, yanlış depolama seçiminden, yetersiz ağ tasarımından ya da abonelik almayıp test edilmemiş depodan güncelleme yapmaktan çıkar. Bunları doğru kurduğunda kurumsal iş yükleri sorunsuz çalışır.

VMware sanal makinelerimi Proxmox'a taşımak ne kadar sürer#

Tek bir makine için işlemin kendisi, disk boyutuna ve kopyalama hızına bağlı olarak genellikle bir saat civarındadır. Asıl süreyi belirleyen hazırlık aşamasıdır: Windows makinelerde VirtIO sürücülerinin önceden kurulması, ağ ayarlarının not alınması ve test edilmesi. Onlarca makineli bir ortamda geçişi haftalara yayıp gruplar hâlinde ilerlemek en güvenli yaklaşımdır.

Proxmox'ta vMotion karşılığı var mı#

Evet, Proxmox küme içindeki düğümler arasında canlı göç yapabilir ve bu özellik ek lisans gerektirmez. Paylaşımlı depolama (Ceph, NFS, iSCSI) kullanıyorsan göç yalnızca bellek durumunu taşır ve saniyeler sürer. Yerel disk kullanıyorsan diski de kopyalayan göç mümkündür ama belirgin biçimde daha uzun sürer ve ağ trafiği yaratır.

Hangisi daha iyi performans verir#

Aynı donanımda ikisi de donanım sanallaştırma özelliklerini kullandığı için ham performans farkı çoğu iş yükünde ölçülebilir ama küçüktür. Farkı yaratan platform değil, yapılandırmadır: paravirtual disk ve ağ sürücüleri kullanıp kullanmadığın, depolama katmanının tipi, misafir ajanın kurulu olup olmaması. Yanlış yapılandırılmış bir VMware makinesi, doğru yapılandırılmış bir Proxmox makinesinden çok daha yavaş çalışır.

Aynı ortamda ikisini birlikte kullanabilir miyim#

Evet ve geçiş dönemlerinde yaygın bir yaklaşımdır. İki platformu ayrı kümeler olarak çalıştırıp iş yüklerini kademeli taşırsın. Dikkat etmen gereken şey yönetim yükünün ikiye katlanmasıdır: iki farklı yedekleme akışı, iki farklı izleme kurgusu ve iki farklı yama takvimi anlamına gelir. Bu yüzden birlikte yaşatmayı kalıcı bir durum değil, planlı bir geçiş penceresi olarak kurgula.

Kapanış#

Bu karşılaştırmanın özeti şu: Proxmox lisans maliyetini ortadan kaldırır ve sana Linux'un tüm esnekliğini verir, karşılığında daha fazla karar ve daha fazla sorumluluk ister. VMware ise kararların çoğunu senin yerine vermiş, geniş bir ekosistem ve destek zinciri sunar, karşılığında ciddi bir lisans bedeli ister. Aklında kalması gereken dört şey: özellik listesi yerine hangi özelliği gerçekten kullandığına bak; toplam maliyete personel zamanını da kat; depolama seçimi platformdan daha belirleyicidir; ve geçişi tek seferde değil, test makineleriyle başlayarak kademeli yap.

Hangi platformu seçersen seç, altında sağlam bir donanım olması gerekir. Kendi hipervizörünü kurmak için dedicated sunucu paketlerimize ya da kendi donanımını getireceksen colocation seçeneğimize bakabilirsin. Sanallaştırma katmanıyla hiç uğraşmadan kaynak kullanmak istersen VDS ve bulut sunucu paketlerimiz hazır teslim edilir; işletim yükünü paylaşmak istersen sunucu yönetimi hizmetimiz devreye girer.