Дизастэ Рикавери своими руками

С марта собирался написать про это.

«Дешевое» решение

После одного из европейских VMUG (VMware User Groups – когда собираются те, кто не равнодушен к технологиям виртуализации от VMware и делятся опытом) появились скрипты, как самому сделать DR для сервисов в виртуальной инфраструктуре VMware.

Первоисточник с презентацией тут. 

Состав:

1. Площадки с развернутой VMware vSphere – 2 штуки
2. СХД с репликацией между ними – 2 штуки
3. ВМ – в ассортименте
4. скрипты Power Shell (вот прямая ссылка) – 1 набор
5. голова и руки – по вкусу

Готовка:

1. Система хранения данных (СХД) с возможностью получения реплик от СХД основной площадки
2. Настроить репликацию средствами СХД дисковых LUNов, содержащих ВМ
3. Создать дополнительные атрибуты ВМ
4. Сохранить информацию по ВМ в файлы .cvs
5. Установить vCenter
6. Доставить .cvs-файлы в резервный ЦОД.

Хотя, по заявлению автора, хосты ESX еще не требуются, я бы установил хотя бы один ESXi и ВМ с vCenter + ВМ с vCenter AutoDeploy для развертывания ESXi (новый функционал в vSphere 5)

Использование:

В случае пришествия Годзиллы на основную площадку (помните, в SimCity был такой disaster? :)), или при тестировании:

1. Выключить основной сайт

1. С помощью скрипта “reverse boot priority” (последовательность обратная загрузке)

2. Включить ESXi в резервном ЦОДе
3. (пере)подключить СХД
4. Запустить vCenter, подключить к нему ESX-ы
5. Активировать кластер DRS, установить его в «Fully Automated»
6. Запустить остальные скрипты восстановления в последовательности:

1. Скрипт поиск по LUNам и регистрация ВМ
2. Скрипты импортирования:

1. Атрибутов
2. Ресурс-пулов
3. Папок
4. Ролей и прав на объекты vCenter

3. Скрипты перемещения ВМ в папки и ресурсные пулы
4. Запуск ВМ в определенной последовательности

7. Пойти курить (в случае если это не тестирование – самое время начать курить :) ШУТКА!). DRS отработает, и распределит ВМ по ESX-ам в кластере
8. Проверить загруженные ВМ на их работоспособность.

Что с этим делать дальше?

В принципе, все почти готово.

Однако эти скрипты только могут помочь технической составляющей DR-решения. Они не учитывают многих факторов для реального DRP.

Но и по технической составляющей есть замечания.

Использование СХД с репликацией уже подразумевает недешевое решение. Хотя, как вариант, если в основном ЦОДе используется iSCSI в качестве продуктивной системы хранения, то возможно использовать StarWind с их репликацией.

Я вижу еще одну альтернативу. Veeam Backup & Replication! (а куда вы от него денетесь? ;)). Это значительно упростит схему, автоматизирует, и уменьшит стоимость как CAPEX, так и OPEX [вы не знаете этих слов? Написать про это?].

Разворачиваем решение (опишу схематично):

1. Разворачиваем Veeam Backup & Replication (VBR). В v5 версии есть два варианта расположения сервера:

1. на основной площадке. При этом необходимо защитить и реплицировать базу данных VBR
2. на резервной площадке. В случае катастрофы на основной площадке, и “живой” резервной сервер будет также живым.

2. На резервном сайте устанавливаем любую подходящую СХД, без привязки к тому, что стоит в основном ЦОДе.
3. Устанавливаем на резервном сайте ESXi. Один ставим, остальные в уме – но необходимо сразу запланировать минимально достаточное количество ESX серверов, и лучше все же их тоже развернуть (уже знаем про AutoDeploy в vSphere 5), если только вы точно не знаете, когда произойдет катастрофа в продуктивном ЦОДе.
4. Устанавливаем и настраиваем vCenter: строим инфраструктуру ресурсных пулов, папок и т.д. Включаем кластер DRS.
5. Если вы планируете на этом сайте держать контроллеры доменов AD, я бы посоветовал еще установить 1 ВМ в качестве DC.
6. Настраиваем репликацию ВМ на резервную площадку. Напомню, что в VBRv5 не обязательно создавать первоначальную полную реплику всех ВМ через тонкий канал связи WAN. VBR позволяет перевезти копии на съемных носителях, а потом настроить репликацию (в выходящей скоро v6 кое-что в этом плане еще улучшится)
7. Далее работаем со скриптами:

1. От импорта-экспорта, как в вышеописанном варианте, можно почти отказаться: по большей части это статические редко меняющиеся настройки; первоначально на этапе 3 мы уже настроили инфраструктуру. Желательно периодически перегонять роли и права, особенно если используется доменная аутентификация к виртуальной инфраструктуре.
2. Создаем cvs-файл со списком ВМ в последовательности необходимой для загрузки.
3. Пишем скрипты на PowerShell (напомню тем, кто не знает, у Veeam Backup есть свой набор комманд-лет) по последовательному запуску реплик ВМ, указанных в cvs-файле. Желательно написать два скрипта: один для тестирования, второй для запуска DR site в случае если что.

8. Следим за логами репликации (достаточно просто настроить оповещения на e-mail). Периодически тестируем решение.

Для тестирования необходимо, чтобы скрипт умел делать:

1. выключать задания на репликацию
2. создаваться снапшоты всех реплик
3. изолировать сеть с внешней стороны – то есть не дать возможность мешать работы основным работающим ВМ
4. запускать ВМ в последовательности, прописанной в cvs

После тестирования необходимо:

1. выключить ВМ
2. возвратить реплики в предыдущее состояние до запуска (не удалять снапшоты, а возвращать к ним!)
3. возвращать сеть в исходное состояние
4. включить репликацию

Вот, собственно пример скрипта, проверяющего работоспособность реплик VBR, предлагаю взять его за основу.

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

Вторая причина – скоро выходит Veeam Backup & Replication v6, в котором появится много интересного касательно репликации, еще расширится и дополнится PowerShell (скрипты от VBRv5 скорее всего останутся совместимыми).