Максимизация TCP-соединений на балансировщике нагрузки HAProxy
В настоящее время я использую HAProxy для балансировки нагрузки по tcp-соединениям от клиентов к моему серверу приложений Erlang. Соединение является постоянным, что означает, что я ограничен примерно 64K клиентами на оптимизированном сервере (в настоящее время я использую HAProxy на экземпляре m1.large EC2). Мой сервер приложений предназначен для горизонтального масштабирования в зависимости от количества соединений TCP. Что меня беспокоит, так это то, что мне потребуется такое же количество серверов HAProxy, что и для серверов приложений, поскольку это соединение 1:1. Есть ли в настоящее время способ "прокси" tcp-соединения с сервером приложений, чтобы после того, как HAProxy отправит клиента на мой сервер Erlang, он сможет освободить соединение, готовое обслуживать другого клиента? Есть ли какие-нибудь документы, существующие решения, которые я могу прочитать, так что мне нужно беспокоиться только об ограничении 64 КБ на моих серверах приложений, а не на самих серверах балансировки нагрузки?
4 ответа
Что заставляет вас думать, что вы ограничены до 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) и 2^16 номеров портов TCP, или приблизительный суммарный потенциал одновременных соединений 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), что может сделать пул портов достаточно маленьким (например, 10k портов / с?). Существуют настройки ядра, позволяющие изменить длительность закрытия и разрешить повторное использование закрывающихся портов.
Вам не понадобятся эти настройки для постоянных соединений, поскольку они живут достаточно долго (по крайней мере, за пару минут до обновления). Тем не менее, важно знать о потенциальной проблеме.
HAProxy maxconn
Настройте maxconn
установка в HAProxy. Это максимальное количество открытых соединений, разрешенное в любое время.
Это можно настроить в global
за frontend
или за backend
, Страница статистики показывает, что является активным параметром для всех и каждого.
Linux Ulimit
Ulimit - это максимальное количество файлов, открываемых одним процессом (сокеты - это файлы в linux). Linux по умолчанию находится где-то между 1К и 10К.
HAProxy автоматически настраивает свой процесс ulimit на основе maxconn
параметр.
Вам, вероятно, потребуется настроить ulimit вручную для процесса Erlang.
Я думаю, что лучший способ ответить на ваш вопрос - указать, что вам не нужно отображение 1:1 между HAProxy и вашими серверами приложений. Постоянное соединение возможно с HAProxy несколькими способами. Я бы предложил поискать в документации "постоянный", чтобы узнать больше: http://haproxy.1wt.eu/download/1.4/doc/configuration.txt.
Например, при использовании только TCP-соединений добавление источника баланса в конфигурацию обеспечит вам постоянство.
64 КБ на хост - это определенное жесткое ограничение, но сервер приложений, обрабатывающий его, обычно до этого исчерпывает память. Обычно Java-серверы приложений запускаются при 2000 одновременных подключениях до того, как 32-битному виртуальному серверу не хватает памяти.