У меня была точно такая же проблема, но моя проблема была не в брандмауэре и не в адаптере 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