7 апреля 2010 г. 16:39 пользователь Dmitriy MiksIr
<miksir@xxxxxxxx> написал:
big bond wrote:
Я прочел раз шесть наверное )
А смысл в том, что когда у толстого приложения пик, оно съедает свои бекенды и залезает на дополнительные, у тощих приложений критичность низкая, им можно и лагать иногда, толстое же - флагман, оно должно всегда быть на высоте.
Так и отдайте ему все бекенды, пусть оно там живет. Если проблема в том, что бекендов не хватает на пики обоих приложений и нужно приотеризацию сделать, то тогда это не подходит, но и проверка бекенда GET-ом у железного балансировщика тоже это не решит. Тут можно разве что лимитом коннектов поиграться, но скорее все же тут нужен умный бекенд, который будет принимать соединения на тяжелое приложение с приоритетом.
Вы не поверите, решает таки. Тут есть некоторая тонкость, те бекенды, о которых я говорю, в некотором роде тоже фронтенды перед другими бекендами, т.е. балансировщик -> полубекенд(web) -> бекенд (webapp) + бекенд (DB). Но не будем вдаваться в тонкости, это не так важно.
Кроме всего прочего, способ проверки живости бекенда путем GET'а определенного URL имеет и другую полезную особенность - можно проверить живость и отклик не только веб-бекенда, а целиком системы appserver+dbserver, дёрнув нужный URI.
Ну для этого есть системы мониторинга, которые должны проверять эти и другие вещи и что-то делать - от пометки бекенда мертввым то его ребута.
Поверьте, системы мониторинга каждой части системы есть и отлично выполняют свою работу, но это уж никак не связано с балансировкой.
ОК, всем спасибо за такое внимание к моему вопросу, я получил всю необходимую информацию, буду делать выводы.
