У нас есть установка поддержки активности на двух машинах, где обе машины настроены одинаково.
vrrp_instance RP_VI_1 {
interface eth3
state BACKUP
virtual_router_id 61
priority 150
advert_int 1
garp_master_delay 5
virtual_ipaddress {
x.x.x.x dev eth2
}
}
Обе машины работали с этой конфигурацией около полугода без проблем, но сегодня вечером произошел, казалось бы, ошибочный переход между состояниями.
host1: in BACKUP state
host2: in MASTER state
03:44:44: host1: Transition to MASTER state
03:44:45: host1: Entering MASTER STATE
03:44:46: host1: Received higher prio advert 150
03:44:46: host1: Entering BACKUP state
В то время host2 не переходил между состояниями и не регистрировал никакой информации. Таким образом, host1 отправил в сеть бесплатный ARP, и его MAC-адрес был кэширован в течение нескольких часов, в то время как он сбросил весь трафик.
Наша самая большая проблема здесь в том, что host1 вернулся в состояние BACKUP, заявив, что было получено «объявление с более высоким приоритетом», в то время как оба хоста имеют одно и то же значение prio, равное 150. Как может быть, что этот переход был запущен без того, чтобы системы взаимодействовали впоследствии, чтобы решить, кто должен остаться master и, таким образом, разослать новый бесплатный ARP, чтобы гарантировать передачу пакетов на правильный хост?
После прочтения определений VRRPv2 (RFC3768) становится очевидным следующее:
1) В качестве прерывателя связи между двумя мастерами используется первичный IP-адрес с одинаковым приоритетом. Выигрывает хост с более высоким IP-адресом, хост с меньшим IP-адресом перейдет на MASTER.
2) Вариант garp_master_refresh for keepalived можно использовать для повторной отправки бесплатного ARP через x секунд. Поскольку это значение по умолчанию равно 0, теперь запросы отправляются повторно по умолчанию, указание этого должно привести к восстановлению системы через некоторое время.