Задачи по расписанию, которые нужны каждому игровому серверу

Большинство серверов работает вообще без расписаний, а большинства проблем, о которых рассказывают люди, помогли бы избежать четыре из них: предупреждение, сохранение, backup и перезапуск, именно в таком порядке, каждую ночь, в час, когда никто не играет. Настройка занимает минут десять, и она разом снимает жалобы «после нескольких дней всё тормозит», «мы потеряли вечер построек» и «сервер упал без предупреждения».

Вкладка, которая всё это делает, принимает выражение cron и список упорядоченных задач с задержками между ними. Каждая задача - одно из трёх: команда консоли, backup или действие питания. Всё ниже - о том, какие задачи, в каком порядке, с каким промежутком, и точные команды для игр, где команда неочевидна.

Как строится расписание: cron, задачи и задержки#

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

0 5 * * *      05:00 every day15 4 * * *     04:15 every day0 */6 * * *    every six hours, on the hour*/15 * * * *   every fifteen minutes0 5 * * 1      05:00 on Mondays30 3 * * 0     03:30 on Sundays0 5 1 * *      05:00 on the first of the month

Две ловушки. Во-первых, */5 в поле минут означает «каждые пять минут», а голое 5 - «в пять минут каждого часа», один раз. Перепутав их, вы получите либо задание, которое, кажется, никогда не запускается, либо запускающееся 288 раз в сутки. Во-вторых, когда ограничены и день месяца, и день недели, cron запускает задание, когда совпадает любое из них, а не оба. 0 5 13 * 5 - это не «пятница, 13-е», а «13-е число каждого месяца и каждая пятница». Оставьте одно из них как *, если не имеете в виду именно это.

Часовой пояс важнее, чем кажется. Расписание идёт по часам панели, а не вашего ноутбука, поэтому проверьте, что показывает интерфейс, прежде чем считать, что 05:00 - это ваши 05:00. И не назначайте ничего на промежуток между 02:00 и 03:00: в поясе с переходом на летнее время задания в этом окне в одну ночь года выполняются дважды, а в другую ни разу. 04:00 и 05:00 безопасны. Синтаксис подробнее разобран в статье выражения cron простыми словами, включая сокращения, которые поддерживаются не везде, - пишите пять полей, и вас ничто не удивит.

Задержки - вторая половина. Расписание - это список задач по порядку, у каждой есть ожидание перед запуском. Именно оно превращает набор команд в безопасную последовательность, потому что сохранение, не закончившееся к началу backup, - как раз тот сбой, который backup должен был предотвратить.

Ночная последовательность по минутам#

Вот полная схема для сервера Minecraft как одного расписания на 0 4 * * *, где всю работу делают задержки.

Принцип прост: объявить, заморозить, скопировать, отпустить, перезапустить. Числа вы настраиваете сами - мир в 3 GB требует более долгой паузы между задачей backup и save-on, чем мир в 300 MB, - но порядок не меняется.

Две ошибки, которые стоит назвать. Backup в ту же минуту, что и перезапуск, даёт копию сервера, который выключается. А save-off без парного save-on позже оставляет сервер неспособным сохраняться до перезапуска, что нормально в этом расписании и катастрофично в том, которое перезапуском не заканчивается. Если сомневаетесь, вообще не используйте save-off: одного save-all flush уже намного лучше, чем ничего.

Четыре расписания, которые нужны большинству серверов#

Уберите всё лишнее, и останутся те, что окупаются.

1. Ночной перезапуск. Долго работающие игровые серверы накапливают всякое: сущности, данные чанков, фрагментацию памяти, плагины с медленной утечкой. Перезапуск в 05:00 никому ничего не стоит и всё это сбрасывает. Одно это расписание предотвращает больше жалоб «после нескольких дней всё тормозит», чем любая замена оборудования. Что оно скрывает и когда оно неверный ответ - тема статьи расписания перезапусков, которые помогают.
2. Backup перед ним. Не в тот же момент, а до него, с сохранением между ними, как выше. На тарифе с двумя слотами он вращается: вчерашний перезаписывает позавчерашний, поэтому второй слот должен хранить заблокированную заведомо хорошую копию, а не ещё одну ночную. Арифметика хранения разобрана в статье резервные копии, из которых действительно восстанавливаются.
3. Предупреждение перед этим. Перезапуск, о котором никого не предупредили, неотличим от падения, и игроки сообщают о нём как о падении. Двух сообщений, за пятнадцать минут и за пять, достаточно.
4. Что-то специфичное для вашей игры. Команда сохранения, вайп, дамп базы данных, смена карты. Таблица ниже - отправная точка.

Пятое стоит добавить, когда первые четыре заработают: еженедельное задание, которое делает то, о чём вы иначе забудете. Очистка журналов, перенос backup мира в заблокированный слот или напоминание о тренировке восстановления. Сторона хранения описана в статье журналы, которые стоит хранить.

Команды, которые стоит запланировать, по играм#

Консоль панели отправляет то, что вы вводите, на стандартный ввод сервера или на его RCON, в зависимости от игры. Там, где у игры нет консольного интерфейса, доступны только задачи backup и действие питания - и это не ограничение панели, это особенность игры.

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

Для сервера Rust вайп идёт в собственном ритме, а не в ночном, и это в той же мере решение сообщества, что и техническое: о выборе времени рассказано в статье вайпы Rust без потери игроков. Для всего, за чем стоит база данных, - фреймворка FiveM, экономики Minecraft, веб-приложения - дамп относится к отдельному расписанию, за несколько минут до backup, чтобы архив его подхватил.

Расписания для приложений, веб- и серверов баз данных#

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

• Дамп базы данных. Задача с командой консоли, запускающая pg_dump или mongodump в папку сервера в 04:05, чтобы backup в 04:15 заархивировал его и увёз с машины. Команды и флаги - в статье резервное копирование и восстановление баз данных.
• Собственный планировщик фреймворка. schedule:run в Laravel ожидает вызова каждую минуту, что законное применение */1 * * * * и одно из немногих заданий, которые должны запускаться так часто. Аналоги в Django и Rails устроены так же.
• Очистка журналов. Всё, что пишет файл журнала бесконечно, рано или поздно заполнит диск, а полный диск - инцидент намного хуже медленного сервера. Еженедельное задание, удаляющее файлы старше четырнадцати дней, ничего не стоит.
• Перезапуск, только если он оправдывает своё место. Здоровому процессу Node или Python ночной перезапуск не нужен, а его добавление скрывает утечку, которую следовало бы исправить. Если память растёт каждый день, прочитайте лимиты памяти Node простыми словами, прежде чем планировать вокруг этого.

Одно, что планировать не нужно: продление сертификата. На слоте прокси сертификат выпускается и продлевается автоматически в окне в 21 день, и задание cron, дёргающее его, ничего полезного не делает.

Как проверить, что расписание действительно выполнилось#

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

Три проверки, по возрастанию усилий:

1. Посмотрите на список backup. Отметки времени - самое дешёвое доказательство. Если самый новый архив одиннадцатидневной давности, вы уже знаете.
2. Следите за размером. Архив вдвое меньше прошлонедельного означает, что что-то перестало включаться. Рост нормален; резкое уменьшение - никогда. Это самое раннее предупреждение, которое всё это вам даёт, и работает оно, только если кто-то смотрит, - о том, как сделать это автоматическим, а не героическим, рассказывает статья мониторинг, который что-то говорит.
3. Один раз прочитайте консоль в назначенный час. Поставьте расписание на пять минут вперёд, посмотрите, как приходят команды, затем верните обратно. Это занимает несколько минут и ловит неверное имя команды, неверное экранирование и неверное предположение о том, какую консоль слушает игра. Как должен выглядеть вывод, объяснено в статье как читать консоль.

Остерегайтесь %, если пишете cron на VDS, а не в панели: в crontab неэкранированный % обрывает команду, и всё после него становится стандартным вводом. Имя файла с датой вроде $(date +%F) там нужно писать как $(date +\%F). Один этот символ отвечает за поразительную долю backup-заданий, которые ничего не производят.

Если у вас несколько серверов, разнесите их по времени. Десять backup, стартующих в 04:00 на одном узле, борются за один и тот же диск, и каждый идёт дольше, чем должен. Распределите их по часу: 5 4, 20 4, 35 4, 50 4. То же относится к перезапускам, и у этого приятный побочный эффект: не все ваши сообщества уходят в темноту в один и тот же миг.

Когда расписание - неподходящий инструмент#

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

• Перезапуск, чтобы замаскировать утечку. Законно как временная мера, нечестно как стратегия. Запишите, что он скрывает; эта запись и есть отчёт об ошибке. Причины разделены в статье почему ваш игровой сервер постоянно перезапускается.
• Более частые backup вместо правильных. Шесть backup в день в два слота означает, что самое старое восстанавливаемое состояние - восемь часов назад. Проблема, возникшая вчера, уже невосстановима. Глубина важнее частоты, как только вы перешли за один в день.
• Планирование в обход падения. Перезапуск каждые четыре часа, потому что сервер падает каждые пять, - это не обслуживание, а обратный отсчёт. Он ещё и натыкается на наблюдатель падений: три перезапуска за час, о которых вы не просили, вызывают предупреждение на странице сервера и автоматически открывают тикет, а запланированные перезапуски не считаются, так что считаются настоящие падения.

FAQ#

В какое время должен идти ночной перезапуск?

В час с наименьшим числом игроков, для европейского сообщества это обычно между 04:00 и 06:00 по местному времени. Проверьте свои числа, а не копируйте значение по умолчанию: у сервера, где игроки в основном в другом часовом поясе, тихий час совсем в другом месте. Избегайте 02:00-03:00 из-за перехода на летнее время.

Сколько расписаний может быть у одного сервера?

Сколько нужно; практический предел - ваша собственная ясность. Одно расписание с упорядоченной последовательностью задач проще осмыслить, чем пять, которые случайно идут рядом, так что предпочитайте задержки внутри одного расписания отдельным строкам cron с разницей в пару минут.

Считается ли запланированный перезапуск при обнаружении падений?

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

Может ли расписание сделать дамп базы данных?

Да, как задача с командой консоли, если нужные инструменты доступны в окружении сервера. Пишите дамп в собственную папку сервера и поставьте задачу backup через несколько минут, чтобы архив увёз его с машины. Дамп в место, которое backup не покрывает, - самый частый способ сделать всё это бесполезным.

Что будет, если задача ещё выполняется, когда стартует следующая?

Ничего хорошего, и для этого и нужны задержки. Backup сервера на 20 GB не заканчивается за шестьдесят секунд, а перезапуск, наступивший поверх него, даёт неполный архив. Один раз замерьте свои задачи и задайте задержки по измеренным числам, а не по надежде.

Стоит ли делать backup перед каждым обновлением?

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