Один большой сервер или кластер малых — что выбрать

MAATRIX GAMES

Комьюнити выросло, один сервер уже не тянет весь онлайн, и встаёт развилка: докупить ресурсов текущей машине или разбить проект на несколько серверов поменьше. Вопрос не праздный — от него зависит, сколько времени вы будете тратить на администрирование через полгода, и как быстро игроки простят вам первый серьёзный краш. Разберём оба варианта на практике, без религии "кластер — это всегда правильно".

Что вообще значит "кластер" в игровых серверах

Кластер — это не один сервер с бОльшим количеством ядер, а несколько независимых процессов (часто на разных машинах или VPS), которые либо связаны логически, либо объединены прокси-слоем. У разных игр это устроено по-разному, и путать эти схемы — источник половины проблем при масштабировании.

В ARK: Survival и ARK: Survival Ascended кластер — это несколько отдельных карт (например, The Island, Scorched Earth, Aberration), между которыми игроки телепортируются через обелиски или сталкиваются с крипичным меню перехода. У каждой карты свой процесс сервера, свой конфиг, но общий ClusterID и общая директория ClusterDirOverride, через которую передаются инвентари и дино при переходе между картами.

В Minecraft кластер — это набор отдельных серверов (лобби, выживание, мини-игры, крип), объединённых прокси — BungeeCord или Velocity. Игрок физически переключается между JVM-процессами, а прокси делает это прозрачным, включая единый вход по нику и общий чат при желании. Подробно про настройку такой связки — в статье про BungeeCord и Velocity.

В шутерах и раннерах (Rust, CS2, Squad) под "кластером" чаще понимают банально несколько независимых серверов с разными настройками (вайп-расписание, режим, карта) — без единого логина, просто разные точки входа в комьюнити.

Один большой сервер: когда это правильный выбор

Один мощный сервер — это меньше движущихся частей. Один процесс, один конфиг, один лог, один человек, который его администрирует по вечерам после работы. Это по-прежнему разумный дефолт для большинства сообществ до определённого размера.

Плюсы одного сервера:

• Простота. Один server.cfg, один список банов, один набор модов/плагинов, который нужно поддерживать в актуальном состоянии.
• Единая экономика и репутация игрока. Не нужно синхронизировать инвентари, деньги, права между инстансами — всё живёт в одном мире.
• Меньше точек отказа с точки зрения инфраструктуры. Не приходится следить за прокси-слоем, который тоже может упасть и уронить доступ ко всем мирам разом.
• Дешевле на старте. Аренда одного сервера под пиковый онлайн почти всегда дешевле, чем аренда нескольких серверов с запасом на каждый.

Минусы становятся заметны по мере роста:

• Один краш роняет всех. Если движок игры упал (а Minecraft на модах, ARK и Rust падают не так уж редко) — весь онлайн сидит в дисконнекте одновременно, а не только часть игроков на одной карте.
• Апгрейд — это простой. Чтобы добавить RAM или ядра, обычно нужен рестарт, а иногда — миграция на тариф с другими характеристиками, и на время переноса сервер недоступен целиком.
• Тикрейт и TPS падают для всех разом. Один переполненный чанк или зона с боями снижает производительность у всех игроков на карте, даже тех, кто в другом её углу.

Если у вас стабильные 20–60 игроков онлайн и один режим игры (например, ванильный PvE-выживач) — почти наверняка один сервер под правильным тарифом всё ещё лучший вариант. Как прикинуть, сколько RAM реально нужно под текущий онлайн, разобрано в статье про расчёт памяти для игрового сервера.

Кластер: что он реально даёт

Главная причина переходить на кластер — не "круто иметь несколько серверов", а конкретные технические и продуктовые выгоды, которые нельзя получить на одном процессе.

Изоляция крашей

Это самый весомый аргумент. Если один процесс ARK на карте Aberration крашится из-за бага с рендером пещер — остальные карты кластера продолжают работать, и только часть игроков теряет соединение. В Minecraft-кластере с BungeeCord падение сервера мини-игр не затрагивает выживание — прокси просто не даёт зайти на упавший бэкенд, остальные держатся.

Тематическое разделение миров и режимов

Кластер отлично подходит, когда вы хотите предложить игрокам разный опыт под одним брендом сообщества:

• ARK-кластер: The Island (базовый старт) + Ragnarok (открытый мир) + Genesis (эндгейм-контент) — со сквозным переносом дино и инвентаря.
• Minecraft-сеть: лобби + выживание с экономикой + отдельный крип-режим + сезонный ивент-сервер — каждый на своей версии и с нужным набором плагинов, без конфликтов.
• Rust: классический вайп-сервер 2x + отдельный "трёхдневный" быстрый вайп для тех, кто хочет динамику — разная аудитория, разные правила, общий Discord.

Гибкость под нагрузку конкретной зоны

Карту с боями за ресурсы можно разместить на сервере с бОльшим числом ядер, а спокойную стартовую локацию — на более скромном тарифе. Это тоньше настраивается, чем один универсальный сервер под средний сценарий.

Административная цена кластера

Здесь честность важнее маркетинга: кластер — это реально больше работы, и это нужно закладывать заранее, а не узнавать через месяц.

• N конфигов вместо одного. Каждая карта/сервер требует своих настроек баланса, лимитов, списка модов — и рассинхрон между ними (забыли обновить один плагин на одном из серверов) — частая причина багов, которые трудно поймать.
• Общая идентификация игрока. В Minecraft это решает прокси (Bungee/Velocity) через единый логин, но нужна ещё синхронизация прав между бэкендами — обычно через LuckPerms с общей базой MySQL, а не через локальные файлы на каждом сервере.
• Синхронизация данных между картами. В ARK перенос инвентаря и дино между картами кластера завязан на общую директорию ClusterDirOverride — если она недоступна одному из серверов кластера (например, находится на другой машине без общего диска), перенос просто не сработает.
• Мониторинг вырастает кратно. Вместо одного лога и одного процесса, за которым нужно следить, — N процессов, каждый со своими крашами, зависаниями по памяти и рестартами по расписанию.
• Стоимость. Каждый сервер в кластере обычно арендуется отдельно (или как отдельный слот на мощной машине), и совокупная цена почти всегда выше одного сервера с эквивалентной суммарной мощностью — вы платите за изоляцию, и это осознанный компромисс, а не бесплатный бонус.

ARK-кластер: минимальная рабочая схема

Если решили делать ARK-кластер, вот база, с которой стоит начинать (детали настройки конкретных карт и параметры путей отличаются между Survival и Survival Ascended, сверяйтесь с актуальной документацией сборки при развёртывании):

# Общие флаги запуска для каждой карты кластера
-ClusterId=mycommunity
-ClusterDirOverride="/home/gameserver/ark-cluster-data"
-NoTransferFromFiltering=false

Все карты кластера должны указывать на одну и ту же директорию ClusterDirOverride — это ключевое условие переноса дино и инвентаря между картами. Если карты живут на разных серверах, директория должна быть доступна обоим (общее сетевое хранилище или синхронизация) — иначе перенос между картами тихо перестанет работать, и разбираться с этим придётся уже когда игроки пожалуются, что дино "потерялся" при телепорте. Частые проблемы именно с кластерами ARK и их диагностика разобраны в статье про баги кластеров ARK; а с нуля поднять первую карту поможет гайд по запуску ARK: Survival.

Minecraft-кластер: прокси-слой в двух словах

Для Minecraft разница между Bungee и Velocity важна на старте: BungeeCord — старый, но всё ещё широко используемый прокси с большой базой плагинов; Velocity — современнее, быстрее и активнее поддерживается, но часть старых Bungee-плагинов с ним не совместима без прослойки (например, через Geyser+Floodgate для кросс-платформы это тоже нужно проверять отдельно). Минимальная схема сети:

config.yml (BungeeCord) — фрагмент
servers:
  lobby:
    address: localhost:25566
    restricted: false
  survival:
    address: localhost:25567
    restricted: false
listeners:
  - query_port: 25577
    motd: '&aMyCommunity Network'
    priorities:
    - lobby

Каждый бэкенд-сервер слушает свой локальный порт, игроки подключаются только к прокси на публичном 25565. Права между серверами синхронизируются через LuckPerms с общей MySQL-базой, а не локальными YAML-файлами — иначе бан или выдача ранга на одном сервере не подхватится на другом. Подробный разбор настройки самой связки — в статье про BungeeCord и Velocity для Minecraft.

Таблица: что выбрать по сценарию

Промежуточный вариант: вертикальный апгрейд перед кластером

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

Если тариф под текущий сервер уже упирается в потолок — сначала проверьте, действительно ли дело в нехватке ресурсов, а не в конфигурации: методика расчёта RAM под конкретную игру и онлайн разобрана в статье про расчёт памяти.

Частые вопросы