При использовании балансировки нагрузки TCP с HAProxy весь исходящий трафик проходит через LB?

Я настраиваю приложение, которое будет размещаться на виртуальных машинах (вероятно, amazon, но это не обязательно), которое потребует как HTTP-балансировки нагрузки, так и балансировки нагрузки большого количества (около 50 тыс., Если возможно) постоянных TCP-соединений. Количество данных не так велико, но обновления происходят часто.

Сейчас я оцениваю балансировщики нагрузки и немного запутался в архитектуре HAProxy. Если я буду использовать HAProxy для балансировки TCP-соединений, будет ли весь полученный трафик проходить через балансировщик нагрузки? Если да, то будет ли лучше подходить другое решение (например, LVS или даже nginx_tcp_proxy_module)?

HAProxy (как и многие балансировщики нагрузки) обычно поддерживают два диалога. Прокси-сервер имеет сеанс (в данном случае tcp) с клиентом и другой сеанс с сервером. Поэтому с прокси вы в конечном итоге увидите 2х соединений на балансировщике нагрузки. Поэтому весь трафик проходит через балансировщик нагрузки.

Когда дело доходит до масштабирования между несколькими балансировщиками нагрузки, я не думаю, что вам нужно. Но практичный и довольно простой способ сделать это - использовать что-то вроде keepalived с двумя плавающими IP-адресами и циклическим DNS между этими двумя IP-адресами. С помощью keepalived, если один из балансировщиков нагрузки выйдет из строя, другой удержит оба IP-адреса, поэтому таким образом вы получите высокую доступность. При этом, я думаю, вы будете в порядке с одним активным экземпляром haproxy с вашей нагрузкой.

HAProxy очень хорошо масштабируется. Например, сеть Stack Exchange использует веб-сокеты, которые поддерживают открытые соединения TCP. Пока я публикую это, у нас есть 143 000 установленных TCP-сокетов на виртуальной машине VMware без проблем. Загрузка ЦП на виртуальной машине составляет около 7%.

При такой настройке с HAProxy убедитесь, что вы установили maxconnдостаточно высоко. Вот несколько примеров конфигурации HAProxy для начала работы:

frontend fe_websockets
        bind 123.123.123.123:80
        mode tcp
        log global
        option tcplog
        timeout client 3600s
        backlog 4096
        maxconn 50000
        default_backend be_nywebsockets

backend be_nywebsockets
        mode  tcp
        option log-health-checks
        option redispatch
        option tcplog
        balance roundrobin
        server web1 10.0.0.1:1234
        server web2 10.0.0.2:1234
        timeout connect 1s
        timeout queue 5s
        timeout server 3600s

Да, весь трафик должен нормально проходить через балансировщик нагрузки. Запросы принимаются балансировщиком нагрузки, а ответы отправляются обратно балансировщику нагрузки, который отправляет их клиентам.

Для выбора правильного инструмента у меня нет большого опыта в других вариантах. Я использую haproxy, и он действительно хорош и стабилен и может обрабатывать большое количество трафика. Кроме того, его возможности ACL велики.

Существует возможность использовать и настраивать DSR (Direct Server Return), но это не имеет ничего общего с Loadbalancer, но настраивается в стеке tcp (таблицы маршрутизации). Мы использовали это для большого портала о потоке видео. Несмотря на то, что он работает, он доставит вам много головной боли в отношении сложности необходимой маршрутизации.

Таким образом, я бы не рекомендовал использовать эту технику, не рассматривая использование и недостатки очень тщательно.

Может быть, есть несколько советов, чтобы начать там:

• http://www.remsys.com/blog/configuring-dsr-on-the-alteon-load-balancers
• http://community.brocade.com/docs/DOC-1650

Веселиться!