[lvs-users] LVS-Tun to an LVS-Masq ?

[Dave Porter]

Just an update on this...

The following ldirector config seems to solve my problem :-

As a recap, I have a single Global Load Balancer that balances to 2 regional load balancers via iptunnels, the regional load balancers then balance to the real servers via masq.

virtual = 10.116.3.10:8000
	protocol = tcp
	real = 10.116.3.11:8000 ipip
	real = 10.116.4.11:8000 ipip


The regional load balancer config :- these need to be able to accept packets on 10.116.3.11:8000  AND 10.116.3.10:8000.

# This is needed because the Global Load Balancer uses this IP to do the health checks and forward packets to down the tunnel.
virtual = 10.116.3.11:8000
        checkport = 8000
        checktype = connect
        httpmethod = GET
        protocol = tcp
        real = 192.168.1.104:8000 masq
	real = 192.168.1.105:8000 masq
# For the IPIP tunnel - this is needed because otherwise the ipip tunnel packets arrive, but have nothing to process them.
virtual = 10.116.3.10:8000
        real = 127.0.0.1:8000
        protocol = tcp
        checkinterval = 600

Hope this helps someone in the future!

Dave Porter
dporter at optixconsulting.co.uk


On 5 Aug 2011, at 20:36, Joseph Mack NA3T wrote:

> On Fri, 5 Aug 2011, Dave Porter wrote:
> 
>> Hey guys,
>> 
>> I'm sure someone has run into this before, but I couldn't 
>> find anything searching.
> 
> well no. You might be the first.
> 
> (I haven't looked at the other poster's reply. He might have 
> already solved the problem.)
> 
>> Global Loadbalancer GVIP --> Regional LoadBalancer RVIP --> Real Servers RIP
>> 
>> 10.116.3.10      -->       10.116.4.11     -->     192.168.1.1
>> 
>> I'm using LVS-Tun (ipip)  from the Global to the 
>> Regionals, then the Regionals run masquarading to the Real 
>> Servers.
> .
> .
>> In other words, the regional load balancer listens on 
>> 10.116.4.11:80 (and needs to for the health checks to work 
>> from the global), but packets arrive from the global with 
>> destination 10.116.3.11:80
> 
> which is how LVS-DR and LVS-Tun are supposed to work.
> 
>> - these are ignored by the regional as there is no 
>> 'application' listening there.
> 
> As far as the GLB is concerned, the RLB is a realserver 
> listening on the GVIP. You need two things on the RLB
> 
> o a set of ipvsadm rules accepting packets to the GVIP and 
> sending them by LVS-NAT to 192.168.1.x
> 
> o something on the RLB that will accept a packet to the 
> GVIP. This is going to require a little trickery, but 
> nothing too fiendish. The state of the art as it was a 
> couple of years ago is here
> 
> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.routing_to_VIP-less_director.html
> 
>> From memory, probably the simplest is to put the GVIP on a 
> (any) device (lo, dummy, some ethX) on the RLB. Since the 
> location of the RLB will not be receiving advertisements for 
> the GVIP (they'll only be sent to the location of the GLB), 
> then you won't have to handle the ARP problem at the RLB.
> 
>> I can solve the issue by tunnelling the GVIP:port 
>> combination to the RVIP:port within the Regional box 
>> itself, but this seems a bit of a messy solution?
> 
> I'm not sure what you want to do here, but it sounds like 
> you'll be bypassing the load balancing of the GLB.
> 
> Joe
> 
> -- 
> Joseph Mack NA3T EME(B,D), FM05lw North Carolina
> jmack (at) wm7d (dot) net - azimuthal equidistant map
> generator at http://www.wm7d.net/azproj.shtml
> Homepage http://www.austintek.com/ It's GNU/Linux!
> 
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
> 
> LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
> Send requests to lvs-users-request at LinuxVirtualServer.org
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users