Обслуговування сервера MMORPG

Здається, що більшість ігор mmorpg мають регулярне обслуговування сервера, деякі щодня, деякі раз на тиждень. Що вони насправді мають робити, і чому це потрібно?

Якщо ви починаєте з такого проекту, що ви можете зробити, щоб цього уникнути?

Я підозрюю, що вони розгортають останню версію свого коду, що вимагає перезапустити програму (і, сподіваємось, виконати деякі тести, перш ніж повторно ввімкнути доступ). З цієї точки зору, це більше проблема StackOverflow, а менша - сервер ServerFault.

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

• Сервер для входу - обробляє автентифікацію і виступає "хабом" між ігровими серверами. Як тільки клієнт перебуває в грі, він більше не взаємодіє з сервером входу. У такій системі ви можете застосувати виправлення та перезапустити сервер входу, не втручаючись у геймплей (хоча у вас буде період часу, коли люди не зможуть увійти).

• Сервери ігрових процесів - Кластери машин, згруповані в логічні незалежні одиниці ("світи" тощо). Передбачається, що кожен ігровий кластер використовує певний протокол внутрішньої комунікації, щоб відповідати стану один одному; вам, мабуть, доведеться виправити кожен кластер відразу. Один з можливих способів зробити це - наклеїти тепло-відмову. Тоді вам потрібно мати можливість обох

  1. Подайте сигнал клієнту, щоб він підключився до теплового відключення та відключився від старого кластера.
  2. Тримайте стан, синхронізований між відмовою та застарілим сервером додатків, поки всі клієнти переносять.

• Сервери баз даних - Якийсь стійкий сховище даних, як RDBMS. Сподіваємось, ви не часто вносите зміни в сховище даних. Імовірно, кожен геймплейний сервер / кластер має незалежний сховище даних. Можливо, вам вдасться використати той самий трюк з теплою відмовою (і сказати серверам ігрових процесів відключитися, дочекатися синхронізації старих та аварійних баз даних, а потім знову підключитися до відмови), але це здається мені досить ризикованим.

Усі вищезазначені випадки додають неймовірної кількості складності до вже складної системи та вводять купу місць, де збій коду може призвести до втрати даних або пошкодження.

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

Ніхто ще не має досвіду насправді керувати подібним? Ага.

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

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

У мене найбільше досвіду роботи з EVE (я більше лазерний хлопець, ніж хлопець бойових осей), тому деякі з цих прикладів більш орієнтовані на EVE.

Що стосується системних причин:

• Фізичні вузли виходять з ладу на постійній основі. Коли вузол виходить з ладу, зазвичай його діяльність переміщується в інше місце, використовуючи будь-яку кількість засобів. Однак вузол потрібно повернути в експлуатацію якомога швидше. У випадку EVE вони використовують як нестабільну мову обробки, так і віртуальні сервери; Я не впевнений, що таке архітектура Blizzard.
• Необхідно перевірити узгодженість баз даних, журнали потрібно очистити, а індекси та кеші даних потрібно відновити. Це особливо важливо в такій системі, як EVE, лише з одним "живим" екземпляром бази даних.
• Патчі операційної системи потрібно застосовувати в той момент, коли вони можуть перезавантажувати вузли, не маючи зайвої активності мігруючи в інше місце. Міграція займає багато мережевих ресурсів, які в іншому випадку можуть бути присвячені обробці в Інтернеті.
• ММО на основі RDBMS мають величезні проблеми з блокуванням даних та цілісністю референції. Час простою використовується для очищення застарілих замків та порушень цілісності з журналів активності.
• Більшість ігор реалізує географічно розміщені кеші даних для статичної або напівстатичної (див. Підсумкові дані кешування нижче) у зонах інтенсивного використання, тобто на східному узбережжі та на західному узбережжі США. Ці кеші оновлюються вручну під час простою.

Щодо програмних причин:

• Ігри під час роботи використовують багато OLTP - це On Line Transaction Processing - тип читання / запису в бази даних. Однак іноді ви хочете зробити підсумковий звіт ... наприклад, скільки конкретного звіра, якого ви вбили за останні 3 роки шліфування. Це найкраще вирішується у звіті OLAP - це On Line Analytical Processing - який містить підсумкову інформацію на основі безлічі рядків у гігантському наборі даних. Насправді ігри реалізують системи, які використовують OLAP для створення кешу, щоб обмежити кількість запитів, які потрібно прочитати, тобто вони будують загальну кількість на певну дату, і тоді, коли ви задаєте питання, вони просто читають рядки з магазину OLTP, який підсумовує період часу з певної дати. З’єднайте це двоє, і ви зможете фактично оцінити, наскільки вартим стало ваше життя.
• Вищезгадане гаряче виправлення, яке я розглядаю як проблему програмного забезпечення, але розробники програмного забезпечення розглядають як системну проблему. ;)
• Поповнення магазинів предметів - напередодні пояси астероїдів оновлюються щовечора, а певні комплекси також переробляються. Це можна зробити в тій чи іншій мірі в режимі он-лайн, але деякі алгоритми занадто складні і їх потрібно робити в режимі офлайн, оскільки вони коротко підводять базу даних до колін, а підсумовують економічну активність попереднього дня.

Управління економікою із закритими та відкритими петлями є однією проблемою для операторів MMO - якщо ви мені не вірите, прочитайте деякі наукові документи, написані про економіку ігор та деякі дослідження старих ігор, таких як Ultima Online, що мали відносно примітивні економіки. Аналіз, який повинен відбутися для поповнення відкритих циклів та виявлення обману та іншої негативної економічної діяльності, повинен відбуватися в автономному режимі з оглядом даних, який іноді можна зробити лише тоді, коли база даних повністю заблокована.

Якщо ви зауважите, обслуговування Еви відбувається, коли в Англії опівдні, де є основний центр обробки даних.

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

Хоча можливе швидше відновити резервні копії окремих серверів, це призвело б до незаконних вигуків фаворитизму щодо гравців, царини яких потрапляли раніше за графіком. Як такі, вони стримують все, поки не буде виконана вся робота; із сотнями царств, над якими вони можуть працювати, вони, ймовірно, виконують велику частину роботи паралельно, але все ж серіалізують остаточну перевірку перед тим, як повернути речі в Інтернет. Якщо ви робите апаратне оновлення, це, ймовірно, серіалізується у стільки ж центрів обробки даних, скільки у них є.

Щодо того, чому вони виконують технічне обслуговування, частина цього може бути просто перезавантаженням продуктивності. Хоча було б чудово, якби такі перезавантаження не були потрібні, вартість цього та вплив цього не можуть бути спрямовані на їх вибір тут.

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

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

Деякі з останніх тривалих простоїв у EvE Online стосувались встановлення нового обладнання, як-от швидший SAN. Хоча технічно можна переміщувати основну частину даних, створивши нову групу файлів на новому диску, а потім випорожнивши основний, це призвело б до тривалого періоду зниження продуктивності за рахунок постійного вводу-виводу. Тому вони вирішили вилучити базу даних 1,1 ТБ та перемістити її за один раз.

Відповідь на це питання також спирається на конкретну заяву. Наприклад, сервер, що управляє певною зірковою системою, не може бути замінений, не порушуючи гру, тому простої використовуються для переназначення більш потужних серверів на потенційні гарячі точки. Крім того, розраховуються розрахунки власності (суверенітет) зіркових систем. Це залежить від десятків різних змінних, які можуть змінюватися залежно від дій гравця. Зайве говорити, що жива робота може спричинити надмірну блокування та / або інші проблеми одночасності. Але звернення до них найкраще залишити в потоковому потоці .

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

В останній темі Як часто слід перезавантажувати Linux-сервери, згадувалося ще одне добре, перевіряючи, що все запускається належним чином при перезавантаженні або після будь-якої (основної) зміни конфігурації.

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

Я реалізував архітектуру MMO в Erlang, яка підтримує оновлення та розповсюдження гарячого коду. Наприклад, один "GamePlay Server" може працювати на довільній кількості машин, якщо потрібне оновлення обладнання, його об'єкти можна перенести (в режимі реального часу) на інші машини. Це дає змогу оновити програмне забезпечення без будь-яких простоїв.

Ви можете перевірити мій сайт за адресою http://www.next-gen.cc .

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