Жизнь после катастрофы: нюансы организации Disaster Recovery на предприятии
В нашем мире многое нестабильно: запланированный отпуск может сорваться, погода на выходные — испортиться, и технологии, которые нацелены на защиту информации, — не исключение. С первых строчек может показаться, что все тлен, но рисками можно и нужно управлять. Например, поездку можно перенести, а на пикник взять зонтик. Неопределенность порождают как внешние, так и внутренние факторы, а сама она влияет на поставленные нами или компанией цели. За долгие годы работы команда «ЛАНИТ-Интеграции» собрала портфель инструментов, которые могут в буквальном смысле спасти компанию, и с одним из них мы хотим вас сегодня познакомить.
В этой статье расскажу о непредвиденных происшествиях, которые могут случиться на любом предприятии, к каким последствиям это может привести, а главное — как нивелировать риски потери ценной информации.
Суть Disaster Recovery
Disaster Recovery (DR) буквально означает восстановление после катастрофы. Обычно под катастрофой (Disaster) принято считать незапланированное прекращение работы дата-центра, на базе которого функционирует ИТ-инфраструктура предприятия. Конечно, современные ЦОДы имеют резервирование всех необходимых инженерных систем, но от полной остановки все равно не защищены на 100%.
Прекращение работы дата-центра может быть вызвано его повреждением или разрушением из-за масштабных происшествий (пожар, наводнение, техногенные аварии, террористические акты), после которых ЦОД остается в руинах. А вот процесс восстановления работы после катастрофы занимает не один месяц, начиная с ремонта здания и заканчивая повторной закупкой и наладкой инженерных систем, ИТ-оборудования.
Ожидания и реальность от внедрения Disaster Recovery
Для устранения негативного влияния неожиданной остановки дата-центра и сохранения эффективной работы предприятия применяется механизм Disaster Recovery. По сути, DR — это совокупность организационных мер (регламенты, правила, политики, инструкции) и технических средств (оборудование, ПО, каналы связи), направленных на снижение последствий катастрофы и предотвращения полной потери данных. Механизм применим к предприятиям любого масштаба. Это может быть как индивидуальный предприниматель, у которого вся ИТ-инфраструктура состоит из одного ноутбука с программой 1С, так и международная корпорация, использующая большое количество дата-центров по всему миру. В первом случае это может быть просто налаженное резервное копирование данных с одного ноутбука в облачный ресурс вроде Яндекс.Диска и напечатанная на листе инструкция по восстановлению. Во втором — механизм DR будет существенно сложнее и вариативнее, и даже краткое описание займет не одну книгу.
Применяя инструмент реагирования на критические сбои в ИТ-инфраструктуре, предприятие ожидает получение конкретных показателей доступности сервисов, работающих в дата-центре: RPO (Recovery Point Objective, допустимая потеря данных) и RTO (Recovery Time Objective, допустимое время простоя). Чтобы внедрение DR принесло предприятию ожидаемую пользу, необходим определенный уровень ИТ-зрелости. Если в компании нет практики, например, документирования ИТ-систем и бизнес-процессов, четкого следования персонала внедренным регламентам, то Disaster Recovery не принесет никакой практической пользы, а в некоторых случаях может даже навредить.
Четыре модели реализации Disaster Recovery
При выборе конкретной топологии для Disaster Recovery важно учитывать и анализировать массу факторов: наличие своих площадок, каналов связи между ними и интернетом, стоимость облачных ресурсов, допустимость размещения данных в облаке, требований к безопасности, стоимость всех компонентов решения и т.д. Существует четыре основных модели реализации DR.
On-prem-on-prem — когда при отказе собственного или арендованного дата-центра восстановление работы ИТ-инфраструктуры произойдет на дублирующей площадке. Возможны различные варианты реализации такой модели. Самый простой — когда предприятие использует основной ЦОД для продуктивной работы и создает резервный для DR. Все-таки катастрофы пусть и случаются, но весьма редко, и потому просто «греть воздух» в резервном дата-центре весьма накладно. Поэтому в резервном ЦОДе можно разместить тестовые или учебные данные и системы, которые в случае катастрофы будут удалены или остановлены и замещены основными системами. Другой вариант — поделить продуктивную нагрузку между основным и запасным дата-центрами, которые будут резервировать друг друга. Но и это еще не все. Например, незадействованные мощности можно утилизировать тестовыми средами. А для компании с территориально распределенными дата-центрами можно создать один резервный ЦОД на базе еще одной дополнительной локации и в него резервировать ресурсы всех филиалов: какой из них станет жертвой катастрофы — тот и будет восстановлен в резервном центре.
Cloud-cloud — эта модель похожа на предыдущую, однако подразумевает наличие у предприятия виртуального дата-центра на базе облачных провайдеров. Предположим, что затопило все локации VK Cloud, значит, продолжили работать в Яндексе. Дело в том, что крупные облачные провайдеры, как правило, под капотом имеют какие-то средства защиты от катастроф, поэтому топология получается попроще. Техническая реализация такого решения содержит свои нюансы: необходимо уметь пользоваться двумя облачными провайдерами и транслировать конфигурацию между ними. Также важно учитывать связанность облаков друг с другом для своих ресурсов и при необходимости вносить коррективы. К примеру, организовывать стыковку через точки присутствия в одних и тех же дата-центрах, естественно, за дополнительные деньги.
On-prem-cloud — эта вариация подразумевает наличие одного или нескольких дата-центров, которые резервируются на виртуальных ЦОДах в одном облачном провайдере.
Cloud-on-prem — редкий и достаточно странный, но возможный сценарий. Представим, что заказчику принадлежит дата-центр, из которого часть ИС перенесена в облако для быстрого масштабирования в случае необходимости. В результате ИС работают в облаке, но резервируются в собственном ЦОДе.
Три основных этапа реализации DR: на что организациям следует обращать внимание
Как и любой проект, внедрение механизма Disaster Recovery на предприятии имеет определенную последовательность:
Инвентаризация и анализ ресурсов, подлежащих DR. Предприятию в первую очередь важно понимать, сколько и какое оборудование ему необходимо приобрести или арендовать, какой объем облачных ресурсов зарезервировать. Не стоит пренебрегать анализом имеющегося оборудования, которое требует внедрение DR. Нередко бывает так, что для определенных активов внедрить инструмент технически невозможно. Например, в основном облачном дата-центре в качестве межсетевого экрана используется виртуальная система Checkpoint, а в резервном — Fortigate. Оба решения эффективно решают свои задачи, однако потребуется не только уметь пользоваться обоими, но и переводить настройки между ними.
Определение требований к DR. Внедряемый механизм предполагает конкретные показатели RPO и RTO. Однако для различных информационных систем (ИС) эти требования могут отличаться в зависимости от рода деятельности предприятия. Представим, что у агропромышленного комплекса установлен сервер по обслуживанию весовых станций, который учитывает собранный урожай. Если в период уборочных работ сервер остановится, то данные по уже собранному урожаю придется собирать вручную. Однако в остальное время года сервер может простаивать хоть месяц без каких-либо последствий. Таким образом, формируются индивидуальные требования и техническое решение к DR для всех ресурсов.
Разработка технического решения. На этом этапе для набора ресурсов, подлежащих DR, и соответствия требованиям, разрабатываются технические решения. Задействуется специализированное ПО, разрабатываются скрипты, дорабатываются приложения, возможно, даже заменяются сами информационные системы. Набор средств и подходов для реализации DR огромен и не может быть охвачен в рамках одной статьи.
Использование встроенных возможностей приложения для Disaster Recovery
Можно проще всего реализовать DR, когда составляющие информационной системы приложения имеют встроенный функционал для его реализации. В целом, приложения можно разделить на два типа: со встроенными механизмами обеспечения высокой доступности и без них. К первым относятся кластеры без общего диска, например, MS SQL Server Always-On, а также со встроенной репликацией данных — MS Active Directory. То есть узлы таких приложений можно распределить в нужном количестве по дата-центру, и их потеря не повлияет на функционирование. Ко вторым относятся все остальные приложения, которым для обеспечения высокой доступности требуются внешние средства: повторное развертывание, восстановление из резервной копии или перезапуск виртуальный машины из реплики и т.д.
После анализа ресурсов, подлежащих DR, на предмет встроенных средств обеспечения высокой доступности, появляется некоторая ясность по воплощению инструмента в жизнь.
Использование дополнительных технических средств для Disaster Recovery
С приложениями первого типа все ясно: нужно обеспечить сетевую связанность между дата-центром и каналом с достаточной пропускной способностью, а также приемлемой задержкой. Приложениям второго типа сетевой канал тоже, безусловно, нужен, но это далеко не все — нужно каким-то способом организовать репликацию данных. Это можно сделать, например, задействовав функционал репликации систем хранения данных (СХД). Стоит отметить, что сама репликация бывает синхронной и асинхронной, которая, в свою очередь, может быть потоковой, триггерной (по времени или накопленному объему изменений) и снимками. Другой вариант, если в дата-центрах стоят разные СХД, то между ними можно поставить виртуализатор вроде VPLEX. Также можно использовать функции репликации виртуальных машин, которые предоставляются платформой виртуализации, или задействовать дополнительное ПО для дублирования данных файловых систем, вроде DRBD Sync или MS Storage Replication. Как вы понимаете — это далеко не все возможные варианты организации работы.
Импортные DR-решения
Не секрет, что на рынке достаточно много специализированных решений для организации Disaster Recovery. Конкретно мне довелось поработать с Veeam Availability Orchestrator и Veritas Resiliency Platform. Эти два продукта способны решить такие задачи, как репликация данных между дата-центрами, автоматизация DR и unDR, а также тестирование. В то же время они работают с физическими серверами, виртуальными машинами vSphere и иностранными облаками вроде Azure или AWS. Обеспечивается некоторая автоматизация как из коробки, вроде смены сетевых настроек, так и с помощью привязки собственных скриптов. Также нельзя не упомянуть VMware SRM.
Облака российских провайдеров на базе VMware vCloud Director не поддерживаются импортными DR-решениями. Дело в том, что провайдеры пусть и могут положить «под капот» своего облака одни и те же технологии, но реализуют собственный конечный продукт каждый по-своему — со всем на свете интеграцию не напишешь.
Отечественные DR-решения
Наиболее известные отечественные производители — это Hystax DR и Mind Guard. Решение от Hystax более популярное, поддерживает физические и виртуальные серверы, а также иностранных и отечественных облачных провайдеров. До тех же Veritas или Zerto по функциям пока далеко, но зато организовать DR, например, с локальных vSphere и физических серверов в VK Cloud сможет. Также позволяет организовать Disaster Recovery для всех топологий (кроме случаев, когда цель — это физические серверы, не виртуализованные), объединять серверы в группы, создавать отдельные планы репликации данных для них. Вполне рабочий и перспективный продукт, имеющий множество успешных кейсов в России и даже за рубежом.
Возможности инфраструктурного ПО для реализации Disaster Recovery
Конечно же, процесс восстановления виртуальных машин будет наиболее автоматизирован — это в первую очередь связано с возможностью репликации. Даже отечественный Кибер Бэкап ей обзавелся. Как правило, при выполнении Disaster Recovery требуются изменения в основных сетевых настройках реплик на те, которые нужны целевой площадке. Для этого есть некоторый набор функций для автоматизации восстановления виртуальных машин как из коробки, так и с помощью прикручивания собственных скриптов. С физическими серверами несколько сложнее, процесс их восстановления часто требует ручных операций.
Также хорошей практикой может быть организация DR с помощью средств автоматизации вроде Ansible или Puppet, но при условии, если они уже внедрены и активно используются. То есть в процессе выполнения Disaster Recovery фактически происходит повторное «развертывание» ресурсов и подключение к ним актуальных источников данных (реплик файловых систем или баз данных). Управлять ресурсами вручную и организовать DR с помощью Ansible не выйдет — DR-план неизбежно разойдется с актуальной конфигурацией серверов и не будет работать.
Разработка процессов DR, unDR и их тестирование
Катастрофа — явление страшное, но рано или поздно оно заканчивается. Представим, ураган повредил линию электропередачи и все дизельные электростанции, в результате дата-центр оказался обесточен. Чтобы сохранить работоспособность предприятия был выполнен DR в облако. Через несколько дней энергоснабжение ЦОДа восстановили, поэтому нужно производить возврат ресурсов назад — для этого необходимо разработать процесс unDR.
Здесь может быть два варианта развития событий.
Если ЦОД был разрушен и не подлежит восстановлению, то процесс unDR будет выглядеть следующим образом: либо настройка DR в новый дата-центр, либо в новое облако. Поэтому весь процесс разработки будет запущен с самого начала.
Если дата-центр удалось восстановить, то процесс unDR будет осуществляться по заранее запланированному сценарию: без потери данных и с контролируемым простоем информационных систем.
И DR, и unDR ничего не стоят без их тестирования. Как говорится, лучше один раз попробовать, чем сто раз увидеть. Только проверка покажет реальную работоспособность этих процессов и показатели RPO и RTO. Однако это имеет свою стоимость — потребляет рабочее время персонала и деньги на ресурсы облачных провайдеров.
Обучение участников DR-процесса
Начиная внедрение инструмента критического реагирования, предприятие должно позаботиться об обучении сотрудников. Его суть — в приобретении навыков по выполнению плана DR.
Основные участники процесса
Ответственный за запуск процесса DR –это может быть, например, руководитель департамента эксплуатации ИС. Он должен уметь своевременно и обоснованно принимать решения о необходимости запуска механизма и осуществлять общий контроль за процессом.
Администраторы различных компонентов ИС — специалисты, которым необходимо знать, какие конкретные действия нужно предпринять; эксперты должны быть способны выполнить процедуру за требуемое время.
ИТ-менеджеры должны уметь координировать выполнение процесса сотрудниками, которые задействованы в DR.
Пользователи ИС –персонал, который обладает навыками оперативной оценки работоспособности информационной системы по запросам администраторов или ИТ-менеджеров.
Какие есть тренды в организации Disaster Recovery
Любое оборудование может перестать работать и это факт. Однако, как я писал в самом начале, «рисками можно и нужно управлять». Если раньше ценность Disaster Recovery видели исключительно крупные корпорации, для которых остановка дата-центра, — репутационная и финансовая трагедия, то сейчас в сторону технологии все чаще смотрят и небольшие организации со штатом сотрудников один-два человека.
Те, кто не готов тратить силы и финансы на создание собственного резервного ЦОДа, могут обратиться к облачным провайдерам, которые стали развивать Disaster Recovery как сервис.
Производители решений для организации инструмента стараются идти в ногу со временем и активно внедряют новые фичи. Вполне вероятно, что текущая ситуация в мире послужит новым драйвером для развития систем резервного копирования, а также отечественных продуктов и сервисов Disaster Recovery. Это поможет повысить конкурентоспособность отечественных решений — им есть куда расти и развиваться.
