Кажется, что в большинстве MMORPG-игр проводится регулярное обслуживание серверов, некоторые - каждый день, некоторые - раз в неделю. Что им на самом деле нужно делать и почему это необходимо?
Если вы начнете с такого проекта, что вы можете сделать, чтобы этого избежать?
Я подозреваю, что они развертывают последнюю версию своего кода, для чего требуется перезапуск приложения (и, надеюсь, выполнение некоторых тестов перед повторным включением доступа). С этой точки зрения, это скорее проблема StackOverflow, а не ServerFault.
Я думаю, что можно создать систему «горячего исправления», но это обязательно будет невероятно сложно. Насколько я понимаю, «приложение» сервера MMO состоит из нескольких различных компонентов:
Сервер входа - Обрабатывает аутентификацию и действует как «концентратор» между игровыми серверами. Когда клиент входит в игру, он больше не взаимодействует с сервером входа. В такой системе вы можете применить патчи и перезапустить сервер входа в систему, не мешая игровому процессу (хотя у вас будет период времени, когда люди не смогут войти в систему).
Игровые серверы - Кластеры машин, сгруппированные в логически независимые единицы («миры» и т. Д.). Предполагается, что каждый игровой кластер использует какой-то внутренний протокол связи для соответствия состояния друг другу; вам, вероятно, придется исправлять каждый кластер сразу. Один из возможных способов сделать это - исправить аварийное переключение. Тогда вам нужно будет иметь возможность
Серверы баз данных - Какое-то постоянное хранилище данных, например СУБД. Надеюсь, вы не так часто вносите изменения в хранилище данных. Предположительно, каждый игровой сервер / кластер имеет независимое хранилище данных. Вы могли бы использовать тот же трюк с теплым аварийным переключением (и попросить игровые серверы отключиться, дождаться синхронизации старой и аварийной базы данных, а затем повторно подключиться к аварийному переключению), но мне это кажется довольно рискованным.
Все вышеперечисленные случаи добавляют невероятную сложность и без того сложной системе и создают множество мест, где сбой кода может вызвать потерю или повреждение данных.
Другое решение - использовать язык, который рассчитан на 100% безотказную работу и имеет встроенные возможности для горячего исправления работающего кода. Erlang хороший выбор (пример горячей замены), и Java имеет аналогичную функциональность.
Ни у кого другого нет опыта действительно запускать что-то подобное? Ага.
Есть несколько причин, объединяющих как код, так и системы. Во-первых, помните, что большинство текущих «больших» движков MMO были запрограммированы несколько лет назад, и, несмотря на модернизацию графики и технологий с тех пор, все еще зависят от того, как многие из этих систем были написаны примерно в 2000 году. Eve-Online, например, по-прежнему работает на одном огромном экземпляре Microsoft SQL Server, поэтому они всегда пытаются извлечь из него больше, обновляя оборудование.
Примером улучшения с момента запуска WoW и EVE является работа, проделанная в распределенных базах данных типа "ключ-значение", таких как Google MapReduce (и его реализация с открытым исходным кодом, Hadoop), чрезвычайно быстрые службы очереди обработки положительных ответов (Amazon SQS) и другие ». облачные »-ориентированные технологии.
У меня самый большой опыт работы с EVE (я больше люблю лазеры, чем боевые топоры), поэтому некоторые из этих примеров больше ориентированы на EVE.
Что касается системных причин:
Что касается программных причин:
Управление экономикой как с замкнутым, так и с разомкнутым циклом - одна из проблем для операторов MMO - если вы мне не верите, прочтите некоторые академические статьи, написанные об экономике игр, и некоторые исследования старых игр, таких как Ultima Online, которые имели относительно примитивную экономику. Анализ, который должен произойти для пополнения открытых циклов и выявления мошенничества и другой негативной экономической деятельности, должен происходить в автономном режиме с моментальным снимком данных, который иногда может быть выполнен только тогда, когда база данных полностью заблокирована.
Если вы заметили, обслуживание Евы происходит в полдень в Англии, где находится основной центр обработки данных.
Я подозреваю, что общее время, в течение которого Blizzard (я предполагаю, что это, учитывая, что вы публикуете свой вопрос сегодня утром во вторник) предлагает обслуживание для всего кластера; не каждому серверу требуется так много времени для выполнения работы.
Хотя можно было бы восстановить отдельные серверы быстрее, это вызвало бы незаконные крики фаворитизма по отношению к игрокам, чьи игровые миры вышли из строя раньше в расписании. Таким образом, они держат все в порядке, пока вся работа не будет сделана; имея сотни областей, над которыми нужно работать, они, вероятно, выполняют большую часть работы параллельно, но все же сериализуют окончательную проверку, прежде чем возвращать вещи в оперативный режим. Если вы выполняете обновление оборудования, оно, вероятно, будет сериализовано в таком же количестве центров обработки данных, как и они.
Что касается того, почему они выполняют обслуживание, некоторые из них могут быть просто перезагрузкой производительности. Хотя было бы здорово, если бы такие перезагрузки не требовались, их выбор может зависеть от стоимости этого и от последствий невыполнения.
Когда вы смотрите на то, почему они не могут кластеризовать процессы и выполнять последовательное обслуживание, то, что мало кто знает об инфраструктуре WoW, предполагает, что несколько машин предоставляют услуги для каждой области (т.е. одна для мира, одна для инстансов и рейдов, одна для полей битвы. и т. д.) они не используют настройку процесса активный-активный с общим состоянием. Нет обмена живым состоянием, только постоянные данные через базу данных.
В конце концов, механизм предоставления онлайн-сервиса с отслеживанием состояния для такой большой базы подписчиков ставит под сомнение некоторые из лучших практик, которые мы могли бы придерживаться, когда говорим о веб-сайте или другом традиционном интернет-сервисе.
Некоторые из недавних продолжительных простоев в EvE Online были связаны с установкой нового оборудования, например, более быстрого SAN. Хотя технически можно переместить большую часть данных, создав новую файловую группу на новом диске, а затем опустошив основную, это привело бы к длительному снижению производительности из-за постоянного ввода-вывода. Поэтому они выбрал чтобы отсоединить базу данных объемом 1,1 ТБ и переместить ее за один раз.
Ответ на этот вопрос также зависит от конкретного приложения. Например, сервер, обслуживающий определенную звездную систему, не может подвергаться горячей замене без нарушения игрового процесса, поэтому время простоя используется для переназначения более мощных серверов в потенциальные точки доступа. Кроме того, рассчитываются расчеты владения (суверенитета) звездных систем. Это зависит от десятков различных переменных, каждая из которых может меняться в зависимости от действий игрока. Излишне говорить, что выполнение этого живого может вызвать чрезмерную блокировку и / или другие проблемы с параллелизмом. Но решать их лучше всего переполнение стека.
по-видимому, то, с чем вы не могли справиться с помощью кластеризации / балансировки нагрузки, например, основные изменения схемы БД.
В недавней теме Как часто мне следует перезагружать серверы linux Был упомянут еще один хороший момент, подтверждающий, что все запускается правильно при перезагрузке или после любого (основного) изменения конфигурации.
Простое обновление оборудования (или замена оборудования) в играх MMORPG также называется «обслуживанием сервера». Настолько банально, что мы часто об этом забываем.
Я реализовал архитектуру MMO в Erlang, которая поддерживает обновление и распространение горячего кода. Например, один «GamePlay Server» может работать на произвольном количестве машин, если требуется обновление оборудования, его объекты могут быть перенесены (в реальном времени) на другие машины. Это позволяет обновлять программное обеспечение без простоев.
Вы можете проверить мой сайт по адресу http://www.next-gen.cc.
Я убежден, что окно обслуживания также позволяет выполнять плановую замену оборудования, чтобы компоненты не выходили из строя.