Hello!

On Tue, Oct 28, 2014 at 10:31:11PM +0500, Никита Кардашин wrote:

> Привет всем,
>
> Каким образом можно корректно работать с tomcat-upstream, который
> используется для java-приложения, deploy которого занимает несколько минут?
>
> Среда:
> На входе стоит nginx proxy, в котором настроено n апстримов в режиме
> round-robin с max_fail=1. За ним - n серверов приложений, на которых
> работает Apache Tomcat, в котором работает java-приложение.
>
> Если падает один из серверов приложений - все прекрасно, nginx стучится к
> нему, получает 500/502 и выкидывает апстрим из списка доступных на заданное
> время и рероутит запрос на другой апстрим. Пользователь проблемы не видит.
> Но это если упало совсем. Если не упало, а зависло или ушло в re-deploy
> (либо мы сами стартовали re-deploy) - возникает проблема.
>
> Проблема:
> Деплой java-приложения в случае краша или обновления занимает несколько
> минут (в особо злом случае - до десяти). Томкат, сволочь, в это время
> принимает входящие соединения на свой порт, но не обслуживает их, а вешает
> на холд до момента завершения деплоя приложения. Nginx принимает коннект от
> пользователя, маршрутизирует запрос к апстриму, и... ждет 3-5 минут пока
> бэкэнд не поднимется.
> В итоге пользователь видит белый экран или частично загрузившуюся страницу
> (как повезет раунд-робином), хотя в живых есть куча других апстримов,
> которые могли бы обслужить его запрос.
>
> Осложняется ситуация тем, что апстрим в некоторых ситуациях может долго
> думать или отдавать много данных и решить проблему "в лоб", урезав
> proxy_read_timeout до нескольких секунд - нельзя.
>
> Меня может что-то спасти?

Если процедура проходит в штатном режиме, то правильно - убрать
обновляемый сервер из блока upstream{}, после обновления - вернуть
обратно.

Если говорить о нештатных ситуациях, то имеет смысл посмотреть в
сторону балансировщика least_conn. В отличие от round-robin'а он
сразу заметит большое количество соединений, ждущих ответа, и
перестанет направлять запросы на "плохой" бекенд.

Ну и в nginx-plus есть некоторое количество более других решений,
таких как активные health check'и и реконфигурация
upstream-серверов на лету. Но это уже реклама.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru