Proxmox VE Sunucu Kiralama: Cluster ve Yedekleme

Proxmox VE sunucu kiralama, Linux ve Windows sanal makinelerini tek bir fiziksel sunucuda toplamak veya birden fazla host üzerinde yönetmek isteyen kurumlar için değerlendirilebilecek bir sanallaştırma yaklaşımıdır. Doğru teklif yalnız işlemci ve RAM sayısına değil; VM yoğunluğu, depolama gecikmesi, ağ ayrımı, lisanslar, kesintiye dayanıklılık ve geri yükleme planına dayanır. Cluster kurmak tek başına kesintisizlik sağlamaz; yedek almak da çalışan bir kurtarma senaryosu olduğu anlamına gelmez.

Kısa cevap: Tek hostlu, ölçülmüş iş yükleri için uygun bir dedicated fiziksel sunucu yeterli olabilir. İş sürekliliği gerektiren çoklu host ortamlarında cluster quorum, disk erişimi, kaynak rezervi ve başarısızlık senaryoları birlikte tasarlanmalıdır. Sanal makine yedekleri ayrı bir hedefte tutulmalı, geri yükleme süresi test edilmeli ve hizmet kapsamı sözleşmeyle doğrulanmalıdır.

1. Proxmox VE ne yapar, hangi ihtiyacı karşılar?

Proxmox Virtual Environment; KVM sanal makineleri, Linux Container (LXC), sanal ağlar ve depolama yönetimini tek yönetim arayüzünde birleştiren açık kaynaklı bir sanallaştırma platformudur. Üretici Proxmox VE ürün sayfasında sanallaştırma, cluster ve yüksek erişilebilirlik yeteneklerini açıklar. Bir platformda özelliğin bulunması, hizmet sağlayıcının her teklifte o özelliği kurup yöneteceği anlamına gelmez.

Kurumların kullanım senaryoları farklıdır: birden fazla departmanın uygulamaları ayrıştırılabilir, test sistemleri ayrı tutulabilir veya ERP ve Active Directory gibi hizmetler bağımsız sanal makinelerde çalıştırılabilir. ERP ve muhasebe sunucusu çözümleri için veritabanı gecikmesi önem kazanırken dosya hizmetlerinde kapasite, erişim ve yedekleme tasarımı öne çıkabilir.

KVM ile çalışan tam sanal makineyi, ana sistemin çekirdeğini paylaşan LXC konteyneriyle aynı güvenlik ve uyumluluk varsayımlarına dayandırmayın. Özellikle Windows uygulamalarında lisans ve üretici destek koşullarını ayrıca inceleyin. Her iş yükünü konteynerleştirmek zorunlu veya uygun değildir.

2. Dedicated host mu, VPS mi, özel bulut mu?

Teknik seçim için ilk soru şudur: Hypervisor katmanını kim yönetecek? Ayrılmış donanım isteyen, kendi sanallaştırma mimarisini kuracak kurumlar fiziksel host seçeneğine odaklanabilir. Hypervisor yönetimini işletmek istemeyen kurumlar için VPS ve bulut sunucu kiralama daha basit bir teslim modeli olabilir. Bu modeller aynı şey değildir; sanal sunucu satın alan müşteri çoğu zaman fiziksel hostun yönetimini üstlenmez.

Özel bulut ve hibrit altyapı seçenekleri, proje büyüdükçe lokasyon ve operasyon kapsamının birlikte değerlendirilmesini gerektirir. Karşılaştırmada yalnız aylık kira bedelini değil, destek, lisans, izleme ve kurtarma sorumluluklarını da yazılı isteyin.

3. CPU, RAM ve disk planı nasıl yapılmalı?

Üreticinin resmî Proxmox VE donanım gereksinimleri işletim sistemi için kaynak gerektiğini, sanal misafirlerin kendi kaynak tüketimine sahip olduğunu ve ZFS/Ceph gibi depolama teknolojilerinin ek gereksinimler doğurduğunu belirtir. Bu nedenle toplam RAM'i sanal makinelerin RAM toplamına bire bir eşitlemek doğru değildir.

Boyutlandırmada her VM için ortalama ve tepe CPU kullanımı, eş zamanlı işlem, tahsis edilmiş RAM, dinamik bellek davranışı, disk kapasitesi, günlük büyüme, disk okuma/yazma gecikmesi ve yedekleme penceresi ölçülmelidir. Örneğin çok sayıda düşük CPU kullanan sunucu ile birkaç yoğun SQL sunucusunun aynı çekirdek ihtiyacına sahip olduğunu varsaymayın.

Daha sonra şu ayrımı yapın: mevcut kaynak gereksinimi, bir host arızasında diğer hostlarda taşınabilecek iş yükü, bakım sırasında gereken boş kapasite ve 12–24 aylık büyüme. Yalnız normal saatlerde yeten bir cluster, tek host kaybında kapasite yetersizliğine düşebilir.

4. NVMe, ZFS, Ceph ve ortak depolama arasında karar

Depolama katmanı, sanallaştırmanın kullanıcı tarafından hissedilen performansında çoğu zaman belirleyicidir. NVMe sürücü etiketi tek başına yeterli değildir: RAID/ZFS planı, disk yazma dayanımı, gecikme, hata alanı, kontrolcü, ağ yolu ve yedek depolama ayrımı da önem taşır.

Yerel ZFS; host üzerinde veri bütünlüğü, snapshot ve uygun disk düzeni gibi olanaklar sunabilir. Ancak tek hostun bozulması durumunda yerel disklerin başka host tarafından kendiliğinden kullanılabileceği varsayılmamalıdır. Ceph, çoklu host üzerinde dağıtık depolama kurmaya yönelik bir seçenektir; yazma yükü, ağ bant genişliği, kapasite verimliliği, gecikme ve hata alanları hesaba katılmadan sırf “yüksek erişilebilirlik” adıyla eklenmemelidir.

Proxmox'un yönetim ve depolama belgeleri ortak depolama ile canlı taşıma senaryolarını açıklar. Paylaşımlı depolama kullanılan bir mimaride bile uygulama oturumu, sürücü davranışı ve ağ kesintisi sıfır duraklama anlamına gelmez. Snapshot, replikasyon ve bağımsız yedek birbirinin yerine geçmez.

5. Cluster quorum ve yüksek erişilebilirlik aynı kavram mı?

Hayır. Cluster üyesi hostların birbirini görebilmesi ve karar verebilmesi için quorum mekanizması gerekir; yüksek erişilebilirlik ise arıza koşullarında iş yükünün uygun kaynaklarda yeniden çalıştırılmasına ilişkin ek bir işletim modelidir. Bir sunucu odasının ağ erişimini kaybetmesi veya disk yolunun kesilmesi gibi senaryolarda iki kavramın farklı etkileri ortaya çıkar.

İki hostlu cluster tasarımlarında oy çoğunluğu ve ağ bölünmesi (split-brain) riski özellikle incelenmelidir. Gerekirse üçüncü oy için qdevice/witness yaklaşımı değerlendirilebilir; ancak her mimaride aynı sayıda node ile aynı SLA'nın elde edileceği söylenemez. Proxmox VE yönetim kılavuzundaki cluster bölümü ürünün güncel sürümüne uygun doğrulama için başvuru noktasıdır.

Gerçek HA tasarımına karar verirken cluster ağının fiziksel ayrımı, ortak hata noktaları, depolama erişimi, fencing/yeniden başlatma davranışı, VM öncelikleri ve kapasite rezervi gözden geçirilmelidir. Test planında en az bir host arızası, ağ bölünmesi, depolama yavaşlaması ve planlı bakım senaryosu bulunmalıdır. Tek host kurulumunu “HA cluster” olarak adlandırmak yanıltıcı olur.

6. Ağ ve hypervisor yönetimini güvenli tutun

Proxmox yönetim arayüzü, VM trafiği, cluster iletişimi, depolama ve yedekleme ağları mümkün olduğunda mantıksal veya fiziksel olarak ayrılmalıdır. Gereksiz yönetim portlarını internete açmak yerine VPN, yönetici erişim kısıtları, MFA ve kayıtlı yetkilendirme kullanılmalıdır. Ağ katmanını tasarlarken VPN ve güvenlik duvarı hizmetlerinin kapsamı keşif sırasında açıkça belirlenmelidir.

Yetkili kullanıcı rolleri; hypervisor yöneticisi, yedekleme operatörü ve yalnız VM konsoluna erişebilen uygulama sorumlusu şeklinde ayrıştırılabilir. Gereğinden fazla root erişimi vermek ya da aynı kimlik bilgisini çok sayıda ekipte paylaşmak olay araştırmasını zorlaştırır. Güncelleme ve yama pencerelerinde sürüm uyumluluğu, snapshot sınırları ve geri dönüş prosedürü önceden planlanmalıdır.

Tek başına TLS, firewall veya MFA kurmak bütün güvenlik risklerini ortadan kaldırmaz. Denetim kayıtlarının saklanması, gizli anahtar yönetimi, ayrı yedek hedefi ve test edilmiş olay müdahale adımları da teklifin kapsamına girmelidir.

7. Proxmox Backup Server ile gerçek kurtarma stratejisi

Proxmox Backup Server (PBS), yedekleri ayrı bir hizmet ve depolama katmanında yönetmeye yardımcı olur. Üretici resmî Proxmox Backup belgelerinde doğrulama işleri, yedek saklama kuralları ve uzak konuma senkronizasyon gibi özellikleri açıklar. Bunların kurulumda etkin olduğu varsayılmamalı, alınan hizmette tek tek doğrulanmalıdır.

İşletme önce kabul edilebilir veri kaybı hedefini (RPO) ve yeniden çalışmaya dönüş hedefini (RTO) yazmalıdır. Sonra kritik VM'ler için yedekleme sıklığı, başarılı/başarısız görev bildirimi, saklama süresi, yedek dosyalarının doğrulanması, erişim yetkileri ve mümkünse farklı hata alanındaki ikinci kopya planlanır. Yedekleme ve felaket kurtarma hizmetleri bu tasarımın ayrı bir kapsam kalemi olarak değerlendirilmesini sağlar.

Bir yedeğin doğrulama testinden geçmesi, uygulamanın bütün servisleriyle çalışır şekilde döneceğini tek başına kanıtlamaz. Bu yüzden seçilmiş Windows/Linux VM'leri izole ortama geri yükleyin; uygulama, veritabanı, erişim, lisans ve dosya tutarlılığını kontrol edin. Geri yükleme süresini ölçmeden belirli bir RTO garanti etmeyin.

8. Fiziksel sunucu veya hypervisor geçişi nasıl planlanır?

Mevcut VMware, Hyper-V veya farklı KVM altyapısından Proxmox VE'ye geçişte sanal disk formatları kadar sürücü, BIOS/UEFI önyükleme, ağ kimliği, uygulama lisansı ve veri tutarlılığı önemlidir. Üreticinin geçiş yöntemleri başvuru noktası olabilir; ancak bütün VM'lerin hiçbir uyarlama olmadan taşınacağını varsaymak güvenli değildir.

Önce sanal makine envanterini ve bağımlılık sırasını çıkarın: DNS, Active Directory, dosya hizmeti, veri tabanı, uygulama, kimlik doğrulama ve entegrasyonlar. Ardından test taşıması, başarısızlık koşulu, geri dönüş adımı ve bakım penceresi belirleyin. Active Directory ve dosya sunucusu mimarileri taşınırken isim çözümleme ve izin kontrolleri özellikle önem taşır.

Canlıya geçiş günü yalnız VM açılıyor mu diye bakmayın. Uygulama oturumu, veritabanı sorgusu, şube VPN'i, planlı işler, yedekleme, izleme, sertifikalar ve kullanıcı deneyimi için kabul testi yapın. Eski hostu kaldırmadan önce verilerin tamamlandığını ve geri dönüş koşullarının sona erdiğini doğrulayın.

9. Proxmox sunucu kiralama fiyatına neler dahil olmalı?

Proxmox VE açık kaynaklı bir platform olsa da fiziksel sunucu, kurulum, lisanslanan misafir işletim sistemleri, gerekli abonelik/destek modeli, ağ güvenliği, yedekleme ve operasyon hizmetleri ayrı maliyetler doğurabilir. Üretici aboneliği ile sunucu kiralama hizmetini aynı kalem olarak düşünmeyin; hangi desteğin kim tarafından verileceği sözleşmede açık yazılmalıdır.

Sadece “8 çekirdek, 64 GB RAM” yazan iki teklif eşdeğer olmayabilir. Sunucunun iş yükü, kullanılan disk mimarisi ve hizmet sınırları farklıysa toplam sahip olma maliyeti de değişir. Yönetilen sunucu hizmetleri seçeneğinin devrede olduğu projelerde bakım ve destek sorumlulukları önceden yazılmalıdır.

10. Teklif öncesi 10 maddelik teknik kontrol listesi

1. Mevcut VM ve konteyner sayısını, görevlerini ve işletim sistemi sürümlerini listeleyin.
2. CPU/RAM ortalama ve tepe kullanımını, depolama gecikmesini ve büyüme hızını kaydedin.
3. Tek host, çoklu host veya HA hedefini iş etkisiyle birlikte tanımlayın.
4. Cluster quorum, ağ yolu, disk ve fiziksel hata alanlarını görünür kılın.
5. İş yüklerinin lisans ve üretici desteği gereksinimlerini doğrulayın.
6. ZFS/Ceph/SAN seçiminin performans ve kurtarma etkilerini karşılaştırın.
7. Yönetici erişimi, MFA, firewall, VLAN ve loglama sorumlularını belirleyin.
8. Bağımsız yedek, saklama, doğrulama ve geri yükleme testini bütçeye ekleyin.
9. Bakım, sürüm yükseltme, arıza ve geri dönüş prosedürünü yazılı isteyin.
10. Teklifleri yalnız aylık bedelle değil, risk, operasyon ve büyüme maliyetiyle değerlendirin.

Bu liste sabit bir donanım reçetesi değildir. Belirli bir mimari ve hizmet teklifi ancak iş yükü ölçümleri ve destek koşulları ortaya konduğunda hazırlanabilir.

Sık sorulan sorular

1. Proxmox VE için dedicated sunucu şart mı?

Proxmox VE çeşitli uygun donanım ve sanallaştırma ortamlarında çalışabilir; fakat üretim için ayrılmış host, performans izolasyonu ve donanım yönetimini doğrudan planlamak isteyen kurumlarda daha anlaşılır olabilir. Nihai seçim VM yoğunluğu, disk/ağ ihtiyacı ve sağlayıcı koşullarına bağlıdır.

2. İki Proxmox hostuyla yüksek erişilebilirlik kurulabilir mi?

İki hostlu mimariler mümkündür; ancak quorum, ağ bölünmesi ve oy çoğunluğu konusu çözülmeden kesintisiz hizmet sözü verilmemelidir. Tasarıma uygun bir qdevice/witness, depolama ve kurtarma modeli ayrıca değerlendirilmelidir.

3. Ceph her Proxmox cluster için gerekli mi?

Hayır. Yerel disk, ZFS, SAN/NAS veya dağıtık depolama senaryolarından uygun olan seçilir. Ceph çoklu host depolaması için bir araçtır; ağ, disk kapasitesi, bakım ve hata alanı gereksinimleri tasarlanmadan eklenmesi gereksiz maliyet ve karmaşıklık yaratabilir.

4. Snapshot almak veri yedeği sayılır mı?

Snapshot belirli senaryolarda geri dönüşü kolaylaştırır, fakat ayrı hata alanındaki, saklanan ve geri yüklenebilen bağımsız yedeğin yerine geçmez. Kritik uygulamalarda yedekleme hedefi ve düzenli restore testleri gerekir.

5. Proxmox Backup Server aynı fiziksel hostta olmalı mı?

Aynı fiziksel hata alanındaki tek kopya, host arızası veya fidye yazılımı riskini yeterince azaltmayabilir. Ayrı depolama, yetki ayrımı ve uygun durumda farklı lokasyon seçeneği düşünülmelidir; gerçek seçenekler hizmet sağlayıcıyla netleşir.

6. Windows Server veya SQL Server lisansı Proxmox'a dahil midir?

Proxmox VE'nin açık kaynak yapısı misafir işletim sistemi veya veritabanı lisansını otomatik karşılamaz. Windows Server, SQL Server, uzaktan masaüstü erişim ve diğer ticari yazılımlar için geçerli lisans sözleşmeleri ayrıca değerlendirilmelidir.

7. Proxmox'a geçerken uygulamalar ne kadar süre durur?

Tek ve garantili bir süre verilemez. Kaynak platform, disk hacmi, veri senkronizasyon yöntemi, uygulama bağımlılığı ve ağ yönlendirmesi süreyi belirler. Test taşıması, iş akışı kabulü ve geri dönüş planıyla kesinti riski yönetilir.

Proxmox altyapınız için teknik keşif ve teklif

İhtiyacınız tek bir dedicated sanallaştırma hostu da olsa çoklu cluster ve ayrı yedek deposu da olsa, Proxmox VE sunucu kiralama kararını teknik ölçümlere dayandırın. Mevcut VM sayısını, tepe CPU/RAM kullanımını, toplam veri hacmini, kritik uygulamaları, RPO/RTO hedeflerini ve yönetim beklentisini paylaşın.

Netsun Bilişim'in sunabileceği fiziksel altyapı, ağ, yedekleme ve yönetim seçenekleri keşif sonrasında doğrulanır. Belirli bir Proxmox aboneliğinin, HA özelliğinin veya yönetilen desteğin teklife dahil olduğu önceden varsayılmaz. Proxmox sunucu altyapınız için ihtiyaç analizi ve teklif talep edin; kesin kapasite, lisans ve hizmet sorumluluklarını yazılı olarak netleştirelim.