Keepalived + LVS no funciona desde otros hosts pero sí desde localhost en LB

Keepalived + LVS no funciona desde otros hosts pero sí desde localhost en LB

Tengo un keepalived + LVS configurado. Estoy intentando ponerme a trabajar.

Los clientes, LB y servidores reales están todos en la misma subred.

Configuración mantenida:

global_defs {
    notification_email {
        [email protected]
    }
    notification_email_from [email protected]
    smtp_server 127.0.0.1
    smtp_connect_timeout 30
    router_id ukld5p500x
}

vrrp_instance some_service {
    state             MASTER
    interface         em1
    virtual_router_id 100
    priority          100
    virtual_ipaddress {
        10.0.0.75
    }

    track_script {
        chk_fail
    }
}

virtual_server 10.0.0.75 58563 {
    delay_loop      10
    lb_algo     rr
    lb_kind     DR

    protocol        TCP

    real_server 10.0.0.70 58563 {
        weight          1
        TCP_CHECK {
            connect_timeout 3   
            connect_port    58563
        }
    }

    ... more real_servers ...

}

Entonces, si configuro lb_type en nat, entonces puedo conectarme desde el LB al puerto/VIP y todo pasa, pero no desde un host externo (cliente). Si configuro lb_type en DR, ni el LB que se conecta a sí mismo ni un cliente externo podrán conectarse.

sys.net.ipv4.ip_forward está configurado en 1 y solo hay un cajero automático LB configurado.

Respuesta1

No sé si recibió respuesta porque es muy antiguo, pero DR (enrutamiento directo) es muy diferente a NAT. NAT hace que el equilibrador de carga (LB) actúe como un enrutador al pasar el paquete al servidor real, y el servidor real lo devuelve al LB para entregárselo al cliente.

Con DR, el LB es sólo un pseudointermediario. Cuando un paquete llega al VIP que tiene el LB, decide a qué RS (servidor real) enviarlo yreescribeel encabezado del paquete cambiando la dirección MAC. Luego pasa el paquete de regreso al conmutador, y el conmutador lo entrega al RS con la dirección MAC coincidente.

Luego debe engañar a su RS para que acepte un paquete destinado a su interfaz. Normalmente, esto se hace agregando el VIP a un adaptador de loopback y dándole una máscara de red de 255.255.255.255. Su demonio de servicio también deberá configurarse para escuchar en este VIP (en Apache simplemente agrega una línea adicional Listen xxxx:80).

Para colmo, hay que lidiar con el problema de ARP. Normalmente, añadiendo

net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth0.arp_ignore = 1

a tu sysctl.conf se encargará de ello

información relacionada