0

I've got a keepalived + LVS set up I'm trying to get to work

Clients, LB and real servers are all on the same subnet.

Keepalived config:

global_defs {
    notification_email {
        admin@example.com
    }
    notification_email_from admin@example.com
    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 ...

}

So if I set lb_type to nat then I can connect from the LB itself to the VIP/port and stuff goes through, but not from an external host (client). If I set lb_type to DR then neither the LB connecting to itself nor an external client can connect.

sys.net.ipv4.ip_forward is set to 1 and there is only one LB configured atm.

Tom Taylor
  • 41
  • 1
  • 4

1 Answers1

2

Don't know if you've gotten this answered since its so old, but DR (Direct Routing) is much different than NAT. NAT makes the load balancer (LB) act like a router by passing the packet to the real server, and the real server passes it back to the LB to deliver back to the client.

With DR, the LB is only a pseudo-middleman. When a packet comes in on the VIP the LB has, it decides which RS (real server) to send it to, and rewrites the packet header by changing the MAC address. It then passes the packet back to the switch, and the switch delivers it to the RS with the matching MAC address.

You then have to trick your RS into accepting a packet destined for its interface. You typically do this by adding the VIP to a loopback adapter and giving it a netmask of 255.255.255.255. Your service daemon will also need to be configured to listen on this VIP as well (in apache you just add an additional Listen x.x.x.x:80 line).

To top it off, you have to deal with the ARP problem. Typically, adding

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

to your sysctl.conf will take care of it

Dave
  • 21
  • 2