keepalived VRRP_script не переключается при сбое

Итак, я запускаю keepalived на двух серверах и не могу переключить его на другой.

Ниже у меня есть мой конфиг для одного из серверов. Единственное различие между ними заключается в том, что главный номер приоритета равен 110, а задний - 109.

Но когда я прекращаю свой процесс с помощью /etc/init.d/process stop, keepalived не перестает работать. Я просто получил VRRP_Script (chk_script) не удалось и ничего больше. Нет переходов или ничего.

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

Это мой chk_script ниже. Та же проблема возникает и при выполнении процесса killall -0 в качестве сценария.

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

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

Кто-нибудь знает решение для этого? Спасибо.

У меня была точно такая же проблема, но моя проблема была не в брандмауэре и не в адаптере Ethernet, а в настройках «веса» сценария проверки.

Это была моя конфигурация:

МАСТЕР:

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

РЕЗЕРВНОЕ КОПИРОВАНИЕ:

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

}

Причина, по которой мастер отказывался освободить VIP, заключалась в том, что, несмотря на сбой сценария, мастер по-прежнему имел номер с более высоким приоритетом с сервера BACKUP. Это произошло из-за того, что настройки «weight» в check_script было недостаточно, чтобы покрыть «GAP» между номером приоритета, что означает повышение номера приоритета сервера BACKUP по сравнению с номером сервера MASTER. Я объясню дополнительно:

Согласно руководству keepalived, положительное число в настройке «вес» добавит это число к приоритету, если проверка прошла успешно.
Отрицательное число вычтет это число из номера приоритета, если проверка не удалась.

Итак, согласно моей конфигурации:

Приоритеты сервера Предыдущий сбой сценария:
MASTER: 152
РЕЗЕРВНОЕ КОПИРОВАНИЕ: 100
Failover_IP: MASTER

Отказоустойчивый IP-адрес правильно «захватывается» главным сервером, поскольку главный сервер имеет более высокий приоритет по сравнению с резервным сервером (152> 100)

Приоритеты сервера ПОСЛЕ отказа скрипта:
MASTER сервер: 148
BACKUP сервер: 102
Failover_IP: STILL ON MASTER

Отказоустойчивый IP-адрес все еще находится на главном сервере, потому что мастер снова имеет более высокий приоритет по сравнению с BACKUP (148> 102). Сервер MASTER отказывался освободить IP-адрес, и он правильно сделал, поскольку его приоритет был выше, чем у другого сервера.

Решение в моей ситуации было:

Решение -1: Измените номер приоритета обоих серверов, чтобы у них не было большого «GAP».
Например:
главный приоритет: 150
резервный приоритет: 149
вес контрольного сценария: как есть (2).

В приведенной выше конфигурации при успешном выполнении сценария (то есть все в порядке) приоритеты будут следующими:
Master: 152
Backup: 149
IP_Location: On Master (152> 149)

При сбое сценария:
Мастер: 150
Резервное копирование: 151
IP_Расположение: В резервном хранилище (151> 150)

Решение - 2: Измените весовой номер сценария с 2 на -60

У меня была та же проблема - два сервера CentOS 7.1 с track_script и сбой vrrp_script на MASTER приведет только к сообщению об одиночном журнале «VRRP_Script (chk_script) fail», а не к отказоустойчивости. Однако на сервере BACKUP я получал много сообщений keepalived, пытаясь захватить виртуальный IP-адрес до тех пор, пока на сервере MASTER произошел сбой track_script.

Решение в моем случае: брандмауэр (iptables) на сервере MASTER не был настроен правильно для разрешения пакетов VRRP / многоадресных пакетов, в то время как брандмауэр на другом сервере, BACKUP, был настроен правильно.

Я ввел одинаковые правила iptables на оба сервера следующим образом:

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

Это работало на одном из серверов (сервер BACKUP VRRP), но не на сервере MASTER, потому что я забыл, что интерфейс не был назван eth0 на сервере MASTER, поэтому эти два правила не имели никакого эффекта.

Это объяснило поведение, которое я наблюдал:

Если keepalived не может видеть какой-либо другой динамик VRRP для определенного virtual_router_id, он по-прежнему считает себя тем, у кого наивысший приоритет (таким образом, законный MASTER), даже после модификации с отрицательным весом, поскольку он никогда не получает сообщения VRRP с приоритетом выше, чем его собственный ( потому что объявления других ораторов блокируются брандмауэром и никогда не могут достичь процесса keepalived, чтобы он узнал о них). Вот почему вы не видите, чтобы выпустить VIP.

Сервер BACKUP, тем не менее, смог увидеть рекламу (теперь потерпевшего неудачу) MASTER, обнаружил, что приоритет в этих пакетах уменьшен до значения, меньшего его собственного, и продолжил объявлять себя MASTER и отправлять безвозмездные ARP для запроса VIP. Таким образом, мы оказались в ситуации, когда оба сервера решили, что им нужно будет обслуживать VIP как МАСТЕРА.

Выводы: - Всегда проверяйте конфигурацию брандмауэра на всех динамиках VRRP, если вы испытываете странное поведение (нет аварийного переключения, несколько мастеров). Журналирование с поддержкой активности не так полезно, как могло бы быть (простое сообщение «VIP не выпущен, потому что я все еще наивысший приоритет» после строки «VRRP_Script (chk_script) fail») значительно облегчило бы устранение неполадок.

• Скрипт track_script не является переключателем типа «включено / выключено» («если сценарий в норме: право на избрание VIP; если НЕ в норме: совершенно неприемлемо для избрания VIP») - он просто увеличивает / уменьшает вероятность победы на выборах и только при условии сохранения активности когда-либо считает себя единственным спикером VRRP и никогда не получает сообщений от других спикеров, на самом деле не так много выборов - вы всегда выигрываете.

Я просто столкнулся с той же ситуацией, что и вы, и немного изучил keepalived. Давайте подумаем, что происходит на каждом сервере. Предполагая, что вы хотите реализовать архитектуру восстановления после отказа вручную,

На 1-м узле BACKUP

Каждый раз, когда track_script терпит неудачу количество падений, он отправляет объявление на второй узел BACKUP. Точкой здесь является Приоритет, установленный внутри рекламы. В твоем случае,

129 (109 + 20)

отправляется на 2-й сервер BACKUP.

На 2-м сервере BACKUP

Далее на втором узле BACKUP.

Согласно 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

Поскольку вы включили nopreempt и получили vrrp с более высоким приоритетом, 2-й узел BACKUP не собирается переходить в состояние.

Решение

Так что если вы хотите, чтобы переход состояния происходил на втором узле, вы можете,

1. Установите вес в 0 на 1-м узле BACKUP. Это отправит объявление с приоритетом 0 на второй узел BACKUP. док описывает больше о весе 0.

2. Отключите запрет на втором узле BACKUP.

3. Установите вес как минимум -2 на 1-м узле BACKUP.