Дизастер рекавери что это

Как избежать убытков от ИТ-сбоя: план по аварийному восстановлению

Об эксперте: Евгений Колбин, вице-президент «Сбера», генеральный директор SberCloud.

Ключевая практика борьбы с последствиями ИТ-сбоев — разработка и внедрение планов по аварийному восстановлению (Disaster Recovery Plan, DR-план), которые являются частью планов непрерывности бизнеса.

Хорошо продуманный DR-план позволяет предусмотреть и снизить последствия большинства ИТ-сбоев, включая:

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

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

Как и почему меняется Disaster Recovery сегодня

Основных причин изменения Disaster Recovery в сторону оптимизации самого процесса две:

DR становится дешевле

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

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

Экономия не сказывается на вопросах надежности и безопасности: облака обеспечивают более высокий уровень устойчивости ИТ-инфраструктуры и бизнес-приложений, чем корпоративные On-Premise системы.

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

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

DR становится быстрее

При критических сбоях компаниям необходимо действовать быстро. Сегодня рынок предлагает большое количество сервисов автоматизированного восстановления. Это высвобождает важные ресурсы (например, время сотрудников), которые можно направить на более приоритетные проекты. Облачные DR-системы также увеличивают скорость аварийного восстановления — с помощью облачного резервного ЦОДа можно не только в течение нескольких минут восстановить утерянные данные, но и развернуть на его мощностях резервную ИТ-инфраструктуру.

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

DR становится проще

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

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

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

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

Если сравнивать российские предприятия с западными, то отечественные компании только учатся непрерывности бизнеса. Закон о хранении персональных данных подстегнул российский рынок: сначала — хостинга, затем — облачных провайдеров. Провайдеры, в свою очередь, ринулись разрабатывать и внедрять как можно больше удобных решений и моделей работы для заказчиков. Такая сильная конкуренция за растущий рынок на руку клиентам: они получают разнообразные надежные сервисы по выгодной стоимости. Это касается и решений для Disaster Recovery, которые, будучи важной частью индустрии Cloud, продолжат развиваться и становиться удобнее.

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

Источник

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

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

Источник

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 — не забудьте учесть метеорит

Даже во время катастрофы всегда есть время на чашку чая

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

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

В этом посте я хочу поделиться рекомендациями, как надо писать DRP и что он должен содержать. А еще мы рассмотрим следующие штуки:

Для каких компаний это может быть полезно

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

Документация важна

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

После того, как у вас на руках есть хорошее описание компонентов сервиса, поднимите статистику по авариям. Почти наверняка они будут совершенно типовые. Например, у вас время от времени переполняется диск, что приводит к отказу ноды до ее ручной очистки. Или становится недоступен клиентский сервис из-за того, что кто-то опять забыл продлить сертификат, а Let’s Encrypt настроить не смог или не захотел.

Мысли как диверсант

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

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

После того, как типовые проблемы записаны, наливаем еще кофе и начинаем рассматривать самые странные сценарии, когда какие-то параметры начинают сильно выходить за пределы нормы. Например:

Что такое этот ваш DRP?!

Итак вы определили модель угроз. Учли и местных жителей, которые режут оптоволоконные кабели в поисках меди, и военный радар, который роняет радиорелейную линию строго по пятницам в 16:46. Теперь надо понять, что с этим всем делать.

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

В аварийной ситуации думать сложно! Должны быть простые инструкции для парсинга спинным мозгом.

Хороший DRP состоит из нескольких простых блоков:

Как правильно тестировать

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

Неправильно — «Зайдите на виртуализацию и ребутните мертвую ноду»
Правильно — «Подключитесь через веб-интерфейс к virt.example.com, в разделе ноды выполните перезагрузку ноды, которая вызывает ошибку».

Не допускайте двусмысленностей. Помните про испуганного стажера.

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

Ключевые пункты

Источник