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

Почему у меня проблема с расщеплением мозга в Keepalived?

Когда я запускаю свой экземпляр BACKUP keepalived, он также принимает состояние MASTER, как вы можете видеть ниже:

Mar 28 02:38:05 localhost Keepalived_vrrp[23527]: VRRP_Instance(VI_01) Entering BACKUP STATE
Mar 28 02:38:05 localhost Keepalived_vrrp[23527]: VRRP sockpool: [ifindex(2), proto(112), unicast(1), fd(10,11)]
Mar 28 02:38:05 localhost Keepalived_vrrp[23527]: VRRP_Script(check_haproxy) succeeded
Mar 28 02:38:17 localhost Keepalived_vrrp[23527]: VRRP_Instance(VI_01) Transition to MASTER STATE
Mar 28 02:38:21 localhost Keepalived_vrrp[23527]: VRRP_Instance(VI_01) Entering MASTER STATE

Главный конфиг:

# Script used to check if HAProxy is running
vrrp_script check_haproxy {
script "/usr/sbin/pidof haproxy"
interval 2
}
# Virtual interface
# The priority specifies the order in which the assigned interface to take over in a failover
vrrp_instance VI_01 {
state MASTER
interface eth0
advert_int 4
unicast_src_ip 10.1.2.50
unicast_peer {
        10.1.2.51
    }
virtual_router_id 51
priority 150
# The virtual ip address shared between the two loadbalancers
virtual_ipaddress {
    10.1.2.100
}
track_script {
check_haproxy
}

Конфигурация резервного копирования:

# Script used to check if HAProxy is running
vrrp_script check_haproxy {
script "/usr/sbin/pidof haproxy"
interval 2
}
# Virtual interface
# The priority specifies the order in which the assigned interface to take over in a failover
vrrp_instance VI_01 {
state BACKUP
advert_int 4
interface eth0
unicast_src_ip 10.1.2.51
unicast_peer {
        10.1.2.50
    }
virtual_router_id 51
priority 100
# The virtual ip address shared between the two loadbalancers
virtual_ipaddress {
    10.1.2.100
}
track_script {
check_haproxy
}
}

Затем я пошел проверить, разговаривают ли два экземпляра друг с другом:

Мастер

$ tcpdump -i eth0 'ip proto 112'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:48:33.557462 IP host1.novalocal > 10.1.2.51: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 4s, length 20
02:48:37.558487 IP host1.novalocal > 10.1.2.51: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 4s, length 20
02:48:41.559496 IP host1.novalocal > 10.1.2.51: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 4s, length 20

Резервное копирование

$ tcpdump -i eth0 'ip proto 112'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:49:38.269751 IP host2.novalocal > 10.1.2.50: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20
02:49:39.270461 IP host2.novalocal > 10.1.2.50: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20
02:49:40.271197 IP host2.novalocal > 10.1.2.50: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20

Любые подсказки относительно того, почему экземпляр BACKUP не распознает MASTER?

Обновление 1:

iptables результаты:

Мастер

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Резервное копирование

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Решение

Оказывается, проблема в брандмауэре. Я смог убедиться в этом, выполнив tcpdump на хосте назначения, чтобы проверить, были ли получены объявления. После устранения проблемы с брандмауэром я теперь получаю рекламу vrrp, которой раньше не было. На резервном хосте выполнялось следующее:

tcpdump -i eth0 src host 10.1.2.50
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
01:06:42.709813 IP 10.1.2.50 > sntstsvmrla2a02.novalocal: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 1s, length 20
01:06:43.709901 IP 10.1.2.50 > sntstsvmrla2a02.novalocal: VRRPv2, Advertisement, vrid 51, prio 101, authtype none, intvl 1s, length 20

Как показывает ваш tcpdump, обе системы пытаются общаться друг с другом, но не получают ответов. Итак, оба думают, что другая система не работает, и резервная копия делает то, для чего она предназначена. Вам нужно выяснить, что блокирует общение.