Transição indesejada mantida para mestre

Question

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

A configuração é 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 que é bem-sucedida.

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

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

• Inicializa pela primeira vez 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 que?

Percebi que as mensagens de log sobre o IPVS do kernel e o cálculo da impressão digital do host são impressos somente depois que o keepalived é iniciado. Isso me faz pensar que o keepalived é o primeiro software no sistema que faz o sistema trocar pacotes na interface de rede e, de alguma forma, disparar um failover indesejado.

Além disso, a Instância 2 entra no estado de BACKUP assim que o serviço 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)]

Considerando que a instância 1 se torna MASTER somente após as mensagens IPVS e impressões digitais 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 os dois keepalived
• Eu começo o keepalived na instância 1, ele vai para o MASTER.
• Eu começo a manter o recurso na instância 2, ele vai para o BACKUP e não aciona um failover.

Então tudo parece ok.

    

Answer 1

Por padrão, no caso de prioridade igual, o VRRP selecionará o nó com o endereço principal mais alto como o MASTER.

link link

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