|
Malcolm Cowe wrote:
>
> Roberto Nibali wrote:
> >
> > Hello Melcolm,
> >
> > Malcolm Cowe wrote:
> > >
> > > I saw this on freshmeat and found it quite interesting. The approach
> > > towards persistence is something that perhaps LVS could learn from.
> >
> > Forgive my ignorance: But what exactly is missing in the LVS persistency
> > approach?
>
> No idea, I don't use the persistence features in my LVS setup =). And
> before you start with the flaming, I was simply pointing out a similar,
First off: I apologize if my questions sounded like a flame start but as
you might have guessed English is not my first language.
> less ambitious project which claims to have a new solution, superior to
> plain RR and a new way to establish persistence. I have no idea about
LVS has other schedulers, like WRR or WLC or DH ...
> the limitations and advantages of Pen over LVS, since I have not had the
> opportunity to try it out, and have at this time no requirement for
Ok. Now this is very strange: You say that "... The approach towards
persistence is something that perhaps LVS could learn from." Have you
checked the persistency handling in pen-0.3.2? Unfortunately I cannot
download the whole tar-ball but I get about the first 18k of the pen.c.
Let's have a little look at it:
o It contains races on SMP systems due to the old and wrong signal handling
code. A. Cassen will certainly remember the discussion about his signal
handling.
o I cannot find the persistency code, but I also only have a fragment of
it.
o It will not support a lot of connections.
o You cannot give weights to real server (see WRR in LVS)
o ... unfortunately I couldn't download more of the code
From the authors README:
The load balancing algorithm keeps track of clients and will try to
send them back to the server they visited the last time. The client
table has a number of slots (default 2048, settable through command-line
arguments). When the table is full, the least recently used one will
be thrown out to make room for the new one.
The last one is especially bad. If you throw out the template of stickyness
for a server, you are not persistent anymore. What happens if the table
fills up with 2048 https requests and request number 2048 comes in before
the VISA transaction of the requestor 1 has finished doing his stuff? You
loose him to the next server which doesn't have the information 1 just
entered. --> you lost persistency.
> persistent connections (my cluster just needs high timeout values on the
> connections -- is there any way to make the connections never timeout?
> =]).
What for? You break the flow of TCP which is fundamental. You can set
the timeout very high but this is nonsense and defeats the purpose of
load balancing. Give me an example where you would need such a thing.
> I submitted this URL with the view that somebody with expertise with
> load-balancing and persistence might be able to make a judgement on
> whether or not this implementation has merit and might prove useful to
> the LVS development effort. I am aware, from the contents of this
I understand, but from my point of view, there is not a lot of code we
could use to improve the LVS or provide a new feature. If I once get to
download the whole archive in one piece I will look at his algorithm for
load balancing and if it's something groundbreaking new which we don't
already cope with one of the LVS schedulers, we certainly integrate a
new scheduler. I just wanted to point out, that I don't see anything
useful in the pen code which could be used for LVS withouth being mean
to someone.
> mailing list, that there are a number of significant obstacles with the
> provision of a load-balanced service, which has necessitated the
> development of a persistent connection model, and that this model has
> its own difficulties (cf. the AOL problems).
AOL problem can be solved with fwmarks and persistency AFAIC remeber.
> I mean no offence. I mean no disrespect to the impressive achievements
> of the LVS developers. I think LVS is great, and cannot wait for the
> production version of my X11 application cluster to come online later
> this month.
Excellent, thanks for the link, as I said I'm always happy to learn new
stuff and I'm sure Wensong is more then keen to find new ways to improve
LVS. Also on my side, I apologize if I sounded offensive(ly), I didn't
mean to.
Best regards,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
