Для чего нужен резервный цод?

Особенности катастрофоустойчивости

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

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

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

Нередко к катастрофоустойчивости относят и такое понятие, как Disaster Recovery, или DT. Однако формально этот термин обозначает аварийное восстановление системы. Оно требуется для поддержания работоспособности корпоративной инфраструктуры после масштабного сбоя в работе.

Термин «катастрофоустойчивость» тесно связан с двумя факторами – RTO и RPO. Разберемся, что они обозначают:

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

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

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

Recovery time objective

Показатель связан с временем простоя, которое требуется на восстановление. Чем ниже показатель, тем быстрее проект начинает работать после сбоя и тем больше бизнес платит за это решение. Метрика отражает максимальное значение, то есть если RTO = 30 минут, инфраструктура этого проекта заработает не позднее, чем через полчаса.

Recovery point objective

Если время влияет на сервис, то от RPO зависят объемы потерянных данных в аварийных ситуациях. На практике это частота резервного копирования: чем меньше показатель, тем меньше актуальной информации вы потеряете

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

Универсального решения по определению уровня RPO и RTO — нет. Чтобы определить его, нужно оценить риски, опираясь на потребности проекта. Помогут следующие вопросы:

Как часто обновляются данные на сервере?
Сколько активных пользователей у сайта или приложения?
Какую сумму в минуту или в час (зависит от продукта) вы теряете при простое?

Перекрывает ли убытки увеличение расходов на инфраструктуру этого проекта?

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

Tier IV — максимальная отказоустойчивость

Допустимое время простоя за год – 26 минут
Показатель доступности – 99,995%
Резервирование – дублированное (2(N+1))
Уровень надежности – максимальный

Дата-центры Tier IV построены на инфраструктуре предшествующего уровня с добавлением концепции максимальной отказоустойчивости (Fault Tolerance). Это позволяет минимизировать любые простои в предоставлении услуг, будь то плановые работы или аварийный ремонт. На сегодняшний день это наивысший уровень надежности для центров обработки данных по классификации Uptime Institute.

Tier 4 включает в себя требования всех предыдущих стандартов. Главная отличительная черта ЦОД IV заключается в полном многоуровневом резервировании компонентов инфраструктуры. Все инженерные системы объекта резервируются по схеме 2 (N+1). Это означает, что помимо основной системы ЦОД, дублируются и все дополнительные по схеме N+1. Кроме того, в инфраструктуре применяется секционирование, при котором основные и резервные компоненты системы распределены по разным помещениям. Секционирование делает компоненты независимыми друг от друга, что повышает эксплуатационную надежность дата-центра при выходе одного из них (либо самого помещения) из строя. Объект 4 уровня должен использовать данный подход для организации всех критических систем ЦОД.

Главное, что нужно знать про ЦОД уровня Tier IV:

Объект предоставляет максимальные показатели отказоустойчивости на сегодняшний день. Все работы и ремонт происходят без прерывания услуг;
Система использует резервирование для каждого компонента, которые также дублируются;
Применение секционирования – физической изоляции компонентов инфраструктурных систем для независимой работы каждой из них;
Показатель безотказной работы составляет 99,995%.

Дата-центры уровня IV подойдут для организаций с критически важными сервисами, для которых непозволителен простой. На сегодняшний день в России дата-центры такого уровня находятся в зачаточном состоянии. Во-первых, строительство и реализация объекта данного класса стоит огромных средств, что обязательно скажется и на стоимости конечных услуг. Во-вторых, многие клиенты услуг ЦОД считают Tier IV избыточным решением для своего бизнеса. Тем не менее в мире немало сертифицированных Uptime Istitute дата-центров Tier 4, но пока превалируют именно объекты 3 уровня.

Какую роль в СБЭ играют ДГУ

«Грязное» городское электричество с нестабильным напряжением не подходит для питания критических нагрузок ЦОДа. Поэтому оно обязательно пропускается через ИБП, который выравнивает напряжение до нужного значения.

Но если городское электроснабжение пропадает, бразды правления по снабжению ЦОДа электричеством передаются ДГУ. Происходит это по следующему алгоритму:

ИБП фиксирует отсутствие электроэнергии на входе и автоматически переключается на питание от аккумуляторов.
Одновременно сбой отмечает АВР, ждет восстановления питания 5 секунд, после чего подает команду на запуск ДГУ. Для старта требуется 15–30 секунд.
После запуска генераторов АВР перекрывает основную линию и запускает резервную. На это уходит около 10 секунд, с этого момента электроснабжение ЦОДа осуществляется от ДГУ.
Питание восстанавливается, и ИБП переходят в штатный режим работы.

Когда городское электроснабжение возобновляется, ЦОД снова возвращается к классической схеме питания:

АВР отмечает наличие электричества и через 5 секунд отключается от ДГУ.
ИБП переключаются на питание от аккумуляторов.
АВР запускает основную линию и через 60 секунд подает команду на остановку ДГУ.

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

Infiniband

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

Существующие протоколы имеют известные недостатки. Так в Fibre Channel не предусмотрена маршрутизация, а передача данных через TCP/IP сопровождается большими накладными расходами и высокой задержкой передачи данных. Авторы Infiniband стремились сделать свой вариант сетевого соединения свободным от указанных недостатков.

Основные компоненты Infiniband показаны на .

Channel Adaptor — устройство, устанавливаемое в оборудование для связи по Infiniband; различают Host Channel Adaptor (HCA), который установлен в компьютере (т.н. Processor Node), и Target Channel Adaptor (TCA), обеспечивающий подключение к Infiniband систем хранения данных.
Коммутатор (switch) — объединяет устройства (HCA и TCA) внутри одной подсети (IB Subnet).
Маршрутизатор (router) — соединяет разные подсети Infiniband. Использование маршрутизации позволяет объединять в сети Infinband неограниченное количество узлов.

Рисунок 8. Компоненты Infiniband

Схема адресации в Infiniband позаимствована из IPv6.

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

Send — передать данные другому Channel Adaptor;
RDMA Write — записать данные в память другого Channel Adaptor;
RDMA Read — прочитать данные из памяти другого Channel Adaptor;
Atomic — записать в память другого Channel Adaptor 32-разрядное слово и вернуть предыдущее значение — используется в примитивах синхронизации.

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

Спецификация Infiniband составлена так, что в качестве основного канала связи используется канал 2.5 Gigabit/s — это так называемый однократный (1X) интерфейс. Объединение четырех линий связи 2.5 Gigabit/s составляет четырехкратный (4X) интерфейс с пропускной способностью 10 Gigabit/s, а объединение двенадцати линий 2.5 Gigabit/s — двенадцатикратный (12X) интерфейс с пропускной способностью 30 Gigabit/s.

Однократный и четырехкратный интерфейсы используются для соединения HCA и TCA к сети Infiniband, а двенадцатикратный — для соединения коммутаторов и маршрутизаторов.

Для работы четырехкратного интерфейса используются 4 пары оптоволокна, а для работы двенадцатикратного — 12. Таким образом, для связи площадок сетями Infiniband можно использовать существующие технологии для передачи сигналов 2.5 Gigabit (темная оптика, технологии спектрального уплотнения DWDM и CWDM).

Также в спецификации Infiniband предусмотрены решения по резервированию путей между устройствами Infiniband и решения по управлению пропускной способностью — объединение пропускной способности Channel Adaptors, установленных в одном узле, и ограничение пропускной способности Infiniband для разных приложений (QoS).

В настоящий момент Infiniband находится в том же состоянии, в котором Fibre Channel был в 2001 году — появляются промышленные решения на Infiniband у производителей серверов. Вполне вероятно, что следующее поколение серверов Sun, IBM и HP уже будет обладать встроенными HCA, а устройства хранения данных следующего поколения также будут поддерживать подключение по Infiniband в дополнение к Fibre Channel и iSCSI.

Какие методы используются для управления непрерывностью

Технически ITSCM представляет собой сочетание реактивных и проактивных мероприятий.

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

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

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

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

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

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

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

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

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

Немного теории: телекоммуникационный стандарт

Система электроснабжения ЦОДа должна отвечать главным требованиям – непрерывности, качеству, надежности. Как обеспечить соблюдение этих требований, изложено в стандарте TIA/EIA-942, на котором основаны российские нормы СН 512-78.

Минимальные требования для ЦОДов:

min рабочая нагрузка розеточной группы – 2,5 кВт;
min число розеток – двойной блок на каждые 4 метра;
наличие системы резервного питания (ИБП и дизель-генераторы);
единые нормы надежности электропитания для машинных залов и помещений с внешними коммуникациями.

В Приложении G.5 этого стандарта определены требования к электрооборудованию и организации системы электроснабжения. Основные моменты:

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

Для обеспечения отказоустойчивости к системе ИБП предъявляются следующие требования:

наличие индивидуального средства отключения каждого модуля;
наличие байпаса;
применение нескольких «линеек» аккумуляторов;
избыточность ИБП – запас не менее 20 % свыше требуемой удельной мощности.

Мощные ИБП структуры on-line с двойным преобразованием напряжения – базовый элемент архитектуры СБЭ современных дата-центров. Они создают оптимальные условия для работы подключенного к ним ИТ-оборудования в штатном режиме, а при отключении электропитания от города, обеспечивают автономное питание от аккумуляторов.

Облачный ЦОД

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

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

Почему важен план обеспечения непрерывности бизнеса?

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

Крайне важно иметь план BC, учитывающий любые возможные сбои в работе

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

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

Вам также может потребоваться план BC по юридическим или нормативным причинам

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

Основные элементы плана обеспечения непрерывности бизнеса

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

№1. Устойчивость

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

№ 2. Восстановление

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

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

№3. непредвиденные обстоятельства

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

Аварийное восстановление и непрерывность бизнеса

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

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

Подробнее о понятиях

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

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

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

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

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

Аренда выделенного
сервера

Разместим оборудование
в собственном дата-центре
уровня TIER III.

Конфигуратор сервера

Подбор оборудования для решения Ваших задач и экономии бюджета IT

Запросить КП

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

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

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

избежать потери важных для компании данных.

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

Tier III — параллельное техническое обслуживание

Допустимое время простоя за год – 1 час 36 минут
Показатель доступности – 99,982%
Резервирование – частичное (N+1 / 2N)
Уровень надежности – высокий

Дата-центр уровня Tier 3, пожалуй, самый распространенный на сегодняшний день. Это связано с потребностями современного бизнеса, который не готов мириться с простоями и потенциальными перебоями своих сервисов. Такие дата-центры обладают высокой степенью надежности, где резервируется все компоненты инфраструктуры. Объекты III включают в себя все компоненты предыдущего уровня в классификации Uptime Institute. Тем не менее разница между ними достаточно ощутима. Даже если смотреть на допустимое время простоя в год, то объект Tier 3 сокращает его на 92,7% (20 часов) по сравнению с предшествующим уровнем.

Для объекта уровня Tier III характерны:

Наличие дополнительных каналов электропитания по схеме резервирования N+1;
Использование промышленных систем охлаждения и кондиционирования с резервированием, а также систем контроля ТВР – температурно–влажностностного режима в серверных залах;
Присутствие ДГУ – дизель–генераторной установки на случай аварий энергосети;
Наличие нескольких независимых энерговводов;
Распределенное резервирование каналов связи;
Соответствие регламентам и применение инструкций при работе эксплуатационной команды дата-центра;
Наличие систем противопожарной безопасности: раннего оповещения, противодымной вентиляции, установок газового пожаротушения;
Использование фальшпола;
Присутствие промышленных ИБП в машинных залах;
Возможность проведения технических работ и обслуживания ЦОД без остановки;
Расположение ЦОД в отдельном здании с огороженной территорией;
Уровень безотказной работы Uptime – 99,982% в год.

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

Главное, что нужно знать про ЦОД уровня Tier III:

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

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

Что такое Disaster Recovery?

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

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

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

Что такое Disaster Recovery Plan

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

На каком этапе развития компании требуется DRP, сказать непросто. Можно сформулировать этот критерий следующим образом. Disaster Recovery Plan требуется компании, когда:

Остановка сервера/приложения или потеря базы данных влечёт за собой значительные финансовые, репутационные или иные потери;
В штате имеется полноценный IT-отдел со своим бюджетом;
Есть реальная возможность выделить средства на полноценное или хотя бы частичное резервирование на случай возникновения аварии.

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

Основная цель Disaster Recovery Plan: создание пошаговой инструкции с указанием времени на выполнение отдельных процедур. С помощью плана компания:

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

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

Целью DRP может являться:

Подготовка сотрудников

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

Сохранение работоспособности. Восстановление работы сервисов в короткий срок и сохранение данных.

PR-контакты

Правильное взаимодействие со СМИ, клиентами партнёрами в момент аварии играет важную роль.

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

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

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

Выводы

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

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

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

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