Как правильно распределять трафик на сервера?

Question

[lightalex]

Доброго времени суток!
Есть IP на который идет куча пакетов данных
Эти пакеты данных распределяются на определенные порты (для каждого соединения выбирается подходящий порт)
Всем этим сейчас занимается программа на Java
На всякий случай уточню что сейчас в Java программу могут слаться команды на переключение портов. Т.е. все пакеты начинают слаться на другой порт.
На данный момент если ложится эта программа или сервер на котором находится программа, то проект полностью накрывается медным тазом
Вопрос - как сделать этот центральный узел более надежным?
Как это реализуется в больших проектах?
P.S. Центральный узел получается очень высоконагруженным. Речь идет об онлайн игре. Пакетов шлется хренова туча...
P.S.S. Прошу прощение если вопрос кажется детским. Увы в теме сетей практически ноль. Так что если вам не сложно - объясните попроще :)

Answer 1

[Andrey Tsvetkov]

Во всех компаниях, где мне доводилось работать, эту роль выполнял Nginx. Если фильтрация соединений сложнее чем распарсить url, то напишите на Lua обработчик ваших соединений. Nginx+Lua достаточно неубиваемая связка.

Comments

[lightalex]

То есть по сути сервер один?
Просто я думал что каким-то образом создается связка из нескольких серверов, которые страхуют друг друга

[Andrey Tsvetkov]

Можно и связку, для Nginx не важно куда проксировать запрос. А если вам надо, чтоб несколько серверов принимало соединения, то тут вам надо на уровне DNS подключать машины, на которых будет входящие запросы принимать Nginx+Lua и отправлять их в обработку

[lightalex]

Andrey Tsvetkov, то есть, если говорить простым языком, то у нас есть допустим три сервера и на все три сервера приходит один и тот же пакет. Далее сервера решают кто из них будет обрабатывать пакет и в результате пакет уходит дальше только с одного сервера.
Я правильно описал идею?

[Andrey Tsvetkov]

Нет, пакет приходит на один из трёх серверов, на какой именно решает DNS. Далее данный пакет встречает Nginx, который в свою очередь так же может отправить на обработку одному из нескольких машин

[lightalex]

Andrey Tsvetkov, а DNS при выборе учитывает завис сервер или нет? Также учитывается ли нагруженность сервера?

[Night]

lightalex, DNS не имеет возможности этого учитывать.
Всегда предполагается, что ваши фронты живы, и сами балансируют нагрузку по "загруженным серверам".

[lightalex]

Night, два вопроса
1) А что будет если один отвалится?
2) Как они должны балансировать нагрузку между собой?

[Night]

lightalex,
1) этот сервер не будет обслуживать запросы, ставите софт для мониторинга и прочее.
2) haproxy, nginx

Answer 2

[Griboks]

Надёжность - это комплексное понятие. Её можно повысить разными способами. В данном случае разумно использовать резервирование и диагностику. Резервировать можно как саму программу, так и целый сервер. Тогда диагностика будет подразумевать своевременное обнаружение сбоя в работе, переключение трафика на резервный сервер и запуск процесса восстановления. Имеет смысл проанализировать, из-за чего происходят сбои и, если, например, всё дело в высокой нагрузке, использовать гибкое распределение ресурсов по нескольким серверам. Также необходимо вычислить какие именно элементы приводят к сбоям и, соответственно, зарезервировать их.

Comments

[lightalex]

Вот вопрос то в том как сделать это гибкое распределение ресурсов. Просто в идеале вообще не допустить сбоя. То есть чтобы ни один пакет не потерялся.
Вопрос в том - как этого добиться

Answer 3

[Дмитрий Шицков]

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

Comments

[lightalex]

Не совсем так
При подключении, пользователя забрасывает на главный сервер. Далее по желанию пользователя он может перемещать между серверами.
Но с технической точки зрения для клиента существует только один сервер - центральный узел (та самая Java программа). А этот узел уже передает пакеты к тому серверу, который выбрал пользователь.
Просто клиент написан очень криво и не умеет переключаться между несколькими IP или портами. Он как создает соединение, так соединение и есть. Поэтому и нужен этот центральный узел, чтобы перекидывать это самое соединение между серверами.
То есть получается что все зависит от центрального узла. Рухнул центральный узел - пакеты не могут доставляются серверам. И как следствие все игроки вылетели из игры. Я пытаюсь избежать такой ситуации.

[Дмитрий Шицков]

lightalex, понятно. В один момент времени может ли каждый из игровых серверов работать с двумя разными центральными или это вызовет конфликты?

[lightalex]

Дмитрий Шицков, может
Главное чтобы пакеты не терялись и не дублировались

[Дмитрий Шицков]

lightalex, в таком случае мой вариант все-таки сработает, мне кажется. Вы модете запустить 2 центральных узла и с помощью haproxy или nginx распределять соединения по центральным узлам. Правда, как я понимаю в случае падения одного из них отвалится половина игроков, т.к. второй "центральный" не сможет подхватить уже установленные сессии. Или сможет? Есть какая-то база данных, которую можно объединить на эти 2 узла?

Однако, склоняюсь к вывтду, что сторонними сркдствами делу не поможешь. Необходимо менять логику работы цеетралтных узлов. Они должны быть входной точкой для клиентов, но после выбора улиентом сервера, перкнаправлять его на сервер напрямую, а ек проксировать пакеты. Только в таком случае падение центрального узла не будет приводить к отвалу всех клиентов.

[lightalex]

Дмитрий Шицков, по сути соединение это тупо шифрованный текст, который отправляется на определенный ip+порт. После того как пакет приходит в центральный узел, он декодируется. В пакете содержится никнейм игрока. Далее узел сверяет по таблицам на каком сервере сейчас находится игрок и отправляет данные из пакета на соответствующий сервер. Так что передавать между центральными узлами информацию о соединении не составит труда.
Мне больше не понятна ситуация как при попадании пакета в ip+порт он может быть отправлен на один из нескольких серверов (центральных узлов). Вот как сделать чтобы попадая в порт, пакет отправлялся на работающий центральный узел и при этом не потерялся. Как я понимаю haproxy - это один сервер, который будет перекидывать пакеты на другие сервера (центральные узлы). Так? И получается что у нас в любом случае будет место, где принимающий сервер один. Так? Я просто на всякий случай уточняю, чтобы убедиться что я все до конца понимаю.

Понятно что нужно переписывать это шлако-клиент. Но увы клиент невозможно переписать. Так что приходится работать с тем что есть и пытаться выжать максимум стабильности из изначально нестабильной архитектуры :(

[Дмитрий Шицков]

lightalex, да, у вас все так же будет входная точка, но с значительно более высокой надежностью. В задачи haproxy аойдет перекидывание пакетов на сервера и контроль их состояния. От частоты контроля будет зависеть, сколько пакетов уйдет в никуда, прежде чем весь поток будет перенаправлен на работающий сервер. Т.е. абсолютно без потерь не обойтись, но они сведутся к минимуму. Зависит от типа вашей игры. Возможно это приведет лишь к лагу на секунду. Если у вас tcp, то скорее всего пакет даже не потеряется.

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

P. S. Если уж очень захочется, то можно и haproxy задублировать с использованием VRRP

[lightalex]

Дмитрий Шицков, там все зависит от важности пакета. Если это тупо пакет перемещения игрока, то конечно это будет всего лишь лаг. А если в этот момент будет переключение кодировки пакетов, то тогда увы кранты соединению. Как я уже говорил, так очень криво написан клиент. Я полагаю что изначально не рассчитывалась игра на сервера. Возможно небольшие частные серверы на 10-20 игроков.

А система VRRP как-то учитывает доступность haproxy? Был ли принят пакет? Или просто учитывается онлайн маршрутизатора?

[Дмитрий Шицков]

А система VRRP как-то учитывает доступность haproxy? Был ли принят пакет? Или просто учитывается онлайн маршрутизатора?

VRRP лишь протокол. Правильнее было бы написать мне о демоне keepalived. В самом простом варианте он проверяет сетевую доступность хоста, однако можно учитывать и другие параметры - доступность TCP порта и сервиса на этом порту, к примеру.

https://habrahabr.ru/company/netangels/blog/326400/ - образец схемы работы (привожу только только как образец логики работы, в статье рассматривается балансировка на nginx и LVS)

[lightalex]

Дмитрий Шицков, а кто в этой схеме получается занимается анти-ддос вопросом? Распределительный узел?

[Дмитрий Шицков]

lightalex, обычно провайдер интернет-канала :) Победить атаку Ддос своими силами иногда затруднительно, а зачастую и вовсе тщетно.
Однако принимать меры стоит в любом случае. Обычно эта роль возлагается на маршрутизаторе, т.е. на внешнем периметре вашей сети строится защита. Если маршрутизатор вам неподконтролен или отсутствует, то да, внешним рубежом выступит хост с haproxy, в противном случае при атаке первым лягут менее производителтные игровые сервисы.

[lightalex]

Дмитрий Шицков, огромное спасибо за просвещение! Начал лучше понимать что и как работает в серьезных проектах :)

Answer 4

[Станислав Бодро́в]

Есть IP на который идет куча пакетов данных

Куча - это сколько pps?

На данный момент если ложится эта программа или сервер на котором находится программа, то проект полностью накрывается медным тазом

Расследование, почему постоянно при повышении нагрузки программа ложится, было? Источник отказа найден? Виновный наказан?

Вопрос - как сделать этот центральный узел более надежным?
Как это реализуется в больших проектах?

В больших проектах, где шишки уже набиты и мазоли натёрты, в первую очередь думают о высокой доступности, надёжности, масштабируемости и безопасности, а не о CD/DI, системах автоматизации чего всего подряд, докере и всяких новомодных фичах.
Смотри, пробуй нормальный баллансировщик.

Comments

[lightalex]

1) С одного клиента может идти от 7 до 200 пакетов в секунду. Система рассчитывается на онлайн в 10к юзеров. То есть получается до 2.000.000 pps. Я конечно не специалист, но мне кажется что это дофига :) Даже если не брать максимум, а какой-нибудь средничек в 500,000 pps

2) Так нет пока нагрузки. Просто здравый смысл подсказывает что Java программа не выдержит и ляжет. Вообще она рассчитана на 100-200 юзеров, а как я указал выше, система затачивается под чуть большее количество. Вот я не верю что Java программа будет стабильно работать и за неделю ни разу не накроется. Вот не доверяю я Java... Так что надо писать нормальную систему. А раз переписываем, то почему бы не спросить совета у умных людей и не сделать как надо?

3) Вот я как раз и думаю о высокой доступности и надежности. Если отвалятся все пользователи разом это будет очень, очень плохо. Так что, как я уже сказал, советы умных людей и грамотный подход к вопросу :)
Просто меня очень напрягает это "узкое горлышко", которое создает клиент своей особенностью соединения с сервером. А клиент модифицировать нельзя. Поэтому нужно это самое горлышко сделать максимально надежным, так как получается что это самое уязвимое место в системе...

[Станислав Бодро́в]

С одного клиента может идти от 7 до 200 пакетов в секунду. Система рассчитывается на онлайн в 10к юзеров. То есть получается до 2.000.000 pps.

200×10000×8×1500 = 24000000000 бит/с. Или 24 Гбит/с для пакета ТСР. Это очень хорошо и круто.

Просто здравый смысл подсказывает что Java программа не выдержит и ляжет.

Не кастомизированное ядро Linux при нормальных сетевых картах выдаёт порядка 300'000 pps или около 4 Гбит/с. У тебя довольно хорошая программа на Яве. С таким интенсивным трафиком может не справляться ядро. Если лишнее из твоей программы повыкидывать и допилить, а лучше переписать на Си, то получится неплохой балансировщик). Хотя не совсем представляю, как 20G обрабатывает твой балансировщик на недопиленном ядре и без кучи интеловских сетевух. Реально хорошая программа на Java))

Что делать? Тут несколько вариантов. Самый (относительно) простой программный - определиться что ближе Netmap или DPDK.Ознакомиться с тем как можно прокачивать сетевой стэк Линукс. Накупить серверов, сетевух, настроить ПО.
Для построения кластера высокой надёжности (именно поэтому нужно несколько серверов) можно присмотреть CARP, Heartbeat, Piranha, или какое-нибудь другое решение
Второй способ состоит в установке специальных сетевых устройств для балансировки трафика (балансировка по IP с использованием маршрутизаторов). Он довольно затратный. Требует дорогих устройств, специалистов, знания сетевых протоколов. Позволяет выполнять более простое увеличение мощностей (некоторые железки позволяют делать типа агрегации), фильтрацию и приоритезацию трафика, балансировку по географическому положению клиентов.
Дальше считай и прикидывай сам.

[lightalex]

Не кастомизированное ядро Linux при нормальных сетевых картах выдаёт порядка 300'000 pps или около 4 Гбит/с. У тебя довольно хорошая программа на Яве. С таким интенсивным трафиком может не справляться ядро.

Так я и не знаю справится ли Java программа. Я ее не тестировал. Она просто есть опенсурс. Но у меня есть сомнения что она сможет обработать столько трафика. Там тупо используется либа от Netty.

Спасибо за ответ!
Уже появилась идея как можно реализовать систему в рамках моего проекта, чтобы система была отказоустойчивой и надежной

[Станислав Бодро́в]

lightalex, удачи.