Upstream member liveness

What is the scope of the upstream member liveness: is it per upstream
group,
or per vhost ?

If the question is unclear, consider I have 3 nginx - one balancer and
two
backends, and the following config part on the nginx balancer:

upstream backends {
server 192.168.0.1;
server 192.168.0.2;
}

And on both 192.168.0.1 and 192.168.0.2 the following configs:

server {
server_name A;

    root /foo/bar1;

location / {
    fastcgi_pass 127.0.0.1:9000;
}

}

server {
server_name B;

root /foo/bar1;

location / {
    fastcgi_pass 127.0.0.1:9000;
}

}

server 192.168.0.1 returns 500 for vhost A, will it be considered dead
for
vhost B (and I supposed it will be) ?

Thanks.

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,266077,266077#msg-266077

On Monday 11 April 2016 07:01:01 drookie wrote:

What is the scope of the upstream member liveness: is it per upstream group,
or per vhost ?

It’s per upstream group.

If the question is unclear, consider I have 3 nginx - one balancer and two
backends, and the following config part on the nginx balancer:

upstream backends {
server 192.168.0.1;
server 192.168.0.2;
}

[…]

server 192.168.0.1 returns 500 for vhost A, will it be considered dead for
vhost B (and I supposed it will be) ?

[…]

It won’t be cosidered dead for any vhost, unless you have “http_500” in
your
“fastcgi_next_upstream” directive.

http://nginx.org/r/fastcgi_next_upstream

wbr, Valentin V. Bartenev

I’m asking about the balancer behaviour, not the backends.

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,266077,266080#msg-266080

On Monday 11 April 2016 07:20:56 drookie wrote:

I’m asking about the balancer behaviour, not the backends.

I’ve answered about the balancer.

wbr, Valentin V. Bartenev

Is there someone besides Captain Evidence who knows the answer ? This is
actually the problem of the modern internet: half of the decent
questions is
flooded out by people, who not only think they know the answer, but are
arrogant enough to insist it, and from the point of an outer observer
the
topic looks “answered”.

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,266077,266137#msg-266137

On Wednesday 13 April 2016 00:47:14 drookie wrote:

Is there someone besides Captain Evidence who knows the answer ? This is
actually the problem of the modern internet: half of the decent questions is
flooded out by people, who not only think they know the answer, but are
arrogant enough to insist it, and from the point of an outer observer the
topic looks “answered”.

[…]

Ok, probably “fastcgi_next_upstream” in my answer misled you, since
nginx with
the “upstream” block for sure talks to other nginx instances by HTTP
using
“proxy_pass”, then “proxy_next_upstream” would the correct answer in
this
case.

In the configuration below:

upstream backends {
server 192.168.0.1;
server 192.168.0.2;
}

proxy_pass http://backends;

nginx doesn’t care (and knows nothing) about the virtual hosts presented
on
these servers in the upstream block, and don’t try to differentiate
requests
in terms of liveness using the host header or any other parameter.

If the “192.168.0.1” will be recognized as dead by the rules that are
described in the documentation, it will be considered dead for all
requests
for all hosts that use this upstream block.

So the “member liveness” is per upstream group.

What I also wanted to bring to your attention is that by default the 500
response isn’t recognized as a fail attempt, unless you have configured
it
using the proxy_next_upstream, fastcgi_next_upstream,
uwsgi_next_upstream,
or scgi_next_upstream directives (depending on the protocol).

wbr, Valentin V. Bartenev

Waow.
I am off-topic, but Valentin I shall note you are showing a great deal
of
patience.
Without any doubt your interlocutor will be glad and thankful for it,
and
will demonstrate it as good as when he (quickly) becomes upset.

Btw, I do not know any Captain Evidence, only Captain Obvious.

B. R.

On Wed, Apr 13, 2016 at 12:47:14AM -0400, drookie wrote:

Hi there,

Is there someone besides Captain Evidence who knows the answer ?

There’s you, me, him, them, everybody.

At least, everybody who read the previous answers in the thread.

This is
actually the problem of the modern internet: half of the decent questions is
flooded out by people, who not only think they know the answer, but are
arrogant enough to insist it, and from the point of an outer observer the
topic looks “answered”.

Since you already know that, why would you believe any answer to
your question? (Including this one.)

And, by extension, why would you even ask a question?

Read The Fine Source.

It’s the only way to be sure.

Good luck with it,

f

Francis D. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs