Назад | Перейти на главную страницу

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. Это произошло из-за того, что настройки «веса» в check_script не хватило для покрытия «разрыва» между номерами приоритетов, что означало повышение номера приоритета сервера BACKUP до значения MASTER Server. Далее поясню:

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

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

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

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

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

IP-адрес аварийного переключения все еще находится на главном сервере, потому что главный снова имеет более высокий приоритет по сравнению с BACKUP (148> 102). ГЛАВНЫЙ сервер отказывался предоставить IP-адрес, и он сделал это правильно, поскольку его приоритет был выше, чем у другого сервера.

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

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

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

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

Решение - 2: Измените весовое число скрипта с 2 на -60.

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

Решение в моем случае: брандмауэр (iptables) на главном сервере не был настроен правильно, чтобы разрешить пакеты VRRP / многоадресные пакеты, в то время как брандмауэр на другом сервере, РЕЗЕРВНОЕ КОПИРОВАНИЕ, был настроен правильно.

Я ввел одинаковые правила 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 server), но не на MASTER, потому что я забыл, что интерфейс не был назван «eth0» на MASTER-сервере, поэтому два правила не имели никакого эффекта.

Это объясняло наблюдаемое мной поведение:

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

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

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

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

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

На 1-м узле BACKUP

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

129 (109 + 20)

отправляется на 2-й РЕЗЕРВНЫЙ сервер.

На 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

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

Решение

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

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

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

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