Re: Корректная работа с tomcat deploy

[Maxim Dounin]

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/