Drp что это

DRP-план в ИТ-компании и проверка его работоспособности

Проводим проверку работоспособности плана восстановления после аварии.

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

У большинства предприятий есть (ну, или хотя бы должен быть) план восстановления после аварии. Аналогичный план должен быть у оператора дата-центра. Любой из подобных объектов подвержен влиянию внешних факторов — полностью исключить вариант аварии нельзя. Даже, казалось бы, самые защищенные объекты могут все же попасть в очень неприятную ситуацию, о чем мы как-то уже писали.

Соответственно, DRP-план (disaster-recovery plan) должен помочь компании быстро выйти на предшествующий аварии рабочий уровень. Обычно в таком плане описываются действия сотрудников в случае аварии. При составлении такого плана цель обычно — сведение к минимуму последствий аварии с обеспечением возможности вернуть контроль над решением критически важных задач, используя заранее определенные ресурсы. Но план — планом, а будет ли он работать? Для проверки этого стоит провести «учебную тревогу».

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

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

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

Как часто нужно проводить «учебные тревоги»?

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

Эксперты рекомендуют проводить проверку не реже раза в год.

Готовимся

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

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

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

Как тестировать

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

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

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

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

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

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

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

Что, если что-то пойдет не так?

Это, скорее всего, произойдет в той либо иной степени. Главное — стоит помнить, что гладко проверка такого уровня на все 100% пройти не может. Какие-то ошибки сотрудников и вмешательство неожиданных факторов обязательно повлияют на реализацию плана.

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

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

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

Кстати, интересно было бы узнать, подготовлена ли ваша компания к подобным проблемам, и если да, то как вы проверяете работоспособность составленного плана, и какие у него есть особенности?

• дата-центр
• drp—план
• хьюстон у нас проблемы

• Блог компании King Servers
• IT-инфраструктура
• Восстановление данных

BCP и DRP. Разница иногда не очевидна

Привет, хабр! Это скорее не статья-разъяснение, а статья-рассуждение о непрерывности и самая мякотка, надеюсь, будет в комментариях.

В силу того, что business continuity превратился в модный тренд, что-то вроде нанотехнологий, инноваций и импортозамещения, самое время определиться, что такое BCP и что такое DRP, в чем их разница и почему BCP и DRP как в том анекдоте «не муж и жена, а четыре совершенно разных человека».

BCP (business continuity plan) – план обеспечения непрерывности бизнеса. Содержит детальный план, что необходимо сделать для восстановления бизнес процессов.

DRP (disaster recovery plan) – план восстановления после катастрофы. Содержит детальный план по восстановлению инфраструктуры. Обычно имеется ввиду ИТ инфраструктура, но это могут быть самые разные механизмы, автотранспорт и здания.

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

DRP – это план про восстановление. Если сгорел склад, то есть запасной склад на такой случай. Если в ЦОД пришли маски-шоу, есть резервный ЦОД. Если сломался автомобиль – есть запасные части для ремонта. Или резервный автомобиль. В зависимости от требований бизнеса, о которых мы поговорим в другой статье.

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

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

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

BCP создается и тестируется совместно с представителями бизнеса. DRP создается и тестируется внутри ИТ подразделения.

Очень интересует мнение практиков, которые забороли путаницу в терминологии в непрерывности.

— * — требования бизнеса – это именно требования от бизнеса, а не размышления внутри ИТ департамента, как могли бы выглядеть бизнес требования.​

�� План аварийного восстановления (DRP)

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

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

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

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

Компания Gartner Group сообщает, что 40% предприятий, переживающих катастрофу, перестают функционировать в течение пяти лет после ее начала. Если есть желание остаться среди тех 60%, которые смогли выжить, стоит внедрить план DRP до начала катаклизмов, и следовать ему, если бедствие все же разразится.

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

К области обеспечения непрерывности деятельности относится несколько документов:

1. Первый из них — план управления в кризисной ситуации (Incident Management Plan, IMP), который задействуется в первые минуты после наступления чрезвычайной ситуации (куда бежать, кому звонить, где собираться и т.п.). Главная задача документа — в первую очередь сохранение жизни и здоровья людей, а затем и имущества организации.
2. Второй документ — план непрерывности бизнеса (Business Continuity Plan, BCP). В нем описываются пути продолжения функционирования организации в кризисных условиях, например, использование альтернативных площадей, обходных технологий, ручное выполнение операций и т. д. Главная задача — обеспечить выполнение обязательств организации перед клиентами и контрагентами, продолжить предоставление услуг и выпуск товаров.
3. Одной из составляющих задачи BCP является обеспечение непрерывности функционирования информационных и телекоммуникационных систем. Поскольку эти системы сегодня играют важнейшую роль в жизни большинства организаций, проблеме обеспечения непрерывности их работы посвящен отдельный, третий документ — план аварийного восстановления ИТ-систем (Disaster Recovery Plan, DRP).

Что бы обезопасить свой бизнес от проблем, связанных с отказом информационной системы фирмы, руководитель или другое ответственное лицо должны разработать и внедрить План Аварийного Восстановления (Disaster Recovery Planing сокр. DRP).
План аварийного восстановления на самом деле не является чем-то новым в нашей жизни. Он основан на действия, которые вы выполняем на ежедневной основе. Ведь именно от этих действий зависит обеспечение непрерывности бизнеса. Рассматривая эти действия, мы должны выработать меры, которые обеспечат непрерывность бизнеса.

Эти меры можно разделить на три основных класса:

1. смягчение последствий катастрофы — действие в результате которого мы уменьшаем количество затрат на восстановление;
2. предотвращения катастрофы — действие, направленное на избежание катастрофы;
3. переноса ответственности за катастрофу — смещение риска неконтролируемого события на третью сторону (например – страхование рисков).

Распространенное заблуждение в том, что DRP это универсальное руководство как действовать в случае землетрясения или наводнения. Это не цель DRP. Окончательный план аварийного восстановления будет состоять из серии небольших планов для решения конкретных вопросов (таких, как потеря охлаждения в дата-центре из за отключения энергии, или разрыв линий связи из за экскаватора, перерубившего кабель). Кроме того мы не собираемся писать руководство по ремонту системы охлаждения серверной или протягивать новые линии связи. План должен объяснить, что нужно проверить перед вызовом техника и действия, которые вы могли бы принять в раскаленном помещении, пока мы ждем специалиста по ремонту системы охлаждения.
Катастрофы происходят гораздо чаще, чем люди понимают. И мы не имеем в виду только глобальные катастрофы (землетрясения, цунами, террористические атаки,) Есть множество меньших катастроф, которые могут причинить такой же ущерб. Например такие банальные вещи, как ошибки программ, протечки воды в серверной, зараженные вирусом файлы, и т.д. Конечно, всегда можно положиться на «авось», но как бы не вышло что этот «авось» станет последним для вашего бизнеса.

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

DRP, обеспечивающий непрерывное функционирование бизнеса, предполагает следующие этапы:

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

По данным зарубежной печати средняя стоимость приведения в действие плана послеаварийного восстановления для каждого инцидента составляет $287,6 тыс. В Северной Америке средняя стоимость достигает $900 тыс. Во всем мире эта сумма наиболее велика для организаций, работающих в сфере здравоохранения и в сфере финансовых услуг. Так, в Северной Америке средняя стоимость простоев в финансовых учреждениях составляет $650 тыс. Это настораживает, если учесть, что каждое четвертое испытание оказывается неудачным, и только 93% организаций смогли привести свои планы послеаварийного восстановления в действие.

�� Похожие статьи на сайте

• Методологии управления проектами PM
• Основы управления проектами
• Диаграмма Ганта
• План аварийного восстановления (DRP)
• Как избежать ошибок при планировании
• PERT диаграмма
• История управления проектами

Disaster Recovery в облако: кому нужно и как его обеспечить

Рассказываем, кому стоит позаботиться об аварийном восстановлении инфраструктуры и какими способами можно реализовать DR.

Эта инструкция — часть курса «Начинаем работу с VMware».

Смотреть весь курс

Рассказываем, кому стоит позаботиться об аварийном восстановлении инфраструктуры и какими способами можно реализовать DR.

Что такое Disaster Recovery

Disaster Recovery, или аварийное восстановление, — это комплекс инструментов, обеспечивающих быстрое восстановление инфраструктуры, данных, работы всех систем в случае критических сбоев.

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

По сути, Disaster Recovery подразумевает резервную площадку для восстановления полного «клона» или части инфраструктуры компании. Чтобы отвечать требованиям DR, площадка должна:

→ быть географически удалена от основной (в таком случае ЧС, произошедшая в первом дата-центре, не затронет второй),

→ иметь хорошую сетевую связность с местом размещения инфраструктуры (чем выше пропускная способность канала, тем быстрее данные будут «добираться» до резервной площадки).

Способы организации DR

Disaster Recovery — концепция, которую можно реализовать разными способами.

Сделать самостоятельно на своей инфраструктуре (on-premises)

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

Построить Disaster Recovery на арендованных физических серверах

Сделать это можно за счет полного дубля инфраструктуры в концепции георепликации (размещения в другой географической точке). Такая реализация, впрочем, лишена гибкости — организация DR, как и внесение изменений в инфраструктуру, займет больше времени. Гибкости нет и в оплате резервной инфраструктуры — аренда минимум на месяц.

Развернуть Disaster Recovery в облако

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

Также очевидным преимуществом является модель оплаты pay-as-you-go — оплата за потребленные ресурсы, которую поддерживают облака. Если компании не нужна активная репликация инфраструктуры 24/7/365, она может экономить на ресурсах.

Disaster Recovery as a service

В качестве альтернативы самостоятельному созданию резервной площадки в облаке можно рассмотреть готовый сервис по DR. Помимо перехода на OPEX-модель, он облегчит такие задачи, как поиск и — самое главное — настройка инфраструктуры в концепции Disaster Recovery. Также клиент, как правило, получает дополнительные «плюшки» в виде консультации экспертов и SLA. У Selectel в этом списке также защита от DDoS-атак и соответствие 152-ФЗ.

Аварийное восстановление в облако

Пользуйтесь вычислительными ресурсами в облаке на базе VMware в Selectel в случае аварии на вашей основной площадке.

Характеристики Disaster Recovery

Основные характеристики, своеобразные метрики аварийного восстановления — это RPO (Recovery Point Objective) и RTO (Recovery Time Objective). В зависимости от их значений компания выбирает техническое решение, которое будет в основе Disaster Recovery.

RTO

Определяет максимальное время простоя, которое может позволить себе бизнес. Чем меньше этот показатель, тем незаметнее для конечного пользователя пройдет переключение на резервную площадку. Допустим, RTO установлен на 15 минут. В таком случае сервис начнет работать в штатном режиме не позже этого времени. В идеале — раньше.

Чем меньше RTO, тем больше это будет стоить бизнесу. Поскольку в реализации будут использовать более технологичные (и дорогие) решения, а резервную инфраструктуру нужно будет держать в состоянии active-active.

RPO

Определяет максимальный объем данных, который может позволить себе потерять компания в случае аварии и простоя. Чем меньше устанавливается показатель, тем чаще компания делает резервное копирование. Так, если RPO составляет 1 минуту, значит, резервная копия будет создаваться каждую минуту.

Все это также влияет на стоимость решения. Поэтому нет «золотых стандартов» RPO и RTO — каждая компания определяет эти показатели индивидуально. Обычно это консенсус между тем, что потеряет компания из-за простоя, и тем, что она потратит на достижение нужных метрик RPO и RTO.

Есть компании — например, крупные банки, чьи потенциальные репутационные и финансовые издержки в случае даунтайма всегда покроют затраты на организацию Disaster Recovery на высшем уровне. А есть бизнес, которому выгоднее «полежать», чем увеличивать чек за инфраструктуру.

Определение показателей RTO и RPO – это часть плана аварийного восстановления IT-систем (Disaster Recovery Plan, DRP). В идеале такой план должен быть у любой компании — вне зависимости от масштаба и специфики бизнеса. О нем мы еще напишем подробнее.

Всем ли нужен Disaster Recovery?

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

Крупный банк

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

Служба доставки еды

В районе ЦОД, где расположена инфраструктура сервиса, случился шатдаун. Пользователи не могут заказать продукты домой (допустим, сервис неудачно выбрал провайдера без ИБП и ДГУ). За час, ушедший на восстановление систем, несколько сотен клиентов не смогли выполнить свои заказы — финансовые убытки оцениваются в несколько сотен тысяч. Половина этих клиентов заказали доставку у конкурентов. Добила ситуацию потеря части данных о заказах клиентов — несколько десятков людей ждали свою пиццу в течение 4 часов. Еще один денежный транш ушел на сохранение лояльности клиентов.

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

Чем отличаются бэкапы от Disaster Recovery?

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

Гайд по репликации инфраструктуры в облако

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

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

1. Выберите провайдера. При выборе отталкивайтесь от того, где расположены дата-центры, на какие ресурсы в облаке вы можете рассчитывать, какая пропускная способность каналов связи и производительность инфраструктуры. Нелишним будет уточнить, есть ли тестовый период решений, сравнить цены на рынке, выяснить, подписывает ли провайдер соглашение об уровне услуг (SLA) с клиентом.

1. Выберите техническое решение. Как правило, провайдер предлагает несколько решений по организации Disaster Recovery с разными значениями RTO и RPO. Ознакомьтесь со всеми и выберите наиболее подходящее. Если сомневаетесь в выборе, хороший провайдер всегда подскажет решение.

1. Сформируйте план аварийного восстановления (DRP), если у вас его еще нет. Базово в нем должен быть прописан алгоритм действий в случае аварии: кому звонить, кого подключать, как распределяется ответственность за восстановление систем. Главная задача плана — исключить паническое накопление ошибок и неправильных действий в случае ЧС. В крупных компаниях в DRP прописывают даже порядок коммуникации со СМИ, чтобы отработать потенциальные риски.

1. Преднастройте сетевую инфраструктуру, NAT, межсетевые экраны. Инфраструктура — это не только набор серверов. Если вы быстро восстановили сервер БД, но при этом не связали его с веб-сервером, полноценно приложение работать не будет. Настройка сети требует много времени, поэтому откладывает ее на последний момент не стоит. К слову, часто в готовых DR-сервисах это можно настроить в интерфейсе.

1. Настройте техническое решение и DR для сервисов. Вне зависимости от выбранного решения (если это, конечно, не полная настройка DR под ключ) систему придется настраивать. Так, например, если вы выбрали Cloud Director Availability, нужно будет обеспечить управление инфраструктурой через плагин vSphere или Cloud Director. Опасаться этого пункта, впрочем, не нужно: если вы выбрали правильного провайдера, подробные инструкции по настройке вы найдете в его базе знаний.

1. Протестируйте работоспособность системы. Просто настроить и забыть — не вариант. Настроенный Disaster Recovery нужно протестировать, то есть искусственно устроить отказ инфраструктуры на основной площадке и реализовать тот самый план Б. Это ваш шанс найти слабые места в DRP и засечь время восстановления. Действительно ли оно соответствует желаемым метрикам RPO и RTO? В Selectel протестировать настроенную систему для решения можно бесплатно.

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

Технические решения для DR

Существует несколько технических решений, которые позволяют организовать аварийное восстановление в облако. Наиболее распространенные реализуются через Cloud Director Availability и Veeam Cloud Connect Replication (в связке с Veeam Backup & Replication). Эти решения предлагает и Selectel.

Cloud Director Availability

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

Особенности

• минимальный RPO – 5 минут,
• можно управлять и основной инфраструктурой, и репликациями в единой панели управления Cloud Director,
• при настройке сетей не нужно открывать дополнительные порты (достаточно порта TCP 443),
• есть подробная документация по настройке и видеодемонстрация настройки.

Кому подойдет

Решение более простое в настройке и не требует серьезной экспертизы. В среднем, развертывание системы занимает около 15 минут, но клиент должен иметь инфраструктуру в облаке VMware. Это может быть частное облако на собственной инфраструктуре, частное облако у другого провайдера, частное облако в Selectel. Подойдет компаниям, которые не хотят переплачивать за дополнительные лицензии.

Veeam Cloud Connect

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

Особенности

• минимальный PRO – 1 минута,
• необходимо иметь Veeam Backup & Replication (бесплатный Community Edition не подойдет, минимум — версия Standard, для сжатия трафика — Enterprise),
• тестировать настроенную систему придется вручную, автоматическое тестирование не поддерживается.

Кому подойдет

Решение больше подходит компаниям, которые уже использует платное ПО от Veeam в работе.

Если у вас остались вопросы по реализации Disaster Recovery для своего бизнеса, пишите на sales@selectel.ru.

Инструменты Veeam для резервного копирования — в чем разница?

Знакомство с публичным облаком на базе VMware в Selectel

Зарегистрируйтесь в панели управления

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