DR-учения у трёх клиентов: двое уложились в SLA, один - нет

Тайские наводнения ударили не только по производству HDD - они здорово встряхнули IT-директоров в компаниях, которые вроде бы и не связаны с Таиландом никак. У нескольких клиентов в октябре прошли экстренные встречи по теме BCP: «а что у нас с планом восстановления после катастрофы?». Мы в таких случаях обычно отвечаем: «давайте проверим» - и предлагаем провести учения.

В ноябре провели плановые DR-тесты у троих. Результат получился показательным: двое уложились в согласованный SLA, один - нет. Рассказываем, как это было.

Как устроены учения

Сценарий одинаковый для всех трёх: полная потеря основной площадки. Инициируем её условно - просто перестаём трогать боевую инфраструктуру и работаем только с резервной. Задача команды: поднять критичные сервисы на резервной площадке из Veeam-бэкапов и довести их до состояния «пользователи могут работать».

Фиксируем время от объявления старта до подтверждения работоспособности каждого сервиса. Это и есть реальный RTO - не тот, что написан в договоре, а тот, что получается на практике.

Veeam Backup & Replication 5 используем у всех троих - описывали его подробнее в посте про дедупликацию бэкапов. На резервных площадках у каждого - один-два ESXi-хоста, куда идут реплики или откуда разворачиваются бэкапы.

Клиент А: всё по плану

Небольшая компания, 15 ВМ, критичных из них - пять: контроллер домена, почта на Exchange, 1С, файловый сервер, веб-сайт. SLA на восстановление - 4 часа.

Резервная площадка настроена через Veeam Replication: реплики критичных ВМ обновляются каждые 2 часа. На учениях достаточно было зайти в Veeam Console на резервной площадке и включить реплики. Единственный затык - забыли сменить IP-адреса контроллера домена в настройках реплики, пришлось делать вручную уже после запуска. Съело лишние 20 минут.

Итого: все пять сервисов подняты за 2 часа 10 минут. В SLA уложились с запасом.

Клиент Б: уложились, но нервно

Компания покрупнее - около 40 ВМ, из них критичных 12. Здесь реплик нет: восстановление идёт из бэкапов на NAS через Instant VM Recovery. SLA - 6 часов.

Учения показали два неожиданных места. Первое: NAS на резервной площадке оказался примонтирован к ESXi-хосту через NFS, и при попытке запустить Instant VM Recovery выяснилось, что версия ESXi на резервнике не совпадает с основной (4.0 против 4.1 на боевом). Несколько ВМ запустились со скрипом и предупреждениями. Разобрались, потеряли около часа.

Второе: план восстановления описывал порядок подъёма сервисов, но не описывал зависимости между ними. Поднять SQL раньше контроллера домена - и авторизация не работает, приложение висит с ошибками. Восстановили правильный порядок эмпирически, потратив ещё минут сорок.

Итого: уложились в 5 часов 40 минут. В SLA попали, но без документированного порядка подъёма ещё немного - и не попали бы.

Клиент В: за SLA вышли

Это самый сложный случай. Среда смешанная: часть ВМ на VMware, часть сервисов на физических серверах - старый файловый сервер и специфическое ПО, которое «не виртуализируется». SLA на восстановление критичных сервисов - 4 часа.

Физика сразу создала проблему. Бэкап физических серверов - через Veeam Endpoint Protection, восстановление идёт на резервное железо. Резервного железа с нужными характеристиками на площадке не оказалось: стоял один сервер, но с другой конфигурацией сетевых карт. Veeam восстановил образ, но сеть после загрузки не поднялась - пришлось вручную разбираться с драйверами. Это съело полтора часа только на одну машину.

ВМ-ки восстановились нормально, но без физики общая картина не складывалась - зависящие от физического сервера сервисы не работали.

Итого: критичные сервисы в полном составе заработали через 5 часов 50 минут. За SLA вышли почти на два часа.

Что из этого следует

Реплики быстрее бэкапов. Это очевидно, но учения подтвердили разницу конкретными цифрами: клиент с репликами восстановился в два раза быстрее клиента с Instant VM Recovery, хотя у второго объём ВМ был в три раза больше.

Порядок подъёма сервисов - отдельный документ. Не «восстановить сервисы», а «сначала DC, потом DNS, потом SQL, потом приложение» с указанием зависимостей. Без этого команда теряет время на эмпирику в стрессовых условиях.

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

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

С клиентом В договорились на повторные учения через квартал - после того как приведём резервную площадку в порядок. С остальными двумя - раз в год, как и планировали.

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