LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] Sorry, it's pretty unusable!

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] Sorry, it's pretty unusable!
From: Graeme Fowler <graeme@xxxxxxxxxxx>
Date: Thu, 17 Oct 2013 13:51:39 +0100
Hi

On 17 Oct 2013, at 07:48, "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> 
wrote:
> I'm not subscribed to the list, so I hope someone will receive it anyway:

Yes we did, but if people reply to the list then you won't see it unless you're 
watching an archiver somewhere...

> I could pretty well use LVS for a load-balance, high-availability scenario 
> like distributing SMTP requests to different servers, but the setup seems so 
> complicated that I won't do. Reading the documentation, I felt that the NAT 
> (masq) mechanism would be the most elegant for my requirements. However as it 
> tuned out it did not work (as for many others). The reason is simple: LVS 
> rewrites the destination TSAP (IP address and port), but it leaves the source 
> TSAP unchanged. So any replies from a real server go to the original sender, 
> instead of the LVS host

That's right. In NAT mode, the realservers don't talk directly to anything but 
the director.

> The proposed solution is to set the LVS host as default gateway on any real 
> server. This has several problems:
> 1) You create a SPoF on the LVS host
> 2) You create a network bottleneck on the LVS host (_all_ traffic from a real 
> goes to the LVS host which must be a router)
> 3) If LVS host and real server are not in the same subnet, you cannot route 
> from the real server to the LVS directly
> 4) You cannot have two different LVS hosts that use different services on the 
> same real host

That's NAT mode for you.

> I reall wonder why you don't rewrite the source TSAP (in addition to the 
> destination TSAP) as well so that the sender of the packet seems to be the 
> LVS host. On a second rewrite the LVS destination TSAP would be rewritten to 
> the original requester. I feel this would work like a charm:
> 1) The real server will reply to the LVS host automatically
> 2) Only LVS traffic needs to go through LVS host
> 3) LVS host does not need to be a router (after rewriting the destination, I 
> think)
> 4) LVS host and real server can be in different subnets
> 5) You can use one real server from different LVS hosts
> 
> Did I overlook something that makes this impossible or impractical?

Yes. You've sort of described both DR and TUN modes here, except for the source 
IP being rewritten. LVS/IPVS is *not a proxy*, it's a fancy router. If you want 
to do this with source rewriting, use a system such as haproxy.

NAT mode is most useful where the realservers don't require any special 
configuration apart from their default gateway.

DR and TUN modes require extra configuration on the realservers, but do away 
with the SPOF and bottleneck in the director.

Graeme
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

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