|
On Fri, 25 Jul 2008, David Dyer-Bennet wrote:
> The usual problem is balancing loads where each request uses a small
> portion of the server, isn't it?
well yes, but even more true is that the scheduler must
sample over a long enough period that a large number of
connections are sampled.
> 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.
that's where we get new ideas.
> Yet another approach is to do weighted connection scheduling and just buy
> enough hardware to get the response we need, using it somewhat
> inefficiently.
a very well trodden path in computing.
> Wait, the director can't tell how many realservers are behind it?
the director knows the number of IPs that are servicing the
virtual service. They could all be on one machine for all
the director knows (and in many current implementations of
LVS, the realservers are all running on one big box,
appearing, via another meaning of virtual server, to be
individual machines).
> 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,
the director is the box running ip_vs()/ipvsadm.
Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
|
