Proxmox VE Cluster Kurulumu: Corosync, Quorum ve Depolama

Proxmox VE’de tek düğümü kümeye çevirmek birkaç komut sürer. Üretimde gece yarısı kendi kendine yeniden başlamayan bir küme kurmak ise ağ, quorum ve depolama kararlarını baştan doğru vermeye bağlıdır. Bu rehber, Proxmox VE’ye geçen veya yeni küme kuran sistem yöneticileri için corosync ağ tasarımını, pvecm ile küme oluşturmayı, iki düğümlü kümede QDevice’ı, depolama seçimini, HA yapılandırmasını ve sahada en sık çıkan küme arızalarını ele alıyor.

Proxmox VE kümesinin bileşenleri

Bir Proxmox VE kümesinde üç bileşen birlikte çalışır:

• Corosync: Düğümler arası üyelik ve mesajlaşma katmanı. Hangi düğümün kümede olduğuna ve quorum’un sağlanıp sağlanmadığına o karar verir.
• pmxcfs (Proxmox Cluster File System): /etc/pve altında bağlanan, corosync üzerinden tüm düğümlere çoğaltılan yapılandırma dosya sistemi. VM yapılandırmaları, depolama tanımları ve kullanıcılar burada durur. Quorum kaybedilince bu dosya sistemi salt okunur olur; VM başlatamaz, yapılandırma değiştiremezsiniz.
• HA yöneticisi (pve-ha-crm, pve-ha-lrm): HA’ya alınmış kaynakları izler, yeniden başlatır, başka düğüme taşır. Erişilemeyen düğümün VM’lerini güvenle başka yerde açabilmek için watchdog tabanlı self-fencing kullanır.

Pratik sonucu şu: corosync ağı kararsızsa bu “bir uyarı” değildir. Quorum kaybı, salt okunur yapılandırma ve HA etkinse düğümlerin kendini yeniden başlatması (fencing) gelir. Küme ağdan çöker.

Ağ tasarımı: corosync, depolama ve VM trafiği

Corosync düşük ve kararlı gecikme ister. Bant genişliği ihtiyacı küçüktür, ama gecikme dalgalanmasına çok duyarlıdır. Proxmox dokümantasyonu corosync trafiğinin depolama trafiğiyle aynı fiziksel bağlantıyı paylaşmamasını açıkça önerir. Önerilen ayrım:

Corosync (Kronosnet taşımasıyla) birden fazla link destekler; bir link koparsa diğerine geçer. Bu yedekliliği bond yerine corosync’in kendi link mekanizmasıyla kurmak daha öngörülebilir sonuç verir, çünkü bond’un LACP ve failover zamanlamaları corosync’in toleransıyla her zaman uyuşmaz. Güvenlik duvarı varsa düğümler arasında corosync için UDP 5405–5412 portlarının açık olduğunu doğrulayın.

Her düğümün adı küme ağındaki IP’sine çözümlenmeli (/etc/hosts veya DNS), tüm düğümlerde zaman senkronizasyonu (chrony) çalışmalı. Saat kayması küçük görünür, katılımı bozar.

Küme oluşturma ve düğüm ekleme

Kümeyi ilk düğümde oluşturun. --link0 ve --link1 parametreleri corosync’in hangi adresleri kullanacağını belirler:

# Ilk dugumde (pve1)
pvecm create prod-cluster --link0 10.10.50.11 --link1 10.10.51.11

# Diger dugumde (pve2), kumedeki bir dugumun adresi verilerek
pvecm add 10.10.50.11 --link0 10.10.50.12 --link1 10.10.51.12

# Durum kontrolu
pvecm status
pvecm nodes

Kümeye eklenecek düğümde hiç VM veya konteyner olmamalı. Katılım sırasında /etc/pve içeriği kümeninkiyle değiştirilir ve aynı ID’li konuklar çakışır. Mevcut konukları önce yedekleyin, katılımdan sonra geri yükleyin. Tüm düğümler aynı Proxmox VE ana sürümünde olmalı.

Aynı işlem web arayüzünde Datacenter → Cluster menüsünden de yapılır. Link adreslerini açıkça belirtmek için komut satırı daha net; arayüzde varsayılan olarak yönetim IP’sinin seçilip corosync’in yönetim ağına düşmesi sahada sık görülür.

Quorum ve iki düğümde QDevice

Corosync’te her düğümün varsayılan olarak bir oyu vardır; kümenin çalışması için oyların yarısından fazlası gerekir. Üç düğümlü küme bir düğüm kaybını tolere eder (3 oydan 2’si). İki düğümlü kümede bir düğüm kapanınca kalan düğüm 2 oydan yalnız 1’ine sahiptir. Quorum gider.

Çözüm, kümenin dışında çalışan bir QDevice. QDevice, küçük bir Linux makinesinde (sanal makine olabilir ama kümenin içinde olmamalı) çalışan corosync-qnetd servisidir ve kümeye ek bir oy verir:

# Kume disindaki QDevice hostunda
apt install corosync-qnetd

# Kumedeki tum dugumlerde
apt install corosync-qdevice

# Kumedeki bir dugumde
pvecm qdevice setup 10.10.50.20
pvecm status   # "Qdevice" satiri ve toplam oy sayisi kontrol edilir

pvecm qdevice setup komutu QDevice hostuna root olarak SSH ile bağlanıp sertifikaları dağıtır; kurulum sırasında bu erişim açık olmalı, sonra SSH parola girişini yeniden kısıtlayabilirsiniz. Proxmox dokümantasyonu QDevice’ı çift sayıda düğümlü kümeler için önerir. Tek sayılı kümede ek oy, bazı arıza senaryolarında küme davranışını öngörülemez hale getirebilir.

Depolama seçenekleri karşılaştırması

Proxmox VE birçok depolama türünü destekler. Küme için doğru seçim düğüm sayısına, mevcut sunucu ve depolama altyapısına (SAN) ve kabul edilebilir veri kaybına (RPO) göre değişir:

Ceph havuzlarında varsayılan size=3, min_size=2’dir: her veri üç kopya tutulur, iki kopya erişilebilir olduğu sürece G/Ç devam eder. Üç düğümlü Ceph kümesinde bir düğüm giderse veri erişilebilir kalır, ama üçüncü kopyanın yeniden kurulacağı ayrı bir düğüm yoktur; küme o süre boyunca “degraded” çalışır. Kalıcı dayanıklılık için dört veya daha fazla düğüm tercih edin. Ceph ağını corosync’ten mutlaka ayırın.

ZFS replikasyonu (pvesr) iki–üç düğümlü küçük kümeler için pratiktir; aralık dakika düzeyinde ayarlanabilir. HA ile kullanıldığında devralma anında son replikasyondan sonraki değişiklikler kaybolur. Bu RPO’yu iş sahibine yazılı olarak kabul ettirin. Mimari ölçekte HCI ve SAN karşılaştırması için HCI mı klasik SAN mı karar rehberine bakın.

HA yapılandırması

Bir VM’i HA’ya almak için depolaması paylaşımlı (veya replikasyonlu) olmalı. Kaynak komut satırından şöyle eklenir:

ha-manager add vm:101 --state started --max_restart 1 --max_relocate 1
ha-manager status

Hangi VM’in hangi düğümü tercih edeceği eski sürümlerde HA gruplarıyla tanımlanırdı; Proxmox VE 9 ile bu yapı “HA rules” (düğüm ve kaynak affinity kuralları) modeline taşındı. Kullandığınız sürümün dokümantasyonuna göre yapılandırın. Bakım için düğüm boşaltırken HA bakım modunu kullanın: ha-manager crm-command node-maintenance enable pve2 komutu HA kaynaklarını diğer düğümlere taşır.

Fencing davranışını mutlaka test edin. Bir düğümün ağ kablosunu çekin veya düğümü kapatın, VM’lerin diğer düğümde kaç saniyede açıldığını ölçüp kayda geçirin. İş sahibine söyleyeceğiniz kurtarma süresi bu ölçümdür, broşürdeki değer değil. Test edilmemiş HA, HA değildir.

Sık karşılaşılan küme sorunları

• Rastgele düğüm yeniden başlatmaları: Sahada en sık gördüğümüz sebep, corosync bağlantısının depolama veya yedekleme trafiğiyle aynı NIC’i paylaşması. Yoğun yedek saatinde gecikme artar, düğüm quorum’u kaybeder, HA watchdog’u fencing yapar. journalctl -u corosync çıktısında link kayıplarını arayın; zaman damgaları yedek penceresine denk geliyorsa teşhis büyük ölçüde konmuştur.
• Kümeye katılım başarısız: Ad çözümleme, saat farkı, farklı ana sürüm veya düğümde mevcut konuk.
• /etc/pve salt okunur: Quorum yok. pvecm status ile oy sayısına bakın; ağ sorununu çözmeden pvecm expected kullanmayın.
• Düğümü kümeden çıkarma: Düğüm kapatıldıktan sonra kalan bir düğümde pvecm delnode pve3 çalıştırılır. Çıkarılan düğüm aynı kimlikle ağa geri bağlanmamalı; yeniden kurulması önerilir.
• Güncelleme sırası: Düğümleri tek tek güncelleyin, önce VM’leri boşaltın; ana sürüm yükseltmelerinde Proxmox’un yükseltme kontrol betiğini (ör. pve8to9) çalıştırın ve uyarıları kapatmadan ilerlemeyin.

Proxmox VE’nin diğer platformlarla karşılaştırması için VMware sonrası platform seçimi yazısına, kurulum ve işletim desteği için Linux ve açık kaynak platform hizmetleri sayfasına bakabilirsiniz. Ayrıntılı başvuru kaynağı Proxmox VE yönetim kılavuzu.

Sık sorulan sorular

Proxmox VE kümesi için en az kaç düğüm gerekir?

İki düğümle küme kurulabilir, ancak bir düğüm kapandığında quorum’un gitmemesi için küme dışında bir QDevice gerekir. Ceph kullanılacaksa en az üç, kalıcı dayanıklılık için dört veya daha fazla düğüm önerilir.

Corosync trafiği yönetim ağıyla aynı NIC’i paylaşabilir mi?

Küçük ve düşük trafikli ortamda çalışır, ama depolama, yedekleme veya canlı geçiş trafiğiyle aynı bağlantıyı paylaşırsa gecikme dalgalanır ve quorum kaybı yaşanabilir. En az bir corosync linkini ayrı fiziksel NIC’e alın ve ikinci bir link tanımlayın.

ZFS replikasyonu ile HA kullanılırsa veri kaybı olur mu?

Olabilir. ZFS replikasyonu asenkron çalışır; düğüm beklenmedik şekilde kapanınca VM diğer düğümde son başarılı replikasyon anındaki diskle açılır ve sonraki değişiklikler kaybolur. Bu RPO kabul edilemiyorsa Ceph veya paylaşımlı depolama kullanın.

Mevcut VM’leri olan bir düğüm kümeye eklenebilir mi?

Hayır. Katılımda düğümün yapılandırması kümeninkiyle değiştirilir ve ID çakışmaları oluşabilir. Konukları önce yedekleyin, düğüm kümeye girdikten sonra yeni ID’lerle geri yükleyin.