Я подготовил сервер с 8 ядрами и планирую развернуть сетевую службу. Для распределения нагрузки запросов я бы хотел запустить 8 экземпляров своего сервиса. Здесь ничего шокирующего. У меня нет доступа к аппаратному балансировщику нагрузки. Я должен упомянуть, что в настоящее время я выделил 5 публичных IP-адресов (но я могу получить больше).
Таким образом, хотелось бы услышать ваши рекомендации по построению программного решения для балансировки нагрузки.
Очевидный выбор:
Мои цели:
Я должен упомянуть, что это не служба на основе HTTP, поэтому NGiNX и тому подобное нет.
Я не люблю HAProxy из-за его требований к памяти; кажется, что для каждого клиентского подключения требуется буфер чтения и записи. Таким образом, у меня были бы буферы на уровне ядра, в HAProxy и в моем приложении. Это становится глупо! Возможно, я что-то упускаю в этом отношении?
Спасибо!
Каким бы ни было решение, если вы установите процесс для пересылки потоковых данных, ему потребуются буферы для каждого соединения. Это потому, что вы не всегда можете отправить все, что получили, поэтому вы должны хранить излишки в буфере. При этом использование памяти будет зависеть от количества одновременных подключений. На одном большом сайте успешно работает haproxy с настройками по умолчанию при 150000 одновременных подключений (4 ГБ ОЗУ). Если вам нужно больше, версия 1.4 позволяет настраивать размер буфера без перекомпиляции. Однако имейте в виду, что буферы ядра для каждого сокета никогда не будут меньше 4 КБ на направление и на сокет, так что не менее 16 КБ на соединение. Это означает, что бессмысленно заставлять haproxy работать с менее чем 8 КБ на буфер, так как он уже будет потреблять меньше, чем ядро.
Кроме того, если ваша служба - это чистый TCP, а прокси-сервер не имеет дополнительной ценности, обратите внимание на сетевые решения, такие как LVS. Это намного дешевле, поскольку он обрабатывает пакеты и не требует поддержки буферов, поэтому буферы сокетов будут отбрасывать пакеты, когда они будут заполнены, и его можно установить на том же компьютере, что и служба.
редактировать: Javier, предварительно форкованные процессы, использующие ОС для балансировки нагрузки, вообще не так хорошо работают. ОС просыпается каждый обрабатывается, когда он устанавливает соединение, только один из них получает его, а все остальные снова ложатся спать. Haproxy в многопроцессорном режиме показывает лучшую производительность около 4 процессов. Уже на 8 процессах производительность начинает падать. Apache использует против этого хороший трюк: он блокирует accept (), так что только один процесс ожидает подтверждения. Но это убивает функцию балансировки нагрузки ОС и останавливает масштабирование между 1000 и 2000 процессами. Он должен использовать массив из нескольких блокировок, чтобы несколько процессов проснулись, но он этого не делает.
без подробностей о вашем сервисе сказать очень сложно; но в целом я бы предпочел префоркинг. Это проверенная и надежная серверная стратегия (а не новомодный трюк, как некоторые думают после чтения фан-сайтов о торнадо / единорогах).
Помимо этого, несколько советов:
каждый предварительно созданный процесс может использовать современные не-select стратегии (в основном libevent) для работы с огромным количеством клиентов.
очень редко соотношение 1: 1 между ядрами и процессами дает оптимальную производительность; обычно гораздо лучше сделать некоторую динамическую адаптируемость к нагрузке.