DR в глобальных облаках: повышаем надежность аварийного восстановления

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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