DEV Community

Hakan İSMAİL
Hakan İSMAİL

Posted on

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

#infrastructure #linux #monitoring #networking

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.

Bölüm 1: Redundant Corosync Links

Kurulum: İkinci Link'i Eklemek

Ş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
Enter fullscreen mode Exit fullscreen mode

Doğrulama:

corosync-cfgtool -s
Enter fullscreen mode Exit fullscreen mode 
LINK ID 0 udp
    addr    = 192.168.122.11
    status: ... connected ... connected
LINK ID 1 udp
    addr    = 10.10.10.11
    status: ... connected ... connected
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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ü.

Yanlış Anahtar, Saatler Süren Bir Araştırma

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
}
Enter fullscreen mode Exit fullscreen mode

İş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ş.

Doğru Syntax, Kesin Kanıt 

interface {
  linknumber: 0
  knet_link_priority: 5
}
interface {
  linknumber: 1
  knet_link_priority: 10
}
Enter fullscreen mode Exit fullscreen mode 
corosync-cmapctl | grep -i "interface.*priority"
Enter fullscreen mode Exit fullscreen mode 
totem.interface.0.knet_link_priority (u8) = 5
totem.interface.1.knet_link_priority (u8) = 10
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

Corosync her iki linki de değerlendirip yüksek öncelikli olanı (link1, corosync-net) seçmiş.

Kesme ve Geri Getirme Testi

link1'i fiziksel host'tan kestim:

sudo virsh domif-setlink pve-a vnet0 down
Enter fullscreen mode Exit fullscreen mode 
[KNET  ] link: host: 3 link: 1 is down
[KNET  ] host: host: 3 (passive) best link: 0 (pri: 5)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
[KNET  ] rx: host: 3 link: 1 is up
[KNET  ] host: host: 3 (passive) best link: 1 (pri: 10)
Enter fullscreen mode Exit fullscreen mode

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.

Bölüm 2: İzleme Araçları

corosync-quorumtool: Daha Okunabilir Bir Alternatif 

corosync-quorumtool -s
corosync-quorumtool -l
Enter fullscreen mode Exit fullscreen mode

İç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.

Token/Consensus Formülünü Canlı Doğrulamak 

corosync-cmapctl | grep -E 'totem.token|totem.consensus'
Enter fullscreen mode Exit fullscreen mode 
runtime.config.totem.token (u32) = 3125
runtime.config.totem.consensus (u32) = 3750
totem.token_coefficient (u32) = 125
Enter fullscreen mode Exit fullscreen mode

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.

Beklenmedik Bulgu: İki Ayrı corosync.conf

pve-cluster (pmxcfs) loglarına bakınca, hiç bilmediğimiz bir mekanizma ortaya çıktı:

journalctl -u pve-cluster -n 20
Enter fullscreen mode Exit fullscreen mode 
[dcdb] notice: wrote new corosync config '/etc/corosync/corosync.conf' (version = 7)
Enter fullscreen mode Exit fullscreen mode

Bir saniye sonra, corosync log'unda:

[CFG] Config reload requested by node 1
Enter fullscreen mode Exit fullscreen mode

Ş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.

Yan Etki: Corosync Restart'ı HA'ya da Yayılıyor

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.

Bölüm 3: Bir Node'u Gerçekten Çıkarmak

Prosedür

pve-c'yi resmi prosedürle çıkardım:

# pve-c'de
systemctl stop pve-cluster corosync

# pve-a'da
pvecm delnode pve-c
Enter fullscreen mode Exit fullscreen mode 
pvecm status
Enter fullscreen mode Exit fullscreen mode 
Nodes: 2
Expected votes: 3
Total votes: 3
Quorum: 2
    0x00000000    1    Qdevice
Enter fullscreen mode Exit fullscreen mode

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.

Ortamın Kararsızlığı: Beklenmedik Bir HA Kilitlenmesi

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, ...)
Enter fullscreen mode Exit fullscreen mode

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.

Bölüm 4: 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
Enter fullscreen mode Exit fullscreen mode 
pvecm status
Enter fullscreen mode Exit fullscreen mode 
Total votes: 3
    0x00000000    1    Qdevice
Enter fullscreen mode Exit fullscreen mode

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.

Gerçek Bir 2-Node + QDevice Testi

pve-b'yi çökerttim:

sudo virsh destroy pve-b
Enter fullscreen mode Exit fullscreen mode 
pvecm status
Enter fullscreen mode Exit fullscreen mode 
Nodes: 1
Total votes: 2
Quorum: 2
Quorate: Yes
    0x00000001    1    pve-a
    0x00000000    1    Qdevice
Enter fullscreen mode Exit fullscreen mode

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ı.

Bölüm 5: Beklenmedik Kapanış, Affinity Kilitlenmesi

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"
Enter fullscreen mode Exit fullscreen mode 
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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Birkaç dakika sonra:

ha-manager status
Enter fullscreen mode Exit fullscreen mode 
lrm pve-b (active, ...)
service vm:102 (pve-b, started)
Enter fullscreen mode Exit fullscreen mode

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.

Genel Değerlendirme

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.

Top comments (0)