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



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

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

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

    И что делать?


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

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

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

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



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

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

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

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

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

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

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

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

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



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

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

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

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

    Итог


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

    Ссылки


    • +29
    • 13,4k
    • 4
    КРОК Облачные сервисы
    92,00
    Облачная IaaS-платформа собственной разработки
    Поделиться публикацией

    Комментарии 4

      0

      Заголовок не раскрыт: конкретики про "дешевизну" не приведено. Может пять рублей в цифрах выиграли, а нагородили...

        0
        Однажды в три часа ночи спросонья админ выберет в интерфейсе неправильное направление репликации, перезатрёт данные репликой, сломанной две недели назад, и бизнес спустит свои требования туда, куда и следовало купит дизель-генератор.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Между площадками сетевая связность на уровне L3. Подсети c разной адресацией. При переключении на резервную площадку происходит смена IP-адресов в ОС через VMware tools. Это штатный функционал Zerto.
            В момент настройки репликации администратор мапит подсеть с основной площадки на подсеть в резервной площадке. Также на резервной площадке определена изолированная подсеть для тестовых переключений – Zerto поддерживает режим теста, при котором ВМ на основной площадке не выключаются. В случае тестового переключения ВМ на резервной площадке будут подняты в изолированном сегменте – проблем с инфраструктурой не будет.
            С проблемой USN rollback в данном кейсе не сталкивались, так как реплицируемые ВМ используют ОС Linux c локальными пользователями. В случае кейса с AD лучшей практикой будет поднять контроллер домена на резервной площадке.

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

          Самое читаемое