keepalived VRRP_script nie ulega awarii

Dlatego korzystam z keepalived na dwóch serwerach i nie mogę przejść do trybu failover na innym.

Poniżej mam konfigurację dla jednego z serwerów. Jedyną różnicą między nimi jest to, że master numerów priorytetowych to 110, a back to 109.

Ale kiedy zatrzymuję proces za pomocą /etc/init.d/process stop keepalived nie przechodzi w tryb failover. Właśnie dostałem błąd VRRP_Script (chk_script) i nic więcej. Brak przełączeń awaryjnych lub nic.

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
}
}

To jest mój skrypt chk_script poniżej. Ten sam problem występuje również, gdy wykonuję proces killall -0 jako mój skrypt.

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

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

Czy ktoś zna rozwiązanie tego problemu? Dzięki.

Miałem dokładnie ten sam problem, jednak mój problem nie dotyczył zapory ani adaptera Ethernet, ale ustawienia „wagi” skryptu sprawdzającego.

To była moja konfiguracja:

MISTRZ:

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

UTWORZYĆ KOPIĘ ZAPASOWĄ:

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

Skrypt kontrolny:

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

}

Powodem, dla którego mistrz odmówił wydania VIP, było to, że pomimo niepowodzenia skryptu, master nadal miał wyższy priorytet z serwera BACKUP. Stało się tak, ponieważ ustawienie „weight” na check_script nie wystarczało do pokrycia „GAP” między numerem priorytetu, co oznacza podniesienie numeru priorytetu serwera BACKUP większego niż ten z serwera MASTER Server. Wyjaśnię dalej:

Zgodnie z instrukcją zachowania, dodatnia liczba w ustawieniu „waga” doda tę liczbę do priorytetu, jeśli kontrola się powiedzie.
Liczba ujemna odejmie tę liczbę od numeru priorytetu, jeśli kontrola się nie powiedzie.

Zgodnie z moją konfiguracją:

Priorytety serwera Uprzednia awaria skryptu:
MASTER: 152
BACKUP: 100
Failover_IP: MASTER

IP przełączania awaryjnego jest poprawnie „przechwytywane” przez serwer główny, ponieważ serwer główny ma wyższy priorytet w porównaniu do serwera zapasowego (152> 100)

Priorytety serwera PO awarii skryptu:
serwer MASTER: 148
serwer BACKUP: 102
Failover_IP: STILL ON MASTER

IP pracy awaryjnej jest nadal na serwerze głównym, ponieważ Master ma ponownie wyższy priorytet w porównaniu do BACKUP (148> 102). Serwer MASTER odmówił wydania adresu IP i zrobił to, ponieważ jego priorytet był wyższy niż na drugim serwerze.

Rozwiązaniem mojej sytuacji było:

Rozwiązanie -1: Zmień numer priorytetowy obu serwerów, aby nie miały dużo „GAP”.
Na przykład:
Priorytet główny: 150
Priorytet kopii zapasowej: 149
Waga skryptu kontrolnego: jak to jest (2).

W powyższej konfiguracji, gdy skrypt się powiedzie (co oznacza, że ​​wszystko jest w porządku), priorytetami będą:
Master: 152
Backup: 149
IP_Lokalizacja: On Master (152> 149)

Gdy skrypt się nie powiedzie:
Master: 150
Backup: 151
IP_Lokalizacja: On Backup (151> 150)

Rozwiązanie - 2: Zmień liczbę wag skryptu z 2 na -60

Mam ten sam problem - dwa serwery CentOS 7.1 z track_script, a niepowodzenie vrrp_script na MASTER spowodowałoby tylko komunikat samotnego dziennika „VRRP_Script (chk_script) nie powiódł się”, a nie awarię. Na serwerze BACKUP dostałem jednak wiele wiadomości o kontynuowaniu próby przejęcia wirtualnego adresu IP tak długo, jak długo zawiodłem track_script na serwerze MASTER.

Rozwiązanie w moim przypadku: Zapora ogniowa (iptables) na serwerze MASTER nie została poprawnie skonfigurowana, aby zezwalać na pakiety VRRP / pakiety multiemisji, a jednocześnie zapora ogniowa na drugim serwerze, BACKUP, została poprawnie skonfigurowana.

Wprowadziłem te same reguły iptables na obu serwerach w następujący sposób:

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

Działa to na jednym z serwerów (BACKUP VRRP), ale nie na MASTER, ponieważ zapomniałem, że interfejs nie został nazwany „eth0” na serwerze MASTER, więc te dwie reguły nie miały żadnego efektu.

To wyjaśniało zachowanie, które zaobserwowałem:

Jeśli keepalived nie widzi żadnego innego głośnika VRRP dla określonego virtual_router_id, nadal uważa się za ten o najwyższym priorytecie (a więc prawowitym MASTER) nawet po negatywnej modyfikacji wagi, ponieważ nigdy nie odbiera komunikatów VRRP o priorytecie wyższym niż własny ( ponieważ reklamy innych głośników są blokowane przez zaporę ogniową i nigdy nie mogą dotrzeć do procesu podtrzymywania aktywności w celu ich uświadomienia). Dlatego nie widzisz, żeby to zwolniło VIP.

Serwer BACKUP był jednak w stanie zobaczyć reklamy (teraz nieudanego) MASTER, znalazł priorytet w tych pakietach zredukowany do wartości mniejszej niż jego własna, i zaczął ogłaszać się MASTER i wysyłać nieodpłatne ARP, aby odebrać VIP. Skończyliśmy więc w sytuacji, gdy oba serwery pomyślały, że będą musiały służyć VIP-owi jako MASTER.

Wnioski: - Zawsze sprawdź konfigurację zapory na wszystkich głośnikach VRRP, jeśli występują dziwne zachowania (brak przełączania awaryjnego, kilka MASTER). Zapisywanie na bieżąco nie jest tak pomocne, jak mogłoby być (prosty komunikat „VIP nie został wydany, ponieważ wciąż jestem najwyższy prio” po wierszu „Błąd VRRP_Script (chk_script)” znacznie ułatwiłby rozwiązywanie problemów.

• Track_script nie jest przełącznikiem typu włącz / wyłącz („jeśli skrypt OK: kwalifikuje się do wyborów VIP; jeśli NIE OK: całkowicie nie kwalifikuje się do wyborów VIP”) - jedynie zwiększa / zmniejsza prawdopodobieństwo wygrania wyborów i jeśli jest tylko utrzymywany kiedykolwiek uważa się za jedynego mówcę VRRP i nigdy nie otrzymuje wiadomości od innych mówców, naprawdę nie ma zbyt wielu wyborów - zawsze wygrywasz.

Właśnie wpadłem na taką samą sytuację jak ty i zacząłem uczyć się o utrzymywaniu życia. Zastanówmy się, co dzieje się na każdym serwerze. Zakładając, że chcesz wdrożyć ręczną architekturę powrotu po awarii,

W 1. węźle BACKUP

Za każdym razem, gdy track_script nie powiedzie się liczba upadków , wysyła reklamę do drugiego węzła BACKUP. Wskaż tutaj priorytet ustawiony w reklamie. W Twoim przypadku,

129 (109 + 20)

jest wysyłany do drugiego serwera BACKUP.

Na drugim serwerze BACKUP

Dalej jest na drugim węźle BACKUP.

Według RFC ,

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

Ponieważ masz włączoną funkcję „nieopreempt” i otrzymujesz vrrp o wyższym priorytecie, drugi węzeł BACKUP nie przejdzie do fazy przejścia do stanu.

Rozwiązanie

Jeśli więc chcesz, aby zmiana stanu miała miejsce w drugim węźle, możesz albo

1. Ustaw wagę na 0 w 1. węźle BACKUP. Spowoduje to wysłanie ogłoszenia o priorytecie 0 do drugiego węzła BACKUP. doc opisuje więcej o wadze 0.

2. Wyłącz opcję nopreempt na drugim węźle BACKUP.

3. Ustaw wagę na co najmniej -2 w 1. węźle BACKUP.