Евгений Макарьин, руководитель группы разработки продуктов и решений Linxdatacenter 

Рано или поздно, любая техника выходит из строя. Верить, что ИТ-оборудование будет работать годами, а серверная в офисе никогда не упадет – опасно.  

Чтобы подобные инциденты не стали сюрпризом, важно закладывать их вероятность в план аварийного восстановления (Disaster recovery или DR-план). Какую роль в современных DR-планах играют глобальные облачные провайдеры – рассказывает Евгений Макарьин, руководитель группы разработки проектов и решений Linxdatacenter. 

Аксиома непрерывности бизнеса сегодня: только при наличии и регулярном тестировании DR-плана компания сможет рассчитывать на предсказуемые сроки возобновления работы в штатном режиме в случае отказа инфраструктуры и ИТ-систем. 

Создание и реализация корпоративного DR-плана требует много ресурсов, как на этапе разработки и запуска, так и при поддержании систем и процессов в состоянии постоянной готовности.  

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

«Заоблачный» уровень защиты 

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

Триумвират «больших облаков» – Amazon Web Services, Google Cloud Platform и Microsoft Azure – предоставляет клиентам максимальную автоматизацию процессов на всех этапах от инсталляции DR-решения до последующего управления, мониторинга и реагирования на инциденты. 

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

Почему нельзя просто делать disaster recovery в России?  

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

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

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

Зачем вам это 

Предположим, ваша ИТ-инфраструктура находится в ЦОДе, который внезапно загорелся. Картина реальная и очень страшная. Собственно, все помнят кейс OVH во Франции – даже компаниям, которые хранили резервные копии в удаленных ЦОДах, пришлось потом часами и днями восстанавливаться из бэкапов и поднимать инфраструктуру. 

Происходит это из-за ручных манипуляций и отсутствия регулярных тестов. То есть команда представляет, что нужно делать, однако если не тестировать систему регулярно и не проводить учения, восстановление часто идет не по плану.  

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

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

DR в глобальном облаке позволяет получить полностью работающую инфраструктуру в среднем за 20 минут после инициации плана аварийного восстановления.   

Подготовка 

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

Как правило, такие решения состоят из нескольких основных блоков – это консоль для управления всем процессом и агенты (специальное ПО), устанавливаемые на исходные Windows или Linux-серверы заказчика. Потребуется аккаунт в публичном облаке, где автоматически разворачивается так называемая staging зона с сервером репликации. Там же хранятся реплики данных. 

Рядом готовится целевая зона, где стартуют виртуальные машины клиента в случае тестового или «боевого» запуска DR-плана. 

Такое решение позволяет максимально автоматизировать процесс миграции для десятков и даже сотен серверов.  

На старт, внимание, DR! 

После того, как данные сервера изначально передадутся в глобальное облако, включается постоянная поблочная репликация. Это позволяет добиться показателя RPO (целевая точка восстановления, до которой восстанавливается «упавшая» ИТ-система), в несколько секунд. 

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

В глобальных облаках для этого создается security-группа, виртуальные сети, причем желательно с внутренней адресацией, аналогичной исходной инфраструктуре. И далее в консоли можно гранулярно для каждого отдельного сервера, настроить параметры, с которыми этот сервер будет стартовать при активации DR-плана.  

Например, можно установить тип машины, то есть сколько ядер и памяти будет назначено, способ тарификации, подсеть, IP-адрес, security-группы и так далее. Для многих настроек предусмотрена возможность автоматического подбора параметров, аналогичных исходному серверу. 

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

Вопросы доступа 

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

В чем преимущества?  

Во-первых, такой партнер проведет аудит инфраструктуры. Оценит, какие компоненты ИТ-системы клиента требуют защиты – оборудование, виртуализация, операционные системы, приложения. Выяснит, как много ресурсов на них выделено и как много используется. Также оценивает, как организована связность и загружена полоса пропускания, что тоже очень важно. 

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

В-третьих, создает инфраструктуру под клиента в глобальном облаке. Подготавливает нужные учетные записи, сети, access-листы, security-группы, маршруты, шлюзы, балансировщики нагрузки и так далее.  

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

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

Далее партнер возьмет на себя управление DR-инфраструктурой и поддержание DR-плана в актуальном состоянии. Это очень важная и достаточно трудозатратная часть стратегии по поддержанию работоспособности бизнеса. 

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