Given the high quality of all the other LVS code I wouldn't jump to the
conclusion that the SH scheduler doesn't work for production sites.
For a start SH gives exactly the same kind of response as persistence
and it's layer 4 based on source hash...
I don't totally understand the original post but is it not the app that
is failing when the source ip of the client (AOL mega proxy) changes?
Therefore this is nothing to do with LVS.
Their are hundreds of session implementations for web servers, it's one
of the first things web programmers should learn (i.e. INSERT INTO
sessiontable.....)
LVS doesn't do L7 'cause L7 should be done by your app (i.e. that's what
L7 is for.)
Joseph Mack NA3T wrote:
On Fri, 2 Jun 2006, Martijn Grendelman wrote:
Hi,
I was justing browsing the HOWTO, when I stumbled upon this recent
piece of text:
Apr 2006: No-one has tried this, but it seems that the -SH scheduler
could replace persistence without the failover problems of
persistence. The -SH scheduler schedules according to the client IP,
meaning that all of a client's connection requests will be sent to
the same IP. The -SH scheduler has been around for a while, but it
seems that no-one has known what it did.
It's nice to know that someone reads the HOWTO :-)
When I first started to toy around with LVS, I did just what is
written here: i tried to use the SH scheduler for "session affinity"
at L7.
However, I had problems, that I posted to this list:
http://www.in-addr.de/pipermail/lvs-users/2004-March/011171.html
when I realised that I didn't know what the SH scheduler did, I looked
through all the postings with "SH" and "scheduler" to find that no-one
else knew a whole lot either.
hmm - It seems that the packets get scrambled ocassionally,
presumably a consequence of the code having never been tested.
I never found a solution, and I finally decided that SH wasn't going
to work, and I set up an Msession server for "session clustering" and
used the RR scheduler. This setup works perfectly and is still in use
today.
However, since Msession is hopelessly outdated, and its successor
(Mcache) doesn't seem to get off the ground, and I haven't found any
workable (open source) alternatives, I would really like have another
look at LVS persistence of some sort.
The question is: has anything changed in the SH scheduler in the past
two years, that could possibly have fixed the problems I ran into? I
suspect, since only No-one has tried using it, there's not a big
chance of that ;-)
AFAIK, nothing has happened to the SH scheduler since the day it was
released. Unless you want to spelunk the code to find out what's going
on, the SH scheduler is basically unsupported and apparently not ready
for production.
Sorry
Joe
|