Por que estou achando um problema de cérebro dividido em keepalived?

Question

Quando inicio a minha instância de salvaguardar BACKUP, também assume o estado MASTER, como pode ver abaixo:

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

Configuração principal:

# 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
}

Configuração de backup:

# 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
}
}

Eu fui então verificar se as duas instâncias estavam conversando entre si:

Mestre

$ 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

Backup

$ 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

Alguma dica de por que a instância de BACKUP não está reconhecendo o MASTER?

Atualização 1:

Resultados do iptables:

Mestre

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

Backup

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

Solução

Acontece que foi um problema de firewall. Consegui verificar isso realizando tcpdump no host de destino para validar se os anúncios foram recebidos. Depois de corrigir o problema do firewall, agora recebo os anúncios vrrp que não estavam presentes antes. O seguinte foi executado no host de backup:

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

    

Answer 1

Como mostra o seu tcpdump, ambos os sistemas tentam conversar entre si, mas não recebem respostas. Então, ambos acham que o outro sistema está inativo, e o backup faz o que foi feito. Você precisa descobrir o que está bloqueando as comunicações.