Как мы обеспечивали резервное копирование ИТ-инфраструктуры клиента в Донецке

    Резервное копирование для заказчика – обычная услуга, но этот случай отличает то, что заказчик, компания РБК Укринвест и его инфраструктура располагаются в Донецке. Наверное, не имеет смысла рассказывать о постоянных бомбардировках, обстрелах зданий и т.д., думаю, что все и так в курсе. Но именно эти обстоятельства заставили клиента задуматься о необходимости полного бэкапа его 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
    68.85
    #1 Корпоративный облачный провайдер
    Share post

    Comments 38

      +3
      Вы меня извините за оффтоп, но откуда гифка? :)
        +9
        Я ждал вопроса :) "Игра Эндера".
          +1
          Шикарный фильм. Смотрел пару дней назад.
            +6
            Книга в x100 раз круче фильма.
              0
              Это почти всегда =)
                0
                К сожалению, о книге узнал только после просмотра фильма. В конце, правда, горизонт своим гуманизмом завалили. (как в книге не в курсе)
                  +1
                  В этот раз просто до слёз, имхо. Просто не понравился фильм после неё. А я, если что, смотрю почти всё :)
                +2
                Про «шикарный» это вы погорячились. В фильме дети с серьёзными лицами пытаются всем показать какие они крутые бойцы (бои даже с экрана выглядят забавно), убицы, войны и проч. Помимо этого ещё поднимается тема «я их убил, я такой плохой, но ведь я должен и ко-ко-ко». Вы уж извините, но даже не пародия, это просто невероятно тупо. В стиле какого-нибудь наивного анимэ для подростков. Это я ещё даже про сюжетные тупости не вспоминаю, ага.

                Возможно всё дело в том что я книгу не читал. Но после просмотра этого, желания читать книгу не возникает.
                  0
                  Посмотрел сегодня фильм, не совсем понял зачем их учили драться, играть с эту игру с командами. (ну ладно тут тактика)
                  Если в итоге им из знаний понадобилось только лишь удаленно управлять кораблями через интерфейс. Так бы их и готовили к этому.
                    0
                    А сама идея «давайте отправим огромный межпланетный корабль (!) с детьми (!), чтобы он просто прилетел на орбиту и выпустил ядерную ракету» вам как?
                      0
                      Не просто тактика, а вообще навыки и логика боя в невесомости в трёхмерном пространстве.
                        0
                        А зачем, если он, в итоге, тупо кнопку нажал и всё само получилось?
                          0
                          Он сначала всю войну выиграл, тащемта. Атака на родную планету жукеров была уже финальной битвой. И, опять же, там не было «тупо кнопку нажал, и всё само получилось».
                          Вы точно хотя бы фильм-то смотрели? =) Там даже та самая BFG пушка не у Эндера под управлением была. А тактика последнего боя была именно самоубийственная атака вида «игнорировать вражеский флот и собственные потери, но протащить БФГ-носец до расстояния прямого удара по поверхности», показанная впервые именно в одной из их командных игр (где вся команда прикрывала телами одного члена со всех сторон, сопровождая его до «ворот»).
                            0
                            Это у вас видимо из книжки отложилось, так как в фильме эти моменты может и были, но обыграно всё было так, что в единую логическую цепь, вот так вот гладко, всё не складывалось ну никак.

                            Я фильм смотрел сквозь пальцы фейспалма, но последние кадры помню неплохо. Там это выглядело не как «игнорировать вражеский флот и собственные потери», а как «я машу руками и всё само летит куда надо, а я усердно изображаю душевную боль потерь от жалящих меня насекомых».
                              0
                              Ну, посмотрите, вот: vk.com/video-19802817_169945330?hd=3&t=1h27m55s ←1ч27м55с.
                              Сначала он (жертвуя эскадрой) выманивает их малые корабли из «маток», чтобы плостность была достаточная для цепной реакции, а потом строит щит из всех кораблей «Все боевые единицы образуют щит!», а потом вообще прямым текстом(!) говорит: «прикрывать Петру как прикрывали Алаи в бою с Бонзо». Как это можно было не заметить — не знаю. Разве что специально.
                                0
                                На мой взгляд, цивилизация, способная отправить в космос межпланетные боевые корабли, с указанным количеством беспилотников всяко будет в состоянии отправить, например, миллион тех беспилотников, которые с лёгкостью проделали бы ровно то же самое, только без участия детей.

                                Я очень сомневаюсь что «гениальный план» по прикрытию пушки беспилотниками это невероятно гениальная идея, пришедшая в голову внезапно (!) ребёнку, до которой бы при этом не додумалась группа инеженеров, способных создать технологии, которые были у детишек в фильме. Или ещё момент — неужели вы думаете, что цивилизация, обладающая возможность построить межпланетный флот, не способна набрать достаточное количество ядерного оружия, чтобы уничтожить одну жалкую планету?

                                Короче это всё притянуто за уши и от этого выглядит невероятно картинно и неуместно.
                                  0
                                  1. Кто управлял бы беспилотниками? ИИ?
                                  2. Почему-то, инженеры ещё никогда армиями не командовали.
                                  3 Там вообще не ядерное оружие было, если что.
                                  4. До планеты-то ещё пробиться нужно. Повторюсь — это только финальная часть финальной битвы, повторюсь, он перед этим ещё и всю войну выиграл.
                                  5. Там обе цивилизации межпланетные флоты строили — и люди, и жукеры, вас это не смущает?
                                    –2
                                    1. Да хоть ии, указанный уровень технологий подразумевает развитой ИИ.
                                    2. Вроде и межзвёздных перелётов пока никто не совершил.
                                    3. Но ведь ядерное априори мощнее чем какая-то пукалка, так что это всего лишь камень в огород реалистичности.
                                    4. И почему бы не пробиваться, например, ядерными ракетами? Выйграл не он, а штуки, которыми он управлял, если на то пошло. Очевидно, что любой технологически развитой цивилизации под силу создать ИИ, ничуть не уступающий человеку. Получилось так как получилось лишь потому что это плод воображения какого-то автора, а не потому что это логично и реалистично, извините.
                                    5. У жукеров, кажется, не было ядерного оружия — значит они априори лузеры.
                                      +1
                                      Энивэй, не кажется ли вам что мы тут чрезчур оффтопим?
                        +1
                        какие они крутые… войны


                        Часто натыкаюсь в инете на такое странное написание. Откуда Й? Вы слышали, как звучит это слово хотя бы в единственном числе?
                  +12
                  Спасибо, за описание решения! Мы аналогичную задачу решили другим путем – просто вывезли три стойки оборудования в дата-центр в Киев. Пересечение блокпостов – тайна покрытая мраком.
                    0
                    Оборудование в стойках было такое дорогое, что пришлось его везти (с риском потерять вообще) или информация (базы данных, настроенные сервера итд)?

                    Если предположить, что заранее «соломку подстелили», разработали политику backup & recovery, любой сервер можно восстановить на чистом железе, бэкапы есть и последние «учения» по замене серверов прошли недавно и успешно — получилось бы в этих условиях не везти сервера через блокпосты без гарантий успеха, а просто купить и смонтировать на новом месте требуемое железо и по сети перелить туда бэкапы?
                      0
                      Вместо «такое дорогое» правильнее будет «дорогое для нас». Кризис в стране, а в регионе вообще катастрофа. По сравнению с переездом, разработка стоимость и время реализации любого другого решения была-бы просто космической для компании.
                      Переезжали в два этапа – сначала основная масса оборудования, потом хранилища с резервными копиями.
                        0
                        По сравнению с Вашим методом, первичная синхронизация инфрастурктуры на удаленном объекте была произведена нами за 3 дня включая установку и настройку Агентов Асигры. В сравнении с Вашим вариантом, такое количество серверов физически невозможно было бы отвезти, смонтировать, задублировать и запустить на удаленном объекте. Все работы проводились в условиях цейтнота ( т.е. полного отсутствия времени ) и риск разрушения исходной инфрастурктуры в данном случае был максимальным из возможных.
                      0
                      Скажите, с точки зрения эксперта, при подъеме клонов вариант с изменением записей DNS — единственный, или возможны альтернативы?
                      Дело в том, что подъем клонов как правило происходит после серьезной аварии, при этом часть компьютеров в сети в аварии не пострадают, у них всякие плюшки не прекращают работать (локальный dns кэш например). Я сейчас в процессе планирования аналогичной схемы резервного копирования, пробую разные варианты, и склоняюсь к прописыванию двух адресов на одно имя в DNSе плюс переконфигурация сетевых карт клонов после приема на «запасном аэродроме».
                      И спасибо за полезную статью.
                        0
                        Предполагаю что есть вариант всю подсеть с серверами промаршрутизировать в облако. Ну и кеширование DNS не такая уж большая проблема — сроки восстановления думаю в любом случае больше времени жизни стандартного кеша.
                        Два адреса на одно имя не рекомендую. Будете ловить затыки при попытке обращения к «резервному» адресу. А в худшем случае есть возможность ненароком вообще воспользоваться резервным сервером при живом рабочем.
                          0
                          Ага, понял.
                            0
                            Сервера в любом случае лучше держать в отдельной подсети.
                            В таком случае для изменения маршрутизации вполне хватит OSPF или даже статики. AS — тут можно, но по моему не обязательно (если речь идет о не особо большой инфраструктуре).
                            Другой вопрос который нужно решать — это доступ к этим самым серверам.
                            Зачастую в датацентр где расположены сервера так же сходятся и каналы связи в виде оптики, VPN'ов и т.п., а при физическом разрушении ДЦ эти каналы так же потеряются. Т.е. инфраструктура связи тоже нуждается в некотором пересмотре при подобной схеме резервирования. Придется кроме резервирования серверов также продумать и резервирование связи или план по ее перенастройке. Но это опять таки зависит от того что и как было сделано в резервируемой инфраструктуре изначально.
                          +1
                          Дело в том, что днс для двойных а-записей использует переключение раунд-робин, что означает политику балансировки.

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

                            И еще вопрос в догонку (см пост чуть выше) — какие-то меры по принудительному изолированию упавших серверов предусмотрены? Например, на случай, когда небольшой сбой воспринимается оператором (или начальником оператора) как крупная авария, он производит переключение на клонов, а через некоторое время время в основном офисе просто дали свет, заработали сервера… Есть какая-то красная кнопка?
                              0
                              Учитывая озвученные риски могу предположить что требования автоматического восстановления к системе не предъявлялось. Думаю что вначале производится оценка ситуации персоналом и только после нее запускаются резервные машины.
                                0
                                Основная и резервная инфрастукртуры териториально, физически и логически разделены и не имеют общих точек сетевого объединения на L2 уровне, находятся на географически и територияльно разделенных объектах. В этом случае запуск дублирующей инфрастурктуры никак не повлияет на работоспособность основной инфрастурктуры даже в случае ошибочного принятия решения о подъеме резервной инфрастурктуры. В описанном Вами случае ошибочно включенная дублирующая инфрастурктура может быть просто выключена и в последующие циклы синхронизации при инкрементальном резервном копировании будет синхронизирована с основной инфраструктурой. В подробной красной кнопке была бы необходимость, если бы обе инфрастурктуры имели единое L2 сетевое пространство.
                                  0
                                  Я как обычно… подумал, но вслух сказать забыл.
                                  Вопрос был и про внутренние сети и про внешние сети, конкретно про exchange — почта доступна снаружи, одновременная работа основного сервера и его клона — нежелательна.

                                  Впрочем, вы уже ответили, красной кнопки нет, я и сам понимаю, что в ваших условиях это лишнее.
                            0
                            Рекомендую на всякий случай ознакомиться с данным постом:
                            VMware сломала механизм CBT для резервного копирования виртуальных машин
                              +2
                              Гифка на EDGE соединении просто прекрасна.
                                +1
                                Эх. А я аналогично shaytan катался с серверами в Киев. Укринвест, Андрей Л. respect.
                                  0
                                  Прочитал про то, что выкачивание данных заняло три дня и тоже заинтересовался — не лучше ли было человека/флешку в мирный мир отправить и уже из промежуточной точки переслать данные провайдеру.
                                    +1
                                    Ну если человек-флешка бессмертный, то проще. Ну или как в фильме Джонни Мнемоник.

                                  Only users with full accounts can post comments. Log in, please.