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

Кто-нибудь знает, как это исправить? Благодарю.

Источник

3 ответа

У меня была точно такая же проблема, но моя проблема была не в брандмауэре и не в адаптере 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, положительное число в настройке "вес" добавит это число к приоритету, если проверка прошла успешно.
Отрицательное число вычтет это число из номера приоритета, если проверка не пройдена.

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

Приоритеты сервера Предыдущий сбой скрипта:
МАСТЕР: 152
РЕЗЕРВНОЕ КОПИРОВАНИЕ: 100
Failover_IP: MASTER

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

Приоритеты сервера ПОСЛЕ сбоя скрипта:
МАСТЕР-сервер: 148
РЕЗЕРВНЫЙ сервер: 102
Failover_IP: все еще на мастере

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

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

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

В приведенной выше конфигурации, когда скрипт завершится успешно (то есть все в порядке), приоритеты будут такими:
Мастер: 152
Резервное копирование: 149
IP_Расположение: на мастере (152 > 149)

Когда скрипт не работает:
Мастер: 150
Резервное копирование: 151
IP_Location: при резервном копировании (151 > 150)

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

Источник

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

Решение в моем случае: брандмауэр (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 и никогда не получает сообщений от других спикеров, на самом деле выборов не так много - вы всегда выигрываете.
Источник

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

На 1-м узле BACKUP

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

129 (109 + 20)

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

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

Далее идет 2-й узел 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

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

Решение

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

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

  2. Отключите nopreempt на 2-м узле BACKUP.

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

Источник
Другие вопросы по тегам