VRRP_script keepalived não está falhando

Question

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

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

Mas quando eu paro meu processo com /etc/init.d/process stop keepalived não falha. Acabei de obter o VRRP_Script (chk_script) falhou e nada mais. Nenhum 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 mando o processo -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 correção para isso? Obrigado.

    

Answer 1

Eu tive exatamente o mesmo problema, no entanto, meu problema não estava no firewall nem no meu adaptador Ethernet, mas nas configurações de "peso" do script de verificação.

Esta foi minha configuração:

MASTER:

vrrp_instance haproxy {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1

BACKUP:

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 fato de o script ter falhado, o mestre ainda estava tendo um número de prioridade mais alta do servidor BACKUP. Isso aconteceu porque a configuração "weight" em 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 BACKUP para o do MASTER Server. Eu explicarei ainda mais:

De acordo com o manual de keepalived, um número positivo na configuração "weight" adicionará esse número à prioridade se a verificação for bem-sucedida.
Um número negativo subtrairá 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:
MESTRE: 152
BACKUP: 100
Failover_IP: MASTER

O IP de failover é corretamente "agarrado" pelo servidor mestre, já que 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 de BACKUP: 102
Failover_IP: AINDA EM MASTER

O IP de failover ainda está no servidor mestre, porque o Mestre novamente tem prioridade mais alta em comparação ao BACKUP (148 > 102). O servidor MASTER estava se recusando a liberar o IP e o que ele fez desde que sua prioridade foi maior do que o outro servidor.

A solução na minha situação foi:

Solução -1: Altere o número de prioridade de ambos os servidores para que eles não tenham muito "GAP".
Por exemplo:
Mestra Prioridade: 150
Prioridade de backup: 149
Peso do check_script: como é (2).

Com a configuração acima, quando o script for bem-sucedido (o que significa que está tudo bem), as prioridades serão:
Mestrado: 152
Backup: 149
IP_Location: On Master (152 > 149)

Quando o script falha:
Mestre: 150
Backup: 151
IP_Location: no backup (151 > 150)

Solução - 2: altere o número de peso do script de 2 para -60

    

Answer 2

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

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. / p>

Eu tinha inserido as mesmas regras do iptables em ambos os servidores da seguinte forma:

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 era chamada 'eth0' no servidor MASTER, portanto as duas regras não tiveram efeito algum .

Isso explica o comportamento que eu observei:

Se o keepalived não puder ver nenhum outro alto-falante VRRP para um certo virtual_router_id, ele ainda acredita ser aquele com a prioridade mais alta (MESTRE por direito) mesmo depois de uma modificação negativa de peso, uma vez que nunca recebe mensagens VRRP com prioridade maior que próprio (porque os anúncios de outros alto-falantes são bloqueados pelo firewall e nunca podem alcançar o processo keepalived para torná-lo ciente deles). É por isso que você não vê isso liberar o VIP.

O servidor BACKUP, no entanto, foi capaz de ver os anúncios do MASTER (agora com falha), encontrou a prioridade naqueles pacotes reduzidos a um valor menor que o seu próprio, e procedeu a se declarar MASTER e enviar ARPs gratuitos para reivindicar o VIP. Então acabamos em uma situação em que os dois servidores achavam que precisariam 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 (nenhum failover, vários MASTERs). A criação de log de manutenção de vida não é tão útil quanto poderia ser (uma mensagem simples "VIP não liberado porque ainda sou o mais alto" depois que a linha "VRRP_Script (chk_script) falhou" teria facilitado a resolução de problemas imensamente.

• Um track_script não é um tipo on / off de switch ("if script OK: elegível para a eleição VIP; se NÃO OK: completamente inelegível para a eleição VIP") - simplesmente aumenta / diminui a probabilidade de ganhar a eleição, e se o keepalived só se observa como o orador do VRRP somente e nunca recebe nenhuma mensagem de outros oradores, não há realmente muita eleição - você sempre ganha.

Answer 3

Eu acabei de esbarrar na mesma situação que você e fiz alguns estudos sobre keepalived. Vamos pensar no que está acontecendo em cada servidor. Supondo que você queira implementar a arquitetura de failback manual,

No primeiro nó de BACKUP

Toda vez que o track_script falha no número de fall vezes, ele envia o anúncio para o segundo nó BACKUP. Aponte aqui o conjunto de Prioridade dentro do anúncio. No seu caso,

129 (109 + 20)

é enviado para o segundo servidor de BACKUP.

No segundo servidor de BACKUP

A próxima é no 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

Desde que você tenha nopreempt ativado e recebendo uma prioridade mais alta vrrp, o segundo nó BACKUP não vai indicar a fase de transição.

Solução

Então, se você quiser fazer a transição de estado acontecer no segundo nó, você pode,

1. Defina peso para 0 no primeiro nó BACKUP. Isso enviará anúncio de Prioridade 0 ao segundo nó de BACKUP. doc descreve mais sobre o peso 0.

2. Desative o nopreempt no segundo nó BACKUP.

3. Defina o peso para pelo menos -2 no primeiro nó BACKUP.