# Redundant Links, İzleme Araçları ve Bir Affinity Kilitlenmesi (Modül 5)

Seri: Proxmox VE Cluster ve Corosync | Hafta 5 Serinin adı "Cluster ve Corosync"; ama dört modüldür ağırlık HA Manager, resource affinity ve CRS'teydi, Corosync'in kendisine (redundant link'ler, izleme araçları) hiç dönmemiştim. Bu modülde iki konuyu birleştirip derinlemesine işledim: birden fazla corosync link'i tanımlayıp gerçekten birini kesip diğerinin devralmasını kanıtlamak, ve günlük operasyonda kullanılacak izleme araçlarını tek tek denemek. İkisi de planladığımdan çok daha fazla soru açtı; biri yanlış bir config anahtarı yüzünden saatler süren bir araştırmaya dönüştü, diğeri ise hiç beklemediğim bir kilitlenme keşfiyle bitti. Şu ana kadar cluster'ımızda tek bir corosync link'i vardı (link1, izole corosync-net ağı). Management ağını (192.168.122.x) link0 olarak ekleyip gerçek bir yedeklilik kurdum; /etc/pve/corosync.conf'u kopyalayıp düzenleyip atomik olarak yerine taşıdım: cp /etc/pve/corosync.conf /etc/pve/corosync.conf.new # nodelist'teki her node'a ring0_addr ekledim, totem'e ikinci bir interface bloğu ekledim mv /etc/pve/corosync.conf.new /etc/pve/corosync.conf Doğrulama: corosync-cfgtool -s LINK ID 0 udp addr = 192.168.122.11 status: ... connected ... connected LINK ID 1 udp addr = 10.10.10.11 status: ... connected ... connected Teknik olarak başarılı; iki link de bağlı. Ama log'a dikkatlice bakınca, mimarimizin niyetini tersine çeviren bir şey oldu: [KNET ] rx: host: 3 link: 0 is up [KNET ] host: host: 3 (passive) best link: 0 (pri: 1) link_mode: passive modunda, öncelik eşitken düşük numaralı link kazanıyor. link0'ı sonradan eklediğim için, o Corosync'in asıl trafiğini üstlenmiş; Modül 0'da özellikle izole ettiğimiz corosync-net (link1) sessizce yedek konuma düşmüştü. Bunu düzeltmek için link1'e daha yüksek öncelik vermeye çalıştım: interface { linknumber: 0 priority: 5 } interface { linknumber: 1 priority: 10 } İşe yaramadı. corosync-cmapctl | grep priority sadece tek, indekslenmemiş bir satır gösterdi: totem.interface.priority (str) = 10. Diğer parametreler (knet_ping_interval, knet_ping_timeout) düzgün şekilde interface.0.* / interface.1.* diye ayrılmışken, priority öyle değildi. Log'da "best link" seçimi hâlâ (pri: 1) gösteriyordu; bizim verdiğimiz değer hiç okunmamıştı. Tam bir servis restart'ının (systemctl restart corosync) sorunu çözebileceğini düşündüm; denedim, çözmedi. Restart, pve-a'yı ~13 saniyeliğine cluster'dan düşürdü (Nodes: 1, Quorate: No), ama priority yine tek, indekslenmemiş kaldı. Sebep, resmi man sayfasında (corosync.conf(5)) çıktı: doğru anahtar priority değil, knet_link_priority. Bizim yazdığımız priority, geçerli bir knet parametresi olmadığı için corosync tarafından sessizce, gevşek bir yere yazılmış; hiçbir zaman gerçek link seçim mantığına girmemiş. interface { linknumber: 0 knet_link_priority: 5 } interface { linknumber: 1 knet_link_priority: 10 } corosync-cmapctl | grep -i "interface.*priority" totem.interface.0.knet_link_priority (u8) = 5 totem.interface.1.knet_link_priority (u8) = 10 Bu sefer düzgün indekslenmiş. Log de anında değişti: [KNET ] host: host: 3 (passive) best link: 0 (pri: 5) [KNET ] host: host: 3 (passive) best link: 1 (pri: 10) Corosync her iki linki de değerlendirip yüksek öncelikli olanı (link1, corosync-net) seçmiş. link1'i fiziksel host'tan kestim: sudo virsh domif-setlink pve-a vnet0 down [KNET ] link: host: 3 link: 1 is down [KNET ] host: host: 3 (passive) best link: 0 (pri: 5) Anında link0'a geçiş; pvecm status kesintisiz Quorate: Yes kaldı, hâlâ tam oy sayısıyla. Sonra geri açtım: sudo virsh domif-setlink pve-a vnet0 up [KNET ] rx: host: 3 link: 1 is up [KNET ] host: host: 3 (passive) best link: 1 (pri: 10) Saniyeler içinde link1'e geri dönüş. Bu, hem failover'ı hem failback'i (yüksek öncelikli link geri gelince otomatik ona dönme) doğru anahtarla kesin olarak kanıtladı. İlk yanlış denemede ("sticky" davranış sandığım şey) aslında sadece önceliğin hiç uygulanmamış olmasıydı; gerçek mekanizma tam beklendiği gibi çalışıyor. corosync-quorumtool: Daha Okunabilir Bir Alternatif corosync-quorumtool -s corosync-quorumtool -l İçerik pvecm status ile aynı, ama membership tablosu hex ID (0x00000001) yerine düz ondalık ID + doğrudan hostname gösteriyor. Günlük kullanımda daha okunabilir. corosync-cmapctl | grep -E 'totem.token|totem.consensus' runtime.config.totem.token (u32) = 3125 runtime.config.totem.consensus (u32) = 3750 totem.token_coefficient (u32) = 125 Modül 0'da bulduğumuz formül: token = 3000 + (node_sayısı - 2) × token_coefficient. 3 node ile: 3000 + 1×125 = 3125. Tam uyuyor. consensus = 1.2 × token = 3750. O da uyuyor. Aylar önce bir dokümandan öğrendiğimiz bir formülü, kendi cluster'ımızın gerçek sayılarıyla doğrulamış olduk. corosync.conf pve-cluster (pmxcfs) loglarına bakınca, hiç bilmediğimiz bir mekanizma ortaya çıktı: journalctl -u pve-cluster -n 20 [dcdb] notice: wrote new corosync config '/etc/corosync/corosync.conf' (version = 7) Bir saniye sonra, corosync log'unda: [CFG] Config reload requested by node 1 Şimdiye kadar hep /etc/pve/corosync.conf'u düzenledik; bu, pmxcfs üzerinden cluster geneline otomatik yayılan sanal bir dosya. Ama corosync daemon'ının kendisi aslında /etc/corosync/corosync.conf'u okuyor, farklı bir yol. pmxcfs bizim düzenlememizi algılayıp gerçek dosyayı arkada kendisi yazıyor, corosync de bunu saniyeler içinde fark edip reload istiyor. İki ayrı dosya, tek görünen arayüz. systemctl restart corosync denememizin ardından, pve-ha-crm/pve-ha-lrm logları da bir "Boot" işareti ve yeniden başlatma döngüsü gösterdi; VM'ler yeniden başlatılmış, lock'lar yeniden alınmış. "Sadece corosync'i restart ettim" sanısı, HA katmanına da dalga dalga yayılabiliyor. pve-c'yi resmi prosedürle çıkardım: # pve-c'de systemctl stop pve-cluster corosync # pve-a'da pvecm delnode pve-c pvecm status Nodes: 2 Expected votes: 3 Total votes: 3 Quorum: 2 0x00000000 1 Qdevice Beklenmedik detay: QDevice oyu 2'den 1'e düşmüş. lms algoritmasının formülü N-1 (node sayısı eksi bir); önceden 3-1=2'ydi, şimdi 2-1=1. pvecm delnode, node sayısını düşürse de QDevice algoritmasına (lms olarak kalmaya devam ediyor) hiç dokunmuyor; bunu elle yönetmek bize düşüyor. pve-c çıkarma işleminden sonra, ha-manager status saatlerce şunu gösterdi: fencing standby (CRM watchdog standby) lrm pve-a (wait_for_agent_lock, ...) lrm pve-b (wait_for_agent_lock, ...) Corosync/quorum seviyesi tamamen sağlıklıyken (Quorate: Yes), HA CRM/LRM katmanı ayrı bir kilitte takılı kalmıştı. Loglardaki Boot işaretleri, host laptop'un bu süre zarfında birkaç kez uyku/uyanma döngüsünden geçtiğini gösteriyordu; nested VM'ler bu geçişlerde bazen kendini resetliyor. Bu, kontrollü bir test değildi, dürüstçe belirtmem gerekiyor. Ama şunu net gösterdi: corosync seviyesinde quorum sağlıklı olması, HA katmanının da sağlıklı olduğu anlamına gelmiyor; ikisi ayrı ayrı bozulabiliyor. lms'ten ffsplit'e Geçiş Artık gerçekten 2 node'dayız; Modül 2'de "resmi olarak desteklenmiyor" dediğimiz lms yerine, resmi olarak önerilen ffsplit'i test edebileceğimiz ilk an bu. sed -i 's/algorithm: lms/algorithm: ffsplit/' corosync.conf.new pvecm status Total votes: 3 0x00000000 1 Qdevice QDevice oyu 1'de kaldı; ffsplit her zaman sabit 1 oy veriyor, lms'in değişken N-1 formülü değil. 2-node özelinde rakamsal sonuç aynı görünüyor (zaten N-1=1 burada), ama mekanizma temelden farklı; asıl fark bir node düştüğünde ortaya çıkacak. pve-b'yi çökerttim: sudo virsh destroy pve-b pvecm status Nodes: 1 Total votes: 2 Quorum: 2 Quorate: Yes 0x00000001 1 pve-a 0x00000000 1 Qdevice pve-a (1 oy) + QDevice (ffsplit'in sabit 1 oyu) = 2, eşik de 2. Quorate: Yes. Bu, Modül 2'de simüle ettiğimiz senaryonun, artık gerçekten resmi olarak desteklenen 2-node yapılandırmasında, doğru algoritmayla çalıştığının kanıtı. Asıl beklemediğim şey burada oldu. VM 102 (o an pve-b'deydi) için ha-manager status, fence durumundan sonra sonsuza kadar recovery'de takılı kaldı. Loglara baktım: journalctl -u pve-ha-crm -n 40 | grep -i "102" 08:16:50 recovering service 'vm:102' from fenced node 'pve-b' failed, no recovery node found 08:17:00 recovering service 'vm:102' from fenced node 'pve-b' failed, no recovery node found 08:17:10 recovering service 'vm:102' from fenced node 'pve-b' failed, no recovery node found ... (her 10 saniyede bir, kesintisiz tekrarlanıyor) Sebep: Modül 4'te tanımladığımız negatif resource affinity kuralı (VM 100 ve 102 asla aynı node'da olamaz) hâlâ aktifti. Tek ayakta kalan node (pve-a) zaten VM 100'ü barındırıyordu; VM 102 için yasal hiçbir hedef yoktu. Sistem bu imkansız durumu, Modül 4'teki gerçek migration hatasından (exit code 255, birkaç denemeden sonra error state'ine düşme) tamamen farklı bir şekilde ele aldı: hiç error'a düşmedi, sadece sessizce, sabırla, her 10 saniyede bir yeniden denemeye devam etti. pve-b'yi geri getirdim: sudo virsh start pve-b Birkaç dakika sonra: ha-manager status lrm pve-b (active, ...) service vm:102 (pve-b, started) pve-b geri gelir gelmez, VM 102 için nihayet yasal bir hedef oluştu (VM 100'den uzak), ve kilitlenme kendiliğinden çözüldü. Bu, Modül 3'teki "yanlış çalışmaya devam etmektense hiç çalışmamak" fail-safe felsefesinin bir üst seviyesi: burada sistem "hiç çalışmamayı" bile seçmedi, "kuralı çiğnemektense sonsuza kadar beklemeyi" seçti. HA'nın kendi kurtarma mantığı, kendi affinity kurallarıyla çelişkiye düşebiliyor, ve sistem bunu görmezden gelmiyor; askıda bırakıyor. Bu modül, planladığımdan çok daha derin bir yere gitti, ve muhtemelen serinin en yoğun modülü oldu. Birincisi, priority yerine knet_link_priority gerektiği yanlış anahtar hatası. Saatler süren bir araştırmaya (config reload mı restart mı, cmapctl'in tuhaf tek satırı, "sticky" yanlış hipotezi) yol açtı, ama sonunda man sayfasını okumanın (tahmin etmek yerine) değerini bir kez daha kanıtladı. İkincisi, pmxcfs'in arkada iki ayrı corosync.conf dosyası yönetmesi. Beş modüldür /etc/pve/corosync.conf'u düzenliyorduk, corosync'in gerçekte /etc/corosync/corosync.conf'u okuduğunu hiç fark etmemiştik. Üçüncüsü, ve en değerlisi: affinity kilitlenmesi. Bunu planlamamıştık; gerçek bir node çıkarma operasyonunun, gerçek bir node çökmesinin, ve Modül 4'te tanımladığımız bir kuralın kesişiminde kendiliğinden ortaya çıktı. HA'nın "kuralı çiğnemektense sonsuza kadar bekle" tercihi, sistemin ne kadar temkinli tasarlandığını gösteren en net kanıt oldu. Bu seride Corosync'in temellerinden (Modül 1) quorum'a (Modül 2), HA Manager'a (Modül 3), resource affinity ve CRS'e (Modül 4), ve şimdi redundant link'lere ve izleme araçlarına kadar geniş bir yüzeyi gezdim. Her modülde en az bir varsayımım yanlış çıktı, ve neredeyse her seferinde yanlış çıkan varsayım, doğru olandan daha çok şey öğretti. Bu, sanırım bu serinin özeti: hazır bir HOL yokken, doğru cevabı bilmiyor olmak bir eksiklik değil, öğrenmenin kendisiydi. Bu seri, resmi Proxmox VE dokümantasyonundan (pve.proxmox.com), corosync man sayfalarından, ve topluluk kaynaklarından derleniyor. Buradaki gözlemler bir homelab ortamına dayanıyor; production kararları için resmi dokümantasyon ve deneyimli sistem yöneticileri referans alınmalıdır.