Парк серверов у разных провайдеров: как держать его без дежурства

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

Постановка

Несколько серверов у разных провайдеров в разных странах. На них живут сайты, боты и сервисы. Дежурного администратора нет, и не предвидится.

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

Первое: знать, что упало

Проверка состояния раз в пять минут. Не «пингуется ли сервер», а отвечает ли сервис по существу: открывается ли страница, отвечает ли бот, работает ли база.

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

Важность этого пункта я узнал на практике. Однажды заказчица сообщила, что «бот не работает». На деле лежал весь сервер целиком: мессенджер бота видел, но сервер не отвечал ни на что. Без мониторинга разбирательство началось с логики бота — то есть не с того конца.

Правило, которое стоит записать: при жалобе «не работает» первым делом смотрят проверку состояния и доступность машины, а не код.

Второе: чинить то, что чинится само

Сторож раз в две минуты проверяет процессы и перезапускает зависшие.

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

Ценность здесь в частоте. Проверка раз в пять минут для мониторинга приемлема — это про уведомление. Сторож должен быть чаще, потому что это про восстановление.

Третье: копии, которые проверяются

Ежечасные резервные копии с ротацией, четырнадцать поколений.

Ключевое слово — проверяемые. Копия, которую никто не пробовал восстановить, не копия, а надежда. Известный сценарий: архивы создавались год, а при аварии выяснилось, что все они пустые, потому что путь поменялся.

Поэтому копия после создания проверяется: открывается ли, не нулевого ли размера, лежит ли внутри то, что ожидается. Проверка простая, но она превращает ритуал в страховку.

Четырнадцать поколений — это компромисс между местом и глубиной. Он покрывает случай, когда поломку заметили не сразу и надо откатиться на несколько дней назад.

Подробнее про эту часть — в статье почему резервные копии важнее, чем кажется.

Четвёртое: тёплый резерв у другого провайдера

Это то, что отличает отказоустойчивость от простой надёжности.

Все ваши серверы у одного провайдера — это один отказ. Сеть провайдера легла, авария в дата-центре, блокировка аккаунта — и падает всё сразу, независимо от того, сколько у вас машин.

Тёплый резерв — вторая площадка у другого провайдера, где уже развёрнуто окружение и лежат свежие копии. Она не обслуживает трафик в обычное время, но переключение на неё занимает минуты, а не день.

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

Пятое: защита от компрометации

Отказоустойчивость без безопасности бессмысленна: взломанный сервер работает исправно, просто не на вас.

Что сделано: вход только по ключам, парольная аутентификация отключена; защита от перебора; автоматические обновления безопасности; ежедневное сканирование на руткиты и майнеров.

Про майнеров отдельно. Это самый частый исход компрометации небольшого сервера: злоумышленнику не нужны ваши данные, ему нужны ваши вычислительные мощности. Замечают это по счетам и по тормозам, и обычно поздно.

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

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

Нужен ли для этого оркестратор?

Для парка из нескольких серверов — нет. Оркестратор решает задачу управления десятками и сотнями узлов и добавляет свой слой сложности, который тоже надо обслуживать. Здесь достаточно системных средств и расписания.

Как часто делать резервные копии?

По простому правилу: сколько данных вы готовы потерять. Час — значит ежечасно. Для большинства небольших сервисов это верный ответ, и стоит он немного.

Что делать, если сервер у клиента и доступа к панели нет?

Признать это ограничением и записать его. Тогда при падении машины вы не теряете время на попытки перезагрузить, а сразу пишете тому, у кого есть доступ. Знать границы своих возможностей — часть отказоустойчивости.

Сколько это стоит в обслуживании?

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

Как понять, что мониторинг настроен правильно?

Проверить его отключением. Остановите один сервис намеренно и посмотрите, придёт ли уведомление и за сколько. Мониторинг, который ни разу не срабатывал, не проверен — он просто молчит, и молчание это ничего не доказывает.

Что делать с ложными срабатываниями?

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

Где хранить резервные копии?

Не на том же сервере, что и данные. Копия рядом с оригиналом защищает от повреждения файла и не защищает от потери машины, а именно это и есть самый вероятный сценарий.

Коротко о главном

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

Дорогие решения здесь не нужны. Нужна дисциплина: проверка состояния по существу, а не по пингу; копия, которую проверили; резерв именно у другого провайдера, а не вторая машина у того же.

Если у вас серверы, за которыми никто не следит, — расскажите, что на них крутится. Скажу, какие из пяти пунктов у вас закрыты, а какие только кажутся закрытыми. Напишите в Telegram, MAX или VK.