LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Linux Virtual Services

To: Christopher Seawood <cls@xxxxxxxxxxx>
Subject: Re: Linux Virtual Services
Cc: linux-virtualserver@xxxxxxxxxxxx
From: Peter Kese <peter.kese@xxxxxx>
Date: Wed, 26 May 1999 22:33:56 +0200
Christopher Seawood wrote:
> 
> LVS seems to work great until a server goes down (this is where mon comes
> in).  Here's a couple of things to keep in mind.  If you're using the
> Weighted Round-Robin scheduler, then LVS will still attempt to hit the
> server once it goes down.  If you're using the Least Connections
> scheduler, then all new connections will be directed to the down server
> because it has 0 connections.  You'd think using mon would fix these
> problem but not in all cases.
> 
> Adding mon to the LC setup didn't help matters much. I took one of three
> servers out of the loop and waited for mon to drop the entry.  That worked
> great.  When I started the server back up, mon added the entry.  During
> that time, the 2 running servers had gathered about 1000 connections
> apiece.  When the third server came back up, it immediately received all
> of the new connections.  It kept receiving all of the connections until it
> had an equal number of connections with the other servers (which by this
> time...a minute or so later...had fallen to ~700). By this time, the 3rd
> server had been restarted after due to triggering a high load sensor also
> monitoring the machine (a necessary evil or so I'm told).  At this point,
> I dropped back to using WRR as I could envision the cycle repeating itself
> indefinitely.
> 

The 2.2 kernel patch partially fixes this problem. There, the WLC
scheduling
algorithm takes note about which TCP connections to a given server are
active,
and which of them have expired (but are still kept in the tables for
safety
reasons).

Usually a http request is answered in about one second, but a
masquerading
entry is kept in the table for a few more minutes. That means, that 99%
of
connections are just waiting there to be deleted from the table. That
means
that out of 700 connections, probably less than 20 are active.

The 2.2 kernel will tell you that it has 20+680 connections attached to
that
server and if a new server is added, it gets only 20 new connections
instead
of 700.

Well it actually gets 26 new connections, because there is a simple
heuristic which says 100 expired connections counts for one active.

Cheers,
                                Peter


P.S. Maybe it would be wise to implement such scheduling in the 2.0
kernel patch as well.

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