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ı (, izole ağı).
Management ağını () olarak ekleyip gerçek bir yedeklilik kurdum; 'u kopyalayıp düzenleyip atomik olarak yerine taşıdım: Doğrulama: Teknik olarak başarılı; iki link de bağlı.
Ama log'a dikkatlice bakınca, mimarimizin niyetini tersine çeviren bir şey oldu: modunda, öncelik eşitken düşük numaralı link kazanıyor. 'ı sonradan eklediğim için, o Corosync'in asıl trafiğini üstlenmiş; Modül 0'da özellikle izole ettiğimiz () sessizce yedek konuma düşmüştü.
Yanlış Anahtar, Saatler Süren Bir Araştırma Bunu düzeltmek için 'e daha yüksek öncelik vermeye çalıştım: İşe yaramadı. sadece tek, indekslenmemiş bir satır gösterdi: .
Diğer parametreler (, ) düzgün şekilde / diye ayrılmışken, öyle değildi.
Log'da "best link" seçimi hâlâ gösteriyordu; bizim verdiğimiz değer hiç okunmamıştı.
Tam bir servis restart'ının () sorunu çözebileceğini düşündüm; denedim, çözmedi.
Restart, 'yı ~13 saniyeliğine cluster'dan düşürdü (), ama yine tek, indekslenmemiş kaldı.
Sebep, resmi man sayfasında () çıktı: doğru anahtar değil, .
Bizim yazdığımız , 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 Bu sefer düzgün indekslenmiş.
Log de anında değişti: Corosync her iki linki de değerlendirip yüksek öncelikli olanı (, corosync-net) seçmiş.
Kesme ve Geri Getirme Testi 'i fiziksel host'tan kestim: Anında 'a geçiş; kesintisiz kaldı, hâlâ tam oy sayısıyla.
Sonra geri açtım: Saniyeler içinde '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ı : Daha Okunabilir Bir Alternatif İçerik ile aynı, ama membership tablosu hex ID () 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 Modül 0'da bulduğumuz formül: . 3 node ile: .
Tam uyuyor. .
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ı (pmxcfs) loglarına bakınca, hiç bilmediğimiz bir mekanizma ortaya çıktı: Bir saniye sonra, corosync log'unda: Şimdiye kadar hep 'u düzenledik; bu, pmxcfs üzerinden cluster geneline otomatik yayılan sanal bir dosya.
Ama corosync daemon'ının kendisi aslında '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 denememizin ardından, / 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 'yi resmi prosedürle çıkardım: Beklenmedik detay: QDevice oyu 2'den 1'e düşmüş. algoritmasının formülü (node sayısı eksi bir); önceden 3-1=2'ydi, şimdi 2-1=1. , node sayısını düşürse de QDevice algoritmasına ( olarak kalmaya devam ediyor) hiç dokunmuyor; bunu elle yönetmek bize düşüyor.
Ortamın Kararsızlığı: Beklenmedik Bir HA Kilitlenmesi çıkarma işleminden sonra, saatlerce şunu gösterdi: Corosync/quorum seviyesi tamamen sağlıklıyken (), HA CRM/LRM katmanı ayrı bir kilitte takılı kalmıştı.
Loglardaki 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: 'ten 'e Geçiş Artık gerçekten 2 node'dayız; Modül 2'de "resmi olarak desteklenmiyor" dediğimiz yerine, resmi olarak önerilen 'i test edebileceğimiz ilk an bu.
QDevice oyu 1'de kaldı; her zaman sabit 1 oy veriyor, 'in değişken formülü değil. 2-node özelinde rakamsal sonuç aynı görünüyor (zaten burada), ama mekanizma temelden farklı; asıl fark bir node düştüğünde ortaya çıkacak.
Gerçek Bir 2-Node + QDevice Testi 'yi çökerttim: (1 oy) + QDevice ('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 'deydi) için , durumundan sonra sonsuza kadar 'de takılı kaldı.
Loglara baktım: 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 () 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 (, birkaç denemeden sonra state'ine düşme) tamamen farklı bir şekilde ele aldı: hiç 'a düşmedi, sadece sessizce, sabırla, her 10 saniyede bir yeniden denemeye devam etti. 'yi geri getirdim: Birkaç dakika sonra: 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, yerine 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 'u düzenliyorduk, corosync'in gerçekte '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