|
"asep noor mukhdari s." wrote:
> Currently I am planning on doing my final project for my bachelor degree.
> I am interested in encanching load balancing policy on LVS,
<unsoliticed advice>
You didn't ask whether anyone one the mailing list thought this project
a good idea, but I'm going to talk about it anyhow.
As Francois said yesterday, LVS does a good job of load balancing already
(eg MRTG images in the HOWTO).
o if you want a project with load balancing lvs, then another possibility
is to integrate Jeremy Kerr's feedbackd with Alexandre Cassen's keepalived.
Jeremy's code was an undergrad project and he hoped to make it part of
keepalived,
but he's graduated now and working and doesn't have time to do it. I know
picking up other people's code is more difficult than starting from scratch
with your own code, but the finished code will almost certainly be used.
It's not obvious at the moment that even if your proposal produces code
that works, that anyone will use it. (This may not matter, if all you
want to do is graduate).
o other projects that could be done with lvs
1. Julian's nfct code: since it was written by Julian, I'm sure it's perfect
but it has not been tested and documented and hence noone is using it.
2. Horms has a generalised framework for writing server state sync demons
and has sample code available. You could figure out and document his
scheme and write a few versions of the modules yourself.
The result would be that everyone would be able use Horms scheme for
the server state sync demon.
3. Currently LVS cannot accept a packet for an IP which is not local
(ie you need the VIP on the director). There are situations where
its useful not to have the VIP on the director eg when you are
serving lots of different IPs. For 2.2 kernels this was solved
by transparent proxy, but this method doesn't work for 2.4 kernels
and beyond. You can solve this problem with fwmarks or
with Julian's routing trick at
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.routing_to_VIP-less_director.html#routing_and_delivery
You might (should?) be able to do the same for the VIP, routing it
to LOCAL_IN.
Alternately (and this would be a lot more work) you could hook
LVS to PREROUTING (with side effects possible) rather than LOCAL_IN.
How much users need (or will make use of) this added functionality
is another matter. It was useful with 2.2 kernels, but then the
functionality could be added with transparent proxy at little cost
to the person setting up LVS.
4. Realserver failover with maintenance of session.
Currently realserver failure losses the session. This
is not important for http, apparently the main use of LVSs.
For telnet, ssh, etc the user has to start again. Moving
tcp sessions is a difficult and not solved problem. However
simple cases might be amenable to solution eg read only
streaming video. If a realserver fails in the middle of
tranferring a video presentation to an important set of
business prospects, they are not likely to be impressed.
Two things (that I can see) would need to be added.
a. The RIP of the failed realserver would have to be
transferred to a new realserver (so the director would
not notice the failover) and the weight for that RIP changed
to 0 (so no new sessions are sent to that RIP).
b. state information (eg the seek position in the video stream)
would have to be propagated to other realserver(s) so
that the streaming_videod knows where to start up the replacement
video stream. The streaming_videod would also have to know
when and how to start up a new session using this state information.
c. The streaming video client would have to have some reconnect
ability and to accept the failover session as a continuation of
the old session.
</unsoliticed advice>
Joe
--
Joseph Mack PhD, High Performance Computing & Scientific Visualization
LMIT, Supporting the EPA Research Triangle Park, NC 919-541-0007
Federal Contact - John B. Smith 919-541-1087 - smith.johnb@xxxxxxx
|
