Pacemaker ve Corosync ile RHEL KVM High Availability

Kısa cevap

Corosync üyeliği ve quorum'u, Pacemaker kaynakları yönetir. Bir host yanıt vermezse önce fencing ile izole edilir, ardından VM'ler sağlıklı hostlarda başlatılır. Fencing olmadan Red Hat HA cluster'ı desteklemez.

Mimari

Her host Corosync üyesidir. Pacemaker, VirtualDomain kaynak ajanıyla her VM'i izler. Host arızasında önce fencing tamamlanır, ardından VM başka bir host'ta başlatılır.

Örnek kaynak tanımı

Aşağıdaki komut yapı göstermek içindir; gerçek kurulumda değerler ortama göre belirlenir.

pcs resource create vm-app01 VirtualDomain \
  config=/etc/pacemaker/vm-app01.xml \
  migration_transport=ssh \
  meta allow-migrate=true \
  op monitor interval=30s

Sık yapılan hatalar

• Fencing'i devre dışı bırakmak
• Tek ağ linki üzerinden Corosync çalıştırmak
• İki node'lu cluster'da QDevice kullanmamak
• VM tanım dosyalarını paylaşımlı olmayan dizinde tutmak

Pacemaker'ın görevi

Pacemaker, her VM'i VirtualDomain kaynak ajanıyla izler; kısıtlar (constraint) ile hangi VM'in nerede, hangi sırayla çalışacağını belirler.

Corosync ve quorum

Corosync, node'lar arası mesajlaşmayı knet üzerinden taşır. Quorum, çoğunluk oyu olmayan bölümün kaynak çalıştırmasını engeller. Redundant link yapılandırması tek ağ arızasında üyelik kaybını önler.

2 node ve 3 node farkı

Üç node'lu cluster doğal çoğunluk sağlar. İki node'lu cluster'da ağ bölünmesinde tie-break için QDevice önerilir; aksi halde iki taraf birbirini fence etmeye çalışabilir.

Canlı taşıma ve failover farkı

Canlı taşıma planlıdır; VM durmadan başka hosta geçer. Failover plansızdır; host kaybında VM yeniden başlatılır, bellek içeriği korunmaz.

Arıza senaryosu: host güç kaybı

Corosync üyelik kaybını algılar → quorum'a sahip taraf fencing ajanını çalıştırır → BMC üzerinden kapanma doğrulanır → VM kaynakları kısıtlara göre diğer hostlarda başlatılır.

Arıza senaryosu: cluster ağı kopması

Host çalışmaya devam ediyor olsa bile üyelikten düşer. Fencing, aynı VM'in iki yerde çalışmasını engellemek için hostu kapatır. Bu yüzden cluster ağı yedekli tasarlanır.

Kabul testleri

• Her node için manuel fence testi
• Cluster ağı link kesme testi
• Host güç kesme ile failover
• Canlı taşıma ile bakım moduna alma

Arıza senaryosu: bir host yanıt vermeyi bıraktığında

Corosync token'ı belirlenen süre içinde ilgili düğümden dönmezse düğüm üyelikten düşer. Kalan düğümler quorum'a sahipse Pacemaker, düğümün durumunu bilinmez kabul eder ve önce fencing ister. Fencing başarıyla tamamlanmadan o düğümdeki VirtualDomain kaynakları başka yerde başlatılmaz; aynı diskin iki yerde açılmasını önleyen kural budur.

Fencing başarılı olduğunda kaynaklar, konum kısıtları (location constraint), sıralama (order) ve birliktelik (colocation) kurallarına göre sağlıklı düğümlerde başlatılır. Bu bir yeniden başlatmadır, canlı taşıma değildir: konuk işletim sistemi açılış süresi kadar kesinti olur.

Sık yapılan hatalar

Sahada en sık karşılaşılan yapılandırma sorunları büyük ölçüde test edilmemiş varsayımlardan kaynaklanır:

• Fencing'i devre dışı bırakarak (stonith-enabled=false) cluster'ı üretime almak — Red Hat bu yapılandırmayı desteklemez.
• Corosync trafiğini tek bir ağ yolunda bırakmak; anlık bir switch sorunu gereksiz fencing'e yol açabilir.
• Fencing cihazına (iLO/iDRAC/IPMI) erişimi, izlenen ağla aynı yoldan sağlamak.
• VM'lerin libvirt autostart ayarını açık bırakmak; kaynak hem Pacemaker hem libvirt tarafından başlatılmaya çalışılır.
• Kısıtları yalnızca kağıt üzerinde tasarlayıp `pcs constraint` çıktısıyla doğrulamamak.

Kabul testi

Üretime geçişten önce her düğüm için en az şu testlerin kayıt altına alınması gerekir:

• `pcs stonith fence <düğüm>` ile manuel fencing ve düğümün geri katılması
• Corosync ağının bir bacağının kesilmesi — cluster'ın etkilenmemesi
• Bir host'un güç kesintisi — VM'lerin beklenen sürede diğer düğümde açılması
• Bakım modu (`pcs node standby`) ile kaynakların kontrollü boşaltılması

pcs status --full
pcs stonith config
pcs constraint --full
corosync-cfgtool -s