Início / server / Perguntas / 634903
Accepted
Utegrad
Asked: 2014-10-10 14:39:19 +0800 CST

VIP não caindo do backup keepalived

  • 772

Posso não estar entendendo como isso deveria funcionar, mas não consigo entender por que o sistema BACKUP com esta vrrp_instance básica está fazendo a transição para o mestre imediatamente e nunca parece honrar a prioridade.

Por que o endereço IP virtual não cairia do sistema de backup quando ambos estão íntegros e online?

Parece que ambos os sistemas estão transmitindo o anúncio vrrp. No tcpdumpsistema de backup:

betaproxyslc01.fakecorp.com > vrrp.mcast.net: vrrp betaproxyslc01.fakecorp.com > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 150 , authtype simple, intvl 1s, length 20, >addrs: virtual-app .fakecorp.com auth "password" 15:52:24.541637 IP (tos 0xc0, ttl 255, id 1611, offset 0, sinalizadores [nenhum], proto VRRP (112), comprimento 40)

betaproxyslc02.fakecorp.com > vrrp.mcast.net: vrrp betaproxyslc02.fakecorp.com > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20, >addrs: virtual-app .fakecorp.com auth "password" 15:52:25.410073 IP (tos 0xc0, ttl 255, id 1779, offset 0, sinalizadores [nenhum], proto VRRP (112), comprimento 40)

mas o endereço IP virtual está aparecendo em ambos os hosts com um ip addrcomando.

Aqui está a configuração:

global_defs {
   notification_email {
   [email protected]
   }
   notification_email_from [email protected]
   smtp_server mysmtpserver.fakecorp.com
   smtp_connect_timeout 30
   router_id BETAPROXYSLC01
}

vrrp_script chk_haproxy{
   script "killall -0 haproxy"
   interval 2 # check every 2 seconds
   weight 2   # add 2 points of prio if OK
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    notify /usr/local/bin/notify.sh
    authentication {
        auth_type PASS
        auth_pass keep0ut!
    }
    virtual_ipaddress {
        10.10.0.40
    }
    track_script{
        chk_haproxy
    }
}

No servidor BACKUP, o router_id é diferente, o estado é BACKUP e a prioridade é 100. As outras configurações são as mesmas.

Isso está na instalação do CentOS 7, com Keepalived v1.2.10 (06/10,2014), uma VM convidada Hyper-V, com um kernel 3.10.0-123.8.1.el7.x86_64.

linux

2 respostas

  1. Best Answer

    A comunicação VRRP entre roteadores usa o endereço IP multicast 224.0.0.18 [1] e o protocolo IP número 112 [2] .

    Assim, você só precisa permitir o tráfego de entrada e saída com esses parâmetros específicos para que o VRRP funcione corretamente. As regras de firewall geralmente mencionadas são redundantes e desnecessariamente amplamente formuladas.

    Sugiro que você use estas regras de firewall:

    firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --direct --permanent --add-rule ipv4 filter OUTPUT 0 --out-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --reload

    [1] https://www.rfc-editor.org/rfc/rfc5798#section-5.1.1.2
    [2] https://www.rfc-editor.org/rfc/rfc5798#section-5.1.1.4

    • 5

  2. Fazendo referência às informações do firewall no final desta página , consegui fazê-lo funcionar abrindo o firewall com:

    firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -i eth0 -d 224.0.0.0/8 -j ACCEPT
firewall-cmd --direct --perm --add-rule ipv4 filter INPUT 0 -i eth0 -d 224.0.0.0/8 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p vrrp -i eth0 -j ACCEPT
firewall-cmd --direct --perm --add-rule ipv4 filter INPUT 0 -p vrrp -i eth0 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -p vrrp -o eth0 -j ACCEPT
firewall-cmd --direct --perm --add-rule ipv4 filter OUTPUT 0 -p vrrp -o eth0 -j ACCEPT

    Apenas as primeiras (duas) opções pareciam ser necessárias. Depois que defini a regra para aceitar tráfego para o endereço multicast, o sistema de backup notou o tráfego vrrp, reverteu para o modo de backup e retirou o VIP. Suponho que o que me confundiu foi que pude ver o tráfego multicast de ambos os sistemas em ambos os sistemas com tcpdump.

    • 1

relate perguntas