Início / server / Perguntas / 644949
Accepted
Bastien974
Asked: 2014-11-18 08:13:03 +0800 CST

Keepalived transição indesejada para mestre

  • 772

Estou iniciando 2 instâncias do EC2 na Amazon com Cloudformation, a segunda instância inicia cerca de 30 segundos após a primeira.

A configuração fica assim:

Instância 2

    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    unicast_peer {
        172.17.16.10
    }

Instância 1

    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    unicast_peer {
        172.17.16.11
    }

Ambos são configurados com a mesma verificação de integridade bem-sucedida.

Eu defino a mesma prioridade para não ter um problema de flapping (se o MASTER cair, faça a transição do BACKUP como novo MASTER, mas se o OLD MASTER voltar, fique como está).

O problema está acontecendo durante o início inicial:

  • Inicialização da primeira instância e entra no MASTER STATE
  • A segunda instância começa cerca de 30 segundos depois, inicialmente entra em BACKUP STATE, mas por algum motivo faz a transição para MASTER depois.

Ambos devem ter a mesma prioridade, então por quê?

Percebi que as mensagens de log sobre IPVS do kernel e o cálculo da impressão digital do host são impressas apenas após o início do keepalived. Isso me faz pensar que o keepalived é o primeiro software no sistema que faz com que o sistema troque pacotes na interface de rede e, de alguma forma, acione um failover indesejado.

Além disso, a instância 2 entra em BACKUP STATE assim que o keepalived começa:

Nov 17 17:43:58 ip-172-17-16-11 Keepalived_vrrp[2403]: Using LinkWatch kernel netlink reflector...
Nov 17 17:43:58 ip-172-17-16-11 Keepalived_vrrp[2403]: VRRP_Instance(VI_1) Entering BACKUP STATE
Nov 17 17:43:58 ip-172-17-16-11 Keepalived_vrrp[2403]: VRRP sockpool: [ifindex(2), proto(112), unicast(1), fd(15,16)]

enquanto a instância 1 torna-se MASTER somente após as mensagens e impressões digitais do IPVS do kernel:

Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.650360] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.654035] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.658356] IPVS: Creating netns size=2048 id=0
Nov 17 17:44:28 ip-172-17-16-10 kernel: [  157.661163] IPVS: ipvs loaded.
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_healthcheckers[2391]: Opening file '/etc/keepalived/keepalived.conf'.
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_healthcheckers[2391]: Configuration is using : 5174 Bytes
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_healthcheckers[2391]: Using LinkWatch kernel netlink reflector...
Nov 17 17:44:28 ip-172-17-16-10 Keepalived_vrrp[2392]: VRRP_Script(chk_haproxy) succeeded
Nov 17 17:44:29 ip-172-17-16-10 ec2:
Nov 17 17:44:29 ip-172-17-16-10 ec2: #############################################################
Nov 17 17:44:29 ip-172-17-16-10 ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----

Nov 17 17:44:29 ip-172-17-16-10 ec2: -----END SSH HOST KEY FINGERPRINTS-----
Nov 17 17:44:29 ip-172-17-16-10 ec2: #############################################################
Nov 17 17:44:29 ip-172-17-16-10 Keepalived_vrrp[2392]: VRRP_Instance(VI_1) Transition to MASTER STATE

-- Para testar a configuração:

  • Eu paro ambos keepalived
  • Começo o keepalived na instância 1, ele vai para MASTER.
  • Começo o keepalived na instância 2, ele vai para BACKUP e não aciona um failover.

Então tudo parece ok.

amazon-web-services

1 respostas

  1. Best Answer

    Por design, em caso de prioridade igual, o VRRP selecionará o nó com o endereço primário mais alto como MESTRE.

    https://www.juniper.net/techpubs/en_US/junose11.3/topics/concept/vrrp-router-election-rules.html http://www.ietf.org/rfc/rfc3768.txt 

    If the Priority in the ADVERTISEMENT is equal to the local
            Priority and the primary IP Address of the sender is greater
            than the local primary IP Address, then:

             o Cancel Adver_Timer
             o Set Master_Down_Timer to Master_Down_Interval
             o Transition to the {Backup} state
    • 1

relate perguntas