Поведение nginx после ошибки "no live upstreams"
Добрый день.
Не могу понять поведение nginx при возникновении ошибки:
"no live upstreams while connecting to upstream, client: x.x.x.x, ..."
Я предполагал, что когда все серверы в upstream становятся недоступными,
nginx начинает отвечать 502, пока у какого-то сервера не кончится
fail_timeout.
Но практика показывает, что после ошибки "no live upstreams", nginx
продолжает отправлять запросы на серверы в upstream.
Не подскажут ли знающее люди, почему так?
Тестировал командой:
siege -t 10S -c 10 -b -v 'http://server/url'
Конфиг:
upstream test_backend {
server test1:5020;
server test2:5020;
server test3:5020;
server test4:5020;
keepalive 128;
}
server {
...
location / {
proxy_passhttp://test_backend;
proxy_next_upstream error timeout http_503;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
На серверах, указанных в upstream, крутится python сервис через uwsgi.
nginx хочет keepalive и пытается посылать много запросов в одном TCP
соединении.
А у uwsgi keepalive не включен, поэтому он принимает только один запрос и
закрывает TCP соединение.
Соответственно, nginx получает отлуп (в виде RST пакета) на каждый второй
запрос в TCP соединении.
Отсюда возникает много ошибок "recv() failed" и "upstream prematurely closed
connection".
При таком поведении, у nginx в upstream должны очень быстро кончаться живые
серверы и он должен переставать отвечать на запросы.
Смотрю в лог:
2015/09/02 12:23:46 [error] 6978#6978: *27035 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:46 [error] 6978#6978: *27095 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:46 [error] 6978#6978: *27285 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:46 [error] 6979#6979: *27295 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:46 [error] 6980#6980: *27391 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:46 [error] 6980#6980: *27423 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:46 [error] 6979#6979: *27545 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:46 [error] 6984#6984: *27761 upstream prematurely closed
connection while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:46 [error] 6984#6984: *27761 no live upstreams while
connecting to upstream, client: x.x.x.x, ...
2015/09/02 12:23:46 [error] 6984#6984: *27780 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:47 [error] 6984#6984: *27938 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:47 [error] 6984#6984: *27962 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:47 [error] 6980#6980: *28090 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
2015/09/02 12:23:47 [error] 6980#6980: *28140 recv() failed (104: Connection
reset by peer) while reading response header from upstream, client: x.x.x.x,
...
Думаю "какого черта, он в продолжает посылать запросы, если нет живых
серверов?".
Буду рад, если объясните, как так получается.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,261379,261379#msg-261379
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Поведение nginx после ошибки "no live upstreams"
On Wed, Sep 02, 2015 at 05:55:49AM -0400, xore wrote:
> Добрый день.
>
> Не могу понять поведение nginx при возникновении ошибки:
> "no live upstreams while connecting to upstream, client: x.x.x.x, ..."
>
> Я предполагал, что когда все серверы в upstream становятся недоступными,
> nginx начинает отвечать 502, пока у какого-то сервера не кончится
> fail_timeout.
> Но практика показывает, что после ошибки "no live upstreams", nginx
> продолжает отправлять запросы на серверы в upstream.
> Не подскажут ли знающее люди, почему так?
http://hg.nginx.org/nginx/file/281863981d0b/src/http/ngx_http_upstream_round_robin.c#l497
>
> Тестировал командой:
> siege -t 10S -c 10 -b -v 'http://server/url'
>
> Конфиг:
> upstream test_backend {
> server test1:5020;
> server test2:5020;
> server test3:5020;
> server test4:5020;
> keepalive 128;
> }
>
> server {
> ...
>
> location / {
> proxy_passhttp://test_backend;
> proxy_next_upstream error timeout http_503;
> proxy_http_version 1.1;
> proxy_set_header Connection "";
> }
> }
>
> На серверах, указанных в upstream, крутится python сервис через uwsgi.
> nginx хочет keepalive и пытается посылать много запросов в одном TCP
> соединении.
> А у uwsgi keepalive не включен, поэтому он принимает только один запрос и
> закрывает TCP соединение.
> Соответственно, nginx получает отлуп (в виде RST пакета) на каждый второй
> запрос в TCP соединении.
> Отсюда возникает много ошибок "recv() failed" и "upstream prematurely closed
> connection".
> При таком поведении, у nginx в upstream должны очень быстро кончаться живые
> серверы и он должен переставать отвечать на запросы.
>
> Смотрю в лог:
>
> 2015/09/02 12:23:46 [error] 6978#6978: *27035 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:46 [error] 6978#6978: *27095 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:46 [error] 6978#6978: *27285 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:46 [error] 6979#6979: *27295 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:46 [error] 6980#6980: *27391 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:46 [error] 6980#6980: *27423 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:46 [error] 6979#6979: *27545 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:46 [error] 6984#6984: *27761 upstream prematurely closed
> connection while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:46 [error] 6984#6984: *27761 no live upstreams while
> connecting to upstream, client: x.x.x.x, ...
> 2015/09/02 12:23:46 [error] 6984#6984: *27780 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:47 [error] 6984#6984: *27938 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:47 [error] 6984#6984: *27962 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:47 [error] 6980#6980: *28090 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
> 2015/09/02 12:23:47 [error] 6980#6980: *28140 recv() failed (104: Connection
> reset by peer) while reading response header from upstream, client: x.x.x.x,
> ...
>
> Думаю "какого черта, он в продолжает посылать запросы, если нет живых
> серверов?".
> Буду рад, если объясните, как так получается.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,261379,261379#msg-261379
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Поведение nginx после ошибки "no live upstreams"
Понял, спасибо, ожидал что-то подобное. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,261379,261381#msg-261381 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не применятеся список разрешённых протоколов SSL.
Уверены что в настройках самого OpenSSL не выключена поддержка SSLv3 ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,261349,261383#msg-261383 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не применятеся список разрешённых протоколов SSL.
Уверен, после добавления SSLv3 в конфиги всех опубликованных серверов он становится доступен. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,261349,261384#msg-261384 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не применятеся список разрешённых протоколов SSL.
SNI включен, но не помогает. А вот открытие различных сокетов - решение, но в таком случает придётся как-то разделять на периметре сайты для разных протоколов. Опять же либо по разным внешним IP, либо ставить дополнительный прокси/крутую железку аля Cisco ASA. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,261349,261385#msg-261385 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не применятеся список разрешённых протоколов SSL.
Но чудес не бывает.. Начтите с выяснения почему на одном хосте разные версии OpenSSL ekassir Wrote: --- > Собрал из исходников свежую версию. > Вывод nginx -V > nginx version: nginx/1.8.0 > built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) > built with OpenSSL 1.0.1e-fips 11 Feb 2013 > Вывод openssl version: > OpenSSL 1.0.1p 9 Jul 2015 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,261349,261386#msg-261386 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Планируется ли в официальном репозитории поддежка nginx-light/nginx-full/nginx-extras?
На дебиан подобных дистрибах есть несколько вариантов собранного nginx с разными модулями. Конкретно в моей ситуации потребовался http_image_filter_module которого нет в официальном репозитории дебиана в nginx-light (устанавливаемом по умолчанию) пакете, но он есть во всех остальных. Вопрос решаем в случае использования репозитория дебиана. Но в nginx репозитории такого разделения нет. Получается, что при использовании дополнительных модулей использовать nginx репозиторий не получится. Собственно вопросы. 1) Планируется ли подобное разделение и для официального nginx репозитория? 2) Если нет, то существует ли проверенный репозиторий со свежим nginx, но с несколькими вариантами сборки? P.S. Варианты: сборка из исходников, сборка своего пакета понятны, но хочется быстрого пакетного решения. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не применятеся список разрешённых протоколов SSL.
On 02.09.2015 15:53, ekassir wrote: SNI включен, но не помогает. Клиенты работающие по протоколу SSLv3 не поддерживают SNI. Умеет клиент SNI или нет - можно посмотреть здесь: https://www.ssllabs.com/ssltest/viewMyClient.html https://www.ssllabs.com/ssltest/clients.html А вот открытие различных сокетов - решение, но в таком случает придётся как-то разделять на периметре сайты для разных протоколов. Опять же либо по разным внешним IP До того как появилось SNI - это был вообще единственный вариант. Да и сейчас, это единственный гарантированно работающий вариант. Есть еще один вариант - можно в конфиге проверять $ssl_protocol и если это сайт высокой степени надежности - закрывать соединение или показывать явное сообщение про ошибку, если к нему обратились по более низкой версии протокола, по которой он работать не должен. Тогда - у части серверов будет разрешен протокол SSLv3 и TLS1.0, а у всех остальных - только старшие протоколы TLSv1.1 и TLSv1.2. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не применятеся список разрешённых протоколов SSL.
On 01.09.2015 20:17, Gena Makhomed wrote: Есть необязательное расширение TLS протокола - Server Name Indication https://tools.ietf.org/html/rfc6066#section-3 Но нюанс в том, что server_name там присылается в не-защищенном виде как ClientHello extension, И это имя ведь может не совпадать с имемен хоста, который потом будет прислан по зашифрованному HTTP-протоколу. Тут я ошибся, не может не совпадать. На основании имени из SNI сервер предъявит другой сертификат и клиент покажет сообщение об ошибке, о том что сервер предоставил невалидный сертификат. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Планируется ли в официальном репозитории поддежка nginx-light/nginx-full/nginx-extras?
P.S. Варианты: сборка из исходников, сборка своего пакета понятны, но хочется быстрого пакетного решения. А я всегда собираю свой пакет. apt-get source nginx nano debian/rules dpkg-buildpackage -rfakeroot -uc -b ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
