DEV Community

Hakan İSMAİL
Hakan İSMAİL

Posted on

# HA Manager: Watchdog, Fencing ve Node Affinity (Modül 3)

Seri: Proxmox VE Cluster ve Corosync

Modül 1'de bir node çökünce VM'in kendiliğinden hiçbir yerde açılmadığını göstermiştim; cluster kurmak otomatik yüksek erişilebilirlik demek değildi. Bu modülde o boşluğu dolduran parçaya geçiyorum: HA Manager. Watchdog tabanlı fencing'i, gerçek bir node çökmesinde recovery'nin saniye saniye nasıl işlediğini, ve bir node affinity kuralının beklediğimden çok daha proaktif davrandığını, hepsini gerçekten test ederek öğrendim.

Bu modülde her adımı hem terminalden hem web arayüzünden gösteriyorum; ikisi aynı API'yi kullanıyor, ama bazen birini görmek diğerini daha iyi anlamana yardımcı oluyor.

HA Manager Nedir?

Proxmox VE'nin HA stack'i, Pacemaker gibi harici bir araç gerektirmiyor; kendi başına çalışan bir çözüm. İki daemon var: pve-ha-lrm (Local Resource Manager), her node'da çalışıp o node'daki servisleri kontrol ediyor; pve-ha-crm (Cluster Resource Manager), cluster genelinde kararlar alıyor, sadece bir node'da aktif "master" olabiliyor.

Fencing, bir node arızalandığında onun gerçekten "offline" olduğundan emin olma süreci. Bu kritik, çünkü fence edilmemiş bir node hâlâ shared storage'a erişebiliyor olabilir; aynı VM'i başka bir node'da başlatmak, iki node'un aynı diske aynı anda yazmasına yol açabilir. Proxmox, harici fencing donanımı gerektirmeyen bir yöntem kullanıyor: watchdog timer tabanlı self-fencing. ha-manager, watchdog timer'ı düzenli olarak resetliyor; bir arıza nedeniyle bu reset gerçekleşmezse, timer node'u otomatik olarak reboot ediyor.

Burada altta yatan tasarım felsefesi ilginç: node'un "belki çalışıyordur, belki bozuktur" gibi belirsiz bir durumda kalmasına izin verilmiyor, doğrudan tam bir reboot'a zorlanıyor. Mantığı şu: bir node yarım yamalak, tutarsız bir durumda çalışmaya devam ederse (örneğin ağı kopmuş ama diski hâlâ yazabiliyorsa), bu durum veri bozulmasına yol açabilir; oysa node tamamen durursa, en azından zarar vermeye devam etmiyor. Yanlış çalışmaya devam etmektense hiç çalışmamak, burada bilinçli bir güvenlik tercihi.

Uygulama 1: Watchdog'u Doğrulamak

Nested lab'ımda donanım watchdog yok, Proxmox varsayılan olarak softdog kernel modülüne düşüyor:

cat /etc/default/pve-ha-manager
Enter fullscreen mode Exit fullscreen mode 
# select watchdog module (default is softdog)
#WATCHDOG_MODULE=ipmi_watchdog
Enter fullscreen mode Exit fullscreen mode

Satır yorumlu, yani varsayılan (softdog) kullanılıyor. Doğrulamak için ilk denediğim komut boş döndü:

lsmod | grep watchdog
Enter fullscreen mode Exit fullscreen mode 
(boş çıktı)
Enter fullscreen mode Exit fullscreen mode

Bir an modülün yüklü olmadığını düşündüm. Ama hata bendeydi: "softdog" kelimesi harfi harfine "watchdog" içermiyor. Doğrusu:

lsmod | grep dog
Enter fullscreen mode Exit fullscreen mode 
softdog                12288  2
Enter fullscreen mode Exit fullscreen mode

Modül yüklü. /dev/watchdog ve /dev/watchdog0 cihazları da mevcuttu:

ls -la /dev/watchdog*
Enter fullscreen mode Exit fullscreen mode 
crw------- 1 root root  10, 130 Aug 15 07:41 /dev/watchdog
crw------- 1 root root 243,   0 Aug 15 07:41 /dev/watchdog0
Enter fullscreen mode Exit fullscreen mode

Uygulama 2: VM'i HA'ya Eklemek 

ha-manager add vm:100 --state started
ha-manager status
Enter fullscreen mode Exit fullscreen mode 
quorum OK
master pve-a (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (active, watchdog active, ...)
lrm pve-b (idle, watchdog standby, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-a, started)
Enter fullscreen mode Exit fullscreen mode

Aynı işlem web arayüzünden de yapılabiliyor: Datacenter → HA → Resources.

Datacenter → HA → Resources ekranı, boş kaynak listesi

"Add" butonuna basıp VM'i ve başlangıç durumunu (started) seçiyorsun:

Add HA Resource diyaloğu - VM 100 ve state seçimi

Dikkat çeken bir detay: pve-a hem VM'i barındırıyor hem de CRM master'ı. Bu, sıradaki testi daha ilginç kılıyor; pve-a'yı çökertince sadece VM'in taşınıp taşınmayacağını değil, cluster'ın yeni bir master seçip seçemeyeceğini de gözlemleyeceğim.

Uygulama 3: Gerçek Bir Çökme, Saniye Saniye

Host'tan ping'i başlattım:

ping 192.168.122.251
Enter fullscreen mode Exit fullscreen mode

Ping başlatma - terminal görüntüsü

Sonra pve-a'yı fiziksel host'tan çökerttim:

sudo virsh destroy pve-a
Enter fullscreen mode Exit fullscreen mode

Ping çıktısı Modül 1/2'deki tanıdık deseni tekrarladı: önce sessiz paket kaybı, sonra gateway'in aktif "Destination Host Unreachable" demesi.

İlk kontrolüm (çökmeden ~10 saniye sonra), pve-b'den:

ha-manager status
Enter fullscreen mode Exit fullscreen mode 
quorum OK
master pve-c (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (active, watchdog active, ...)
lrm pve-b (idle, watchdog standby, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-a, started)
Enter fullscreen mode Exit fullscreen mode

Yeni master seçimi hızlı gerçekleşmişti (master pve-c olmuştu), ama VM henüz taşınmamıştı; bu, sürecin ortasında bir "anlık fotoğraf". Birkaç dakika sonra aynı komutu tekrar çalıştırdım:

ha-manager status
Enter fullscreen mode Exit fullscreen mode 
quorum OK
master pve-c (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (old timestamp - dead?, watchdog standby, ...)
lrm pve-b (active, watchdog active, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-b, started)
Enter fullscreen mode Exit fullscreen mode

HA Status ekranı - vm:100 pve-b'de started, lrm pve-a

VM gerçekten pve-b'ye taşınmış. lrm pve-a'nın durumu da ilginçti: sistem bile kesin konuşmuyor, "old timestamp - dead?" diye soru işaretiyle yazıyor.

Tam Zaman Çizelgesi

Tahmin etmek yerine pve-c'nin (master) CRM loglarına baktım:

journalctl -u pve-ha-crm --since "19:46:00" --until "19:50:00"
Enter fullscreen mode Exit fullscreen mode 
19:46:53  node 'pve-a': state changed from 'online' => 'unknown'
19:47:43  service 'vm:100': state changed from 'started' to 'fence'
19:47:43  node 'pve-a': state changed from 'unknown' => 'fence'
19:48:43  successfully acquired lock 'ha_agent_pve-a_lock'
19:48:43  fencing: acknowledged - got agent lock for node 'pve-a'
19:48:43  service 'vm:100': state changed from 'fence' to 'recovery'
19:48:43  recover service 'vm:100' from fenced node 'pve-a' to node 'pve-b'
19:48:43  service 'vm:100': state changed from 'recovery' to 'started'  (node = pve-b)
Enter fullscreen mode Exit fullscreen mode

pve-a'yı çökerttiğim an ~19:46:33'tü. Üç net faz ortaya çıktı:

Algılama (~20 saniye): çökme → online => unknown (19:46:53). Corosync'in kaybı fark edip CRM'e bildirmesi.

Fence kararı (tam 50 saniye): unknown → fence (19:47:43). Muhtemelen ani bir yanlış pozitiften kaçınmak için bekletilen bir politika süresi.

Watchdog güvenlik beklemesi (tam 60 saniye): fence → lock alındı, VM pve-b'de başladı (19:48:43). Bu rakam tesadüf değil; watchdog'un kendi kendini resetleyeceği tam süreyi (tipik 60 saniye) bekliyor, "belki node hâlâ hayatta ve VM'i çalıştırıyordur" ihtimalini sıfırlıyor.

Toplam: ~130 saniye (virsh destroy'dan VM'in yeni node'da çalışmasına kadar).

Uygulama 4: Double-Start'ın Yapısal Olarak İmkansız Olduğunu Kanıtlamak

En kritik soru: pve-a geri gelince VM'i ikinci kez başlatmaya çalışacak mı? İki node'un aynı diske aynı anda yazması gerçek bir felaket senaryosu olurdu.

sudo virsh start pve-a
Enter fullscreen mode Exit fullscreen mode

Boot tamamlandıktan sonra, pve-a'da:

qm status 100
Enter fullscreen mode Exit fullscreen mode 
Configuration file 'nodes/pve-a/qemu-server/100.conf' does not exist
Enter fullscreen mode Exit fullscreen mode

Bu, Modül 1'de gördüğüm birebir aynı hata mesajı, ama tamamen farklı bir anlamda. Modül 1'de bu, "kimse bu VM'i başlatmayacak" demekti. Burada ise: fencing + recovery süreci, VM'in config dosyasını pmxcfs üzerinden gerçekten pve-b'nin dizinine taşımış. pve-a'da böyle bir dosya artık hiç yok. Bu, double-start'ı sadece "önlenmiş" değil, yapısal olarak imkansız kılıyor: pve-a geri gelse bile, elinde VM'i başlatacak bir config bile bulamıyor.

Bunu iki node'dan bağımsız olarak doğruladım. pve-b'de:

pvecm status
ha-manager status
Enter fullscreen mode Exit fullscreen mode 
Nodes:            3
Quorate:          Yes
Total votes:      5
Quorum:           3
Flags:            Quorate Qdevice
...
quorum OK
master pve-c (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (idle, watchdog standby, ...)
lrm pve-b (active, watchdog active, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-b, started)
Enter fullscreen mode Exit fullscreen mode

pve-a'da, aynı anda:

pvecm status
ha-manager status
Enter fullscreen mode Exit fullscreen mode 
Nodes:            3
Quorate:          Yes
Total votes:      5
Quorum:           3
Flags:            Quorate Qdevice
...
quorum OK
master pve-c (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (idle, watchdog standby, ...)
lrm pve-b (active, watchdog active, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-b, started)
Enter fullscreen mode Exit fullscreen mode

Birebir tutarlı: 5 oy, 3 node, vm:100 (pve-b, started), fencing armed. lrm pve-a, hiçbir manuel müdahale gerekmeden, kendiliğinden "old timestamp - dead?" durumundan "idle"a döndü.

Uygulama 5: Node Affinity, Beklediğimden Daha Proaktif

Her şey sağlıklıyken, VM'in tercihen pve-a'da kalmasını söyleyen bir kural tanımladım:

ha-manager rules add node-affinity prefer-pve-a --resources vm:100 --nodes pve-a
Enter fullscreen mode Exit fullscreen mode

Aynı işlem web arayüzünden: Datacenter → HA → Rules.

Datacenter → HA → Rules ekranı

"Add" → "Node Affinity Rule" diyip kaynağı ve tercih edilen node'u seçiyorsun:

Add Node Affinity Rule diyaloğu - vm:100, pve-a

Beklentim şuydu: bu kural sadece bir sonraki arıza/recovery anında devreye girer, halihazırda sağlıklı çalışan bir servisi kendiliğinden taşımaz. Yanılmışım.

Kuralı ekledikten saniyeler sonra, tekrar baktığımda:

ha-manager status
Enter fullscreen mode Exit fullscreen mode 
service vm:100 (pve-b, migrate)
Enter fullscreen mode Exit fullscreen mode

HA Status - vm:100 migrate durumunda

VM zaten taşınmaya başlamıştı; hem de fence ya da relocate değil, migrate durumunda; yani VM durdurulup yeniden başlatılmadı, gerçek bir canlı migration tetiklendi. ~25-30 saniye sonra, tekrar:

ha-manager status
Enter fullscreen mode Exit fullscreen mode 
service vm:100 (pve-a, started)
Enter fullscreen mode Exit fullscreen mode

HA Status - vm:100 pve-a'da started

Tamamlanmıştı. Hiçbir arıza olmadan, ben sadece bir tercih tanımladığım için, HA Manager kendiliğinden mevcut durumu istenen duruma yakınsatmış. Bu, HA Manager'ın sadece reaktif (arızaya tepki veren) değil, aynı zamanda proaktif (deklare edilen tercihe kendiliğinden yaklaşan) bir sistem olduğunu gösterdi; bunu önceden bilmiyordum, test etmeden öğrenemezdim.

Son doğrulama:

qm status 100
Enter fullscreen mode Exit fullscreen mode 
status: running
Enter fullscreen mode Exit fullscreen mode 
pvecm status
ha-manager status
ha-manager rules list
Enter fullscreen mode Exit fullscreen mode 
Nodes:            3
Quorate:          Yes
Total votes:      5
Quorum:           3
...
service vm:100 (pve-a, started)
...
┌──────────────┐
│ rule         │
╞══════════════╡
│ prefer-pve-a │
└──────────────┘
Enter fullscreen mode Exit fullscreen mode

Tamamen tutarlı: VM çalışıyor, cluster quorate, kural hâlâ kayıtlı.

Genel Değerlendirme

Bu modülde üç şey beni özellikle şaşırttı.

Birincisi, fencing'in üç net fazlı, toplamda ~130 saniyelik bir süreç olması. "HA var, arıza olunca hemen düzelir" gibi belirsiz bir beklentim vardı; gerçekte sistem, her biri ayrı bir amaca hizmet eden (algılama, yanlış pozitiften kaçınma, watchdog güvenlik payı) üç ayrı bekleme süresinden geçiyor. Bu, hız değil, güvenlik önceliğiyle tasarlanmış bir sistem.

İkincisi, pve-a'nın config dosyasının gerçekten pve-b'ye taşınmış olması. Double-start korumasını "kilitli bir mekanizma" gibi hayal etmiştim; gerçekte çok daha basit ve zarif: VM'i başlatacak bilgi artık orada yok, o yüzden başlatılamıyor.

Üçüncüsü, node affinity kuralının proaktif davranışı. Bu, testin planımı tersine çevirdiği bir andı; "muhtemelen böyle çalışır" diye düşünüp geçebilirdim, ama gerçekten test edince tam tersini gördüm. Modül 2'de de benzer bir şey olmuştu (split-brain'i tetiklemeye çalışıp başaramamak); bu serinin tekrar eden bir teması gibi görünüyor: varsayımlarım, gerçek testlerden daha az güvenilir çıkıyor.

Bir sonraki modülde, HA Manager'ı biraz daha zorlayacağım: birden fazla VM ile resource affinity kurallarını (aynı node'da tutma/ayrı tutma), ve CRS'in (Cluster Resource Scheduler) yük dengeleme davranışını test edeceğim.

Bu seri, resmi Proxmox VE dokümantasyonundan (pve.proxmox.com) 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)