Репликация : предоставление нескольких одинаковых реализаций одной и той же системы или подсистемы, запросы выполняются параллельно

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

3. Разнообразие: предоставление нескольких различных реализаций одной и той же системы и использование их как реплицированная система.

Преимущества отказоустойчивой архитектуры очевидны, но имеются недостатки:

1. Проблемы в обнаружении ошибок в одном компоненте.

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

3. Уменьшение приоритета устранения ошибок. Знание о неисправности, при наличие отказоустойчивой системы, вероятно, уменьшит важность устранения неисправности.

4. Трудность тестирования.

5. Стоимость. Как отказоустойчивые компоненты, так и избыточные компоненты увеличивают стоимость конечной системы.

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

Отказоустойчивый кластер (HA, High-Availability cluster) состоит из группы серверов, которые могут быть надежно применены с минимальным временем бездействия благодаря аппаратной части. Они работают применяя программное обеспечение высокой доступности для использования избыточных компьютеров в группах или кластерах, которые предоставляют непрерывное обслуживание при сбое компонентов системы. Сбой сервера без кластеризации, с работающим конкретным приложением, аварийно завершает работу. Приложение будет в не рабочем состоянии в течение того времени, пока не рабочий сервер не будет починен и запущен заново. Кластеризация отказоустойчивого кластера нейтрализует эту проблему, определяя ошибки аппаратного и программного обеспечения и после этого перезапуская приложение в другой части кластера, без вмешательства администратора системы.

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

1) Простой способ запуска, остановки, принудительной остановки и проверки состояния приложения;

2) Приложение должно иметь возможность использовать сетевое хранилище (NAS или SAN);

3) Приложение должно сохранять как можно больше своих состояний на энергонезависимом хранилище;

4) При сбои и восстановление данных приложение не должно нарушать целостность последних;

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

Конфигурации иногда можно отнести к одной из следующих моделей:

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

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

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

4. N + M - В тех случаях, когда один кластер управляет несколькими службами, наличие только одного выделенного узла отказоустойчивости может не обеспечивать достаточную избыточность. В таких случаях включены и доступны несколько резервных серверов (M). Количество резервных серверов - это соотношение между требованиями к стоимости и надежности.

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

6. N-k-N - комбинация active / active и кластеров N + M, кластеры N-k-N перераспределяют службы, экземпляры или соединения из отказавшего узла среди оставшихся активных узлов, тем самым устраняя необходимость для «резервного» узла, но введя необходимость в дополнительной экземпляре для всех активных узлов.

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

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

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

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

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

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

Меры по управлению аварийным восстановлением ИТ разделяются на три типа:

1) Профилактические меры - меры контроля, предотвращающие возникновения события;

2) Меры обнаружения - средства контроля, обнаруживающие нежелательные события;

3) Корректирующие меры - средства контроля, исправляющие или восстанавливающие системы возникновения события;

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

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

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

Часть из наиболее распространенных стратегий защиты данных состоят из:

1. резервные копии, сделанные на диске

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

3. Частные облачные решения, реплицирующие данные управления (виртуальные машины, шаблоны и диски) в области хранения, являющиеся частью частной настройки.

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

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

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

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

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

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

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