Proxmox VE Nedir? Sanallaştırma, Cluster ve Yedekleme Rehberi

KVM sanal makineleri ile LXC containerları farklı izolasyon ve işletim modelleri sunar

KVM, donanım sanallaştırma desteğini kullanarak her misafir işletim sistemi için ayrı sanal donanım ve kernel çalıştırır. Windows ve Linux sunucular, üretici appliance'ları ve güçlü izolasyon isteyen uygulamalar için genel amaçlı seçenektir. Sanal makineye vCPU, bellek, disk denetleyicisi, ağ kartı ve BIOS/UEFI ayarları atanır; guest agent, shutdown, IP görünürlüğü, snapshot ve yedek tutarlılığı gibi işlevleri iyileştirebilir. LXC ise host Linux kernelini paylaşan sistem container modelidir. Daha düşük ek yük ve hızlı açılış sağlayabilir, ancak yalnız Linux iş yüklerini destekler ve kernel paylaşımı nedeniyle izolasyon, modül, ayrıcalık ve üretici desteği KVM'den farklıdır. Uygulamanın container içinde çalışması mümkün diye LXC otomatik tercih edilmez; güven sınırı, kernel gereksinimi, backup davranışı ve destek koşulu incelenir. Kritik servislerde seçim, kaynak kazancından önce hata etkisi ve kurtarma prosedürüyle yapılır.

Tek node tasarımında CPU soketi ve çekirdek, NUMA, bellek, yerel disk, RAID/ZFS, ağ portu ve genişleme payı gerçek iş yükü ölçümleriyle boyutlandırılır. Fiziksel sunucudaki toplam RAM'i sanal sunucu sayısına bölmek yeterli değildir; hypervisor payı, cache, storage servisi, anlık tepe, failover kapasitesi ve ballooning davranışı hesaba katılır. CPU overcommit iş yükü karakterine göre kontrollü yapılır. Disk kapasitesi kadar IOPS, gecikme, yazma dayanımı, yedek penceresi ve yeniden oluşturma etkisi önemlidir. ZFS veri bütünlüğü, snapshot ve replikasyon yetenekleri sunar; ancak bellek, disk topolojisi ve bakım gereksinimi doğru planlanmalıdır. Donanım RAID ile ZFS veya Ceph bileşenleri ezbere birleştirilmez. Sunucu firmware'i, HBA/NIC desteği, disk sağlık telemetrisi ve yedek parça bulunabilirliği platform uyumluluğunun parçasıdır.

İş yükü modeli

Windows/Linux desteği, kernel ihtiyacı, izolasyon, lisans, performans ve üretici desteğine göre KVM sanal makine veya LXC container seçilir.

CPU ve bellek

Tepe kullanım, overcommit, NUMA, failover payı, cache, ballooning ve host servisleri ölçülerek node kapasitesi hesaplanır.

Disk ve IOPS

Kapasite, gecikme, yazma dayanımı, RAID/ZFS düzeni, yeniden oluşturma süresi ve yedek penceresi birlikte değerlendirilir.

Donanım desteği

CPU sanallaştırma, firmware, NIC/HBA, disk sağlık verisi, sürücü, yedek parça ve destek yaşam döngüsü doğrulanır.

Misafir standardı

Guest agent, sanal donanım, zaman, shutdown, sürücü, snapshot ve uygulama tutarlılığı ortak şablona bağlanır.

Cluster ve yüksek erişilebilirlik quorum, bağımsız hata alanı ve yeterli kapasite gerektirir

Proxmox cluster, node yapılandırmasını ve yönetimini ortaklaştırır; tek arayüzden sanal makineler, containerlar, storage ve ağ görünür. Cluster iletişimi corosync üzerinden düşük gecikmeli ve kararlı bir ağ ister. Quorum, hangi node grubunun değişiklik yapmaya yetkili olduğunu belirleyerek bölünmüş beyin riskini azaltır. İki node'lu yapıda tek node veya iletişim kaybı quorum sorununa dönüşebilir; qdevice belirli topolojilerde ek oy sağlayabilir fakat üçüncü üretim node'unun kapasitesini ve arıza bağımsızlığını ikame etmez. Node sayısı, oy dağılımı, switch, ağ kartı, VLAN, MTU, gecikme ve paket kaybı kontrollü test edilir. Cluster ağı ile yönetim, storage, migration, VM ve backup trafiği aynı fiziksel bağlantıyı paylaşacaksa bant genişliği ve hata etkisi açıkça hesaplanır. Bond veya ikinci switch yalnız kablo sayısını artırmakla kalmamalı, gerçek arıza alanını azaltmalıdır.

Yüksek erişilebilirlik, bir node arızasında seçilmiş VM veya containerın başka node üzerinde yeniden başlatılmasını otomatikleştirebilir. Bu işlem kesintisiz çalışma garantisi değildir; misafir işletim sistemi ve uygulama yeniden açılır, tutarlılık kontrolü ve servis başlatma süresi vardır. Hedef node gerekli CPU, RAM, network ve storage erişimine sahip olmalıdır. Paylaşımlı storage veya uygun replikasyon modeli olmadan diske erişim mümkün olmayabilir. Fencing, arızalı node'un aynı diske yeniden yazmasını önlemek için kritik bir güvenlik mekanizmasıdır. HA grupları, öncelik, failback ve bakım davranışı uygulama sahipleriyle belirlenir. Bir node kaybı sırasında kalan node'ların normal yükü ve bakım payı karşılayıp karşılamadığı ölçülür. Cluster, storage ve UPS aynı odada ve aynı güç hattındaysa uzak felakete karşı koruma sağlamaz. HA ile felaket kurtarma ayrı hedeflerdir ve farklı testler gerektirir.

• Corosync için gecikme, paket kaybı, MTU, switch ve NIC bağımsızlığını ölçün; cluster trafiğini doygun storage veya backup akışından koruyun.
• Quorum hesabını node sayısı, oy, qdevice, bakım ve ağ bölünmesi senaryolarıyla birlikte belgeleyin.
• Bir node kaybında kalan CPU, RAM, storage IOPS ve ağ kapasitesinin kritik VM'leri gerçekten çalıştırabildiğini yük testiyle gösterin.
• HA yeniden başlatma süresini uygulamanın açılış, veritabanı tutarlılığı ve istemci yeniden bağlantı süresiyle birlikte ölçün.
• Node, switch, storage, UPS, oda ve operatör bağımlılıklarını çıkararak cluster ile felaket kurtarma kapsamını birbirinden ayırın.

Depolama seçimi performans, arıza alanı ve operasyon yetkinliğiyle eşleştirilmelidir

Proxmox VE yerel LVM/LVM-thin, directory, ZFS, NFS, iSCSI ve Ceph dahil farklı storage modellerini kullanabilir. Yerel storage sade ve düşük gecikmeli olabilir, ancak VM diskinin başka node'a erişimi için migration veya replikasyon planı gerekir. NFS veya SAN merkezi yönetim ve ortak erişim sağlar; ağ ve storage denetleyicisi ortak hata noktası oluşturmamalıdır. ZFS yerel diskte checksum, snapshot, sıkıştırma ve gönder/al gibi yetenekler sunar. Bunun karşılığında uygun disk erişimi, ECC bellek tercihi, cache davranışı, scrub, kapasite ve disk değiştirme prosedürü ister. Ceph, birden fazla node ve disk üzerinde dağıtık storage sunabilir; küçük ve kaynak sınırındaki kümelerde ek CPU, RAM, hızlı ağ, doğru failure domain ve işletim yetkinliği gereksinimi göz ardı edilmemelidir. Ürün özelliğinin bulunması her ölçekte aynı sonucu vermez. Storage kararı VM sayısı, çalışma seti, gecikme, yazma yoğunluğu, büyüme, yedekleme ve kurtarma hedefiyle yapılır.

Ağ tasarımında yönetim, corosync, migration, storage, backup ve VM trafiği mantıksal olarak ayrılır; fiziksel portların paylaşılması halinde QoS ve kapasite kanıtı gerekir. VLAN, bond, bridge ve firewall kuralları hem host hem misafir tarafında belgelenir. MTU uyumsuzluğu storage veya migration trafiğinde aralıklı ve zor teşhis edilen sorunlar üretebilir. Canlı migration, çalışan VM belleğini hedef node'a taşırken değişen bellek sayfası ve ağ kapasitesinden etkilenir; kesinti süresi gerçek yükle ölçülmelidir. Storage migration ise disk boyutu ve kaynak/hedef IOPS'a bağlıdır. Ağ veya storage üzerinde tek yüksek hızlı port bulunması yedeklilik anlamına gelmez. Switch bakımı, kablo çekilmesi, bond üyesi kaybı ve storage yolu kesintisi ayrı senaryolarda uygulanır. Tasarım dosyasında her bridge, bond, VLAN, IP, gateway, storage hedefi, kimlik bilgisi, MTU ve firewall rolü açık tutulur.

Storage modeli

Yerel, ZFS, NFS, iSCSI veya Ceph; gecikme, IOPS, ortak hata noktası, büyüme, bakım ve ekip yetkinliğiyle karşılaştırılır.

Failure domain

Disk, HBA, node, switch, storage denetleyicisi, güç ve oda arızalarının kaç VM'i etkileyeceği görünür kılınır.

Ağ ayrımı

Yönetim, corosync, migration, storage, backup ve VM ağlarının VLAN, bond, port, MTU ve kapasite planı ayrı tutulur.

Migration

Canlı ve storage migration sırasında süre, ağ tüketimi, disk gecikmesi, uygulama etkisi ve geri dönüş adımı gerçek yükte ölçülür.

Bakım

Scrub, disk değişimi, rebalance, firmware, switch bakımı ve node boşaltma işlemleri sorumlu ve zaman penceresiyle belgelenir.

Yedekleme, güvenlik ve geçiş kabulü platformdan bağımsız geri dönüş kanıtı üretmelidir

Proxmox VE bütünleşik vzdump yedekleriyle VM ve container verisini yapılandırmayla birlikte arşivleyebilir; Proxmox Backup Server ise artımlı aktarım, tekilleştirme, doğrulama ve ayrıntılı geri yükleme gibi ek yetenekler sunar. Yine de snapshot yedekle aynı şey değildir. Snapshot aynı storage arızası, yetkisiz silme veya şifreleme olayından etkilenebilir. Yedek kopyası ayrı kimlik, ayrı hata alanı ve mümkünse değiştirilemezlik kontrolüyle korunur. Uygulama ve veritabanı tutarlılığı guest agent, freeze/thaw, dump veya uygulamaya özel yöntemle ele alınır. Saklama politikası günlük, haftalık ve aylık kopya sayısını rastgele değil RPO, kapasite ve mevzuat gereksinimine bağlar. Başarılı görev kaydı geri dönüş garantisi değildir; rastgele VM, tek dosya, veritabanı ve tam hizmet geri dönüşleri düzenli test edilir. Yedek deposu doluluk, doğrulama, süre, hata ve son başarılı kopya yaşı için izlenir.

Yönetim arayüzü ayrı VLAN, VPN ve kişisel hesaplarla sınırlandırılır; root erişimi günlük kullanım hesabı yapılmaz. İki faktörlü kimlik doğrulama, rol tabanlı yetki, API token kapsamı, sertifika, audit logu ve süreli tedarikçi erişimi uygulanır. Host paketleri, kernel, microcode ve Proxmox sürümü desteklenen yükseltme sırasıyla güncellenir. VMware, Hyper-V veya fiziksel sunucudan geçişte kaynak disk, BIOS/UEFI, sürücü, ağ, lisans, saat, performans ve geri dönüş yolu envanteri çıkarılır. Pilot VM kapalı veya kontrollü kopyayla taşınır; veri değişiminin durdurulacağı cutover noktası belirlenir. Kabul testi açılışla bitmez: uygulama, veritabanı, servis hesapları, DNS, IP, firewall, yedek, izleme, HA ve kullanıcı işlemleri doğrulanır. Kaynak sistem, iş sahibi yazılı kabul verene ve geri dönüş süresi dolana kadar kontrollü tutulur.

• Snapshot, replikasyon ve yedek kopyasının farklı riskleri karşıladığını kabul edin; tek storage üzerindeki snapshotı bağımsız yedek saymayın.
• VM, container, tek dosya, veritabanı ve tam hizmet geri dönüşlerini ölçülen süre ve veri kontrolüyle periyodik test edin.
• Yönetim VLAN'ı, VPN, kişisel hesap, 2FA, rol, API token, sertifika ve audit kaydını ortak güvenlik standardında yönetin.
• Geçiş öncesi disk, boot modu, sürücü, IP, lisans, bağımlılık, performans ve cutover planını uygulama sahibiyle doğrulayın.
• Cluster, storage, HA, yedek, izleme, güncelleme ve migration sonuçlarını güncel as-built ve kabul dosyasında saklayın.