У меня есть udp-сервер, это центральная часть моего бизнес-процесса. чтобы справиться с нагрузками, которые я ожидаю в производственной среде, мне, вероятно, понадобится 2 или 3 экземпляра сервера. Сервер почти полностью не имеет состояния, он в основном собирает данные, а верхний уровень знает, как обрабатывать минимальный объем устаревших данных, которые могут возникнуть из нескольких экземпляров сервера.
У меня вопрос, как мне реализовать балансировку нагрузки между серверами? Я бы предпочел как можно более равномерно распределять запросы между серверами. Я также хотел бы иметь некоторую точность, я имею в виду, что если клиент X был перенаправлен на сервер y, тогда я хочу, чтобы все последующие запросы X отправлялись на сервер Y, если это разумно и не перегружает Y.
Между прочим, это система .NET ... что бы вы порекомендовали?
состояние является внутренним внутри серверов, а не какой-либо транзакцией. состояние - это некоторые данные, которые серверы собирают из данных, которые они получают, и его можно проверить с помощью простого WCF WebService. Приложение основано на UDP, и хотя я не согласен с этим решением, его уровень оплаты выше моего.
В настоящее время я пробую NLB от MS, он работает нормально, он работает с верностью прямо из коробки, но создает шум во всей сети ...
Тоже нет DNS ... Да и протокол вполне костюмированный.
Виртуальный сервер Linux - это высокомасштабируемый и высокодоступный сервер, построенный на кластере реальных серверов. LVS поддерживает протокол UDP и алгоритм хеширования источника (это используется, когда вы хотите, чтобы клиент всегда появлялся на одном и том же реальном сервере).
Я использую LVM для балансировки DNS (rr), SIP (sh).
У меня есть udp-сервер, [...] сервер почти полностью не имеет состояния [...] имеет некоторую точность, я имею в виду, что если клиент X был перенаправлен на сервер y, то я хочу, чтобы все последующие запросы X отправлялись на сервер Y, поскольку пока это разумно и не перегружает Y.
Итак, вы используете нераскрытый протокол приложения, который сохраняет некоторое состояние приложения и работает поверх UDP? Вы как бы идете в трудном направлении. UDP не является надежным транспортом данных, в этом весь смысл - для надежной передачи данных обратитесь к его популярному другу TCP. Единственный способ добиться своей «верности» - это иметь прокси-сервер балансировки нагрузки, который понимает ваш протокол уровня приложения и который знает каково ваше текущее состояние приложения и может действовать соответственно.
Я вижу 3 подхода, которые близки к тому, что вам нужно:
Статически распределять входящие соединения по 3 IP-адресам на основе источник (конечный пользователь) IP-адрес. Таким образом, данный пользователь всегда будет направлен на один и тот же сервер. Большинство профессиональных брандмауэров могут сделать это за вас. Возможно, вам придется сделать 3 сервера высокодоступными самостоятельно, так как большинство брандмауэров не будут выполнять проверки работоспособности серверной части за вас.
Используйте DNS и используйте DNS Round Robin, как уже предложил Мэтт Симмонс.
Используйте встроенные в Windows Балансировка сетевой нагрузки (NLB). Честно говоря, я не знаю, как будет развиваться сценарий аварийного переключения с NLB и вашей службой на основе UDP с полу-сохранением состояния - вам придется исследовать это самостоятельно, исходя из того, как ваше приложение обрабатывает состояние. С другой стороны, NLB очень легко настроить, бесплатно с лицензией Windows, зрелым и хорошо работающим.
Интересный. По общему признанию, большая часть программного обеспечения прокси, которое я видел, основано на TCP.
Большая часть специфической для UDP балансировки нагрузки, которую я видел на своем скудном опыте, основывалась на DNS (то есть: серверы времени, DNS-серверы и т. Д.). Есть ли способ предоставить несколько записей A? Если это сработает, обычный циклический перебор DNS обеспечит справедливое распределение запросов (в любом случае, вероятно, достаточно справедливо), а кеширование клиента обеспечит сохранение точности (при условии, что вы используете платформу на основе кеша на стороне клиента).
Для этого вы можете использовать любой вид балансировщика нагрузки, будь то аппаратный или программный, вы можете выбирать из разных балансировщиков нагрузки в зависимости от того, что вам нужно.
Балансировщик нагрузки уровня 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