Eu tinha exatamente o mesmo problema, no entanto, meu problema não estava no firewall nem no adaptador Ethernet, mas nas configurações de "peso" do script de verificação.
Esta foi a minha configuração:
MESTRE:
vrrp_instance haproxy {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
CÓPIA DE SEGURANÇA:
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
}
O motivo pelo qual o mestre se recusou a liberar o VIP foi porque, apesar do script falhar, o mestre ainda estava tendo um número de prioridade mais alto no servidor BACKUP. Isso aconteceu porque a configuração "peso" no check_script não foi suficiente para cobrir o "GAP" entre o número de prioridade, o que significa aumentar o número de prioridade do servidor de BACKUP para maior do servidor MASTER. Vou explicar melhor:
De acordo com o manual de keepalived, um número positivo na configuração "peso" adicionará esse número à prioridade se a verificação for bem-sucedida.
Um número negativo subtrai esse número do número de prioridade se a verificação falhar.
Então, de acordo com minha configuração:
Prioridades do servidor Falha anterior do script:
MASTER: 152
BACKUP: 100
Failover_IP: MASTER
O ip de failover é "agarrado" corretamente pelo servidor mestre, pois o mestre tem prioridade mais alta em comparação ao servidor de backup (152> 100)
Prioridades do servidor APÓS falha do script:
servidor MASTER: 148
servidor BACKUP: 102
Failover_IP: AINDA NO MASTER
O ip de failover ainda está no servidor mestre porque o Master tem novamente uma prioridade mais alta em comparação com BACKUP (148> 102). O servidor MASTER estava se recusando a liberar o IP e o fez, pois sua prioridade era mais alta que o outro servidor.
A solução na minha situação foi:
Solução -1: altere o número de prioridade dos dois servidores para que eles não tenham muito "GAP".
Por exemplo:
Prioridade Mestre: 150
Prioridade de Backup: 149
Peso Check_script: Como está (2).
Com a configuração acima, quando o script for bem-sucedido (o que significa que tudo está ok), as prioridades seriam:
Mestre: 152
Backup: 149
IP_Location: No mestre (152> 149)
Quando o script falha:
Mestre: 150
Backup: 151
IP_Location: No Backup (151> 150)
Solução - 2: altere o número do peso do script de 2 para -60