[TriLUG] LVS persistence and NAT

Ryan Leathers ryan.leathers at globalknowledge.com
Tue Jan 20 11:17:56 EST 2004


I want my cake and eat it too.  The more I use and read about LVS the
less optimistic I am about cake eating.  Don't get me wrong - I think
LVS is great.  I just want it to handle persistence and distribute load
at the same time.  Let me explain...

I have set up an LVS-NAT instance in my lab with three real servers
fielding http requests.  The real servers run an application server
where state is important.  

Prior to turning on persistence I observed that the load was being
distributed accross all three servers, but the application was unusable.
With persistence turned on, the application state is kept but the load
is no longer distributed.  That is to say, all connections made from all
hosts behind a NAT router wind up going to the same real server due to
the persistence rule.

I understand that persistence is dependant solely upon the source IP
address and the protocol in use.  I also see that a mask may be
specified to account for multiple / changing source addresses.  This
seems fine if there are not too many requests from the same host /
network.

Suppose I have a number of hosts connecting to my application servers. 
Is there a way to maintain state while also distributing the load?  Can
I have my cake and eat it too?  I originally thought firewall marks were
the ticket but I am coming to understand that marking will only
associate multiple protocols which will do nothing to distribute the
load when persistence is required.

I suppose I could move to a more complex clustering model on the back
end, but it would be the bees knees if LVS could be configured to
acheive both goals.
-- 
Ryan Leathers <ryan.leathers at globalknowledge.com>
Global Knowledge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://www.trilug.org/pipermail/trilug/attachments/20040120/87ef7db0/attachment.pgp>


More information about the TriLUG mailing list