ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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


 




Copyright © Lexa Software, 1996-2009.