Proxmox VE ve VMware sanallaştırma altyapılarında yüksek erişilebilirlik (HA cluster), paylaşımlı depolama ve otomatik sunucu devralma mimarisi rehberi.
Hızlı Özet (TL;DR)
Tek bir fiziksel sunucu üzerinde çalışan onlarca sanal makine (VM), o fiziksel sunucunun anakart veya güç kaynağı yandığında tüm şirketin durması anlamına gelir (Single Point of Failure). Yüksek Erişilebilirlik (HA - High Availability) kümesi; en az 3 fiziksel sunucu ve paylaşımlı bir depolama havuzu (SAN/NAS/Ceph) kullanarak, çöken bir sunucudaki sanal makinelerin saniyeler içinde diğer sağlam sunucularda otomatik olarak yeniden başlatılmasını sağlar. Modern imalat tesislerinde ERP, MES, WMS ve kalite kontrol veritabanlarının kesintisiz çalışması için HA küme mimarisi bir lüks değil, operasyonel sürekliliğin temel şartıdır.
Tek Sunucu Mimarisi Neden Kurumsal Bir Kumardır?
Sanallaştırma teknolojisi (Hypervisor), tek bir fiziksel sunucu donanımı üzerinde birden fazla sanal işletim sistemi çalıştırarak donanım maliyetlerini düşürmüş ve kaynak verimliliğini artırmıştır. Ancak KOBİ ve orta ölçekli sanayi işletmelerinde sıkça yapılan mimari hata, tüm kritik iş yüklerini (ERP, muhasebe, dosya sunucusu, e-posta, barkod otomasyonu) tek bir güçlü fiziksel sunucu (Single Host) üzerine yığmaktır. Bu yaklaşımda konsolidasyon sağlanır ancak “Tek Hata Noktası” (Single Point of Failure - SPOF) riski katlanarak büyür.
Fiziksel bir sunucuda çift güç kaynağı (Redundant PSU) ve RAID 10 disk dizisi bulunsa dahi; anakart (Motherboard) arızası, VRM voltaj regülatörü yanması, bellek kontrolcüsü hatası veya hatalı bir BIOS/Firmware güncellemesi tüm kutuyu anında devre dışı bırakır. Üretim yapan bir fabrikada ana sanallaştırma sunucusunun çökmesi; sevkiyat rampasında irsaliye kesilememesi, CNC ve montaj hatlarında iş emirlerinin okunamaması ve yüzlerce personelin mesai saatinde atıl kalması demektir. Yüksek Erişilebilirlik (HA Cluster) mimarisi, bu donanım bağımlılığını ortadan kaldırarak iş yüklerini fiziksel demirden soyutlar.
Tek Sunucu vs HA Küme Mimarisi Karşılaştırması
İki sanallaştırma yaklaşımı arasındaki dayanıklılık, bakım esnekliği ve operasyonel kriterler aşağıdaki tabloda detaylandırılmıştır:
| Kriter | Tek Fiziksel Sunucu (Standalone Host) | 2 Düğümlü + QDevice Küme | Tam Yedekli HA Kümesi (3+ Node Cluster) |
|---|---|---|---|
| Donanım Arızasında Duruş (RTO) | Parça temini ve değişime kadar 24 – 72 saat | Otomatik devralma ile 60 – 120 saniye | Otomatik devralma ile 30 – 90 saniye |
| Planlı Bakım Kolaylığı | Sunucuyu kapatmak için fabrikanın tatil olması gerekir | Canlı taşıma (Live Migration) ile mesai içi bakım | Sıfır kesintiyle (vMotion / Live Migration) bakım |
| Depolama Mimarisi | Sunucu içi yerel diskler (Local RAID Controller) | Paylaşımlı NAS/SAN veya ZFS replikasyon | Dağıtık Ceph, NVMe-oF veya yedekli SAN/iSCSI |
| Ağ Topolojisi Gereksinimi | Standart 1 Gbps kurumsal anahtar | Yedekli 10 Gbps depolama ve küme ağı | Çift omurgalı (LACP / MLAG) 10/25 Gbps ağ |
| Bölünmüş Beyin (Split-Brain) Riski | Uygulanamaz (Tek sunucu) | Harici tanık (QDevice) ile korunur | Corosync Quorum oylaması ile tam koruma |
| İş Sürekliliği Güvencesi (SLA) | Düşük (%95 - %98 erişilebilirlik) | Yüksek (%99.9 erişilebilirlik) | Kurumsal seviyede %99.99+ kesintisizlik |
Quorum (Salt Çoğunluk) Mekanizması ve Split-Brain Koruması
HA kümelerinde en az 3 düğümün (Node) bulunması matematiksel bir zorunluluktur. Dağıtık sistemlerdeki en tehlikeli senaryo Split-Brain (Bölünmüş Beyin) durumudur. Eğer küme yalnızca iki sunucudan (Node A ve Node B) oluşsaydı ve aralarındaki kalp atışı (Heartbeat) ağ kablosu kopsaydı, her iki sunucu da kendisinin sağlam olduğunu ve karşı tarafın çöktüğünü varsayardı. Bunun sonucunda hem Node A hem de Node B aynı sanal makineyi (örneğin ERP SQL sunucusunu) paylaşımlı disk üzerinden aynı anda çalıştırmaya kalkışırdı. Aynı sanal disk dosyasına (.qcow2, .vmdk veya raw LUN) iki farklı hipervizörün eşzamanlı yazma yapması, dosya sistemi üstverisini (Metadata) saniyeler içinde parçalayarak veritabanını geri dönülemez biçimde bozar.
Corosync ve Raft Konsensüs Algoritması
Proxmox VE ve benzeri kurumsal sanallaştırma platformları, düğümler arası durumu izlemek için Corosync Cluster Engine altyapısını ve Raft tabanlı konsensüs (uzlaşı) algoritmasını kullanır. Kümenin sağlıklı karar alabilmesi için toplam oy sayısının yarısından fazlasına, yani $N/2 + 1$ çoğunluğuna (Quorum) sahip olması gerekir:
- 3 Sunuculu Kümede: Toplam 3 oy vardır; Quorum için en az 2 oy gerekir. Sunuculardan biri çökerse kalan 2 sunucu çoğunluğu sağlar ve çöken sunucunun üzerindeki sanal makineleri devralır.
- 5 Sunuculu Kümede: Toplam 5 oy vardır; Quorum için 3 oy gerekir. Aynı anda 2 fiziksel sunucu yansa bile sistem çalışmaya devam eder.
- QDevice (Harici Tanık Düğümü): Bütçe kısıtı nedeniyle 2 güçlü fiziksel sunucu kurulan tesislerde, üçüncü oy hakkını sağlamak üzere düşük donanımlı bağımsız bir mini sunucu veya NAS üzerinde
corosync-qnetdservisi çalıştırılır. Bu tanık düğüm sanal makine çalıştırmaz, yalnızca ağ bölünmelerinde hakemlik yaparak hangi sunucunun aktif kalacağını belirler.
Donanımsal ve Yazılımsal Fencing (STONITH)
Bir sunucu ağdan düştüğünde veya çekirdek kilitlenmesi (Kernel Panic) yaşadığında, diğer sunucuların o düğümdeki sanal makineleri güvenle başlatabilmesi için sorunlu sunucunun gerçekten susturulduğundan emin olunmalıdır. STONITH (Shoot The Other Node In The Head) veya Fencing adı verilen bu mekanizma iki yöntemle çalışır:
- Donanımsal Watchdog (IPMI / iDRAC / iLO): Küme yöneticisi, yanıt vermeyen sunucunun yönetim kartına (Dell iDRAC veya HP iLO) bağımsız yönetim ağından “Gücü Kes / Yeniden Başlat” komutu gönderir veya anakart üzerindeki donanımsal Watchdog zamanlayıcısı (
softdog/ipmi_watchdog) sıfırlanmadığı için sunucu kendini donanımsal olarak resetler. - Depolama Seviyesinde SCSI-3 Kalıcı Rezervasyon (Persistent Reservation): Sorunlu düğümün paylaşımlı LUN veya Ceph havuzuna yazma yetkisi depolama katmanında anında iptal edilerek diske zarar vermesi engellenir.
# Proxmox VE üzerinde HA küme durumunu ve Quorum oylarını doğrulama
pvecm status
ha-manager status
# Kritik ERP sanal makinesini (VMID: 105) yüksek öncelikli HA korumasına alma
ha-manager add vm:105 --group erp-kritik-grup --max_restart 3 --max_relocate 2
Paylaşımlı Depolama (Shared Storage) Mimarileri
Yüksek erişilebilirliğin çalışabilmesi için sanal makine disklerinin fiziksel sunucunun kendi içindeki yerel disklerde değil, kümedeki tüm sunucuların aynı anda erişebildiği ortak bir depolama katmanında bulunması gerekir. Kurumsal sahada üç ana paylaşımlı depolama mimarisi uygulanır:
1. SAN / iSCSI ve Kurumsal NAS (TrueNAS ZFS)
Merkezi bir depolama ünitesi (SAN veya ZFS tabanlı TrueNAS sunucusu), 10 Gbps veya 25 Gbps yedekli fiber/bakır ağ üzerinden tüm hipervizör düğümlerine blok (iSCSI / Fibre Channel) veya dosya (NFS v4.2) seviyesinde alan sunar. Çoklu yol (Multipath I/O - MPIO) yapılandırması sayesinde ağ anahtarlarından biri arızalansa dahi disk erişimi diğer ağ kartı ve anahtar üzerinden kesintisiz sürer.
2. Hiper-Bütünleşik Altyapı (HCI) ve Ceph Dağıtık Depolama
Ayrı bir SAN kabini satın almak yerine, kümedeki 3 veya daha fazla sunucunun içindeki kurumsal NVMe disklerin Ceph yazılım tanımlı depolama (SDS) motoruyla tek bir sanal havuzda birleştirildiği mimaridir. Ceph, yazılan her veri bloğunu varsayılan olarak 3 farklı fiziksel sunucuya (size=3, min_size=2) eşzamanlı kopyalar. Böylece ayrı bir depolama sunucusu maliyeti ortadan kalkar ve sunuculardan biri tamamen yansa dahi hem işlemci/RAM hem de disk verisi diğer düğümlerde eksiksiz varlığını sürdürür. Kurumsal NVMe disklerde bulunan PLP (Power Loss Protection - Güç Kaybı Koruması) kapasitörleri sayesinde elektrik kesintilerinde bile önbellekteki (Write Cache) veriler diske güvenle yazılır.
3. Asenkron ZFS Replikasyonu (Bütçe Dostu Alternatif)
On-premise bütçesi kısıtlı KOBİ’lerde paylaşımlı SAN veya 3 düğümlü Ceph ağı kurulamıyorsa, ZFS dosya sisteminin blok seviyesinde fark kopyalama (zfs send / receive) yeteneği kullanılır. Sanal makineler her 1 ila 5 dakikada bir ikinci sunucuya kopyalanır. Birinci sunucu çöktüğünde en fazla birkaç dakikalık veri farkıyla (RPO) sanal makine diğer sunucuda ayağa kalkar.
Küme Ağ Topolojisi ve Kalp Atışı (Heartbeat) İzolasyonu
Bir HA kümesinin kararlılığı, ağ tasarımının kalitesiyle doğru orantılıdır. Tüm trafiği (kullanıcı erişimi, yedekleme, Ceph/iSCSI disk trafiği ve Corosync kalp atışı) tek bir ağ kablosu üzerinden geçirmek felakete davetiye çıkarmaktır. Büyük bir yedekleme veya disk senkronizasyonu sırasında bant genişliği doygunluğa ulaşırsa, birkaç milisaniyelik Corosync paketlerinin gecikmesi kümenin yanlışlıkla “Sunucu öldü” kararı verip kendini resetlemesine (False Positive Fencing) yol açar.
Bu riski sıfırlamak için kurumsal küme tasarımında ağ trafiği fiziksel veya VLAN düzeyinde mutlaka 4 ayrı katmana bölünür:
- Corosync Ring 0 & Ring 1 (Küme Kalp Atışı Ağı): Düşük gecikmeli, yalnızca küme sağlığını kontrol eden izole 1 Gbps çift fiziksel hat.
- Depolama Ağı (Storage Network - Ceph / iSCSI): Jumbo Frame (
MTU 9000) aktif edilmiş, 10 Gbps veya 25 Gbps hızında yedekli (LACP Bond) veri yolu. - Canlı Taşıma Ağı (Live Migration Network): Sanal makinelerin RAM içeriğini sunucular arasında taşırken kullanılan yüksek bant genişlikli hat.
- Üretim ve İstemci Ağı (VM Production Network): Fabrikadaki bilgisayarların, el terminallerinin ve Özel ERP & CRM ve İmalat Çözümleri kullanıcılarının eriştiği kurumsal VLAN ağı.
Canlı Taşıma (Live Migration) ile Sıfır Kesintili Bakım
HA mimarisinin en büyük operasyonel avantajı donanım bakımında ve yama yönetiminde ortaya çıkar. Geleneksel tek sunuculu yapılarda sunucuya RAM eklemek, arızalı fanı değiştirmek veya hipervizör çekirdek (Kernel) güncellemesi yapmak için tüm şirketin çalışmadığı Pazar gecesi beklenir. HA kümesinde ise süreç tamamen şeffaftır:
- Bakıma alınacak fiziksel sunucu “Maintenance Mode” (Bakım Modu) durumuna geçirilir.
- Üzerinde çalışan sanal makinelerin RAM belleğindeki aktif veriler, arka planda ağ üzerinden hedef sunucuya kopyalanır (Pre-Copy Memory Migration).
- Son milisaniyede yalnızca değişen bellek sayfaları (Dirty Pages) aktarılır ve sanal makinenin ağ MAC adresi anahtar (Switch) üzerinde GARP (Gratuitous ARP) paketiyle yeni sunucu portuna yönlendirilir.
- Kullanıcıların açık olan ERP ekranları donmaz, veritabanı sorguları yarıda kalmaz ve 1 adet ping paketi dahi kaybolmadan fiziksel sunucu boşaltılarak güvenle kapatılır.
Yüksek erişilebilirlik (HA), donanım arızalarına karşı sistemi ayakta tutar; ancak fidye yazılımlarına (Ransomware) veya kullanıcıların yanlışlıkla sildiği tablolara karşı yedeklemenin yerini tutmaz. Bu nedenle HA kümesi mutlaka Ortak Dosya Sunucusu ve Yedekleme mimarisiyle desteklenmeli ve kurumsal iş yükleriniz için Özel Yazılım Geliştirme uzmanlığımızla uçtan uca planlanmalıdır.
Sıkça Sorulan Sorular
Yüksek erişilebilirlik (HA) kümesi kurduğumuzda harici yedekleme almamıza gerek kalır mı?
Kesinlikle hayır; yüksek erişilebilirlik (HA) ile yedekleme (Backup) birbirini ikame eden değil, tamamlayan iki farklı disiplindir. HA kümesi yalnızca fiziksel bir sunucu yandığında sanal makinenin diğer sunucuda çalışmaya devam etmesini sağlar. Eğer sanal makineye fidye yazılımı (Ransomware) bulaşırsa veya bir personel ERP veritabanındaki stok tablosunu yanlışlıkla silerse, HA mimarisi bu bozulmuş veriyi milisaniyeler içinde tüm sunuculara ve paylaşımlı disklere aynen yansıtır. Geçmişteki sağlam veriye dönebilmek için kümeden tamamen bağımsız, değişmez (Immutable) bir yedekleme sunucusu bulundurmak şarttır.
Fiziksel sunuculardan biri tamamen kapandığında sanal makineler kesintisiz mi aktarılır yoksa yeniden mi başlar?
Planlı bakımlarda yapılan Canlı Taşıma (Live Migration / vMotion) işleminde sanal makine hiç kapanmadan ve oturumlar kopmadan diğer sunucuya kaydırılır. Ancak beklenmedik bir anakart yanması veya elektrik çarpması durumunda, çöken sunucunun RAM belleğindeki anlık uçucu veri kaybolduğu için küme yöneticisi (HA Manager) durumu yaklaşık 60 saniye içinde tespit eder, sorunlu düğümü izole eder (Fencing) ve sanal makineleri paylaşımlı diskteki son tutarlı durumundan diğer sağlam sunucularda otomatik olarak yeniden başlatır (Failover). Böylece günler sürecek bir felaket yalnızca 1-2 dakikalık kısa bir yeniden başlamayla atlatılır.
İki adet fiziksel sunucu ile güvenli bir HA kümesi kurulabilir mi?
Yalnızca iki fiziksel sunucu ile ek bir önlem almadan HA kümesi kurmak, “Split-Brain” (Bölünmüş Beyin) ve veri bozulması riski nedeniyle kurumsal standartlara aykırıdır. Ancak bütçe ve kabinet alanı sebebiyle iki adet ana sunucu kullanılmak isteniyorsa, kümede üçüncü oy hakkını (Quorum) sağlayacak hafif bir QDevice (Tanık Düğüm) yapılandırması eklenmelidir. QDevice olarak mevcut bir NAS cihazı, güvenlik duvarı üzerindeki izole bir konteyner veya küçük bir endüstriyel mini PC kullanılarak 2 düğümlü sistemlerde de %100 güvenli çoğunluk oylaması sağlanabilir.