Использование Linux Virtual Server для балансировки нагрузки зон в MMO-игре

Question

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

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

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

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

Что вы, ребята, думаете обо всем сказанном выше?

Обновление: Я отправил тот же вопрос в список рассылки пользователей LVS http://marc.info/?l=linux-virtual-server&m=124976265209769&w=2

Обновление: Я также начал аналогичную тему на форуме gamedev.net http://www.gamedev.net/community/forums/topic.asp?topic_id=544386

Answer 1

Чтобы ответить на ваш вопрос, нам нужно понять, нужен ли вам объем или ответ, но трудно получить оба одновременно.

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

Масштабируемость - я предполагаю, что у вас не хватает памяти, ресурсов процессора и пропускной способности сети.

• Уровень приложения - логика вашего приложения получает пакет приложения и соответственно маршрутизирует.

• Уровень обслуживания - ваша системная структура (какой-либо интерфейс) получает пакет, а через модуль - выполняет маршрутизацию (например, пользовательский модуль apache, даже модули сетевого драйвера - например, написание сетевого фильтра)

• Уровень ядра - выполняет маршрутизацию на уровне сетевых пакетов.

Чем ближе вы подойдете к металлу, тем лучше будет ваш ответ. Я предлагаю использовать выделенный сервер linux заранее для выполнения маршрутизации - переходите на собственный, а не виртуальный. Используйте несколько или объединенные сетевые адаптеры для глобальной сети и выделенный адаптер для каждой конечной точки (по одному + wan, по одному для каждого подключенного сервера приложений)

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

Если объем важен, но время отклика вторично, реализуйте встроенный в C ++ высокоскоростной коммутатор сокетов, работающий в состоянии проблемы / пользователя. Он прост в обслуживании и обеспечивает наилучшую масштабируемость.

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

Заключительные мысли -

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

(a) сообщения должны удобно помещаться в одном сетевом пакете, для большинства домашних маршрутизаторов менее 1500 байт

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

(c) Постарайтесь ограничить видимость зоны для клиентов, они должны знать только о своих зонах и смежных зонах (если вы реализуете пункт b выше)

Надеюсь, это поможет, извините, я не могу быть более конкретным в отношении KTCPVS.

Answer 2

Вы не указали, где находится узкое место. Сетевой трафик? Дисковый ввод-вывод? Циклы процессора?

Предполагая, что вы имеете в виду балансировщик нагрузки 7-го уровня и у вас недостаточно мощности процессора, я думаю, что LVS - не оптимальный выбор. Я выполнил балансировку нагрузки веб-сервера с помощью LVS, который работает просто и не совсем сложен.

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

Answer 3

Почему вы перемещаете логику распределения на балансировщик нагрузки? Это компонент, который не является бесплатным и может сломаться. Кажется, ваши клиенты прекрасно знают, в какой зоне они находятся. Кажется, они могли бы очень хорошо подключиться к zone<n>.example.com. Затем вы будете обрабатывать балансировку нагрузки на уровне DNS.

Answer 4

Самая большая проблема в чем-то подобном - это то, что происходит, когда игроки находятся около границы. Очевидно, они должны иметь возможность видеть и взаимодействовать друг с другом, но они находятся на разных серверах. Таким образом, вам нужно довольно необычное межсерверное взаимодействие, иногда просто дублирование сообщений на оба сервера. Это может быть еще сложнее, когда кто-то находится рядом с «углом», и тогда вам приходится иметь дело с 4 серверами!

Книга Разработка многопользовательской игры содержит главу «Подводные камни общих серверов», в которой подробно рассматривается эта проблема.

До сих пор я не слышал о Linux Virtual Server, поэтому не понимаю, как он подходит. Я думаю, что ваше реальное серверное приложение должно поддерживать эту специфическую для игры балансировку нагрузки, а не пытаться запустить кластер и предполагать, что оно автоматически знает, как разделить ваше приложение (чего не будет). Если бы я был вами, я бы написал серверную программу для обработки своего собственного участка земли, и он должен подключиться к участкам вокруг него, а затем разработать межсерверный протокол для передачи этих сообщений («здесь приходит игрок, я собираюсь начать рассказывать вам о нем! »,« обязательно расскажите мне о сообщениях возле нашей границы »,« хорошо, игрок вышел из моей территории и попадает в вашу, вот его подробные данные »и т. д.) , Я думаю, что это немного сложнее, чем просто запустить другой вариант Linux и предположить, что вы получите автоматическое распределение нагрузки.