Я прочел раз шесть наверное ) А смысл в том, что когда у толстого приложения пик, оно съедает свои бекенды и залезает на дополнительные, у тощих приложений критичность низкая, им можно и лагать иногда, толстое же - флагман, оно должно всегда быть на высоте. Кроме всего прочего, способ проверки живости бекенда путем GET'а определенного URL имеет и другую полезную особенность - можно проверить живость и отклик не только веб-бекенда, а целиком системы appserver+dbserver, дёрнув нужный URI.
А LVS уж совсем не в тему, это L4, а мне требуется L7.
Как говорил мой знакомый профессор - если вы что-то не понимаете, прочтите это еще и еще раз - пока не поймете =)
Nginx умеет делать fallback по ошибке. Ошибкой может быть таймаут - время ожидания соединения. Если у бекенда все процессы заняты - новое соединение отвалится по таймауту и перейдет на следующий бекенд в апстриме. Резервные бекенды в апстриме можно пометить как backup.
Но в общем решение кривое, ибо таймаут указывается в секундах, и ибо соединение сначало пройдется по всем разрешенным бекендам прежде чем уйти на резервный. Но если сделать определенные патчи, то вполне себе живое решение, хотя и костыль жуткий. Ибо того, что вы хотите - нет.
А насчет непонимания - я правда так и не понял смысла всего этого, кроме вашего "я так хочу, значит надо". Если общее количество серверов в сумме способно нормально обрабатывать оба приложения при одновременных пиковых нагрузках на обы приложения, то в чем смысл выделения отдельных бекендов? Во многом, по-этому, как мне кажется, а также в виду неоднозначности оценки загруженности бекенда по времени ответа - в nginx с этим никто и не играется. Если хочется все же софтового решения, то смотрите в сторону LVS.
