On 02.12.2011 19:51, Maxim Dounin wrote:

>>>> А зачем? Health-check нужен на подъем, чтобы не слать запросы
>>>> на неработающий бэкенд вообще. И реализовать достаточно просто.

>>> На подъем это другое дело. С этим я не спорю.

>> так я об этом и спрашивал. именно что на подъем, после того
>> как backend помечался как неработающий. fail_timeout == 10 секунд
>> (что слишком много, если backend лежит можно делать проверку через
>> healtp check хоть раз в секунду) и при этом не будет уходить "налево"
>> запрос от пользователя, если мы не знаем работает сейчас backend
>> или нет, и в прошлый раз - он точно был не рабочим. вероятность того,
>> что он сразу после этого будет уже рабочий - достаточно невысокая.

> Health check'и не отменяют всей той алгоритмики, которая есть
> сейчас. Ибо health check может быть успешным, а реальный запрос -
> нет.

что у нас есть:

1. если backend не смог ответить на health check,
то он с вероятностью 99.999% не сможет ответить на реальный запрос.

2. если backend смог ответить на health check, то скорее всего
он сможет ответить и на реальный запрос. (верятность этого 99%)

т.е. health check помогает уменьшить количество неопределенности
сможет какой-то backend после сбоя обработать реальный запрос или нет.

и ответ на вопрос "работает ли этот backend" можно будет
получить раньше, чем через fail_timeout секунд ожидания.

>> в результате: и повышение QoS для пользователей и более быстрое
>> восстановление сервера после сбоя. если он уже поднялся - не будет
>> простаивать 5-10 секунд, а буквально через секунду включится в работу.

> Более быстрого восстановления - не будет, см. выше.

например, если есть несколько backend`ов и все они помечены
как не работающие, то лучше посылать запрос клиента на тот backend,
который ответил на health check запрос - высока вероятность того,
что он сможет ответить и на реальный запрос. а если не ответил
на health check, то скорее всего такой backend не сможет
ответить и на реальный запрос.

а если есть "живые" backend`ы, то да, можно и не спешить особо,
и ждать fail_timeout секунд, прежде чем слать туда реальный запрос.

> Остаётся, соответственно, небольшое повышение QoS в случае очень
> малого трафика (health check успевает раньше) или при сбое (можно
> сэкономить единицы реальных запросов, т.к. не нужно посылать на
> бекенд реальные запросы, пока health check'и продолжают
> fail'иться).

так это самое неприятное и есть - посылать реальные запросы клиентов
с интервалом в fail_timeout секунд на backend, который не работает.

proxy_connect_timeout по умолчанию 60 секунд, если поставить
1-2 секунды, то живые, но нагруженные backend`ы будут считаться
не работающими и на остальные живые backend`ы в результате
нагрузка еще больше вырастет и их все nginx начнет считать
нерабочими на ближайшие fail_timeout секунд.

а если ставить proxy_connect_timeout больше чем 1-2 секунды, (10-15)
то пользователь такую большую задержку заметит и может не дождавшись
ответа от сервера уйти, посчитав его не работающим или перегруженным,
хотя живые backend`ы были в наличии и ответ он мог получить быстрее.

> Единственное интересное место, которое мне видится - это делать
> другие (меньшие) таймауты для health check'ов. Тогда можно будет,
> теоретически, быстрее определять умершие бекенды по health
> check'ам, чем по реальным запросам, и сохранять какое-то значимое
> количество реальных запросов.

это если реальные запросы приходят реже, чем интервалы health check'ов.
т.е. ответ backend`а на реальный запрос автоматически можно считать
и успешным ответом на health check запрос. таким образом - при средней
и высокой нагрузке на backend`ы - health check запросы на них вообще
не будут отсылаться. они пойдут только если какой-то backend падал,
или если на какой-то backend давно не было реальных запросов.

--
Best regards,
Gena

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