|
On Sat, 1 Jul 2000, Chetan Ahuja wrote:
> There's been talk of a Monitoring framework for LVS here for
> the past 6 months or so. Also the TODO list on the web page has included
> a Load-informed scheduling scheme for a long time now.
> <lots of questions snipped>
There's serveral parts to this problem.
1. a mechanism for changing parameters in the director according to
what the realserver(s) see
2. finding out what loads and transients are placed on a production
realserver
3. deciding the director's response to changes on a realserver.
You're talking mainly about #2, when we don't have much information on
which to make decisions. We don't know what happens on production
realservers. (We can make reasonable estimates as to what is likely to be
happening but that's not exactly the same.)
I monitored activity (=number of clients logged on) at on each mirror
machine in 6 sets of ftp mirros sites (eg all the ftp.kernel.org,
ftp.perl.org mirrors) for serveral months last year 10/times hr (I was
monitoring about 400 machines, about monitor request/sec) to see what a
load informed LVS would have to handle at least for the large GPL oriented
ftp sites. I found that activity need only be monitored every hour to keep
track of activity. Diurnal rythms were predictable as were weekends, and
barring some new release of some highly visible project, not much changed
month by month. The only thing that and LVS would need to handl was that
sites went down now and then for some hours. This was unpredictable as far
as I could tell.
Policies for the ftp service running on theses sites would be quite
different to those for a CNN news site or a stock site.
I think if you could provide a mechanism (#1 above) that would allow the
director to respond to information generated on the realserver(s), this
would be a great step forward. You (or others) could write agents to run
on realservers to monitor parameters of interest. (do you know about mon -
it's in the HOWTO, and /bproc, which produces a global /proc system for a
cluster of machines - it's written by the Beowulf people?) People should
be able to write a script/agent that runs on the realserver and monitors
some service, disk space, memory.... This agent talks to your demon
running on the realserver. This demon talks to its partner on the director
and so on.
Your demons/api would have to be as simple as mon to write agents for,
otherwise people will not be able to write agents for it and your code
will not be used.
The formulation of policies (#3 above) to handle various situations would
presumably be relatively simple once we collected data as to the likely
stresses that LVS's are subject to (control and feedback theory is well
understood).
Joe
--
Joseph Mack mack@xxxxxxxxxxx
|
