Re: upstream member liveness

[B.R.]

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 10:05 AM, Валентин Бартенев  wrote:

> 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
>
> ___
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: upstream member liveness

[Валентин Бартенев]

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

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: upstream member liveness

[Francis Daly]

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 Dalyfran...@daoine.org

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: upstream member liveness

[drookie]

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

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

upstream member liveness

[drookie]

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

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx