On Fri, 7 Jan 2005, Jim Jagielski wrote:
> I'm currently working on code that extended the lb method within the
> 2.1/2.2 proxy from what is basically a weighted request count to also be
> a weighted traffic count (as measured by bytes transferred) and a
> weighted "load" count (as measured by response time). The former is
> further along and the methods will be selectable at runtime... This is
> definitely a scratch I'm itching, but before I spend too much
> (additional) time on it, I'd like some feedback on whether the concept
> is one we can all get behind.
We scratched this one at some point at Covalent as well - using the
scoreboard and some mod_snmp stuff.
> I am also toying with the idea of supporting a CPU load method when the
> origin servers are Apache via a custom response header...
What you'd ideally want is a pluggable 'metric' mechanism - which has two
layers (this is more or less in line with what we dit at Covalent and what
you can do inside some of the Cisco LD's):
layer one:
get_current_SRV(for some container)
which returns a list of
id, IP, weight, priority
for a given service, uri subspace, etc. The result is a function of the
callee. So this is not a de-facto statement server wide.
This works much the same way as a true SRV rercod (as in DNS, as use by
various services such as an active directory service, etc) - the priority
allows for fail over and the weight allows for loadbalancing.
and secondly a
handoff_to(id)
to confirm to the plugin that a certain backend is used for statistics,
N-path, firewall/nat reprogramming, whatever.
The second layer is also pluggable anbd simply returns state
get_load(given backend, for some container)
load: value between -1 (off-line) and 0..255.
this is used by layer one to get the list on a case by case basis.
On top of this you also want a 'ConfigBackEnd <type> [ opaquate values]'
which carries the config info to the right plugin.
And finally (and this is where I got stuck last time and used a horrible
hack (private scoreboard) some neat way of expending the scoreboard.
What I never did - but which you really do want ultimately is something
which can snarf timing and data out of the returned header to detect 500
error's, time-to-server and other things, such as cookies - to record
these and use in the next round as an indication of reliability.
The reason why I never got this done properly is that in a lot of setups
you do NOT want the frontend apache to properly process the data going
back - but you want to route that TCP traffic around the server. Which is
what that handoff() is for. But in those cases such return sniffing is
of no use. As it never sees the data.
The reason for the two layers is that
-> on layer one you can do three simple implementations:
static: round robin on a list, fail over, etc
DNS: based off SRV records in DNS
real: based on a backend which uses layer 2
-> on layer two you can do simple things; like just
pinging - and augment as needed with things like
SNMP later.
-> the reason you have container info (uri space, vhost,
cookies, ssl session info) is to do all sort of
stickyness when you feel like it.
end of braindump and itch sratching.
Dw
