Re: автоматическое назначение веса бекендам

[big bond]

Я прочел раз шесть наверное )
А смысл в том, что когда у толстого приложения пик, оно съедает свои бекенды
и залезает на дополнительные, у тощих приложений критичность низкая, им
можно и лагать иногда, толстое же - флагман, оно должно всегда быть на
высоте. Кроме всего прочего, способ проверки живости бекенда путем GET'а
определенного URL имеет и другую полезную особенность - можно проверить
живость и отклик не только веб-бекенда, а целиком системы
appserver+dbserver, дёрнув нужный URI.
А LVS уж совсем не в тему, это L4, а мне требуется L7.

>
>>
>>
> Как говорил мой знакомый профессор - если вы что-то не понимаете, прочтите
> это еще и еще раз - пока не поймете =)
>
> Nginx умеет делать fallback по ошибке. Ошибкой может быть таймаут - время
> ожидания соединения. Если у бекенда все процессы заняты - новое соединение
> отвалится по таймауту и перейдет на следующий бекенд в апстриме. Резервные
> бекенды в апстриме можно пометить как backup.
> Но в общем решение кривое, ибо таймаут указывается в секундах, и ибо
> соединение сначало пройдется по всем разрешенным бекендам прежде чем уйти на
> резервный. Но если сделать определенные патчи, то вполне себе живое решение,
> хотя и костыль жуткий. Ибо того, что вы хотите - нет.
>
> А насчет непонимания - я правда так и не понял смысла всего этого, кроме
> вашего "я так хочу, значит надо". Если общее количество серверов в сумме
> способно нормально обрабатывать оба приложения при одновременных пиковых
> нагрузках на обы приложения, то в чем смысл выделения отдельных бекендов? Во
> многом, по-этому, как мне кажется, а также в виду неоднозначности оценки
> загруженности бекенда по времени ответа - в nginx с этим никто и не
> играется. Если хочется все же софтового решения, то смотрите в сторону LVS.
>
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100407/b684a99b/attachment.html>