Резервное копирование для заказчика – обычная услуга, но этот случай отличает то, что заказчик, компания РБК Укринвест и его инфраструктура располагаются в Донецке. Наверное, не имеет смысла рассказывать о постоянных бомбардировках, обстрелах зданий и т.д., думаю, что все и так в курсе. Но именно эти обстоятельства заставили клиента задуматься о необходимости полного бэкапа его IT-инфраструктуры в облаке.
Все свои ресурсы мы развернули удалённо
В этом посте я расскажу о технической стороне проекта, о проблемах, которые возникали и о полученных результатах.
Цель
Основная цель – обеспечить сохранность ИТ-инфраструктуры и критически важной корпоративной информации на случай выхода из строя серверной заказчика и соответственно, оборудования.
Примечание: к сожалению, я не имею права опубликовать полный список оборудования и сервисов заказчика в связи с подписанием соглашения о неразглашении. Тем не менее, можно сказать, что ИТ-инфраструктура заказчика соответствует компании уровня среднего бизнеса: в первую очередь, почтовый сервер MS Exchange, инфраструктура критично-значимых для компании виртуальных серверов.
Задача
Основная задача, которая стояла перед нами – обеспечить беспрерывное резервное копирование ИТ-инфраструктуры и критически значимой корпоративной информации заказчика в наше облако. В случае выхода из строя собственного оборудования заказчик должен иметь возможность работать в аналогичной ИТ-инфраструктуре в облаке Cloud4Y. Основное ограничение – совместимость виртуальных сред, на базе которых производится синхронизация инфраструктур виртуальных серверов заказчика с облачной инфраструктурой Cloud4Y. Поскольку у нас и у заказчика среды виртуализации оказались совместимы, мы решили применить решения на базе Asigra-VDR. Для общего представления объема синхронизируемых виртуальных ресурсов: суммарный объем данных составил 1,5 TБ.
Решение
Все работы проводились удаленно совместно с техническими специалистами заказчика. В качестве решения была выбрана Asigra Backup c инкрементальным бэкапом, технологией сжатия и шифрования. Использовалась схема работы Asigra Remote DS-VDR Incremental Restore, что позволило передавать только измененные блоки виртуальных машин.
Как это работает
Схема работы Asigra Remote DS-VDR Incremental Restore выглядит следующим образом:
1) DS-client (агент Asigra) получает только измененные блоки виртуальных машин.
2) DS-client дедуплицирует, сжимает и шифрует измененных блоков и отправляет их на DS-системy через WAN.
3) DS-система получает файлы с DS-Client.
4) DS-система хранит файлы в хранилище резервных копий в сжатом, зашифрованном, и дедуплицированной форме.
5) Remote VDR получает измененные блоки из DS-системы, расшифровывает, распаковывает и обновляет изменившиеся блоки резервной копии виртуальных машин в их оригинальном формате.
6) Remote DS-VDR выполняет инкрементное восстановление из виртуальных машин в режиме ожидания сервера ESXi, путем записи измененных блоков в соответствующем разделе диска.
7) Когда заказчик столкнется с выходом из строя оборудования, то он сможет получить доступ к резервной ИТ-инфраструктуре и корпоративным данным, которые развернуты в облаке Cloud4Y.
Хочется отметить высокую степень сжатия – при объеме 1,5Тб полезных данных архив составил около 450 Гб.
Проблемы
Топ-3 специфических рисков Донецка из-за военных действий: угроза попадания снарядов в помещение, отключение электричества, уничтожение кабельной инфраструктуры. Остальные риски типичны: изъятие серверов в случае нарушения закона, переход помещения в госсобственность – можно обобщить данную проблему как моментальное физическое разрушение ЦОДа.
Самой частой проблемой нашего клиента были падающие каналы связи. У заказчика постоянно пропадал интернет в офисе из-за обстрелов рядом стоящих зданий. Кроме того, периодически выключалось электричество, при этом ИБП хватало всего на 8 часов. По этим причинам синхронизация ИТ-инфраструктуры заказчика с облаком заняла 3 дня.
Залогом успеха выполнения задачи, а именно: «Обеспечить работоспособность клиента, всех его критичных ресурсов в максимально сжатые сроки» — являлся подготовительный этап.
С помощью моих коллег из Cloud4Y, в область ответственности заказчика был внедрен Агент «Asigra DS-Client», позволяющий реализовать технологию инкрементального резервного копирования виртуальных машин клиента. Мы не особо вдавались в состав данных клиента. Интуитивно понятный интерфейс Агента Asigra DS-Client после демонстрационной консультации специалиста клиента, позволил достаточно оперативно ввести в резервное копирование все критично значимые виртуальные сервера клиента.
Важной составляющей для начала успешной работы – первый цикл резервного копирования виртуального ресурса, который должен быть завершен успешно. В связи с тем, что в городе, где располагается клиент, постоянно ведутся боевые действия (связь прерывается, периодически отсутствует электроснабжение), этот этап был пройден за несколько подходов. Эффективность дедупликации и сжатия данных, реализуемая Asigra, позволили форсировать первый цикл резервного копирования и перейти в инкрементальный режим. Для справки можно сообщить, что эффективность сжатия и дедупликации доходила от 1:4 до 1:10 ( т.е. фактический передаваемый объем даже на первом этапе полного резервного копирования был меньше исходной инфраструктуры в несколько раз), что позволило также не перегрузить внешние каналы связи клиента (находящегося на большом расстоянии от облака), а также не мешать текущей работе инфраструктуры клиента.
На стороне Cloud4Y параллельно были развернуты VDR-Агенты Asigra, которые в автоматическом режиме производили восстановление виртуальных машин заказчика как только заканчивался очередной цикл резервного копирования.
Резюмируя практическую сторону резервного копирования: копия виртуальных ресурсов в облаке Cloud4Y разворачивалась с отставанием максимум на 3 часа и теоретически была всегда оперативно готова к работе. Но в этом «теоретически» есть и практическая сторона, которая требует тщательной подготовки на стороне облачного провайдера.
Мы использовали на своей стороне интерфейс управления облачной инфраструктурой VMWare vCloudDirector. Основное практическое преимущество данной платформы – свобода реализации изолированных сетей как в рамках инфраструктуры виртуального ДатаЦентра клиента (VDC), так и в рамках инфраструктуры vApp (виртуальной инфраструктуры).
После очередного цикла автоматического восстановления виртуальные машины «приходят» к нам в конфигурации и составе, которая непосредственно находится у заказчика. То есть, первый цикл восстановления прописывает сетевые интерфейсы виртуальных машин такими, которые изначально находятся у заказчика. Для сокращения времени последующего аварийного подъема инфраструктуры заказчика, требуется заранее подготовить виртуальные изолированные сети в vCloudDirector и прописать в них фактическую адресацию, которая используется у клиента. Этот этап был также сделан в диалоге с техническими специалистами заказчика.
Финальные штрихи подготовки к работе копии виртуальной инфраструктуры – подготовка виртуального шлюза, реализующего доступ виртуальных машин клиента в облаке Cloud4Y «наружу», а также реализующую файерволинг закрытой инфраструктуры клиента.
Результат
1. В облаке всегда находится копия инфраструктуры заказчика с 3-х часовой задержкой (макс).
2. Аварийное восстановление инфраструктуры клиента происходит путем простого запуска его инфраструктуры в Облаке ( что может сделать сам заказчик через интерфейс vCloudDirector его виртуального ДатаЦентра).
3. Внешние сервисы клиента перенастраиваются путем внесения изменений в dns.
В последствии клиент, используя те же технологии резервного копирования Asigra всегда через своего Агента Asigra DS Client может восстановить свою инфраструктуру на исходное или новое место, если возникнет такая необходимость.
В итоге аварийная работа клиента в случае крайне неблагоприятных событий (вплоть до полного разрушения его инфраструктуры) обеспечена.
Спасибо за внимание, будем рады ответить на ваши вопросы.
Автор: Cloud4Y
