Я настраиваю приложение, которое будет размещено с использованием виртуальных машин (вероятно, Amazon, но это не высечено в камне), для чего потребуется как балансировка нагрузки HTTP, так и балансировка нагрузки большого количества (50k или около того, если возможно) постоянных 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
Существует возможность использовать и настраивать DSR (Direct Server Return), но это не имеет ничего общего с Loadbalancer, а настраивается в tcp-стеке (таблицах маршрутизации). Мы использовали это для большого портала потокового видео. Несмотря на то, что это работает, у вас возникнет серьезная головная боль в отношении сложности необходимой маршрутизации.
Таким образом, я бы не рекомендовал использовать эту технику, не учитывая очень тщательно ее использование и недостатки.
Может быть, есть какие-то подсказки для начала:
Радоваться, веселиться!
Да, весь трафик обычно должен проходить через балансировщик нагрузки. Запросы принимаются балансировщиком нагрузки, а ответы отправляются обратно в балансировщик нагрузки, который отправляет их обратно клиентам.
Что касается выбора правильного инструмента, у меня нет большого опыта в отношении других вариантов. Я использую haproxy, он действительно хорош, стабилен и может обрабатывать большой объем трафика. Кроме того, его возможности ACL великолепны.