Здесь мой сценарий (разработанный моим предшественником):
Два сервера 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 и .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. Они также представляют собой смесь ящиков Windows 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 набором для отладки я ничего не видел, чтобы указать, что он обнаружил, что один из серверов back down... И Я хотел бы сделать 100% уверенным, что я могу использовать наши балансированные нагрузки для обслуживания (по одному за раз, конечно), не затрагивая производственные площадки.
