Обнаружение сбоя серверной части балансировки нагрузки прокси-сервера 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%, что я могу взять наши сбалансированные по нагрузке бэкэнды для обслуживания (по одному, конечно), не затрагивая производственные площадки.

2 ответов


http://httpd.apache.org/docs/2.4/mod/mod_proxy.html раздел "Параметры BalancerMember", свойство=повторить попытку:

Если работник пула соединений с серверным сервером находится в ошибке состояние, Apache httpd не будет пересылать запросы на этот сервер, пока время ожидания истекает. Это позволяет [one] закрыть серверную часть сервер для обслуживания, и верните его в сеть позже. Значение 0 означает всегда повторять работников в состоянии ошибки без перерыв.

однако есть и другие условия сбоя, которые не будут пойманы с помощью mod_whatever, например, сервер IIS, выполняющий приложение, которое не работает. IIS включен, поэтому можно установить соединение и прочитать страницу, просто страница всегда будет ошибкой внутреннего сервера 500. Здесь вам придется использовать failonerror, чтобы поймать его и заставить работника в состоянии ошибки.

во всех случаях, когда работник находится в состоянии ошибки, трафика не будет направляется к нему. Я пробовал разные способы использования этого первого сбоя и повторной попытки, но всегда есть случаи, когда страница с ошибкой возвращается к клиенту.


в параметрах BalancerMember есть свойство "ping"

чтение документации похоже, что "ping", установленный в 500ms, отправит запрос, прежде чем mod_proxy направит вас к BalancerMember. mod_proxy будет ждать ответа от BalancerMember 500ms, и если mod_proxy не получит ответа, он будет, но BalancerMember в состояние ошибки.

Я устал от реализации этого, но это, похоже,не помогло с направлением на живой баланс.

<Proxy balancer://APICluster>
    BalancerMember https://api01 route=qa-api1 ttl=5 ping=500ms
    BalancerMember https://api02 route=qa-api2 ttl=5 ping=500ms
    ProxySet lbmethod=bybusyness stickysession=ROUTEID
</Proxy>

http://httpd.apache.org/docs/2.4/mod/mod_proxy.html

свойство Ping сообщает веб-серверу "проверить" соединение с бэкэндом перед пересылкой запроса. Для AJP это заставляет mod_proxy_ajp отправлять запрос CPING на соединение ajp13 (реализовано на Tomcat 3.3.2+, 4.1.28+ и 5.0.13+). Для HTTP это заставляет mod_proxy_http отправлять 100-Continue на бэкэнд (действителен только для HTTP / 1.1 - для не HTTP / 1.1 бэкэндов, это свойство не имеет никакого эффекта). В обоих случаях параметром является задержка в секундах ожидания ответа. Эта функция была добавлена, чтобы избежать проблем с зависшими и занятыми бэкэндами. Это увеличит сетевой трафик во время нормальной работы, что может быть проблемой, но это снизит трафик в случае, если некоторые узлы кластера не работают или заняты. Добавляя постфикс ms, задержка также может быть установлена в миллисекундах.