Обслуживание сервера MMORPG

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

Если вы начнете с такого проекта, что вы можете сделать, чтобы избежать этого?

Я подозреваю, что они развертывают последнюю версию своего кода, для чего требуется перезапустить приложение (и, надеюсь, выполнить некоторые тесты перед повторным включением доступа). С этой точки зрения, это скорее проблема StackOverflow, а не ServerFault.

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

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

• Серверы игрового процесса - кластеры машин, сгруппированные в логически независимые единицы («миры» и т. Д.). Предполагается, что каждый кластер геймплея использует своего рода протокол внутренней связи, чтобы соответствовать состоянию друг друга; вам, вероятно, придется исправлять каждый кластер одновременно. Одним из возможных способов сделать это является исправление аварийного переключения. Затем вы должны быть в состоянии оба

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

• Серверы баз данных - какое-то постоянное хранилище данных, например, СУБД. Надеюсь, вы не будете вносить изменения в хранилище данных так часто. Предположительно, каждый сервер / кластер игрового процесса имеет независимое хранилище данных. Возможно, вы сможете использовать тот же трюк с горячим переключением при сбое (и попросить серверы игрового процесса отключиться, дождаться синхронизации старых и отказоустойчивых баз данных, а затем повторно подключиться к восстановлению при сбое), но мне это кажется довольно рискованным.

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

Другое решение заключается в использовании языка, который рассчитан на 100% безотказной работы и имеет встроенные возможности для оперативного исправления кода. Erlang - хороший выбор ( пример hotpatching ), и у Java есть подобная функциональность .

Ни у кого еще нет опыта на самом деле запустить что-то подобное? Да.

Есть несколько причин, которые связывают и код, и системы. Во-первых, помните, что большинство современных «больших» движков MMO были запрограммированы несколько лет назад, и, несмотря на обновления графики и технологий с тех пор, все еще зависят от того, как многие из этих систем были написаны в 2000 году или около того. Например, Eve-Online по-прежнему работает на одном огромном экземпляре Microsoft SQL Server, поэтому они всегда пытаются извлечь из него больше пользы путем обновления оборудования.

Примером улучшения с тех пор, как WoW и EVE начали работу, является работа, выполненная в распределенных базах данных ключ / значение, таких как Google MapReduce (и его реализация с открытым исходным кодом, Hadoop), чрезвычайно быстрые сервисы очереди обработки положительных ответов (Amazon SQS) и другие " облачные »-ориентированные технологии.

У меня больше всего опыта работы с EVE (я скорее парень из лазеров, чем из боевых топоров), поэтому некоторые из этих примеров более ориентированы на EVE.

Что касается системных причин:

• Физические узлы отказывают на постоянной основе. Когда узел выходит из строя, обычно его деятельность переносится в другое место с использованием любого количества средств. Тем не менее, узел должен быть снова введен в эксплуатацию как можно быстрее. В случае EVE они используют как язык обработки без стеков, так и виртуальные серверы; Я не уверен, на что похожа архитектура Blizzard.
• Необходимо проверить согласованность базы данных, очистить журналы, перестроить индексы и кэши данных. Это особенно важно в системе, подобной EVE, с одним «живым» экземпляром базы данных.
• Исправления операционной системы необходимо применять в то время, когда они могут перезагружать узлы, не требуя слишком большой активности при переносе в другое место. Миграция занимает много сетевых ресурсов, которые в противном случае могли бы быть выделены для онлайн-обработки.
• ММО на основе СУБД имеют огромные проблемы с блокировкой данных и ссылочной целостностью. Время простоя используется для очистки устаревших блокировок и нарушений целостности из журналов активности.
• В большинстве игр реализованы географически расположенные кэши данных для статической или полустатической (см. Сводные данные кэширования ниже) информации в областях интенсивного использования, например, восточное побережье и западное побережье США. Эти кэши обновляются вручную во время простоя.

Что касается причин программного обеспечения:

• Игры при работе используют много OLTP - это On Line Transaction Processing - тип чтения / записи в базы данных. Однако иногда вы хотите получить сводный отчет ... например, сколько зверя вы убили за последние 3 года. Это лучше всего обрабатывается в отчете OLAP - это аналитическая обработка в режиме онлайн - которая содержит сводную информацию, основанную на большом количестве строк в гигантском наборе данных. На самом деле игры реализуют системы, которые используют OLAP для создания кэша, чтобы ограничить количество запросов, которые должны быть прочитаны, т. Е. Они формируют общее количество на определенную дату, а затем, когда вы задаете вопрос, они просто читают строки. из хранилища OLTP, которые суммируют период времени с определенной даты. Объедините их, и вы сможете определить, насколько бесполезной стала ваша жизнь.
• Упомянутое выше горячее исправление, которое я рассматриваю как проблему программного обеспечения, но разработчики программного обеспечения рассматривают как системную проблему. ;)
• Пополнение запасов предметов - в Еве пояса астероидов обновляются каждую ночь, а некоторые комплексы также перерабатываются. Это может быть сделано до такой степени, когда он-лайн, но некоторые из алгоритмов слишком сложны и должны быть выполнены в автономном режиме, потому что они кратко ставят базу данных на колени, пока они подводят итоги экономической активности предыдущего дня.

Управление экономикой с закрытыми и открытыми циклами является одной из проблем для операторов ММО - если вы не верите мне, прочитайте некоторые академические статьи, которые были написаны об экономике игр, и некоторые исследования старых игр, таких как Ultima Online, которые имел относительно примитивную экономику. Анализ, который необходимо выполнить для пополнения открытых контуров и выявления мошенничества и другой негативной экономической активности, должен проводиться в автономном режиме с моментальным снимком данных, который иногда может быть выполнен только тогда, когда база данных полностью заблокирована.

Если вы заметите, обслуживание Евы происходит в полдень в Англии, где находится основной центр обработки данных.

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

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

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

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

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

Некоторые из недавних расширенных простоев в EvE Online связаны с установкой нового оборудования, такого как более быстрая SAN. Хотя технически можно переместить большую часть данных, создав новую файловую группу на новом диске и затем очистив основной, это привело бы к длительному периоду снижения производительности из-за постоянного ввода-вывода. Поэтому они решили отключить базу данных объемом 1,1 ТБ и переместить ее за один раз.

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

по-видимому, что-то, с чем вы не могли справиться через кластеризацию / балансировку нагрузки, такие как основные изменения схемы БД.

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

Простое обновление оборудования (или его замена) также представляется MMORPG как «обслуживание сервера». Так тривиально, мы часто забываем об этом.

Я реализовал MMO-архитектуру в Erlang, которая поддерживает горячее обновление и распространение кода. Например, один «GamePlay Server» может работать на произвольном количестве машин, если требуется обновление оборудования, его объекты могут быть переданы (в режиме реального времени) на другие машины. Это позволяет обновлять программное обеспечение без простоев.

Вы можете проверить мой сайт на http://www.next-gen.cc .

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