7 апреля 2010 г. 16:39 пользователь Dmitriy MiksIr <miksir@maker.ru>написал:

>
>
> big bond wrote:
>
>> Я прочел раз шесть наверное )
>> А смысл в том, что когда у толстого приложения пик, оно съедает свои
>> бекенды и залезает на дополнительные, у тощих приложений критичность низкая,
>> им можно и лагать иногда, толстое же - флагман, оно должно всегда быть на
>> высоте.
>>
>
> Так и отдайте ему все бекенды, пусть оно там живет. Если проблема в том,
> что бекендов не хватает на пики обоих приложений и нужно приотеризацию
> сделать, то тогда это не подходит, но и проверка бекенда GET-ом у железного
> балансировщика тоже это не решит. Тут можно разве что лимитом коннектов
> поиграться, но скорее все же тут нужен умный бекенд, который будет принимать
> соединения на тяжелое приложение с приоритетом.
>
> Вы не поверите, решает таки. Тут есть некоторая тонкость, те бекенды, о
которых я говорю, в некотором роде тоже фронтенды перед другими бекендами,
т.е. балансировщик -> полубекенд(web) -> бекенд (webapp) + бекенд (DB). Но
не будем вдаваться в тонкости, это не так важно.

>
>
> Кроме всего прочего, способ проверки живости бекенда путем GET'а
>> определенного URL имеет и другую полезную особенность - можно проверить
>> живость и отклик не только веб-бекенда, а целиком системы
>> appserver+dbserver, дёрнув нужный URI.
>>
>
> Ну для этого есть системы мониторинга, которые должны проверять эти и
> другие вещи и что-то делать - от пометки бекенда мертввым то его ребута.

Поверьте, системы мониторинга каждой части системы есть и отлично выполняют
свою работу, но это уж никак не связано с балансировкой.

ОК, всем спасибо за такое внимание к моему вопросу, я получил всю
необходимую информацию, буду делать выводы.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru