Обнаружение сбоя серверной части балансировки нагрузки прокси-сервера Apache

вот мой сценарий (по моим предшественником):

два сервера Apache, обслуживающие обратный прокси-сервер для ряда смешанных серверных веб-серверов(Apache, IIS, Tomcat и т. д.). Есть некоторые сайты, для которых у нас есть несколько веб-серверах, и в этих случаях мы делаем что-то типа:

<Proxy balancer://www.example.com>
    BalancerMember http://192.168.1.40:80
    BalancerMember http://192.168.1.41:80
</Proxy>
<VirtualHost *:80>
    ServerName www.example.com:80
    CustomLog /var/log/apache2/www.example.com.log combined
    <Location />
        Order allow,deny
        Allow from all
        ProxyPass balancer://www.example.com/
        ProxyPassReverse balancer://www.example.com/
    </Location>
</VirtualHost>

Итак, в этом примере у меня есть один сайт (www.example.com) в конфигурациях прокси-серверов, и этот сайт проксируется на один или другой из двух серверных серверов, 192.168.1.40 and .41.

Я оцениваю это, чтобы убедиться, что мы отказоустойчивы на всех наших веб-службах (по этой причине я уже поместил два обратных прокси-сервера в общий IP-кластер), и я хочу убедиться, что сбалансированные по нагрузке серверные серверы также отказоустойчивы. Но у меня возникли проблемы с выяснением, встроено ли в модуль mod_proxy_balancer обнаружение сбоев бэкэнда (и логика, чтобы избежать сбоя бэкэнд-сервера)...

Так что если 192.168.202.40 идет вниз, Apache обнаружит это (я пойму, если он сначала примет неудачный запрос) и автоматически направит все запросы на другой сервер, 192.168.202.41? Или он будет продолжать балансировать запросы между неудавшимся бэкэндом и операционным бэкэндом?

Я нашел некоторые подсказки в документации Apache для mod_proxy и mod_proxy_balancer это, похоже, указывает на то, что сбой может быть обнаружен ("maxattempts = максимальное число попыток отработки отказа перед отказом.", "failonstatus = один или разделенный запятыми список кодов состояния HTTP. Если задано, это приведет работника в состояние ошибки, когда сервер возвращает любой код состояния в списке."), но после нескольких дней поиска я не нашел ничего убедительного, говорящего наверняка, что это будет (или, по крайней мере, "должен") обнаружить сбой и восстановление бэкэнда.

Я скажу, что большинство результатов поиска ссылаются на протокол AJP для передачи трафик на серверные серверы, и это, по-видимому, поддерживает обнаружение сбоев, но мои бэкэнды-это смесь Apache, IIS, Tomcat и других, и я уверен, что многие из них не поддерживают AJP. Они также представляют собой смесь окон 2k3/2k8 и Linux (в основном Ubuntu Lucid), в которых работают различные приложения с различными требованиями, поэтому дополнительные модули, такие как Backhand и LVS, не являются для меня вариантом.

Я также попытался эмпирически проверить эту функцию, создав новый тестовый сайт, как это:

<Proxy balancer://test.example.com>
    BalancerMember http://192.168.1.40:80
    BalancerMember http://192.168.1.200:80
</Proxy>
<VirtualHost *:80>
    ServerName test.example.com:80
    CustomLog /var/log/apache2/test.example.com.log combined
    LogLevel debug
    <Location />
        Order allow,deny
        Allow from all
        ProxyPass balancer://test.example.com/
        ProxyPassReverse balancer://test.example.com/
    </Location>
</VirtualHost>

где 192.168.1.200-это фиктивный адрес, на котором не работает ни один веб-сервер, для имитации сбоя бэкэнда. Тестовый сайт обслуживался без проблем для группы разных клиентских машин, но даже с уровнем LogLevel, установленным для отладки, я не видел ничего зарегистрированного, чтобы указать, что он обнаружил, что один из серверных серверов не работает... И я хотел бы убедиться на 100%, что я могу взять наши сбалансированные по нагрузке бэкэнды для обслуживания (по одному, конечно), не затрагивая производственные площадки.