Re: [lvs-users] Weird problem with LVS-DR

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] Weird problem with LVS-DR
From: Graeme Fowler <graeme@xxxxxxxxxxx>
Date: Thu, 20 Dec 2007 11:29:05 +0000
On Wed, 2007-12-19 at 18:42 +0000, Graeme Fowler wrote:
> I'll have an archive search shortly and post the workaround!

I found it eventually, on the keepalived-devel@xxxxxxxxxxxxxxxxxxxxx
list - I'll post it verbatim below.

This *should* allow you, with some modifications, to sort out your
problem and keep an active/active master/backup (by this I mean with
IPVS loaded and configured on both directors).

Original post follows:

Client sends packet to VIP. Director1 (Master) has VIP on external
interface, and has LVS to catch packets and load balance them. Director1
uses LVS-DR to route packet either to itself (which is fine), or to
Director2 (Backup).

There's the problem... Director2 *also* has a VIP, and also has LVS to
catch packets. In the basic case, 50% of the packets being forwarded by
Director1 to Director2 *will now get sent back to Director1* by the
LVS-DR configuration.
Because Director1 LVS has already sent traffic for that connection to
Director2, so it forwards the traffic to Director2.

Time passes, friend.

Your servers collapse under the weight of the amplifying traffic on
their intermediate or backend (or frontend, if you're on a one-net
setup) network.

The solution? A real nice easy one - use iptables to set a MARK on the
incoming traffic - something like:

iptables -t mangle -I PREROUTING -i eth0 -p tcp -m tcp \
                  -s 0/0 -d $VIP --dport $VIP_PORT \
                  -j MARK --set-mark 0x1

Then configure keepalived to match traffic on the MARK value instead of
the VIP/PORT combination, like so:

virtual_server fwmark 1 {
     delay_loop 10
     lb_algo rr
     lb_kind DR
     protocol TCP

     real_server x.x.x.72 25 {
         TCP_CHECK {
             connect_timeout 5
     real_server x.x.x.73 25 {
         TCP_CHECK {
             connect_timeout 5

...and so on for the other MARK values you define in your iptables

<Prev in Thread] Current Thread [Next in Thread>