On 6/28/08, Grzegorz Nosek
<grze...@public.gmane.org> wrote:
However, there still remains the issue of communication between the load
balancer and the outside world, i.e. *how* would you like to be told
that a backend has been deemed up/down and *how* would you like to tell
nginx that backend 1.2.3.4 is currently down?
Simple healthchecking is fine with me. Like ldirectord - I have it
request a PHP file every few seconds (I forget what it's set at) - if
it fails (i.e. the PHP file does not return the expected result) then
$EVENT occurs - which could be as simple as saying "hey, nginx - this
one is down. just stop trying to use it"
As for "how" I don't know. Perhaps like the nginx-status thing,
there's an nginx-api URI defined that accepts pre-defined http auth
and a few basic REST-style commands to control it. Or communication
over a socket, or a special TCP port... that's up to the developers
who understand the architecture better than I do as to what makes the
most sense with nginx :) I don't really care as long as it is easy to
interact with and doesn't require C knowledge and linked libraries to
use it :p
As for dynamically adding/removing backends, mentioned elsethread, it
isn't trivial as it would basically require restarting nginx workers anyway
(at least for upstream_fair, which keeps its state in shared memory).
Disabling/enabling predefined backends would be fine though.
I suppose having a list of -all- available servers setup in the config
and using the API I mentioned would be fine too.
I mean right now this can be done with a hack, by pulling out the list
of upstreams into an include file, and writing to that include file
and sending nginx the appropriate HUP/etc signal to re-read the
config, but that seems a bit messy.
17 messages in ru.sysoev.nginxRe: Is it possible to monitor the fai...
.patch, .patch, .patch
