Свой сервер под кроватью? Нет. Своя инфраструктура? Возможно, уже пора

Долгие годы нам объясняли, что покупать сервер больше не нужно.

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

Аргументы хорошие. Я и сам не испытываю непреодолимого желания в три часа ночи ехать менять накопитель. У меня для бессмысленного ночного бодрствования есть World of Warcraft.

Но потом приходит письмо от Yandex Cloud об атаках на дата-центры и недоступности зоны. И внезапно хочется разобраться, что именно мы купили вместе с удобной кнопкой.

Оказалось, зависимость тоже входила в комплект. Без отдельной строки в счёте.

В статье про резервные копии я уже разобрал, как забрать данные домой. Теперь вопрос шире: может, пора пересмотреть и саму инфраструктуру?

Системник из-под кровати пока не доставайте

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

Делать его единственной опорой бизнеса я бы не торопился.

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

«Почему не работает интернет-магазин?»

«Потому что у нас сегодня уборка».

Технически честный ответ. Коммерчески так себе.

Но собственный сервер совершенно необязательно держать дома.

Колокация: ваше железо, чужая розетка

Есть давно существующая услуга — colocation, или размещение оборудования в дата-центре.

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

Вы выбираете оборудование, систему, способ хранения данных и резервирования. Меньше зависите от специфических облачных сервисов, из которых потом приходится выковыривать проект по частям.

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

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

Поэтому покупать нужно не чувство контроля. Нужно собирать работающую схему.

Два узла и бэкап, который не живёт рядом с ними

Один из вариантов выглядит так:

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

Вторая площадка не обязана повторять первую до последнего винтика. Это может быть собственный сервер, арендованный выделенный или облачный. Главное, чтобы он мог поднять нужный проект с приемлемой производительностью.

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

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

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

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

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

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

Зарубежная площадка тоже не универсальный рецепт. Для персональных данных необходимо отдельно проверить требования к локализации и трансграничной передаче по 152-ФЗ. Нельзя просто назвать базу «резервной» и считать, что её содержимое перестало иметь значение.

А почему обязательно гигантский дата-центр?

Можно посмотреть и на местного интернет-провайдера.

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

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

Перед размещением я бы задал несколько приземлённых вопросов:

• Что произойдёт при отключении электричества и на сколько хватит резерва?
• Откуда приходят каналы связи? Два оператора случайно не лежат в одной трубе?
• Кто ночью заменит диск и где лежит запасной?
• Как попасть к оборудованию и забрать его при переезде?
• Как устроены охлаждение, пожарная защита и физический доступ?
• Какие сроки обслуживания и ответственность записаны в договоре?

«У нас всё надёжно» — пока не ответ. Это настроение продавца.

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

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

99,8%: калькулятор против презентации

Допустим, вам обещают доступность 99,8%.

Если считать на интервале ровно 365 дней без каких-либо исключений, оставшиеся 0,2% — это 17 часов 31 минута простоя.

Звучит уже чуть менее торжественно, чем почти сто процентов.

Но это только арифметический пример. В настоящем SLA, соглашении об уровне сервиса, важны расчётный период, перечень учитываемых отказов, исключения и компенсации. Нельзя прочитать «99,8%» и автоматически выдать провайдеру разрешение отключить вас на семнадцать часов.

И нельзя ожидать, что договор физически удержит питание в розетке. Нужно понимать, что он обещает при нарушении условий и поможет ли это вашему бизнесу пережить простой.

У инженерной сертификации тоже своя задача. Tier Certification Uptime Institute оценивает инфраструктуру и эксплуатационные аспекты дата-центра. Она не проверяет, умеете ли лично вы восстановить свою базу.

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

Сертификат висит. Бизнес лежит.

Давайте всё-таки посчитаем деньги

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

Поэтому сравнивать цену железки со счётом за облако недостаточно.

На горизонте трёх-пяти лет стоит сложить:

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

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

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

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

«Я всё обслуживаю сам, это бесплатно».

Да. И ночь с субботы на воскресенье тоже выдали по акции.

Начать можно без покупки сервера

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

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

Самая полезная проверка здесь довольно простая: представьте, что основной сервер недоступен, а поддержка пока не может назвать срок восстановления.

У вас есть данные? Доступы? Понятная инструкция? Известно, где и за какое время запустится проект?

Если ответы есть и вы уже проверяли их на практике, инфраструктура у вас действительно под контролем.

Если нет, покупка сервера добавит к проблеме только серийный номер.

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

И вот с этим действительно пора разобраться. До следующего письма.