В настоящее время я использую HAProxy для балансировки нагрузки TCP-соединений от клиентов на мой сервер приложений Erlang. Соединение является постоянным, что означает, что я ограничен примерно 64 КБ клиентов на оптимизированном сервере (в настоящее время я использую HAProxy на экземпляре m1.large EC2). Мой сервер приложений предназначен для горизонтального масштабирования в зависимости от количества TCP-соединений. Что меня беспокоит, так это то, что мне понадобится такое же количество серверов HAProxy, что и серверов приложений, поскольку это соединение 1: 1. Есть ли в настоящее время способ «проксировать» TCP-соединение с сервером приложений, чтобы после того, как HAProxy отправил клиента на мой сервер Erlang, он мог освободить соединение, готовое для обслуживания другого клиента? Могу ли я прочитать какие-либо документы и существующие решения, чтобы беспокоиться только об ограничении в 64 КБ на моих серверах приложений, а не на самих серверах балансировки нагрузки?
Что заставляет вас думать, что вы ограничены 64К клиентами? Вы должны быть в состоянии служить больше. Ограничивающим фактором является не количество портов, а мощность памяти и процессора, которые ограничивают количество соединений, которые вы можете открыть в любой момент времени. Проверьте: http://www.kegel.com/c10k.html который устарел, просто подумайте об этом как о проблеме c100k или c1M. :-)
Кстати, на сайте haproxy есть отличная статья на тему балансировки нагрузки и архитектуры haproxy: http://haproxy.1wt.eu/download/1.2/doc/architecture.txt
Что касается лимита подключения, это теоретический предел, которого вы обычно не достигнете, поскольку до этого у вас закончились бы ресурсы.
«Стандарт TCP устанавливает уникальные идентификаторы подключения в виде кортежа из локального IP-адреса, номера локального TCP-порта, удаленного IP-адреса и номера удаленного TCP-порта. В вашем примере оба локальных номера являются фиксированными, что оставляет примерно 2 ^ 32 удаленных IP-адреса (версия 4) и номера портов TCP 2 ^ 16, или приблизительное общее количество одновременных TCP-соединений 281 474 976 710 656 (2 ^ 48, или 2,81 * 10 ^ 14, или 281 триллион) ".
64k одновременно IDLE подключения - это мелочь для HAProxy и Erlang.
Первое, что нужно сделать, это включить страницу статистики на HAProxy. Это НЕОБХОДИМО для мониторинга и настройки производительности.
Тогда давайте ограничимся.
На кортеж может быть только 1 соединение client_IP:client_PORT:server_IP:server_PORT. Это происходит из-за того, как соединения хранятся и извлекаются в ядре (то есть в хеш-таблице). То же самое в Linux и Windows.
Мне придется не согласиться с aseq по этому поводу. Это вовсе НЕ теоретический предел. Это очень практический предел, который может быть достигнут любым, кто проводит умеренное нагрузочное тестирование.
Предположим, что в вашей текущей настройке есть 3 компьютера:
[Test Computer] [HAProxy Computer] [Erlang Computer]
(front) test_IP:????<------>haproxy_IP:80
(back) haproxy_IP:????<------>erlang_IP:80
Все IP фиксированы, а порт веб-сервера фиксирован. Таким образом, остается только один порт в качестве переменного параметра, поэтому максимальное количество подключений ограничено количеством портов, доступных на любом отдельном компьютере. Здесь небольшой запас по высоте (см. Диапазон эфемерных портов). Вам нужно получить больше экземпляров, как экземпляров Erlang, так и экземпляров нагрузочного тестирования.
Заметка: Обратите внимание, что пользователи естественным образом приходят с большого количества IP-адресов, тогда как тестеры нагрузки (curl, Apache ab, JMeter) обычно запускаются на одном компьютере с одним IP-адресом (JMeter и аналогичные инструменты могут масштабироваться с использованием распределенных ведомых устройств).
Заметка: Подключения HAProxy всегда парные (одно к клиенту + одно к внутреннему серверу). Имейте это в виду, потому что большинство системных ограничений должны быть 2 * N, чтобы разрешить N пользователей.
Только несколько портов используются для создания новых подключений. Они называются ephemeral ports. По умолчанию Linux - от 32768 до 61000.
Расширьте ассортимент. Сначала проверьте, есть ли на ваших серверах какие-либо работающие службы, использующие их.
sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 20000 65000
Эта настройка может увеличить количество портов только на 60%. Одного сервера недостаточно, чтобы перейти на веб-масштабирование.
Имейте в виду, что порт не может быть повторно использован в течение целой минуты после закрытия (см. Состояния TCP), что может сделать пул портов довольно маленьким (например, 10 000 портов в секунду?). Существуют настройки ядра для изменения продолжительности закрытия и разрешения повторного использования закрывающихся портов.
Вам не понадобятся эти настройки для постоянных подключений, поскольку они живут достаточно долго (по крайней мере, за пару минут до обновления). Тем не менее важно осознавать потенциальную проблему.
Настроить maxconn настройка в HAProxy. Это максимальное количество открытых подключений, разрешенное в любой момент.
Его можно настроить в global, на frontend или за backend. На странице статистики показаны активные настройки для всех без исключения.
Ulimit - это максимальное количество файлов, открываемых одним процессом (сокеты - это файлы в Linux). По умолчанию Linux находится где-то между 1k и 10k.
HAProxy автоматически настраивает ulimit своего процесса на основе maxconn параметр.
Возможно, вам потребуется вручную настроить ulimit для процесса Erlang.
Я думаю, что лучший способ ответить на ваш вопрос - указать, что вам не нужно сопоставление 1: 1 между HAProxy и вашими серверами приложений. Постоянное соединение возможно с HAProxy несколькими способами. Я бы посоветовал поискать в документации "постоянный", чтобы узнать больше: http://haproxy.1wt.eu/download/1.4/doc/configuration.txt.
Например, для TCP-соединений добавление источник баланса к вашей конфигурации должен обеспечить вам постоянство.
64 КБ на хост - это жесткое ограничение, но серверу приложений обычно не хватает памяти до этого. Обычно серверы приложений Java запускаются при 2000 одновременных подключениях, прежде чем 32-битная виртуальная машина исчерпает кучу.