Хабрахабр

Как отрубали свет в маленьком дата-центре: дешёвый способ аварийного развёртывания

Он нужен круглосуточно. Есть небольшой дата-центр около производственной компании в небольшом городе довольно далеко от Москвы. Потому что компания не айтишная, а производственная, правильно проектировать они когда-то не стали. Так получилось, что ввод от электросети там только один, а ДГУ нет. Потому что когда-то всё и так работало.

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

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

И что делать?

Именно с такой задачей заказчик пришёл к нам. Бюджета особо нет, нужно искать действующее решение.

Называется Disaster Recovery. Нормальный случай (это если не считать появления второго ввода, переноса оборудования или появления дизельного генератора) — развернуть второй точно такой же инстанс в облаке и переключать на него, если вдруг что-то падает. Некоторые вот себе второй ЦОД строят, он стоит холодным и ждёт, когда упадёт основной, либо работает в режиме active-active, принимая 50 % нагрузки.

Но денег на второй полноценный ЦОД нет.

Придумали вот что:

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

А для репликации виртуалок поставили Zerto, этот софт работает на уровне гипервизора. Для репликации базы в облако поставили софт Carbonite Availability (ранее известен как Double-Take Availability), который работает на уровне операционки. Задержка конкретно в этом случае 10 секунд, то есть мы всегда имеем свежую копию данных 10-секундной давности. Оба решения действуют примерно одинаково: сперва реплицируют весь объём данных сервера в облако, а затем перехватывают все записи на диски на основной площадке и дублируют их на диски в облако.

По кнопке из панели управления Зерто мы можем запустить все ВМ сразу. Виртуальные машины не включены. Запуск делается по звонку дежурному администратору. Происходит это в течение примерно 28 минут (машины запускаются параллельно), SLA на простой у нас 1 час. Заказчик сам решает, когда это нужно.

ВМ подхватывают базу и начинают работать.

Разруливает поломки, затем вручную включает реверс-репликацию. Когда на объекте включается питание, заказчик сам разбирается в своей инфраструктуре. Отреплицировали — переключаются. Накопленный за время работы приложений объём изменений в базе данных отправляется назад. Чем больше время работы аварийного инстанса, тем меньше доля трафика, потому что записи часто идут в одни и те же таблицы базы данных, а мы отправляем только разницу. В этом конкретном примере на каждый час работы виртуальных машин накапливается трафика примерно на 5 минут перезаливки.

Заказчик не платит за ресурсы, которые выключены. После обратного переключения в облаке выключаются виртуальные машины. Квантование у нас по часам.

Мы делаем работы по принципу «Disaster Recovery as a Service», даём SLA на это всё. Оплата идёт только за объём хранимых данных, канал и лицензию на софт для репликации (Zerto и Carbonite). И финансово отвечаем за этот SLA.

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

Вот так делает Зерто:

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

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

Так было надо из-за ряда особенностей. В инсталляции применены оба решения сразу. Обычно предлагают что-то одно.

Ещё можно решать похожую задачу отечественным решением Veeam Cloud Connect (обычно используем, если у вас уже есть бэкап Veeam).

Итог

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

Ссылки

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть