|
Hi,
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.
Horms, what's the status of your synchronisation work?
4. Realserver failover with maintenance of session.
Currently realserver failure losses the session. This
Which is also the correct behavior.
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.
I remember having seen an implementation by NEC which kind of did that.
I have to search through my proceedings volumes to find out where I saw it.
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.
But for this the application needs to be failover aware. I don't see how
you could implement a generic smooth application transition failover
without knowing L5 and above information.
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).
The transition time alone is a multiple longer than audio would ever
accept it. For audio streams you also mostly don't rely on unicast which
would be another source of problem for LVS. As for http RS failover we
could use the server pool implementation which is still on my hd somewhere.
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.
The hifi multimedia folks have come up with their own implementations,
tweaks and protocols for streaming and processing over the years.
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.
Now I don't really want to spoil the mood here so I suggest you guys
interested in transparent RS failover should have a look at Werner
Almensberger's paper on "TCP connection passing". Joe, the paper can be
found in the 2004 OLS proceedings, Volume 1, first paper ;). The basic
idea is to synchronise the ICI (internal connection information) of a
socket over the nodes. Oh, the homepage can of course be found at:
http://tcpcp.sourceforge.net/
The online paper at:
http://www.finux.org/Reprints/Reprint-Almesberger-OLS2004.pdf
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
| 