Re: Непонятнное поведение ip hash

[Maxim Dounin]

Hello!

On Wed, Dec 05, 2012 at 02:50:57AM -0500, s.gvozdetskiy wrote:

> Добрый день,  господа!
> 
> В своей работе для сохранения сессионности пользователей используем функцию
> ip_hash nginx.
> 
> пример 
> 
> upstream backend {
>  ip_hash;
>  server 1.2.3.4:80 max_fails=3 fail_timeout=15s;
>  server 1.2.3.4:80 max_fails=3 fail_timeout=15s;
>     }
> 
> В аварийной ситуации столкнулись то ли с ошибкой, то ли с "фичей" реализации
> функции. Несмотря на то что бекенд-сервер указанный в директиве upstream по
> логам выведен из пула nginx при включенной ip_hash, продолжает отправлять на
> него запросы. Кто-нибудь может подсказать направление для дальнеших
> исследований? Так и должно быть?

О какой версии nginx'а речь, и что именно подразумевается под 
словами "по логам выведен из пула", "продолжает отправляеть на 
него запросы"?

В современных версиях это должно работать так:

После 3 ошибок (max_fails) за 15 секунд (fail_timeout) - следующие 
15 секунд nginx на него запросы отправлять не будет, а дальше раз 
в 15 секунд будет отправлять на него один запрос для проверки "а 
не ожил ли бекенд".

Следует иметь ввиду, что все эти вычисления - в рамках одного 
рабочего процесса.

Следует также иметь ввиду, что запросы, отправленные на бекенд до 
признания его неработающим, могут сообщать об ошибке существенно 
позже, чем принимается решение отправить их на какой-либо бекенд.  
E.g. в типичном случае неотвечающего бекенда - через 60 секунд, 
после истечения proxy_connect_timeout.

В версиях старее 1.1.6 логика признания бекенда неработающим была 
заметно более простой (бекенд просто признавался рабочим после 
истечения fail_timeout), что в случае неотвечающего бекенда 
приводило к тому, что в течении 60 секунд (proxy_connect_timeout) 
запросы на него отправлялись, а потом в течении 15 секунд 
(fail_timeout) - нет, и так по циклу.  Если это ваш случай - 
очевидным решением будет обновить nginx.

-- 
Maxim Dounin
http://nginx.com/support.html