Балансировка нагрузки UDP-сервера

У меня есть сервер udp, это центральная часть моего бизнес-процесса. чтобы справиться с нагрузками, которые я ожидаю в производственной среде, мне, вероятно, понадобятся 2 или 3 экземпляра сервера. Сервер почти полностью не имеет состояния, он в основном собирает данные, и уровень выше него знает, как обрабатывать минимальный объем устаревших данных, которые могут возникнуть из нескольких экземпляров сервера.

У меня вопрос, как я могу реализовать балансировку нагрузки между серверами? Я бы предпочел распределить запросы как можно более равномерно между серверами. Я также хотел бы иметь некоторую точность, я имею в виду, если клиент X был перенаправлен на сервер y, то я хочу, чтобы все последующие запросы X отправлялись на сервер Y, если это разумно и не перегружает Y.

Кстати, это система .NET ... что бы вы порекомендовали?

состояние внутри серверов, а не какая-то транзакция. состояние - это некоторые данные, которые серверы собирают из полученных ими данных, которые можно сопоставить с помощью простого веб-сервиса WCF. Приложение основано на UDP, и хотя я не согласен с решением, оно "выше моего уровня оплаты"

В настоящее время я пробую NLB от MS, она работает нормально, она работает с верностью из коробки, но она генерирует шум во всей сети ...

Также нет DNS ... О, и это полностью костюмный протокол.

У меня есть сервер udp, [...] сервер почти полностью не имеет состояния [..] и имеет некоторую точность, я имею в виду, если клиент X был перенаправлен на сервер y, то я хочу, чтобы все последующие запросы X отправлялись на сервер Y, так как Пока это разумно и не перегружает Y.

Итак, вы используете нераскрытый протокол приложения, который поддерживает некоторое состояние приложения и работает поверх UDP? Вы как бы идете в сложном направлении. UDP не является надежной передачей данных, в этом весь смысл - для надежной передачи данных см. Своего популярного друга TCP. Единственный способ получить «верность» - это использовать прокси-сервер с балансировкой нагрузки, который понимает протокол уровня вашего приложения и знает, каково ваше текущее состояние приложения, и может действовать соответствующим образом.

Я вижу 3 подхода, которые приближаются к обеспечению того, что вы ищете:

• Статически распределять входящие соединения по 3 IP-адресам, основываясь на IP-адресе источника (конечного пользователя). Таким образом, данный пользователь всегда будет направлен на один и тот же сервер. Большинство профессиональных брандмауэров могут сделать это для вас. Возможно, вам придется сделать эти 3 сервера высокодоступными самостоятельно, так как большинство брандмауэров не будут выполнять проверки работоспособности сервера за вас.

• Используйте DNS и используйте DNS Round Robin, как уже было предложено Мэттом Симмонсом.

• Используйте встроенную в Windows балансировку сетевой нагрузки (NLB) . Честно говоря, я не знаю, как сценарий отработки отказа будет работать с NLB и вашим полу-состоящим UDP-сервисом - вам придется исследовать это самостоятельно, основываясь на том, как ваше приложение обрабатывает состояние. С другой стороны, NLB очень прост в настройке, бесплатен с лицензией Windows, обладает зрелостью и эффективностью.

Linux Virtual Server - это масштабируемый и высокодоступный сервер, построенный на кластере реальных серверов. LVS поддерживает протокол UDP и алгоритм хеширования источника (используется, когда вы хотите, чтобы клиент всегда появлялся на одном и том же реальном сервере).

Я использую LVM для балансировки DNS (rr), SIP (sh).

Интересно. Большинство прокси-программ, которые я видел, по общему признанию основано на TCP.

Большая часть специфичной для UDP балансировки нагрузки, которую я видел в своем скудном опыте, была основана на DNS (то есть: серверы времени, DNS-серверы и т. Д.). Есть ли способ предоставить несколько записей? Если это сработает, обычный DNS Round Robin обеспечит справедливое распределение запросов (возможно, достаточно справедливое), а кэширование клиента обеспечит сохранение точности (при условии, что вы используете платформу, основанную на кеше, на стороне клиента).

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

Балансировщик нагрузки уровня 3: балансировка нагрузки будет выполняться только с учетом входящего IP-адреса и доступных внутренних IP-адресов. Этот вид балансировщика нагрузки обеспечит постоянство, всегда отправляя один и тот же входящий IP-адрес на один и тот же бэкэнд, хотя такая стратегия может перегрузить один бэкэндов, если множество клиентов приходят с одного и того же IP (будь то прокси или корпоративный шлюз)

Балансировщик нагрузки уровня 7: Балансировщик нагрузки уровня 7 будет не только балансировать как балансировщик уровня 3, но также будет смотреть на содержимое пакета, что даст вам гораздо большую гибкость для ваших политик балансировки.

Учитывая, что вы используете UDP, оба балансировщика должны давать хорошую производительность, также глубокая проверка пакетов в UDP немного более ограничена, чем в TCP (только по причинам протокола).

В зависимости от вашего бюджета вы можете начать с использования программного балансировщика нагрузки (например, linux + IPVS), а затем перейти к аппаратным балансировщикам нагрузки, подобным предлагаемым Cisco или Netapp.

NGINX с открытым исходным кодом и платформа доставки приложений NGINX Plus теперь поддерживают балансировку нагрузки UDP. Новая возможность основана на наших существующих возможностях TCP и HTTP, что делает NGINX мощным, простым в использовании и последовательным интерфейсом для еще более широкого спектра интернет-приложений и устройств.

Доступно в выпуске nginx-1.9.13