keepalived VRRP_script sem failover

Portanto, estou executando o keepalived em dois servidores e não consigo o failover para o outro.

Abaixo eu tenho minha configuração para um dos servidores. O único diferente entre os dois é o número de prioridade mestre sendo 110 e volta sendo 109.

Mas quando eu paro meu processo com /etc/init.d/process stop keepalived, não falha. Acabei de receber o VRRP_Script (chk_script) falhou e nada mais. Sem failovers ou nada.

vrrp_script chk_script {
script "/usr/local/bin/failover.sh"
interval 2
weight 2
}

vrrp_instance HAInstance {
state BACKUP
interface eth0
virtual_router_id 8
priority 109
advert_int 1
nopreempt
vrrp_unicast_bind 10.10.10.8
vrrp_unicast_peer 10.10.10.9
virtual_ipaddress {
  10.10.10.10/16 dev eth0
}
notify /usr/local/bin/keepalivednotify.sh
track_script {
  chk_script weight 20
}
}

Este é o meu chk_script abaixo. O mesmo problema também acontece quando eu faço o processo killall -0 como meu script.

!/bin/bash
SERVICE='process'
STATUS=$(ps ax | grep -v grep | grep $SERVICE)

if [ "$STATUS" != "" ]
then
    exit 0
else
    exit 1
fi

Alguém sabe uma solução para isso? Obrigado.

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

Eu tive o mesmo problema - dois servidores CentOS 7.1 com track_script e a falha do vrrp_script no MASTER resultariam apenas na mensagem de log único "VRRP_Script (chk_script) falhou", não em um failover. No servidor BACKUP, no entanto, recebi muitas mensagens de keepalived tentando assumir o IP virtual pelo tempo em que o track_script no servidor MASTER falhou.

Solução no meu caso: o firewall (iptables) no servidor MASTER não foi configurado corretamente para permitir pacotes VRRP / pacotes multicast, enquanto ao mesmo tempo o firewall no outro servidor, o BACKUP, foi configurado corretamente.

Eu havia inserido as mesmas regras do iptables nos dois servidores da seguinte maneira:

iptables -A INPUT -i eth0 -d 224.0.0.0/8 -j ACCEPT
iptables -A INPUT -p vrrp -i eth0 -j ACCEPT

Isso funcionou em um dos servidores (o servidor BACKUP VRRP), mas não no MASTER, porque eu esqueci que a interface não tinha o nome 'eth0' no servidor MASTER, portanto, as duas regras não tiveram nenhum efeito.

Isso explicava o comportamento que eu observara:

Se keepalived não puder ver nenhum outro alto-falante VRRP para um determinado virtual_router_id, ele ainda se considera aquele com a maior prioridade (portanto, legítimo MASTER), mesmo após uma modificação de peso negativa, pois nunca recebe mensagens VRRP com uma prioridade maior que a sua ( porque anúncios de outros alto-falantes são bloqueados pelo firewall e nunca podem alcançar o processo de manutenção de atividade para torná-lo ciente). É por isso que você não vê o lançamento do VIP.

O servidor BACKUP, no entanto, conseguiu ver os anúncios do (agora falhado) MASTER, encontrou a prioridade nesses pacotes reduzida a um valor menor que o seu e passou a se declarar MASTER e enviar ARPs gratuitos para reivindicar o VIP. Então, acabamos em uma situação em que os dois servidores pensam que precisam servir o VIP como MASTER.

Conclusões: - Sempre verifique a configuração do firewall em todos os alto-falantes do VRRP se você tiver um comportamento estranho (sem failover, vários MASTERs). O registro de keepalived não é tão útil quanto poderia ser (uma mensagem simples "VIP não liberado porque ainda sou o mais alto prêmio" depois que a linha "VRRP_Script (chk_script) falhou") teria facilitado imensamente a solução de problemas.

• Um track_script não é um tipo de chave liga / desliga ("se o script estiver OK: elegível para eleição VIP; se NÃO estiver OK: completamente inelegível para eleição VIP") - apenas aumenta / diminui a probabilidade de ganhar a eleição e, se mantido apenas sempre se observa como o único orador do VRRP e nunca recebe mensagens de outros oradores, não há muita eleição realmente - você sempre vence.

Acabei de me deparar com a mesma situação que você e fiz alguns estudos sobre o keepalived. Vamos pensar no que está acontecendo em cada servidor. Supondo que você deseja implementar a arquitetura de failback manual,

No 1º nó BACKUP

Toda vez que o track_script falha o número de vezes que cai , ele envia o anúncio para o segundo nó BACKUP. O ponto aqui é a prioridade definida dentro do anúncio. No seu caso,

129 (109 + 20)

é enviado para o segundo servidor de BACKUP.

No segundo servidor de BACKUP

A seguir está o segundo nó BACKUP.

De acordo com a RFC ,

If the Priority in the ADVERTISEMENT is Zero, then:

  o  Set the Master_Down_Timer to Skew_Time
else:

  If Preempt_Mode is False, or If the Priority in the
  ADVERTISEMENT is greater than or equal to the local
  Priority, then:

    o Reset the Master_Down_Timer to Master_Down_Interval
  else:

    o Discard the ADVERTISEMENT
  endif
endif

Como o nopreempt está ativado e recebendo o vrrp de maior prioridade, o segundo nó BACKUP não está na fase de transição de estado.

Solução

Portanto, se você deseja fazer a transição de estado no segundo nó, você pode,

1. Defina o peso como 0 no 1º nó BACKUP. Isso enviará o anúncio de prioridade 0 para o segundo nó BACKUP. O documento descreve mais sobre o peso 0.

2. Desative o nopreempt no segundo nó BACKUP.

3. Defina o peso como pelo menos -2 no 1º nó BACKUP.