git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Load balancing and load determination


On 05/11/2018 16:58, William A Rowe Jr wrote:
> On Mon, Nov 5, 2018 at 7:48 AM jean-frederic clere <jfclere@xxxxxxxxx
> <mailto:jfclere@xxxxxxxxx>> wrote:
> 
>     On 30/10/2018 13:53, Jim Jagielski wrote:
>     > As some of you know, one of my passions and area of focus is
>     > on the use of Apache httpd as a reverse proxy and, as such, load
>     > balancing, failover, etc are of vital interest to me.
>     >
>     > One topic which I have mulling over, off and on, has been the
>     > idea of some sort of universal load number, that could be used
>     > and agreed upon by web servers. Right now, the reverse proxy
>     > "guesses" the load on the backend servers which is OK, and
>     > works well enough, but it would be great if it actually "knew"
>     > the current loads on those servers. I already have code that
>     > shares basic architectural info, such as number of CPUs, available
>     > memory, loadavg, etc which can help, of course, but again, all
>     > this info can be used to *infer* the current status of those backend
>     > servers; it doesn't really provide what the current load actually
>     > *is*.
>     >
>     > So I was thinking maybe some sort of small, simple and "fast"
>     > benchmark which could be run by the backends as part of their
>     > "status" update to the front-end reverse proxy server... something
>     > that shows general capability at that point in time, like Hanoi or
>     > something similar. Or maybe some hash function. Some simple code
>     > that could be used to create that "universal" load number.
>     >
>     > Thoughts? Ideas? Comments? Suggestions? :)
> 
>     having the back-ends to provide the load they are able to handle
>     lbfactor (via w_lf or somethere similar. That requires the back-ends to
>     be able to send request to httpd balancer-manager handler.
> 
> 
> Not really. I'd suggest a response header, travelling with each response
> back to the balancer, which can be composed quickly enough to share
> a play-by-play snapshot of the availability of that backend. This adds
> next to no traffic and minimal cpu drain if composed cleanly. And it can
> optionally be axed by the balancer in the response to the client.

The problem is that if there is no requests going to back-end the
load-balancer won't know that the back-end is available again after a
load peak.

> 
> The last thing we want are the routing headaches of contacting an
> ever-changing list one-or-many potential balancers. And we can't
> rely on a dying lbmember to "check in" that it isn't functional. Since
> the balancer must already start requests to the backend, having that
> backend supplement the responses with its health status is simple.
> 
> 

cping/cpong or options * allows check back-end nodes before sending
requests.

-- 
Cheers

Jean-Frederic