|
On Fri, July 25, 2008 11:29, Joseph Mack NA3T wrote:
> On Fri, 25 Jul 2008, David Dyer-Bennet wrote:
>
>> Here's a model that does what I want (but isn't supported by any current
>> scheduler):
>
> you could feed your resource values to feedbackd
But not more often than once a second, it looks like.
The usual problem is balancing loads where each request uses a small
portion of the server, isn't it? So each server is handling a few hundred
to a few thousand requests "at once"? Our workload is different in that
the bigger services now (and bigger ones are expected in the future) will
consume the entire server for almost half a second -- all 8 cores. I'm
not dealing with statistical averages so much as with an actual scheduling
problem.
So yes, I'm aware that I'm looking at stretching (or even twisting) LVS to
do stuff that's not really what it was designed for. Maybe it won't work.
But while it would be interesting work, writing our own
redirector-scheduler from scratch would be a rather big commitment. I
need to make a reasonable try at finding existing tools that will do what
we want before I propose that.
Yet another approach is to do weighted connection scheduling and just buy
enough hardware to get the response we need, using it somewhat
inefficiently. That might well be cheaper than developing and maintaining
a good scheduler for what we need. My career history has watched many,
many attempts at implementing priority schemes in mainframe OS schedulers,
lan media (token ring and FDDI), WAN links (between routers), and so
forth, and not one of them ever seemed to be really successful, and the
long-term solution has always been more resource rather than really clever
management.
>> I was wondering if it worked that way. That doesn't make much sense to
>> me
>> -- in real servers all processes draw from the same resource pools, so
>> it
>> doesn't make sense to firewall them that thoroughly from each other in
>> scheduling. But I imagine most real-world uses have only one virtual
>> service?
>
> the simple ones all do, but LVS has to be able to handle any
> number of virtual services. The director can't tell how many
> realservers aare behind it or whether the different virtual
> services are running on the same or different machines. The
> current way of assuming the serivces are independant is
> simple at least.
Simple is good; making something complex without really good evidence that
it's the *right* thing is a frequently-explored resource black-hole.
Wait, the director can't tell how many realservers are behind it? But
isn't it doing the job of relaying the connections to those realservers?
It can't do that if it doesn't know about them, surely? This probably
means that "director" is a more specific piece that I don't know about,
rather than a synonym for the whole thing. I've read an awful lot of
on-line documentation, but I may have missed the clear architectural
overview; at least I don't remember seeing one, what I know about the
architecture is based on inference from more-detailed documents.
--
David Dyer-Bennet, dd-b@xxxxxxxx; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info
|
