Re: Release new code: Scheduler for distributed caching- API

To: "Julian Anastasov" <ja@xxxxxx>, "Matthew S. Crocker" <matthew@xxxxxxxxxxx>
Subject: Re: Release new code: Scheduler for distributed caching- API
Cc: "Thomas Proell" <Thomas.Proell@xxxxxxxxxx>, <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: "Mark" <mark@xxxxxxxxxxxx>
Date: Sat, 28 Oct 2000 08:47:14 +1000
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
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>;
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
> > > > ldirector their load so the ldirector can update its routing table?
> > >
> > > 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
> > need an API for applications so they (because they are the only ones
> > 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
> > busy fast server can still be a better choice than a non-busy slow
> >
> > 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
> > 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        
> > ----------------------------------------------------------------------
> Regards
> --
> Julian Anastasov <ja@xxxxxx>

<Prev in Thread] Current Thread [Next in Thread>