Что такое disaster recovery plan

Disaster Recovery vs High Availability

Business continuity (непрерывность выполнения бизнес-задач) — один из самых популярных запросов при построении инфраструктуры. Для того, чтобы ее обеспечить, используются два основных подхода: High Availability и Disaster Recovery. Мы постарались рассмотреть оба подхода и показать преимущества и контекст применения каждого.

Отказоустойчивость (High Availability) позволяет продолжать выполнение бизнес-задач при выходе из строя какого-либо компонента инфраструктуры.

Катастрофоустойчивость (Disaster Recovery) же позволяет продолжать выполнение бизнес-задач при выходе из строя ЦОД целиком, например, из-за отключения электричества на длительное время, пожара или любого иного масштабного природного явления.

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

Рассмотрим основные моменты:

Услуги по обеспечению непрерывности весьма востребованы, так как в любых технически сложных системах аварии неизбежны.

В финансовом секторе и промышленном производстве к высокому спросу подталкивают требования обеспечения непрерывности бизнеса, накладываемые регуляторами. В остальных сегментах, например, для торговых сетей, построение отказоустойчивых инфраструктур или их аренда (как в ЦОД, так и облачных провайдеров) объясняется растущей конкуренцией.

Для обеспечения непрерывности бизнеса (Business Continuity) необходимо подготовить два плана:

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

BCP же будет описывать, как организовать удаленную работу сотрудников, перенаправить поступающие товары на новый склад или вызвать такси.

Оба плана должны разрабатываться, исходя из требований бизнеса, и использоваться сразу после возникновения аварии. В них должны содержаться протестированные наборы инструкций и список ответственных, которые эти инструкции должны выполнить.

Технологии резервирования

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

Выделяют три вида резервов:

Холодный резерв

Некое серверное помещение с запасным оборудованием. В «сценарии катастрофы» может планироваться закупка либо хранение оборудования на складе.

Следует помнить, что большая часть оборудования поставляется под заказ и оперативно ввести в работу десятки единиц серверов, СХД, коммутаторов представляется маловероятным.

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

Теплый резерв

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

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

Горячий резерв

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

Минус как горячего, так и теплого резерва – простой оборудования. Одним из решений может стать решение использовать две площадки равномерно – большинство приложений могут работать как на одной, так и на другой. При использовании мощности всего оборудования можно обеспечить балансировку нагрузки, например, на одно из приложений при ожидаемом пике.

Отказоустойчивость

Под «Отказоустойчивостью» понимается свойство системы сохранять работоспособность в случае случайного выхода из строя или сбоя отдельных компонентов. Критерий надежности может определятся количеством «девяток после запятой»:

Как измеряется High Availability

Процент доступности рассчитывается следующим образом:

доступность = (минуты в месяце — минуты простоя) * 100 / минут в месяц

Поставщик услуг обычно предоставляет показатели доступности в своих соглашениях об уровне обслуживания (SLA). При этом обслуживание системы и запланированное время простоя являются неотъемлемой частью этого соглашения. Если в SLA заявлено 99,999%, конечный пользователь может ожидать, что услуга будет недоступна в течение следующих промежутков времени:

Если провайдер услуг придерживается стандарта «три девятки» (99,9%), то это означает, что в течение одного года допустимо около 8 часов и 45 минут простоя системы.

Как обеспечить High Availability

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

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

Инфраструктура, настроенная для обеспечения непрерывной доступности, должна иметь дополнительное (избыточное) аппаратное и программное обеспечение, благодаря которому в случае сбоя система останется работоспособной.

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

Катастрофоустойчивость

Под катастрофоустойчивостью подразумевается способность системы сохранить критически важные данные и продолжить выполнять свои функции после массового (возможно, целенаправленного) уничтожения его компонентов в результате различных форс-мажорных ситуаций. Этому определению точно соответствует англоязычный термин «Disaster Tolerance» (DT), однако в общем случае термин «Disaster Recovery» (DR) (дословно «Восстановление после катастрофы») можно также переводить как «катастрофоустойчивость». Отличие DR от DT состоит в том, что DR концентрирует внимание на сохранности данных (при строго контролируемых потерях, если они неизбежны).

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

Для защиты от природных, техногенных катастроф или терактов и обеспечения непрерывности бизнес-процессов необходимо резервирование основных систем хранения и обработки данных. В случае катастрофы может пострадать здание центра обработки данных, поэтому создание территориально удаленной площадки – резервного дата-центра – необходимо. Когда уровня надежности Tier III не хватает, географически распределенная катастрофоустойчивая инфраструктура ЦОД способна гарантировать доступность четыре и даже пять девяток.

Непрерывность работы виртуальных дата-центров

Облако на базе VMware представляет собой облачную инфраструктуру (IaaS) на базе платформы VMware vSphere® и VMware vCloud Director® и предназначено для получения вычислительных ресурсов с удаленным доступом на базе облачной платформы VMware Cloud.

Совокупность виртуальных облачных вычислительных ресурсов (процессоры, память, место на диске, сети) называется виртуальным дата-центром.

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

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

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

Вместо заключения

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

Чтобы обеспечить функционирование своих информационных систем современные бизнесы стремятся повысить отказоустойчивость, например, за счет избыточности входящих в нее компонентов и обращают особое внимание на условия эксплуатации поддерживающего ее IT-оборудования:

Желаем успеха в построении надежных IT-инфраструктур и будем рады поделиться нашей собственной экспертизой. Задавайте любые интересующие вопросы в комментариях, а также наших социальных сетях: ВКонтакте, Фейсбуке и Твиттере.

Полезные статьи и материалы по теме:

Источник

Как разработать план аварийного восстановления (Disaster Recovery Plan)

Отказы и сбои IT-инфраструктуры нельзя исключить полностью. После катастрофы работу сервисов нужно восстановить как можно быстрее — тогда убытки бизнеса будут минимальны. Чтобы сотрудники знали, как действовать, и нужные меры были приняты вовремя, разрабатывают план аварийного восстановления (DRP): выбирают технологии Disaster Recovery с учетом потребностей бизнеса и бюджета, назначают ответственных, прописывают порядок действий для предупреждения катастрофы и устранения ее последствий.

Мы составили руководство по разработке плана аварийного восстановления с общими рекомендациями по восстановлению IT-инфраструктуры.

Что такое план аварийного восстановления

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

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

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

Что должно быть в плане аварийного восстановления (Disaster Recovery Plan)

Цели плана аварийного восстановления

В качестве целей DRP могут быть указаны:

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

Факторы риска

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

Такие мероприятия, как правило, проводят регулярно для оценки состояния IT-инфраструктуры и ее готовности к процедурам аварийного восстановления в случае катастрофы. Это могут быть:

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

Так может выглядеть список потенциальных угроз для IT-инфраструктуры в DRP

Список критически важных сервисов

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

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

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

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

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

Система реагирования на сбои

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

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

Распределение ролей и обязанностей между сотрудниками

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

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

Процесс реализации плана и реагирования на технический сбой

В плане DRP нужно прописать действия команды для восстановления IT-инфраструктуры после катастрофы. Сотрудники должны заниматься восстановлением работы сервисов, оповестить о случившемся нужных членов команды, добиться запуска системы в нужное время.

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

Также в плане прописывают всю важную дополнительную информацию: где хранится документация; что происходит в случае обновления плана; куда обращаться в страховых случаях; кто и как общается с прессой; что делает юридическая группа компании и когда она подключается; когда нужна оценка финансовых рисков и другое.

Каждая задача должна быть максимально конкретной, то есть состоять из точных команд или действий. Например, не просто позвонить ответственному, а позвонить менеджеру Юлии по телефону 8-965-123-45-64 в течение трех минут.

Типовая схема действий после катастрофы

Тестирование плана

Готовый план аварийного восстановления тестируют, чтобы выяснить, сработает он в реальной ситуации аварии или нет.

Существуют различные типы тестов:

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

Источник

Что такое Disaster Recovery

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

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

Причины востребованности

Организации все чаще переносят все бизнес-задачи и процессы в IT-инфраструктуру. Это не удивительно, так как благодаря этому удается оптимизировать процессы, увеличить эффективность сотрудников и снизить издержки.

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

Компании уделяют много внимания стабильности инфраструктуры, используя современное оборудование и программы для защиты информации. Однако даже в этом случае не удается на 100% исключить возможность непредвиденных ситуаций. Поэтому крайне важно не только не допустить сбои, но и мгновенно восстановить инфраструктуру в случае их наступления. Для этого и применяется комплекс аварийного восстановления.

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

Условно аварийное восстановление делят на три уровня:

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

Disaster Recovery обычно предлагают облачные поставщики услуг. Как правило, они могут предоставить необходимые мощности для размещения дополнительной информационной системы. Важно, что основная ИС находится в другом центре обработки данных, то есть системы не зависят друг от друга. Между ними обеспечиваются необходимые каналы связи, позволяющие обеспечить поступление данных и в основную, и в дополнительную ИС.

DRaaS, то есть «восстановление как сервис» существенно отличается от традиционного бэкапа. Основной целью резервного копирования является сохранность файлов во время аварийной ситуации. Аварийное восстановление же помогает сократить время простоя инфраструктуры. По сути резервная копия не позволяет организации продолжить работу на резервной площадке, пока не восстановлена работоспособность основной. Disaster Recovery, наоборот, позволяет применять резервную площадку, на которую будут перенесены все бизнес-процессы.

Основная цель решения – это наличие пошаговой инструкции для устранения любых последствий сбоя. С его помощью можно:

Основные параметры

Disaster Recovery IT-систем подразумевает соблюдение двух критериев, которые влияют на стоимость инфраструктуры и возможную сумму ущерба в случае аварии:

Аварийное восстановление данных будет обходиться компании дороже при меньших показателях RTO и RPO. Однако подбирать стоимость решения необходимо с учетом размера убытков в случае сбоя. Если стоимость восстановления больше, чем возможные потери, то стоит оптимизировать показатели RTO / RPO и уменьшить затраты.

Составление плана

Компании обязательно потребуется разработать DRP – Disaster Recovery Plan. Этот план должен включать в себя параметры воссоздания всех систем после происшествия. По сути, это отдельный документ, в котором описываются мероприятия по устранению последствий инцидента и воссозданию процессов. Важно указать, кто из сотрудников компании отвечает за отдельные задачи плана, а также донести информацию до каждого работника.

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

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

План включает в себя несколько разделов. Сначала он потребует составления целей и списка критически важных сервисов. Затем – необходимо учесть возможные факторы риска.

Целями создания DRP может быть:

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

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

Как вы понимаете, не существует универсального способа аварийного восстановления сервисов. Для каждой компании потребуется индивидуальная разработка DRP и подбор технических параметров. Если вы хотите избежать потери данных и добиться постоянной работоспособности ИТ-инфраструктуры, то обращайтесь в нашу компанию Xelent. Мы подберем подходящее решение для вашего бизнеса!

Источник