Üç sunucu, tek yönetim arayüzü, paylaşımlı depolama ve bir node çöktüğünde sanal makinenin başka bir node üzerinde yeniden başlaması. Proxmox VE kümesi kurmak aslında bu dört sonucu birlikte almak. Corosync tabanlı küme yapısı, hyper-converged Ceph depolama ve HA yöneticisinin üçlüsü doğru kurulduğunda elde edilen şey küçük çaplı bir özel bulut; yanlış kurulduğunda ise bakımı yorucu bir sistem. Kurulum adımlarına geçmeden önce üç kavramı ayırmak gerekiyor: küme iletişimi (Corosync), depolama katmanı (Ceph) ve kaynak yönetimi (HA stack). Üçü birbirinin yerine geçmez, her biri ayrı bir ağ, ayrı bir karar mekanizması ister.
Küme kurulmadan önce ağ planı
Proxmox VE kümesinde node arası haberleşme Corosync üzerinden yürür. Corosync düşük gecikme ister ama yüksek bant genişliği istemez; 1 Gbit'lik ayrı bir arayüz çoğu durumda yeterli. Kritik olan bu trafiğin depolama ve sanal makine trafiğinden ayrı tutulması. Aynı fiziksel ağı paylaşırsanız bir yedekleme işi corosync paketlerinin gecikmesini artırır ve küme sağlıksız sinyaller üretmeye başlar.
Üç node üzerinde kurulum başlamadan her makinede saat senkronu kontrol edilmeli. Proxmox varsayılan olarak chrony kullanır; timedatectl status çıktısında NTP eşleşmesinin aktif olduğunu görmek gerekir. Saat kayması yalnızca logları karıştırmakla kalmaz, pmxcfs'nin çakışma çözümlemesini de etkiler. Ayrıca /etc/hosts üzerinde her node'un diğerlerini isimle çözebildiği doğrulanmalı.
Node isimleri ve IP adresleri küme oluşturulduktan sonra değiştirilmemeli. Küme katılmadan önce makinede çalışan hiçbir VM ya da konteyner olmamalı; boş bir node katılır, dolu node katılmaz.
İlk node ve katılım komutları
Kümeyi ilk node üzerinde oluştururken corosync'in hangi adrese bağlanacağını açıkça belirtmek ileride çok şey kurtarır:
pvecm create pve-cluster --link0 10.10.10.11İkinci ve üçüncü node üzerinde, var olan kümeye IP adresi üzerinden katılım yapılır. Katılım komutu yeni node üzerinde çalıştırılır, kümeye dahil node üzerinde değil. Karşı tarafın root parolası ve sertifika parmak izi sorulur:
pvecm add 10.10.10.11 --link0 10.10.10.12 --link1 10.0.0.12--link1 burada yedek corosync halkasıdır. İkinci link mutlaka farklı bir fiziksel ağ üzerinden verilmeli; aynı switch'e bağlı ikinci bir kablo yedeklilik sayılmaz. Corosync toplamda sekiz linke kadar destekler ama pratikte iki link, yani birincil ve yedek, çoğu kurulum için yeterlidir. Yedek link'in gerçekten çalıştığını ancak ilk ağ planlı kesintiye uğradığında görürsünüz; o yüzden kurulum biter bitmez test edin, bir yıl sonra değil.
Katılım sonrası durum kontrolü:
pvecm status
pvecm nodesÇıktıda üç node görünmeli ve kümenin quorate olduğu yazmalı. Quorum, kümenin karar verebilmesi için gereken oy çoğunluğudur; üç node'luk kümede iki oy karar yeteneğini korur. Üç node'dan birinin çökmesi kümenin çalışmaya devam etmesi anlamına gelir, iki node'luk kümede ise tek bir arıza kalan node'u da dondurur. İki node ile yola çıkılacaksa harici bir qdevice üçüncü oy olarak eklenir; corosync-qdevice paketi küme node'larına, corosync-qnetd paketi harici makineye kurulur ve pvecm qdevice setup ile kayıt yapılır.
Ceph tarafında ne kuruyoruz
Proxmox VE içinde Ceph kurulumu doğrudan yönetilir; ayrı bir ceph kümesi kurup dışarıdan bağlamaya gerek yok. Üç node, her node'da en az bir OSD ile başlandığında varsayılan üç kopya çoğaltma anlamlı hale gelir. Kurulum sırasında sırasıyla paket kurulumu, başlatma, mon ve mgr oluşturma, OSD ekleme adımları izlenir:
pveceph install --repository no-subscription
pveceph init --network 10.10.20.0/24
pveceph mon create
pveceph mgr create
pveceph osd create /dev/sdbmon create her node üzerinde ayrıca çalıştırılır; monitor sayısı üçe ulaşana kadar küme sağlıklı raporlanmaz. OSD ekleme işi disk başına tekrarlanır. Boş, partitionsız bir disk gerekir; üzerine veri yazılmış bir diski OSD yapmaya çalışmak reddedilir. Diskin gerçekten boş olduğunu lsblk ile doğrulamak birkaç saniye alır ve yanlış diski silmenin önüne geçer.
Hepsi bittiğinde pveceph status ya da ceph -s çıktısında HEALTH_OK görülmeli. Bu adımların tamamı GUI üzerinden de yapılabilir; Datacenter bölümünün altındaki Ceph sayfaları aynı işleri tıklama ile yürütür. Komut satırını tercih etme sebebim, adımların tekrarlanabilir ve dokümante edilebilir olması.
Pool ayarları neye göre seçilir
VM diskleri için RBD pool açılırken iki sayı karar verir: size kaç kopya tutulacağı, min_size kaç kopya kaldığında G/Ç'nin kesileceği. Varsayılan üç kopya ve min_size 2, üç node'luk yapıda bir node'un tamamını kaybettiğinizde bile okuma yazmanın sürmesi anlamına gelir. min_size'i 1'e düşürmek degraded durumda yazmaya devam etmeyi sağlar ama tek kopya üzerinden yazılan veri, o sırada başka bir disk arızasıyla karşılaşırsa kurtarılamaz. Karakteristiği bilinmeyen bir kurulumda varsayılanın dışına çıkmak için iyi bir neden gerekir.
pveceph pool create vmpool --pg_autoscale_mode on --add-storagePG autoscaler açıkken placement group sayısıyla elle boğuşmak yerine otomatik ölçeklemeye bırakmak güncel sürümlerde önerilen yol. --add-storage bayrağı pool'u Proxmox depolama listesine kendisi ekler; ayrıca Datacenter, Storage bölümünden RBD türünde depolama tanımlamaya gerek kalmaz.
Kapasite planında üç kopyanın anlamı net olmalı: kullanılabilir kapasite, ham disk kapasitesinin üçte biridir. On iki TB'lık OSD alanı dört TB kullanım sağlar. Bu oranı baştan bilmek, ileride "diskler dolmadı ama pool doluyor" şaşkınlığını önler.
HA tarafında ne kuruyoruz
Depolama hazır olduğunda HA yöneticisi, seçilen VM'leri izleyip gerektiğinde başka node üzerinde başlatan katmandır. Proxmox'un fencing yaklaşımı harici bir fence cihazı değil, watchdog tabanlıdır: her node'un yerel kaynak yöneticisi (LRM), küme yöneticisi (CRM) ile bağlantıyı ve quorum'u koruduğu sürece donanım ya da yazılım watchdog'u sürekli besler. Bağlantı corosync token zaman aşımını aşacak şekilde koparsa watchdog tetiklenir ve node kendini yeniden başlatır. Bu sayede çöken bir node üzerindeki VM'lerin başka bir node'da başlatılması güvenli hale gelir; aynı VM'in iki yerde birden çalışması engellenir. Yazılım watchdog varsayılandır, üretim ortamında IPMI tabanlı donanım watchdog önerilir.
VM'leri HA yönetimine eklemek tek komut:
ha-manager add vm:100Aynı iş GUI'den Datacenter, HA, Add yolundan yapılır. Hangi node'ların tercih edileceğini belirlemek için grup tanımlanır:
ha-manager groupadd production --nodes pve1:2,pve2:1,pve3:1
ha-manager set vm:100 --group productionNode listesindeki sayılar önceliktir; yüksek öncelikli node ayakta olduğunda kaynaklar oraya taşınır. nofailback seçeneği grup önceliklerinin taşıma davranışını devre dışı bırakır, restricted ise kaynağın yalnızca gruptaki node'larda çalışabilmesini zorunlu kılar. Komut setinde grup oluşturma groupadd, güncelleme groupset, silme groupremove alt komutlarıyla yapılır; ayrıca group add diye bir alt komut yoktur.
Kaynağın davranışını ince ayarlayan iki parametre var: max_restart yerel yeniden başlatma denemesi sayısını, max_relocate başka node'a taşıma denemesi sayısını belirler. İkisinin varsayılanı 1'dir. Sık arızalanan bir uygulamanın hızlı biçimde başka node'a geçmesini istiyorsanız yeniden başlatma denemelerini düşük tutmak mantıklı olur.
HA durumu şu komutlarla izlenir:
ha-manager status
journalctl -u pve-ha-crm --since "1 hour ago"Ceph ağ ile corosync ağı ayrımı
Hyper-converged kurulumlarda en sık yapılan hata Ceph çoğaltma trafiğiyle corosync trafiğini aynı fiziksel ağda bırakmaktır. pveceph init --network ile verilen adres bloğu OSD çoğaltması ve monitor haberleşmesinin bağlı olacağı ağdır. Depolama trafiği hacimlidir; corosync ise az veriyle düşük gecikme ister. İkisi aynı switch üzerinden geçtiğinde yüksek anlık depolama trafiği corosync token kayıplarına yol açabilir. Fiziksel olarak ayrılması mümkün değilse VLAN ile ayrım ve QoS işaretleme en azından denenmeli. Ayrıca corosync yedek link'i ile Ceph ağının da farklı fiziksel yolları paylaşması beklenir; üç ayrı ağ çoğu kurulum için lükstür ama iki ayrı fiziksel yol zorunluluktur.
Ceph tarafında monitor sayısı üçe çıkana kadar bekleme nedeniyle kurulumun takıldığı düşünülmemeli; iki mon ile ceph -s uyarı verebilir, üçüncü mon eklendiğinde sağlık durumu düzelir.
Test edilmeden HA kurulmuş sayılmaz
Kurulum tamamlandıktan sonra bir node'un fişini çekmeden önce şu üç testi yapmak gerekir. Birincisi: pvecm status çıktısında quorum ve link'ler kontrol edilir. İkincisi: ceph -s ile HEALTH_OK ve yeterli OSD sayısı doğrulanır. Üçüncüsü: ha-manager status çıktısında kaynakların hangi node'da çalıştığı okunur.
Ardından bir HA'ya ekli VM üzerinde çalışır durumda bir yük bırakıp test node'unun ağını kesin. Beklenen davranış şudur: watchdog tetiklenir ya da node corosync'ten düşer, kaynaklar başka node'da başlar, Ceph degraded raporlar ama G/Ç sürer. VM'nin yeniden başlama süresi disk boyutuyla doğrudan ilgili değildir; Ceph üzerinde olduğu için disk kopyalama yoktur, yalnızca açılış süresi kadar beklenir. Test sırasında VM'nin çalıştığı node'un hangisi olduğunu bilmek, testin sonucunu okumayı kolaylaştırır. Aynı testi corosync yedek link'i için de tekrarlayın; birincil link kesildiğinde kümenin hiçbir şey olmadan devam etmesi gerekir.
Silme ve katılımda dikkat
Bir node'u kümeden kalıcı olarak çıkarmak için önce üzerindeki tüm kaynaklar başka node'lara taşınır, makine kapatılır ve ardından kalan node'lardan biri üzerinde pvecm delnode çalıştırılır. Aynı isimle geri katılım yapılmaz; temiz kurulum gerekir. Node silindiğinde üzerinde kalan Ceph OSD'leri varsa bunların önce kümeden düzgün biçimde çıkarılması gerekir, yoksa küme sürekli olarak kayıp OSD raporlar.
Katılım yönü de karıştırılan noktalardan biri. Katılım komutu her zaman katılacak yeni node üzerinde çalıştırılır ve parametre olarak kümeye dahil bir node'un adresi verilir. Tersini yapmak, yani kümeye dahil node üzerinde yeni makineyi hedefleyerek add komutu vermek desteklenen bir yol değil.
İzleme tarafında üç komut günlük rutinin parçası olmalı: pvecm status, ceph -s ve ha-manager status. Üçünün çıktısı beklenen değerleri gösteriyorsa küme sessizce çalışıyor demektir. HA kurulumunda sessizlik iyiye işarettir; gürültü çıkan bir küme, genellikle ağ katmanında değil, planlamada bırakılmış bir boşluk vardır.