Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
>
> On Fri, Dec 02, 2011 at 03:47:31AM -0500, igor.goncharenko wrote:
>
> > > http://trac.nginx.org/nginx/ticket/64
> >
> > Да. Очень похоже это оно. Тогда в продакшин двигать на 1.0.X нельзя пока :(
>
> Баг потенциально может проявится тогда и только тогда, когда более
> одного бекенда в пуле - мёртвые. И почти не имеет шансов проявится, если при этом
> более одного живого бекенда.
А, интересно, что случается если мы имеем всего 2 бэкенда. Неработающий один считается больше одного или нет? :)
> При этом мёртвый бекенд в пуле - это, вообще говоря,
> чрезвычайная ситуация.
Вот-вот, и пока я иду чинить мертвый бэкенд(ы), я должен быть уверен что nginx работает с живыми.
> [...]
>
> > на эту ветку и сейчас вроде как время
> > пришло, но появилась задача с fcgi пулом.
> > И теперь оказалось, похоже, смысла
> > мигрировать на 1.0.X нет - потому что для
> > задач балансера этот баг - серьезный.
>
> В 0.8.x в этом месте те же проблемы, и существенно
> хуже в других местах.
Никто не меняет продукт в продакшине на новую версию только потому что он существенно лучше в каких-то местах. Я например, меняю только:
a) если я наступил на баги которые были починены в новой ветке
б) если таковых нет - раз в год или в два на новую стабл ветку, чтобы не отставать от жизни
Некоторые вообще не трогают если работает, opennet например, вообще на 0.6, если не врут в хеадерах.
> > Насчет 1.1.X. Ну во-первых, ветка позиционируется как девелопмент, соответственно, использовать на
> > продакшине можно только в крайнем случае.
>
> Отличие stable состоит в первую очередь в том, что её, по возможности, не ломают, т.е. обновления с версии на
> версию не должны приносить сюрпризов. В development нужно быть несколько осторожнее с обновлениями (желательно читать changelog).
changelog читается всегда независимо от ветки.
> По стабильности - 1.1.10 сейчас лучше, чем 1.0.10.
Хорошо, убедили, может тогда есть смысл перевести 1.1.X в стейбл, если она по стабильности лучше и фич уже добалено много за полгода?
> > Во-вторых, упомянутый вами вопрос с долгими запросами. У меня
> > могут быть тяжелые запросы к базе, надо подумать как изменение в схеме
> > балансинга может на них повлять - судя по всему тем, что "живые"
> бэкенды будут нагружены больше чем раньше.
>
> Если вас это пугает - то зачем вы просите сделать merge этого
> изменения в stable? :)
Больше не буду :)
> На самом деле там всё не очень страшно. Алгоритм такой: упавший
> бекенд не будет призна снова работающим, пока не отработает
> успешно хотя бы один запрос, на него отправленный. Запросы на
> него будут отправляться 1 раз в fail_timeout.
>
> Если запросы долгие (много длиннее fail_timeout, т.е. не просто
> "тяжёлые запросы к базе", какой-нибудь streaming или long
> polling) это, потенциально, может привести к тому, что бекенд
> (после смерти и оживания обратно) некоторое время будет продолжать
> считаться мёртвым (пока хотя бы один запрос не завершится, или клиент его не закроет).
> Нагрузка, соответственно, будет идти большей частью на другие
> бекенды.
>
> Есть, впрочем, мнение, что для streaming/long polling подобное поведение тоже вполне
> разумно, и максимум что в подобных ситуациях следует сделать - это
> уменьшить fail_timeout.
Все логично, спасибо за разъяснение.
> > Я бы сделал изменение схемы
> > балансировки в 1.0.x опциональным и
> > выключенным по дефолту, если это
> > возможно.
> Нет.
Ну, попробовать я должен был :)
>
> Maxim Dounin
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
PS. Тут развели холивар по поводу haproxy и alive чеков. Как человек, пользующийся haproxy тоже (как tcp балансировщик), скажу, что от таких чеков больше вреда чем пользы :) Я так скажу - в nginx такая функциональность не нужна, а если так нравятся alive чеки, никто не запрещает вместо nginxа пользовать haproxy благо он http тоже балансировать умеет (может уже и кэшировать, давно в новые версии haproxy не смотрел, хотя вряд ли :).
---
Igor