Поведение 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