Keepalived: NAT VIP para rede interna não utilizada?

Question

Estou construindo um balanceador de carga de prova de conceito com o CentOS 7 e keepalived.

Eu usei o guia de administração do balanceador de carga da Red Hat como referência e implementei um loadbalancer NAT com 2 nós, que transporta tráfego entre uma rede pública e uma rede privada. Para esse efeito, o balanceador de carga possui 2 VIPs: um para o tráfego do cliente, na rede pública; e um para garantir o failover para o tráfego de resposta, na rede privada.

Os 2 balanceadores de carga (lb1 e lb2) estão enviando tráfego para dois hosts executando o apache (fe1 e fe2) na rede interna. lb1 é master, lb2 é backup.

O diagrama é o seguinte:

Oloadbalancerfuncionaefalhaconformeoesperadoquandoumdosdiretorescai.

OquemeincomodaéqueotráfegodeentradanosservidoresreaisnãoéprovenientedoVIPinterno(10.10.33.254),masdosendereçosreaisdoshostsdobalanceadordecarga(10.10.33.2e10.10.33.3).OpingdosservidoresreaistambémestápassandoporendereçosIPreais,enãopeloVIPinterno,apesardeestardefinidocomoogatewaypadrãoparaeles.

Traceroute(lb1comoativo):

[root@rsfe2~]#tracepathwww.google.com1:rsfe20.081mspmtu15001:10.10.33.20.385ms1:10.10.33.20.385ms2:noreply3:192.168.1.11.552ms

(lb1parabaixo,lb2comoativo):

[root@rsfe2~]#tracepathwww.google.com1:rsfe20.065mspmtu15001:10.10.33.30.463ms1:10.10.33.30.462ms2:noreply3:192.168.1.12.394ms

Tabeladeroteamento:

[root@rsfe2~]#iproutedefaultvia10.10.33.254devenp0s8protostaticmetric102410.10.33.0/24devenp0s8protokernelscopelinksrc10.10.33.12

Apesardessaanomaliaaparente,ofailoverdeumbalanceadordecargaparaooutrofuncionacomoesperadodopontodevistadosclientes,aparentementedevidoaosARPsgratuitosdobalanceadordecargasobrevivente.

ParecequeoVIPinternonãoéusadoparanada,excetoanúnciosdoARP,nofinal(nãohátráfegoparaouapartirdele).

Eudeveriaestarpreocupadocomisso,ouestáfuncionandocomoesperado?

Meukeepalived.confdeconteúdo:

global_defs{notification_email{[email protected]@[email protected]}[email protected]_idLVS_DEVEL}vrrp_sync_groupVG1{group{RH_EXTRH_INT}}vrrp_scriptcheck_haproxy{script"/bin/pkill -0 -F /var/run/haproxy.pid"
    interval 1
    fall 1
    rise 5
}

vrrp_instance RH_EXT {
    state MASTER
    interface enp0s3
    virtual_router_id 50
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass password123
    }
    virtual_ipaddress {
        192.168.10.80
    }

    track_script {
        check_haproxy
    }

    track_interface {
        enp0s3
    }
}

vrrp_instance RH_INT {
    state MASTER
    interface enp0s8
    virtual_router_id 2
    priority 101
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass password123
    }

    virtual_ipaddress {
        10.10.33.254
    }

    track_script {
        check_haproxy
    }

    track_interface {
        enp0s8
    }
}

virtual_server 192.168.10.80 80 {
    lb_algo rr
    lb_kind NAT

    real_server 10.10.33.11 80 {
        HTTP_GET {
                url {
            path /check.html
        }
        }
    }
    real_server 10.10.33.12 80 {
        HTTP_GET {
                url {
            path /check.html
        }
        }
    }
}

    

Answer 1

Estou certo de que você está realmente usando o VIP neste caso. A razão pela qual você está vendo o IP nativo é simplesmente devido à natureza do traceroute. Cada salto é projetado de forma que o dispositivo gere um erro de ICMP, que o sistema sempre enviará usando seu endereço primário de adaptadores.