|
While we are talking about an API for the real servers to talk to the
director, here's a feature that I will be needing in the future:
A command to let the real server change a Connection persistence mapping on
the director. Looking through the code it seems like only a couple of lines
manipulating the hash table..(lock, remove,add,unlock). The library could
have a function call like "ERROR_CODE lvs_UpdatePersistantHashTable(Client
Identifier, Old Real Server, New Real Server);"
Just thought I would mention it in the hope that if an API gets developed,
this feature is added.
If not and I decide to go with LVS when I cluster my server, someone from my
team will be patching the LVS code to do this.
Here's a quick question: what would be the best way to implement the API
library?.
My thoughts went along the line of a client library that sends commands to
the director through UDP packets.
If so, does the director have a daemon running to listen to those commands
or does the LVS code do it directly?
If a daemon is used, how does it call the functions to update the
persistence hash table?
(Sorry for the newbie question but I only switched from NT a while ago and
I'm still getting used to the idea if modifying/reading kernel code (I love
it!:) so I'm not quite sure of the schematics...
I'm hoping its just a matter of a including the right header/lib file but
somehow I doubt that :)
Mark Pentland
----- Original Message -----
From: "Julian Anastasov" <ja@xxxxxx>
To: "Matthew S. Crocker" <matthew@xxxxxxxxxxx>
Cc: "Thomas Proell" <Thomas.Proell@xxxxxxxxxx>;
<lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Saturday, October 28, 2000 8:10 AM
Subject: Re: Release new code: Scheduler for distributed caching
>
> Hello,
>
> On Fri, 27 Oct 2000, Matthew S. Crocker wrote:
>
> > > On Thu, 26 Oct 2000, Matthew S. Crocker wrote:
> > >
> > > > Why can't we come up with an API the Real Servers can use to tell
the
> > > > ldirector their load so the ldirector can update its routing table?
It
> > >
> > > Sounds simple, yes. Write it! :-)
> > >
> > > Writing kernel code is hard, and not many people have the experience
> > > and the time to do a good job, even if it WAS simple.
> > >
> > > Moreover, my scheduler was developed as the topic of my master-thesis.
> > > So, there were also other (maybe academic/theoretic) issues, that
> > > were considered. For example that the client doesn't have to install
> > > some extra software (what may speed up the stuff). Another point
> > > was, that the CACHES don't have to have extra software.
> >
> > I'm not talking about rewriting schedulers or kernel modules. I think
we
> > need an API for applications so they (because they are the only ones
that
> > know their true load) can express that load in a numerical way to the
> > directors. The directors can also have a weighting system because a
very
> > busy fast server can still be a better choice than a non-busy slow
server.
> >
> > No changes to the scheduler or kernel needed. Just a way to update the
> > LVS routing table every 5 seconds or so with better load information so
a
> > scheduler can make better decisions.
>
> Hey, it seem I'm not the only one who thinks in this way. I will
> come soon (if the time allows that) with a list of features, ideas,
> examples, etc on this issue. I have a good list of load parameters for
> many platforms.
>
> > -Matt
> >
>
> -- ----------------------------------------------------------------------
> > Matthew S. Crocker
> > Vice President / Internet Division Email: matthew@xxxxxxxxxxx
> > Crocker Communications Phone: (413) 587-3350
> > PO BOX 710 Fax: (413) 587-3352
> > Greenfield, MA 01302-0710 http://www.crocker.com
> > ----------------------------------------------------------------------
>
>
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
>
>
|
