Я тестирую HAProxy в качестве выделенного балансировщика нагрузки за Apache 2.2, заменяя нашу текущую конфигурацию, в которой мы используем балансировщик нагрузки Apache. В нашем текущем, только Apache, настройка, если все внутренние (исходные) серверы отключены, Apache будет обслуживать сообщение о недоступности службы 503. С HAProxy я получаю 502 неверный ответ шлюза.
Я использую простое правило перезаписи обратного прокси в Apache
RewriteRule ^/(.*) http://127.0.0.1:8000/$1 [last,proxy]
В HAProxy у меня есть следующее (работает в режиме tcp по умолчанию)
defaults
log global
option tcp-smart-accept
timeout connect 7s
timeout client 60s
timeout queue 120s
timeout server 60s
listen my_server 127.0.0.1:8000
balance leastconn
server backend1 127.0.0.1:8001 check observe layer4 maxconn 2
server backend1 127.0.0.1:8001 check observe layer4 maxconn 2
Тестирование подключения напрямую к балансировщику нагрузки при отключении внутренних серверов:
[root@dev ~]# wget http://127.0.0.1:8000/ test.html
--2012-05-28 11:45:28-- http://127.0.0.1:8000/
Connecting to 127.0.0.1:8000... connected.
HTTP request sent, awaiting response... No data received.
Предположительно, это связано с тем, что HAProxy принимает соединение, а затем закрывает его.
В режиме TCP haproxy не выдает никакого кода состояния, поэтому единственная оставшаяся точка - это apache. Я думаю, это просто потому, что haproxy принимает, а затем закрывает соединение, которое заставляет apache возвращать 502, что и ожидается.
Итак, поведение, которое вы наблюдаете, правильное. В любом случае лучше работать в режиме HTTP. Я также предлагаю вам включить опцию httplog, которая предоставит вам очень подробные журналы, и опцию http-server-close, чтобы воспользоваться способностью apache поддерживать keep-alive с haproxy, это значительно снизит потребление локального порта источника на автомате.
Я не мог заставить это работать в режиме tcp, но если вы переключитесь в режим http, вы получите 503
defaults
mode http