Eve online перерыв во сколько
Обновлено: 02.07.2024
Эта статья написана в соавторстве с CCP Masterplan.
В этой статье мы расскажем, что происходило «за кулисами» 15 июля 2015 года, в момент самого длинного за последние годы периода отключения сервера EVE Online. Мы делимся с вами этой информацией, потому что знаем, что среди игроков есть много людей, занятых в сфере IT: им могут быть интересны истории из практики. Кроме того, в тексте есть детали о том, как работает уникальный игровой кластер. Если вам это интересно, то подробности о том, что же произошло 15 июля, ниже. Если вы не хотите загружать голову лишними мелочами, ознакомьтесь с этим текстом, написанным вскоре после инцидента.
Предварительные данные
Игроки-ветераны несомненно помнят моменты, когда сервер отключался на дни, а не на часы. В последние годы мы в основном избавились от столь длительных задержек. 15 июля сервер был недоступен для игроков в течение 699 минут, чуть дольше, чем 2 и 3 июня 2013 года, незадолго до выхода «Одиссеи» (что, в свою очередь, потребовало отключить сервер на 342 минуты в силу необходимости выполнить скрипты, обеспечивающие «тирцид», корректировку иерархии кораблей). Ещё раньше, в 2011, при выпуске «Инкарны», сервер отключался на 963 минуты; впрочем, после «Инкарны» выпуски полугодичных обновлений больше не требовали чрезмерно длительных перезагрузок. Сейчас, если речь идёт об автоматической перезагрузке без добавления кода, мы можем быть уверены, что перезагрузка займёт 7 минут; если мы загружаем код, то с запасом укладываемся в отведённые нам полчаса.
Запуск
Кластер «Транквилити» состоит из примерно 250 узловых серверов. Чтобы кластер включился, узлам необходимо выполнить согласованную последовательность действий. Каждый узел должен получить свой ID, создать соединение с каждым из прочих узлов, получить список планетных систем, размещённых на нём, и данные, необходимые для выполнения задачи (например, на узле может размещаться торговая система сектора, ряд корпораций или альянсов, или процесс освоения навыков для некоторой подгруппы пилотов).
При запуске кластер проходит несколько этапов. Кластер не перейдёт на следующий этап, пока все узлы не сообщат, что закончили все процедуры текущего этапа. Отсчёт начинается с -4 и ведётся до 0. Как только все узлы сообщат, что провели этап 0, кластер готов к старту. Управление этим процессом осуществляется с помощью центрального узла, называемого «Полярис». «Полярис» отвечает за проверку этапа, на котором находится каждый узел, и рассылает инструкции о переходе на новый этап по мере выполнения необходимых условий.
-4: Узел запустился, установлена связь с базой данных
-3: Узел установил сетевые соединения со всеми прочими узлами
-2: Подготовлен кэш адресов. По сути, это таблица маршрутизации, позволяющая каждому узлу узнать о назначениях соседних
-1: Все пусковые сервисы закончили инициализацию, началась предзагрузка данных (торговые системы, планетные системы, и так далее)
0: Узел сообщает кластеру, что готов к работе, все пусковые данные загружены, службы готовы принимать запросы
Инцидент
Когда мы отключили сервер 15 июля, чтобы установить первый дополнительный патч для «Эгиды-суверенитета», проблем не ожидалось: тест-серверы, на которых этот код уже был загружен, запустились обычным образом и вели себя нормально. Мы полагали, что этот запуск пройдёт как обычно, в течение 15-20 минут. Первый звонок прозвучал, когда загрузка кода на сервер продлилась чрезвычайно долго, а утилита загрузки выдала неисправимую ошибку и ушла в перезагрузку незадолго до 11:30. В этот момент мы сообщили о задержке при запуске, но не ожидали ничего необычного: иногда в утилитах случаются сбои, бывают просрочки по времени. Мы загрузили код вновь, на этот раз успешно. Запуск сервера начался в 11:42. В 11:46 12 узлов из примерно 250 сообщали, что они зависли (что не позволяло запуститься серверу). Не страшась, мы воспользовались древнейшим IT-трюком: «выключи его и включи снова».
В этот раз запуск прошёл быстрее, но 41 узел по-прежнему оставался на этапе «-1». Мы решили открыть сервер в режиме VIP-доступа (зайти на него в этом режиме могут только учётные записи с особыми полномочиями разработчика) и полностью проработать загрузку кода, чтобы исключить блокировки, конфликты или человеческий фактор. В этот момент мы считали, что причиной проблем является окружение, поскольку тот же код работал на тест-сервере без каких-либо проблем.
К сожалению, две перезагрузки спустя мы ни на шаг не приблизились к решению вопроса. Пришло время вызвать кавалерию. Программисты присоединились к системным администраторам и начали исследовать вопрос со стороны кода; другие разработчики обсуждали возможный откат на предыдущий день, и его последствия. До сих пор откат не рассматривался как вариант, поскольку не было никаких признаков, что проблема в коде, но теперь у нас было время, пока программисты вели следствие, и мы решили, что испытаем его.
Программисты читали логи запуска, пытаясь понять, какие ошибки являются причиной сбоев, администраторы проверяли аппаратное обеспечение и операционные системы: несколькими днями ранее в инфраструктуру были внесены различные изменения. Поскольку «Полярис» был ключевым элементом в системе запуска, мы убрали из системы компьютер, на котором располагался «Полярис», и разместили этот ключевой узел на другом физическом носителе. Этим шагом мы попытались отфильтровать аппаратные и программные проблемы, специфичные для конкретного компьютера в кластере, но очередной запуск вновь был безуспешен. Прогон возможного отката оказался успешным, но мы не считали, что проблема в коде — мы были твёрдо уверены, что речь о внесённом нами патче, о данных или об окружении. Далее мы решили установить первоначальную версию игры для «Транквилити» на тест-сервер «Сингьюлэрити», поскольку на «Сингьюлэрити» были данные и службы DUST, а на «Мультиплисити» (нашем сервере для хотфиксов/обновлений) их не было.
Мы сочли, что этот сценарий маловероятен, но стоит проверки: конечно же, «Сингьюлэрити» успешно заработал. Утилиты наблюдения отметили, что процесс EVE Online пытается установить связь через внешнюю сетевую карту, IBM USB Remote NDIS Network Device, входящую в состав блейд-серверов IBM. Этот сетевой интерфейс предназначен для управления сервером через IMM (Integrated Management Module, интегрированный модуль управления) или AMM (Advanced Management Module, усовершествованный модуль управления). Через этот интерфейс сервером можно управлять на низком уровне. Например, обновлять прошивку с помощью ОС, или передавать данные на сервер. Интерфейс получил IP-адрес, самоподписанный Windows, не входящий в пространство адресов IPv4, и не связанный с нашей внутренней сетью центра данных. Процесс EVE Online не должен был работать с этим интерфейсом, но мы решили устранить эту возможность и отключили интерфейс. Говоря о «Транквилити», мы отключили интерфейс CREST, переименовали обновление, устанавливаемое на сервер, чтобы исключить сбои при перезаписи и всё, что только возможно, и попробовали вновь. В 14:21 завершился очередной запуск: 53 узла остановились на этапе «-1».
В течение часа, пока разработчики вели расследование, мы проверили ещё несколько маловероятных идей. В 15:29 один из разработчиков предложил выгрузить из базы новые записи о системе владения космосом, сохранив их во временных таблицах, и проверить, не являются ли эти данные причиной сбоя. С точки зрения игры наибольшая разница между запуском в среду по сравнению с запуском во вторник состояла в том, что во вторник все сооружения системы суверенитетов были в «нулевом» состоянии, не было никаких связанных с ними боевых действий и окон уязвимости. В ответ на эту идею CCP Lebowski и другие сотрудники отдела контроля качества запустили на «Сингьюлэрити» множество энтоз-событий и попытались тем самым вызвать ошибки или сбои запуска. Несмотря на двойную (по сравнению с «Транквилити») нагрузку «Сингьюлэрити» такими событиями, тест-сервер продолжал загружаться как обычно. В 15:48 мы прогнали скрипт на «Дуалити», убедились, что он работает как задумано, и запустили его на «Транквилити». Скрипт отработал, записи обнулились, и в 16:33 мы с тревогой смотрели на то, как идёт запуск.
Отлично! Теперь осталось понять, почему сброс данных об оборонном режиме и об окнах уязвимости привёл к успешному запуску сервера.
Открывать сервер в таком состоянии было нельзя — фактически мы свели к нулю целый день сражений за власть над «нулями». Мы продолжили исследование. К этому моменту в процессе участвовало 8 программистов, несколько системных администраторов и практически все сотрудники отдела контроля качества, пытавшиеся воспроизвести сбой на «Сингьюлэрити». В 17:10 мы внесли очередную правку: на «Транквилити» добавились данные об окнах уязвимости. Тогда следующий запуск помог бы нам определиться, что именно вызывает сбой: окна уязвимости, или сведения об оборонных режимах. Этот запуск тоже прошёл успешно: мы наконец-то поняли, что речь идёт именно об оборонных режимах. Разработчики начали копать в том же направлении. Затем мы вновь добавили в базу сведения о боевых действиях.
Появилась теория о том, что же приводит к появлению зависших узлов: при запуске узлы, отвечающие за работу планетных систем с идущими сражениями за суверенитет, должны связаться с узлами, отвечающими за соответствующие альянсы. В частности они должны узнать выбранную альянсом столицу. В соответствии с дизайном системы суверенитетов перенос в столицу вступает в силу через несколько дней. Однако в первые дни запуска мы намеревались облегчить альянсам обустройство в новых правилах игры, и добавили опцию, позволяющую временно сменить семидневную задержку на куда более краткую.
Итак, что же мы знали?
- Запуск без данных о боях прошёл успешно как на «Транквилити», так и на всех тест-серверах.
- Запуск с данными о трёх сотнях боёв за суверенитет не удался на «Транквилити», но был успешен на всех тест-серверах.
- Удаление кросс-ссылок на узлы, связанных со столицами альянсов, не помогло.
- Пришло время экспериментировать с загрузкой данных о боях за суверенитет, чтобы найти источник проблемы.
Мы отказались от загрузки данных о боях. Как следствие, запасные командные пункты не появлялись, но в целом сооружения системы суверенитетов загрузились ожидаемым образом. Это было не решение проблемы, но ещё один кусочек паззла, приблизивший нас к пониманию, что именно отграничивает успешный запуск от неуспешного. Этот вариант (хотфикс № 2) привёл к успешному запуску в 19:15, и был продолжен третьим экспериментом: что получится, если теперь мы загрузим данные о боях, но после небольшой задержки, чтобы всё прочее успешно загрузилось до того?
Мы попробовали вновь включить загрузку этих данных (отключенную во втором хотфиксе), но с задержкой и в асинхронном режиме по сравнению с прочим ходом запуска сервера. К этому моменту мы столкнулись с некоторыми другими проблемами: задержки синхронизации «Перфорса», некоторые проблемы с хранением данных, но с каждым хотфиксом мы были всё ближе и ближе.
. к пицце, с благодарностью встреченной нами в 19:48 во время установки третьего хотфикса.
Третий хотфикс вновь уронил «Транквилити», что было особенно интересно. В этом случае мы загружали данные о боях независимо от прочих задач, осуществляемых при запуске, и тем не менее они каким-то образом роняли узлы кластера.
С новыми силами, приданными нам полным столом пиццы, мы вернулись к второму хотфиксу, чтобы продолжить эксперименты с помощью консоли на живом пациенте.
Как только все узлы запустились, и мы подтвердили, что планетные системы успешно загружены, мы открыли окно консоли на сервере и начали отдавать команды и наблюдать результаты в реальном времени. Мы провели несколько проверок и убедились, что ни на одном из узлов нет данных о боях. Как и ожидалось, они ответили, что данных о боях действительно нет. Мы потребовали от всех нод получить соответствующие данные о боях. Сразу после этого кластер начал «тормозить». Через несколько минут несколько узлов прекратило работу и покинуло кластер. По мере этого планетные системы на мёртвых узлах переносились на оставшиеся в живых. Теперь у нас было около 200 узлов из 250. Мы скомандовали кластеру повторно получить данные о боях. Ожидалось, что каждый узел сообщит об известном ему пакете этих данных, и ответит, что получение не требуется (так как данные есть в памяти). На самом деле кластер вновь перестал отвечать в течение нескольких минут, а когда всё успокоилось, умерло ещё несколько узлов. Это было очень странно: ожидалось, что узлы просто запишут в логи определённые данные, поскольку получать им нечего. Тогда мы подумали: может быть, речь не о самих данных о боях, а о связанных с ними записях в логи? Теперь кластер был в не очень хорошем состоянии, мы вновь перезапустили его (оставаясь на втором хотфиксе) и продолжили испытания.
С помощью консоли мы отключили логирование функции загрузки сведений о боях за суверенитет. Затем повторили тот же тест: попросили все узлы загрузить те же сведения. Команда выполнилась почти мгновенно, кластер остался работоспособным. Что за. Дальнейшие проверки подтвердили, что все сведения о боях за суверенитет действительно загрузились. Мы повторили этот эксперимент (с отключенным логированием). Он завершился мгновенно, сообщив, что загрузка данных о боях не требуется.
И наконец мы включили логирование процесса и выдали очередную команду загрузки данных о боях. Кластер вновь начал «тормозить», а узлы — «выпадать» из системы. Похоже, мы нашли виновника, хоть и не знали, почему он совершал преступление, и что было его орудием. По каким-то причинам канал логирования, используемой системой ведения боёв за суверенитет на «Транквилити», снижал производительность узлов до такой степени, что они отключались от кластера.
Примечание: речь идёт о логах, которые разработчики используют для испытания нововведений и исследования проблем. Они не относятся к логам, с которыми работают гейм-мастера, обрабатывая запросы пилотов, или к логам их кошельков.
В 21:48 мы выпустили пятый хотфикс, предположительно решавший проблему. Мы удалили логирование системы ведения боёв за суверенитет, но в остальном практически не трогали код. Успех этого варианта означал бы, что мы почти готовы открывать «Транквилити». Он был выпущен на «Транквилити» в 22:07. В 22:22 сервер был запущен, и мы начали проверки в режиме VIP, чтобы убедиться, что эксперименты не повредили данные о суверенитете. Мы нашли одну проблему с боем-двойником, но легко устранили её. Интерфейс CREST был включен в 22:38, «Транквилити» вышел из VIP-режима и открылся для всех игроков в 22:41.
Послесловие: 20 июля, понедельник
Идя по следу падающих кластеров, нам надо было выяснить, почему один конкретный канал логирования (используемый для боёв за суверенитет) на одном конкретном сервере («Транквилити») приводит к чрезвычайным проблемам со стабильностью сервера. Мы запланировали определённое время VIP-режима на «Транквилити», в течение которого могли бы продолжить эксперименты. Требовалось найти наиболее простой код, который привёл бы к воспроизведению симптомов, что помогло бы в дальнейших исследованиях. Мы вошли в консоль на одной из нод «Транквилити»: отсюда можно было тыкать сервер палочкой и смотреть, что сломается. (До этого мы пробовали повторить ситуацию на «Сингьюлэрити» и «Дуалити»; испытания не привели к ошибкам).
Мы подготовили набор действий, которые следовало провести. Каждый следующий шаг последовательно добавлял факторы, пока проблему не удастся воспроизвести. Как выяснилось, далеко копать не пришлось. Вот как это было:
У нас было два канала логирования: обычный канал, и особый канал, который использовался в системе отслеживания боёв за суверенитет. Мы убедились, что оба канала работают, выполнив на одном узле следующий код:
С помощью Splunk мы в реальном времени наблюдали за логами. Да, каждая строка появилась один раз.
Дальше шаг 1а был повторён на 250 узлах параллельно. Splunk отобразил 250 строк. Потом мы повторили шаг 1b, и результат был тот же: каждый узел записывает одну строку, все строки проходят через канал суверенитета.
Пока всё в порядке. Теперь давайте запишем чуть больше данных, но ничего такого, что приведёт к проблемам, так? Так? Гмм.
Для тех, кто не знаком с Python, вторая строка будет исполнена в цикле 500 раз, и каждый раз выдаст предупреждение через обычный канал. Пятая строка делает то же самое, но через канал суверенитета.
Сначала мы провели шаг 2а на всех узлах параллельно. Команда выполнилась мгновенно; на графике Splunk возник пик в 125 000 строк (250*500). Нагрузка не так велика, как может показаться: вполне приемлемые значения для системы, особенно в точечных пиках, наподобие нашего. Потом мы провели шаг 2b. Случилось кое-что любопытное. Splunk показал нам корректное число строк в логе (наши логи что-то показывают!), но команда выполнилась не так быстро, как в шаге 2а. На самом деле консоль начала реагировать на нас лишь через несколько минут, и полученные данные свидетельствовали, что несколько узлов не ответили. Статус кластера сообщил нам, что эти узлы отключены. Каким-то непонятным образом невинная строка логов смогла привести к отключению узлов из кластера по тайм-ауту.
Легче, чем мы думали! Чтобы воспроизвести мёртвый кластер, даже не понадобилось работать с базой данных или со сведениями о боях. Когда оказывается, что простое логирование данных может выключить работающий сервер, у разработчика определённо есть проблемы. Примерно такие же, как были у нас в среду, 15 июля. Определив проблему, мы перезапустили «Транквилити», и запустили на него игроков, отключив режим VIP.
Как было сказано ранее, такая реакция никогда не наблюдалась ни на одном тест-сервере. В работе «Транквилити» (или его конфигурации) есть нечто уникальное. Мы продолжаем искать причины, объясняющие, почему логирование системы приводит к таким сбоям именно и только на «Транквилити» и именно и только на определённых каналах логирования. Мы знаем, что «Транквилити» несомненно отличается от прочих серверов по масштабу, но пока что наши эксперименты говорят нам, что ответ не сводится к количеству узлов.
Загадка ещё не решена.
Ежедневная перезагрузка (DownTime, DT)
EVE Online DownTime или же ежедневная перезагрузка сервера, если говорить на русском языке является ежедневным событием, которое позволяет игрокам отдохнуть и гарантированно отвлечься от игрового процесса. Эта перезагрузка также необходима для обновления данных, в первую очередь - астероидных поясов и NPC-пиратов.
Обычно, ежедневная перезагрузка сервера EVE Online начинается в 11:00 по времени сервера EVE Online (GMT) и может длиться до получаса (обычно она длится 10-15 минут). Однако в случае установки обновления это время может быть увеличено, но CCP Games всегда предупреждают о подобных событиях заранее.
EVE Online предлагает своим игрокам уникальный игровой опыт, предлагая массу интересных инструментов для взаимодействия между игроками. Зарегистрируйтесь в EVE Online и оцените ее масштабы сами. Благодаря игрокам рождаются ни на что не похожие истории о власти и богатстве, успехах и поражениях. Именно за это игроки и любят эту вселенную.
Сервер EVE Online работает по нулевому часовому поясу согласно всемирному координированному времени - UTC+0. Соответственно, время ежедневной перезагрузки сервера EVE Online для популярных городов русскоязычного пространства будет следующим:
Отслеживать текущее состояние сервера можно как с помощью лаунчера игры, так и на официальном сайте EVE Online. Наш сайт также предоставляет информацию о статусе сервера в режиме реального времени.
Eve online перерыв во сколько
«Каждый день я дожидаюсь перезагрузки сервера и фиксирую результаты».
Последний раз, когда я это писал (кстати, вы читали мою предыдущую запись? Она очень интересная!), автоматическая перезагрузка сервера Tranquility по выходным занимала примерно 4 минуты и 20–40 секунд: этой паузы как раз хватило бы на то, чтобы наскоро выпить чашечку чая. Сегодня же, полтора года спустя, время перезагрузки сократилось до 3 минут и 34 секунд: теперь, чтобы выпить чаю, придётся немного ускориться (я замерил специально для этой записи). Учитывая все технические улучшения, внедрённые с 2019 года, отключение сервера на 3 минуты и 30–40 секунд — вполне ожидаемая цифра.
Я мог бы взять эту разницу в 50–60 секунд, то есть в 22,5%, между декабрём 2019 года и июлем 2021 года и с помощью этого потрясающего научного графика рассчитать,
как долго будет длиться перезагрузка сервера 19 декабря 2026 года. Однако всё несколько сложнее, чем кажется. Итак, у нас есть нижняя граница в условные 3 минуты, в течение которых происходят три разных процесса: выключение, работа с базой данных и запуск. Каждый из них длится примерно минуту, если, конечно, мы не вносим серьёзные изменения, самым важным из которых стало бы отсутствие самой необходимости в перезагрузке. На самом деле даже при лучшем раскладе перезагрузка будет длиться чуть менее 160–200 секунд. Наша цель — не сократить время перезагрузки сервера, а проводить её всё реже и реже, а затем и вовсе её исключить. Тем не менее я решил начать эту статью с конкретного примера, который показывает наши успехи в снижении времени перезагрузки. Новый эксперимент для оценки работы сервера без его автоматического отключения запланирован на 9 сентября.
На этот раз мы преследуем четыре основные цели:
- проверить, насколько хорошо мы исправили ошибки, обнаруженные в ходе первого эксперимента;
- убедиться, что с предыдущего раза ни один код или функция не «поломались», а также выявить иные проблемы;
- оценить объёмы потребления памяти;
- удостовериться, что наша техническая платформа (мы расскажем о ней позднее) не «привязывает» функционал игры к перезагрузке сервера.
Думаю, вам не терпится узнать, что же мы обнаружили в прошлый раз.
В первую очередь мы заметили, что перезапуск сервера — важное событие, знаменующее начало ежедневного цикла. Без него мы столкнулись с рядом проблем: к примеру, сбивались 24-часовые таймеры сооружений, а корпорации не могли присоединиться к межгосударственным войнам. Мы исправили все ошибки, найденные нами и пользователями. Теперь мы собираемся проверить всё ещё раз (мы уже проводили тестирование, но не в масштабах Tranquility), а заодно поискать и другие сходные проблемы.
Кроме того, тогда мы столкнулись с рассинхронизацией времени (исправлено) и излишним потреблением памяти (исправлено частично).
Мы знали, что столкнёмся с рассинхронизацией времени, так что хотели посмотреть, заметят ли её игроки к окончанию второго дня. Желательно, чтобы расхождение во времени составляло приблизительно полсекунды, однако в 2019 году даже на самых мощных компьютерах мы наблюдали рассинхронизацию в 2,25 секунды в конце цикла
и — предсказуемо — в 4,5 секунды к завершению второго дня. Игроки начали замечать расхождение во времени, когда оно превышало 3 секунды. Прежде всего, это выражалось в задержке или сбоях функционирования модулей, когда клиент игры и серверный узел, обслуживающий звёздную систему, не могли синхронизировать цикл работы бортового оборудования. Сейчас расхождение во времени составляет примерно 0,01 секунды — ниже условного максимума в полсекунды.
Известно, что сервер Tranquility задействует много памяти устройства. Поэтому для повышения производительности мы всегда выбирали предварительное вычисление значений и обработку данных с последующим сохранением результатов для дальнейшего использования, а не регулярный перерасчёт этих значений. Например, проекты «Мозги в банке» и «Изменение догматов», которые мы запускали в 2015 году, были посвящены вычислению и хранению навыков и их эффектов (образно выражаясь, «мозгов» персонажей) и передаче результатов этих подсчётов между звёздными системами. Таким образом, отпадала необходимость повторных вычислений при посещении каждой новой системы. Кроме того, мы никогда не проводим чистку памяти, поскольку память узлов и так ежедневно сбрасывается при перезагрузке сервера (примечание: конечно, мы не очищаем кэш-память Redis или нашей базы данных, однако основная кэш-память игры также сбрасывается при перезапуске).
Самые «загруженные» узлы отвечают за звёздное скопление Tranquility. Так, узлы обслуживания персонажей, хранящие, кроме всего прочего, те самые «мозги», которые я упоминал выше, в прошлый раз использовали 75% памяти к концу второго дня, что немногим ниже максимально допустимого значения в 80%. Принимая во внимание данные 2019 года, мы могли бы обеспечить бесперебойную работу скопления Tranquility в течение 3 дней и, возможно, ещё 7 часов, пока «загруженность» одного из узлов не дошла бы до 100%. В 2019 году потребление памяти составило 55% в первый день, однако сегодня это значение упало до 35%, так что мы хотим продолжить наблюдения и пересмотреть предыдущие выводы.
Отказ от перезапуска сервера — наша конечная цель, и мы постепенно движемся к ней, улучшая техническую сторону игры. Так, мы уже несколько лет работаем над технической платформой, поддерживающей микросервисы и сервисные шины, и уже начали использовать её для некоторых задач. Сейчас мы планируем оценить, как эта экосистема работает в главном звёздном скоплении без перезагрузки сервера, и убедиться, что ни одна функция не зависит от этой ежедневной процедуры.
Приглашаем вас на второй эксперимент «Неотключаемый сервер», который начнётся 9 сентября. И да, как и в прошлый раз, скоро вас ждёт новое видео. Мы объединили все свои силы в этом героическом рывке.
- EVE Ingame: Offslash
- Corp: BROD
- Ally: Desman Alliance
- Channel: EVE-wave
- Client: Eng
Да стандартный ДТ и так частенько меньше 30 минут идёт, так что насчёт смерти это громко сказано
Clone Grade Eta
- EVE Ingame: Takeshi Ryuu
- Corp: IRR
- Client: Eng
Позвольте представиться - я CCP Hunter, Database Administrator отдела Virtual World Operations. VWO отвечает за ежедневную работу Tranquility и всё, что с этим связано - базы данных и бесконечные игровые, тестовые и веб сервера.
С момента запуска Евы в мае 2003 официальная продолжительность дт была равна 60 минутам, с 11:00 по 12:00 UTC.
Однако последние пару лет мы активно работали над уменьшением этого времени. В действительности типичный дт последнее время длится 20-30 минут, хотя официальная продолжительность оставалась прежней *барабанная дробь* до сих пор.
Начиная с 1 ноября официальная продолжительность ежедневного дт будет составлять 30 минут, с 11:00 до 11:30 UTC.
Зачем нужно дт?
Tranquility является одной из крупнейших одно-шардовых ММО игр, существующих в настоящее время. Размер базы данных, с которой работает Tranquility, составляет 1.5 терабайт, и мы выполняем ежедневное обслуживание/очистку бд во время дт. Большая часть этих операций является внутренним делом базы данных и происходит незаметно для пользователей, но все эти операции нужны для поддержания базы данных в хорошем состоянии.
Кроме чистки базы данных во время дт так же выполняются некоторые другие операции, например посев новых астероидов, постройка аутпостов, обновление нпц стендов и тому подобное.
Всё это занимает продолжительное время, но мы предпринимали определённые шаги, чтобы уменьшить его, в итоге последнее время большую часть дт занимает выключение и включение кластера обратно.
Что было сделано для уменьшения дт?
Код старых подсистем Евы разрабатывался с расчетом на ежедневное дт, но последние несколько лет новый код пишется таким образом, чтобы не зависеть от наличия дт, а старый код переписывается, чтобы убрать эту зависимость. Можно сказать, что мы до сих пор расплачиваемся за старые грешки.
Кроме того мы работали над процедурами выключения и включения кластера, чтобы они занимали меньше времени.
Что день грядущий нам готовит? Когда исчезнет даунтайм?
Пока что мы не можем обойтись без дт, но его продолжительность уже существенно уменьшилась и продолжает уменьшаться. Фактическое время, требуемое для типичного дт - чуть менее 12 минут. Остальное время используется как буфер для развертывания хотфиксов, патчей и небольшого обслуживания кластера, когда оно требуется.
Мы продолжим работу над уменьшением ежедневного дт до тех пор, пока не добьемся конечной цели - отсутствия дт. А я оставляю вас вместе с несколькими графиками, на которых показана дорога к Еве без дт.
Отдельное спасибо CCP Atlas за помощь в подготовке графиков и текста.
С наилучшими пожеланиями,
CCP Hunter.
Database Administrator
Clone Grade Eta
- EVE Ingame: Takeshi Ryuu
- Corp: IRR
- Client: Eng
Дежурный по зоопарку
- EVE Ingame: Rainbow Hunter
- DUST Ingame: test
- Corp: OMNYX
- Client: Eng
Травля. RMT. Разведение троллей. Пособничество игровой коррупции.
Clone Grade Theta
- EVE Ingame: dp wiz
- Corp: NPC
- Channel: stoned
- Client: Eng
Для начала, позвольте мне представиться. Я CCP Hunter, администратор БД в отделе обслуживания Виртуальных Миров. Мы отвечаем за ежедневную работу Tranquility и всего, что к нему относится: базы данных, бесконечные ряды рабочих, тестовых и веб серверов.
С момента запуска EVE Online в мае 2003, официальный распорядок ДТ составлял 60 минут: с 11:00 по 12:00 по гринвичу.
Однако, два прошедших года мы активно работали над уменьшением этого времени. В действительности типичный ДТ длится 20-30 минут в сутки, хотя официальная продолжительность оставалась прежней *барабанная дробь* до сего момента.
В дополнение к зачисткам бд, некоторые важные операции также выполняются во время дт. Например появление астероидов, строительство аутпостов, обновление NPC станцый. Наконец, во время ДТ, обновляется балансировщик нагрузки и выделяются ресурсы для крупных замесов (не забывайте использовать систему уведомлений о предстоящих операциях, если хотите поблобиться).
Эти операции могут занять длительное время, но мы предпринимаем шаги чтобы его уменьшить. Сегодня большая часть ДТ расходуется на выключение и перезапуск кластера.
Что было сделано для уменьшения ДТ?
Раньше системы в EVE Online проектировались с учётом того факта, что днём будет ДТ. В последние годы больше не создавался код, который зависел от ДТ и была проведена огромная работа по устранению старых участков, которые от него зависели. Можно сказать, что мы сейчас расплачиваемся за старые грехи.
В дополнение к этому, мы переработали процедуры остановки и запуска кластера и теперь он делает всё быстрее.
Что готовит нам будущее, когда мы избавимся от ежедневных ДТ?
Мы продолжим наши усилия по уменьшению ежедневного ДТ до тех пор, пока мы не достигнем окончательной цели - окончательного избавления от ДТ. Оставляю вам эти графики чтобы показать, как это будет происходить.
Спасибо CCP Atlas за помощь с графиком и текстом.
С наилучишими пожеланиями,
CCP Hunter.
Администратор БД
Читайте также: