keepalived VRRP_script başarısız değil


11

Bu yüzden iki sunucuda keepalived çalıştırıyorum ve diğerine yük devretme alamıyorum.

Aşağıda sunuculardan biri için yapılandırmam var. İkisi arasındaki tek fark öncelik sayıları ustası 110 ve geriye 109'dur.

Ancak /etc/init.d/process ile işlemimi durdurduğumda keep keepiveived başarısız olmaz. Ben sadece VRRP_Script (chk_script) başarısız olsun ve başka bir şey olsun. Yük devretme yok ya da hiçbir şey.

vrrp_script chk_script {
script "/usr/local/bin/failover.sh"
interval 2
weight 2
}

vrrp_instance HAInstance {
state BACKUP
interface eth0
virtual_router_id 8
priority 109
advert_int 1
nopreempt
vrrp_unicast_bind 10.10.10.8
vrrp_unicast_peer 10.10.10.9
virtual_ipaddress {
  10.10.10.10/16 dev eth0
}
notify /usr/local/bin/keepalivednotify.sh
track_script {
  chk_script weight 20
}
}

Bu benim chk_script'im. Komut dosyası olarak -0 işlemi killall yaptığımda da aynı sorun olur.

!/bin/bash
SERVICE='process'
STATUS=$(ps ax | grep -v grep | grep $SERVICE)

if [ "$STATUS" != "" ]
then
    exit 0
else
    exit 1
fi

Bunun için bir düzeltme bilen var mı? Teşekkürler.


Yedek örneğiniz öncelik değişikliğini fark eder veya herhangi bir şey kaydeder mi? Her ikisi de günlükleri yardımcı olacaktır.
Jim

Hayır değil. Bir değişikliği fark ettiği tek zaman, efendinin gittiği zamandır. Kalıcı olmayı bıraktığım zamanki gibi. İzlediğim işlemin durdurulması, yalnızca master'da VRRP_Script'in (chk_script) başarısız olduğunu gösterir. Köle üzerinde hiçbir şey yok.
Nvasion

Yanıtlar:


13

Sorunum güvenlik duvarında veya Ethernet bağdaştırıcımda değil, kontrol komut dosyasının "ağırlık" ayarlarında olduğu için aynı sorunu yaşadım.

Bu benim yapılandırmamdı:

USTA:

vrrp_instance haproxy {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1

DESTEK OLMAK:

vrrp_instance haproxy {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1

Check_script:

vrrp_script chk_haproxy {
   script "python /root/ha_check.py"
   interval 2     # check every 2 seconds
   weight 2
   rise 2
   fall 2

}

Master'ın VIP'yi serbest bırakmayı reddetmesinin nedeni, komut dosyasının başarısız olmasına rağmen, master'ın BACKUP sunucusundan daha yüksek öncelik numarasına sahip olmasıydı. Bunun nedeni, check_script üzerindeki "ağırlık" ayarının öncelik numarası arasındaki "GAP" ı kapsaması için yeterli olmaması, BACKUP sunucusunun öncelik numarasını MASTER Server'ınkinden daha fazla artırmasıdır. Daha fazla açıklayacağım:

Kalıcı kullanım kılavuzuna göre, "ağırlık" ayarındaki pozitif bir sayı, kontrol başarılı olursa bu sayıyı önceliğe ekler.
Kontrol başarısız olursa, negatif bir sayı bu sayıyı öncelik numarasından çıkaracaktır.

Yani, benim yapılandırmaya göre:

Sunucu Öncelikleri Komut dosyasında önceki hata:
MASTER: 152
YEDEK: 100
Yük Devretme_IP: MASTER

Yük Devretme ipi, Ana sunucu Yedekleme sunucusundan daha yüksek önceliğe sahip olduğundan ana sunucu tarafından doğru bir şekilde "yakalanır" (152> 100)

Sunucu Öncelikleri Komut dosyasında hata SONRASI:
MASTER sunucusu: 148
BACKUP sunucusu: 102
Yük devretme_IP: STILL ON MASTER

Yük Devretme ipi hala ana sunucudadır, çünkü Ana Bilgisayar YEDEKLEME'ye (148> 102) göre daha yüksek önceliğe sahiptir. MASTER sunucusu, önceliği diğer sunucudan daha yüksek olduğu için IP'yi ve doğru hakkı vermeyi reddetti.

Durumumdaki çözüm şuydu:

Çözüm -1: Her iki sunucunun öncelik sayısını, çok fazla "GAP" olmaması için değiştirin.
Örneğin:
Ana Öncelik: 150
Yedekleme Önceliği: 149
Check_script ağırlığı: Olduğu gibi (2).

Yukarıdaki yapılandırmada, komut dosyası başarılı olduğunda (her şey yolundadır ) öncelikler şöyle olur:
Ana: 152
Yedekleme: 149
IP_Location: Master'da (152> 149)

Komut dosyası başarısız olduğunda:
Master: 150
Yedekleme: 151
IP_Location: Yedeklemede (151> 150)

Çözüm - 2: Betiğin ağırlık sayısını 2'den -60'a değiştirin


Ayrıca bir ağırlık belirtmemek, başarısız bir track_script'in arıza durumunu doğrudan tetikleyeceği anlamına gelir
Oscar

@Nvasion: Sorunumu çözdüğüm için lütfen bu yanıtı kabul et.
Ankur Soni

4

Ben aynı sorunu yaşadım - track_script ile iki CentOS 7.1 sunucusu ve MASTER vrrp_script başarısız bir yük devretme değil, sadece yalnız günlük mesajı "VRRP_Script (chk_script) başarısız" ile sonuçlanacaktır. Ancak BACKUP sunucusunda, MASTER sunucusunda track_script başarısız olduğu sürece sanal IP'yi ele geçirmeye çalışan keepalived çok fazla mesaj aldım.

Benim durumumdaki çözüm: MASTER sunucusundaki güvenlik duvarı (iptables), VRRP paketlerine / çok noktaya yayın paketlerine izin verecek şekilde doğru yapılandırılmamışken, diğer sunucudaki YEDEKLEME, doğru şekilde yapılandırıldı.

Her iki sunucuya da aynı iptables kurallarını girmiştim:

iptables -A INPUT -i eth0 -d 224.0.0.0/8 -j ACCEPT
iptables -A INPUT -p vrrp -i eth0 -j ACCEPT

Bu, sunuculardan birinde (BACKUP VRRP sunucusu) çalıştı, ancak MASTER'da değil, arayüzün MASTER sunucusunda 'eth0' olarak adlandırılmadığını unutmuştum, bu nedenle iki kuralın hiçbir etkisi olmadı.

Bu gözlemlediğim davranışı açıkladı:

Keepalived, belirli bir virtual_router_id için başka bir VRRP hoparlörü göremezse, negatif ağırlık modifikasyonundan sonra bile asla kendisinden daha yüksek bir önceliğe sahip VRRP mesajları almadığı için kendisinin en yüksek önceliğe (dolayısıyla haklı MASTER) olduğuna hala inanır ( çünkü diğer hoparlörlerin reklamları güvenlik duvarı tarafından engellenir ve onları haberdar etmek için hiçbir zaman kalıcı hale getirilmiş sürece ulaşamaz). Bu yüzden VIP'i çıkardığını görmüyorsunuz.

Ancak BACKUP sunucusu, (şimdi başarısız) MASTER'in reklamlarını görebildi, bu paketlerdeki önceliği kendi değerinden daha düşük bir değere indirgedi ve kendini MASTER ilan etmeye ve VIP'yi talep etmek için ücretsiz ARP'ler göndermeye devam etti. Böylece her iki sunucunun da VIP'i MASTER olarak sunmaları gerektiğini düşündükleri bir duruma geldik.

Sonuçlar: - Garip davranışlarla karşılaşırsanız (yük devretme yok, birkaç MASTER) her zaman tüm VRRP hoparlörlerde güvenlik duvarı yapılandırmasını kontrol edin. Tutulan günlük kaydı olabildiğince yararlı değildir ("VRRP_Script (chk_script) başarısız" satırından sonra basit bir mesaj "VIP yayınlanmadı çünkü hala en yüksek prio'yum"), sorun gidermeyi son derece kolaylaştırdı.

  • Bir track_script, açma / kapama anahtarı değildir ("komut dosyası Tamam ise: VIP seçimi için uygun; Tamam değilse: VIP seçimi için tamamen uygun değil") - yalnızca seçimi kazanma olasılığını artırır / azaltır ve yalnızca saklanırsa kendisini tek VRRP hoparlörü olarak gözlemliyor ve hiçbir zaman diğer hoparlörlerden mesaj almıyor, gerçekten çok fazla seçim yok - her zaman kazanıyorsunuz.

0

Ben sadece seninle aynı duruma geldim ve bazı canlılar üzerinde çalıştım. Her sunucuda neler olduğunu düşünelim. Manuel geri dönme mimarisini uygulamak istediğinizi varsayarsak,

1. YEDEK düğümünde

Track_script, düşme zamanını her başarısızlığa uğradığında , reklamı 2. YEDEK düğümüne gönderir. Burada, reklamın içinde yer alan Öncelik yer almaktadır . Senin durumunda,

129 (109 + 20)

2. YEDEKLEME sunucusuna gönderilir.

2. BACKUP sunucusunda

Sonraki, 2. YEDEK düğümünde.

RFC'ye göre ,

If the Priority in the ADVERTISEMENT is Zero, then:

  o  Set the Master_Down_Timer to Skew_Time
else:

  If Preempt_Mode is False, or If the Priority in the
  ADVERTISEMENT is greater than or equal to the local
  Priority, then:

    o Reset the Master_Down_Timer to Master_Down_Interval
  else:

    o Discard the ADVERTISEMENT
  endif
endif

Eğer var, yana nopreempt etkin ve yüksek öncelikli VRRP alma, 2. YEDEK düğüm durum geçiş fazına gitmiyor.

Çözüm

Yani 2. geçişte durum geçişini gerçekleştirmek istiyorsanız,

  1. Set ağırlığı için 0 1 YEDEK düğümünde. Bu, Öncelik 0 reklamını 2. YEDEK düğümüne gönderir . doc ağırlık 0 hakkında daha fazla bilgi verir.

  2. 2. BACKUP düğümündeki nopreempt'i kapatın .

  3. 1. YEDEK düğümünde ağırlığı en az -2 olarak ayarlayın .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.