Disaster Recovery vs High Availability
Business continuity (непрерывность выполнения бизнес-задач) — один из самых популярных запросов при построении инфраструктуры. Для того, чтобы ее обеспечить, используются два основных подхода: High Availability и Disaster Recovery. Мы постарались рассмотреть оба подхода и показать преимущества и контекст применения каждого. Отказоустойчивость (High Availability) позволяет продолжать выполнение бизнес-задач при выходе из строя какого-либо компонента инфраструктуры. Катастрофоустойчивость […]
Business continuity (непрерывность выполнения бизнес-задач) — один из самых популярных запросов при построении инфраструктуры. Для того, чтобы ее обеспечить, используются два основных подхода: High Availability и Disaster Recovery. Мы постарались рассмотреть оба подхода и показать преимущества и контекст применения каждого.
Отказоустойчивость (High Availability) позволяет продолжать выполнение бизнес-задач при выходе из строя какого-либо компонента инфраструктуры.
Катастрофоустойчивость (Disaster Recovery) же позволяет продолжать выполнение бизнес-задач при выходе из строя ЦОД целиком, например, из-за отключения электричества на длительное время, пожара или любого иного масштабного природного явления.
Итоговый выбор зависит от типа задач, с которыми нужно будет работать.
Рассмотрим основные моменты:
| Отказоустойчивость High Availability | Катастрофоустойчивость Disaster Recovery |
|---|---|
|
|
Услуги по обеспечению непрерывности весьма востребованы, так как в любых технически сложных системах аварии неизбежны.
В финансовом секторе и промышленном производстве к высокому спросу подталкивают требования обеспечения непрерывности бизнеса, накладываемые регуляторами. В остальных сегментах, например, для торговых сетей, построение отказоустойчивых инфраструктур или их аренда (как в ЦОД, так и облачных провайдеров) объясняется растущей конкуренцией.
Для обеспечения непрерывности бизнеса (Business Continuity) необходимо подготовить два плана:
- BCP (Business Continuity Plan) – план обеспечения непрерывности бизнеса с детальным описанием того, что необходимо сделать для восстановления бизнес-процессов.
- DRP (Disaster Recovery Plan) – план восстановления после катастрофы с описанием действий по восстановлению инфраструктуры. Обычно подразумевается IT-инфраструктура, но это могут быть также и самые разные механизмы, автотранспорт и здания.
При выходе из строя офисного здания, сгорания склада или поломки автомобиля DRP будет описывать как оперативно запустить новое офисное здание, открыть запасной склад или использовать запасные части для ремонта автомобиля.
BCP же будет описывать, как организовать удаленную работу сотрудников, перенаправить поступающие товары на новый склад или вызвать такси.
Оба плана должны разрабатываться, исходя из требований бизнеса, и использоваться сразу после возникновения аварии. В них должны содержаться протестированные наборы инструкций и список ответственных, которые эти инструкции должны выполнить.
Технологии резервирования
Непрерывность бизнеса подразумевает использование резервной площадки под инфраструктуру. Речь при этом идет не про резервное копирование данных на сервер в соседней стойке или в облако, хотя и это, несомненно, очень важно. В случае форс-мажора необходимо иметь запасную площадку, на которой можно будет развернуть необходимые для поддержания работы мощности, при этом не упустив драгоценное время на поиск, сборку и подключение необходимого оборудования.
Выделяют три вида резервов:
Холодный резерв
Некое серверное помещение с запасным оборудованием. В «сценарии катастрофы» может планироваться закупка либо хранение оборудования на складе.
Следует помнить, что большая часть оборудования поставляется под заказ и оперативно ввести в работу десятки единиц серверов, СХД, коммутаторов представляется маловероятным.
Помимо склада с оборудованием можно предусмотреть хранение наиболее важного или редкого оборудования на складах поставщиков, например, с предварительно проведенными телекоммуникационными каналами в помещении. Восстановление работы в таком ЦОД при катастрофическом сбое основной площадки может растянуться на несколько недель. При выборе такого варианта убедитесь, что ваша компания сможет просуществовать эти несколько недель без ощутимых финансовых потерь.
Теплый резерв
Существующая функционирующая дополнительная площадка, для которой настроены интернет и WAN-каналы, базовая телекоммуникационная и вычислительная инфраструктура. Основное оборудование должно быть подключено и всегда готово к переводу нагрузки.
Такая площадка «слабее» основной по вычислительным мощностям, некоторое оборудование может отсутствовать, но важно, чтобы на площадке всегда была актуальная резервная копия данных. Для запуска такой системы требуется не более одного дня. Данный вариант в настоящее время является весьма популярным решением из-за соотношения цена-качество, а также приемлемого времени ввода в эксплуатацию.
Горячий резерв
Серверная площадка с оборудованием, производительность которого соответствует оборудованию основной площадки, а все данные основной площадки регулярно реплицируются. Такая площадка с готовой инфраструктура, настроенными каналами и актуальными версиями программного обеспечения запускается в пределах установленного RTO.
Минус как горячего, так и теплого резерва – простой оборудования. Одним из решений может стать решение использовать две площадки равномерно – большинство приложений могут работать как на одной, так и на другой. При использовании мощности всего оборудования можно обеспечить балансировку нагрузки, например, на одно из приложений при ожидаемом пике.
Отказоустойчивость
Под «Отказоустойчивостью» понимается свойство системы сохранять работоспособность в случае случайного выхода из строя или сбоя отдельных компонентов. Критерий надежности может определятся количеством «девяток после запятой»:
| Доступность | Downtime в год | Downtime в месяц | Downtime в день |
|---|---|---|---|
| 99.9% | 8,77 часов | 43,83 минут | 1,44 минуты |
| 99.99% | 52,60 минут | 4,38 минут | 8,64 секунды |
| 99.999% | 5,26 минут | 26,30 секунд | 86,00 миллисекунд |
Как измеряется High Availability
Процент доступности рассчитывается следующим образом:
доступность = (минуты в месяце — минуты простоя) * 100 / минут в месяц
Поставщик услуг обычно предоставляет показатели доступности в своих соглашениях об уровне обслуживания (SLA). При этом обслуживание системы и запланированное время простоя являются неотъемлемой частью этого соглашения. Если в SLA заявлено 99,999%, конечный пользователь может ожидать, что услуга будет недоступна в течение следующих промежутков времени:
| Временной период | Время недоступности системы |
|---|---|
| День | 0,9 секунд |
| Неделя | 6,0 секунд |
| Месяц | 26,3 секунд |
| Год | 5 минут и 15,6 секунд |
Если провайдер услуг придерживается стандарта «три девятки» (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-инфраструктур и будем рады поделиться нашей собственной экспертизой. Задавайте любые интересующие вопросы в комментариях, а также наших социальных сетях: ВКонтакте, Телеграме и Твиттере.
Полезные статьи и материалы по теме:
