meta data for this page
2022-12-11 Какими качествами должно обладать хорошее руководство аварийного восстановления?
Данный документ регламентирует порядок действий которые должен предпринять персонал в процессе возникновения проблемы для снижения последствий в краткосрочной перспективе и возможно включать в себя план по восстановлению целевого состояния системы.
Процесс восстановления в случае аварии должен опираться на используемые в текущем решении технологии обеспечения отказоустойчивости и высокой доступности. Например если речь идет о дисковой подсистеме то в состав данных технологий будут входить:
- RAID массив для защиты от выхода из строя дисков;
- Дублирование основных компонентов, отвечающих за предоставление доступа к данным;
- Дублирование каналов связи до клиента;
- Мгновенные снимки для защиты от изменений;
- Удаленная репликация для защиты от аппаратного сбоя;
- Резервирование площадки путем создания метрокластера;
За счет описанных выше технологий достигается достаточно высокий уровень надёжности подсистемы в целом, например производитель систем хранения данных уровня HiEnd - Hitachi Vantara заявляет что СХД VSP способны обеспечить 100% доступность данных (при построении территориально распределенных решений), а большинство производителей СХД среднего уровня прогнозирует отказоустойчивость своих систем на уровне “пять девяток”
| Доступность % | Время простоя в год | Время простоя в месяц | Время простоя в неделю |
|---|---|---|---|
| 90% (“одна девятка”) | 36.5 дней | 72 часов | 16.8 часов |
| 95% | 18.25 дней | 36 часов | 8.4 часов |
| 98% | 7.30 дней | 14.4 часов | 3.36 часов |
| 99% (“две девятки”) | 3.65 дней | 7.20 часов | 1.68 часов |
| 99.5% | 1.83 дней | 3.60 часов | 50.4 минут |
| 99.8% | 17.52 часов | 86.23 минут | 20.16 минут |
| 99.9% (“три девятки”) | 8.76 часов | 43.2 минут | 10.1 минут |
| 99.95% | 4.38 часов | 21.56 минут | 5.04 минут |
| 99.99% (“четыре девятки”) | 52.56 минут | 4.32 минут | 1.01 минут |
| 99.999% (“пять девяток”) | 5.26 минут | 25.9 секунд | 6.05 секунд |
| 99.9999% (“шесть девяток”) | 31.5 секунд | 2.59 секунд | 0.605 секунд |
Если мы касаемся технологий восстановления в случае аварии на площадке с учетом потери площадки целиком то приблизительное время восстановления напрямую зависит от применяемых технологий и уровня автоматизации.
- Метрокластер - минуты;
- Кластер с ручным переключением (напр. VMware SRM) - часы;
- Репликация данных без кластера - дни;
Руководство аварийного восстановления должно в первую очередь служить цели регламентирования действий в случае обнаружения аварии и первичном реагировании для скорейшего восстановления работоспособности системы и строиться на базе используемых в проекте технологий обеспечения высокой доступности. С целью составления такого плана необходимо составить список технологий, которые обеспечивают высокую доступность и по каждой из них подготовить план действий в случае обнаружения аварии. Вторым методом можно предложить подход, основанный на анализе рисков. Необходимо составить перечень возможных аварийных ситуаций которые могут произойти с проектируемой системой и по каждой из них подготовить план действий по снижению последствий т.е. план реагирования. Стоит ли готовить планы реагирования на безвыходные ситуации, например выход единственной площадки из строя - вопрос открытый.
Качественное руководство должно включать в себя не только описание действий в момент аварии но и список операций для восстановления системы в исходное состояние. Например если мы говорим о репликации на уровне дискового массива - в списке действий во время аварии будут:
- Приостановка репликационной пары;
- Включение доступа на запись для slave тома;
- Монтирование slave тома в ОС;
- Запуск систем;
После устранения последствий аварии и в данном примере после восстановления исходной системы хранения важно выполнить все операции в нужном порядке. Например если просто включить репликацию - система которая была главной до сбоя уничтожит все наработанные данные на резервной площадке. Поэтому например план восстановления в исходное состояние будет включать:
- Разворот репликационной пары;
- Ожидание полной синхронизации изменений на основную площадку;
- Начало окна простоя;
- Остановка сервисов на резервной площадке;
- Разворот репликационной пары в оригинальном направлении;
- Запуск сервисов на основной плоащке;
- Конец окна простоя.
Последовательность действий по восстановлению к исходному состоянию является не менее важной процедурой в плане аварийного восстановления и в отличие от плана аварийного реагирования на сбой должна присутствовать для каждого проектируемого сбоя.