Назад | Перейти на главную страницу

Балансировка нагрузки долго работающие TCP-соединения

Я пытаюсь найти лучший способ балансировки нагрузки длительно работающих TCP-соединений для следующего сценария:

У нас есть несколько серверов за избыточным набором брандмауэров, и клиенты устанавливают длительные (обычно 10-15 часов) TCP-соединения с нашими внутренними серверами.
Прямо сейчас «балансировка нагрузки» обрабатывается с помощью циклического подхода на стороне клиента, чтобы пройти через список IP-адресов, которые все размещены на наших брандмауэрах и настроены NAT в соответствии с внутренними серверами.

Я бы хотел отказаться от этого подхода и иметь только один общедоступный IP-адрес и отдельный балансировщик нагрузки, который может проверять работоспособность / нагрузку серверов и соответствующим образом распределять входящие запросы на подключение клиентов.

Одна из проблем здесь заключается в том, что каждый клиент устанавливает 3 сокетных соединения на 3 разных портах, и я бы предпочел, чтобы эти соединения были «липкими», чтобы все эти 3 запроса на соединение отправлялись на один и тот же внутренний сервер.

Я смотрел, например, HAProxy, но я не совсем уверен, действительно ли он подходит для моего сценария. У нас относительно небольшое количество подключений (~ 300 клиентов * 3 сокетных подключения для каждого). Обычно мы видим объем непрерывной передачи данных ~ 15 КБ / с для каждого сокета.

Мы очень ценим любой вклад в это!

Спасибо,

Том

Другие успешно внедрили HAProxy, и он даже помогает запускать сайты StackExchange. Другие популярные веб-интерфейсы: Nginx и фунт. В конечном итоге большинство этих решений будет достаточно эффективным для большинства веб-трафика.

Если ваша цель - высокая доступность и балансировка нагрузки, липкие или постоянные сеансы не рекомендуется, поскольку они снижают эффективность обоих.

Не зная больше о вашей архитектуре или типе трафика, я бы порекомендовал LVS, что является моим предпочтительным решением. Вы имеете в виду сетевой уровень, на котором это решение для балансировки нагрузки более сфокусировано. Он может использоваться с большинством протоколов и не ограничивается веб-трафиком.

Если предположить, что все ваши серверные машины «активны» и могут отвечать на запросы, все, что вам действительно нужно, - это интерфейс балансировщика нагрузки.

Хороший балансировщик нагрузки сможет отслеживать количество подключений, идущих к каждому хосту, и динамически распределять новые подключения, чтобы не перегружать одну из внутренних систем (под «хорошим» я подразумеваю «дорогостоящий», например, Cisco Content Switches / Модули службы переключения контента). Цена идет рука об руку с функциями: переключатели контента довольно высоко на уровне решений.

У меня нет опыта работы с HAProxy, но похоже, что он может выполнять балансировку нагрузки с минимальным количеством подключений, например переключатели контента, так что это, вероятно, будет хорошим выбором (и по гораздо более привлекательной цене). Я не уверен, что HAProxy может отслеживать источник (отправлять все соединения с одного IP-адреса на один и тот же сервер).

Несколько шагов вниз по pf брандмауэр (или pfsense настраиваемое распределение) может выполнять балансировку нагрузки (случайную или циклическую, я не верю, что они могут выполнять «наименьшие взвешенные соединения» в качестве варианта балансировки, как переключатели содержимого). Отслеживание источников реализовано в pf, хотя вам, возможно, придется поиграть с тем, как долго эта информация сохраняется, чтобы избежать проблем с перемещением соединений с одного сервера на другой.
Если вы уже используете pf / pfsense в качестве брандмауэра, это бесплатный вариант: мы используем его в моем текущем развертывании с хорошими результатами, но наши соединения не так долговечны, как ваше.