Практическая работа по Site Recovery. Часть 6 — Использование Site Recovery

В прошлых статьях я завершил описание процедуры установки и настройки решения для аварийного восстановления виртуальных машин между сайтами с использованием Citrix StorageLink Site Recovery. На последнем шаге мы создали аварийный план восстановления и активировали его. Убедились в том, что защищаемая виртуальная машина реплицируется между двумя сайтами.

Тестирование плана аварийного восстановления

Для тестирования работы нашего аварийного плана восстановления запустим консоль StorageLink Manager на сервере вторичного сайта CitSea. В закладке Site Recovery мы видим Contoso Recovery Plan в дереве Imported Recovery Plans, - поскольку создавали данный план мы в первичном сайте.

В меню Action мы можем провести тестирование, выбрав опцию «Test Recovery Plan». Согласимся с предупреждением:

Консоль выдаст информацию, что начался процесс тестирования плана восстановления:

За прогрессом, как обычно, мы можем проследить в закладке Jobs:

По завершению процесса в закладке Site Recovery мы увидим, что появилась тестовая копия нашей защищаемой инфраструктуры (в случае моего лабораторного сценария – одна виртуальная машина):

В консоли HP StorageWorks P4000 Centralized Management Console можно увидеть, что диски виртуальной машины являются снимном (snapshot) её состояния с хранилища в основном сайте в Редмноде:

В консоли Hyper-V Manager мы также видим копию защищаемой виртуальной машины с постфиксомп «_Test» в имени:

Если вы реализовывали сценарий на реальных серверах, то сможете включить её и посмотреть, что проверка её работоспособности не затронет работы самой машины в основном сайте. В моём случае узлы Hyper-V являются виртуальными машинами, так что запустить на них другие машины я не могу.

Удаление результатов тестирования

Когда я убедился, что виртуальная машина корректно реплицируется и запускается в изолированной сети вторичного сайта, я захочу удалить её копию оттуда. Для этого в консоли StorageLink Manager следует выбрать действие Destroy Test Recovery Plan.

Аварийный перенос виртуальных машин

Тестирование это замечательно, и я надеюсь, что в вашем случае в реальной среде всё ограничится ежемесячным тестированием. Однако, если катастрофа таки произойдёт, вам потребуется осуществить реальный перенос нагрузки в резервный ЦОД. Уже без копий, снимков и изолированных сетей. Для этого в консоли StorageLink Manager существует действие Failover Recovery Plan. Выполним его, согласившись с предупреждением:

По окончанию процесса мы увидим, что теперь аварийный план находится в состоянии Failed-over в дереве Recovery Plans, вместо Imported Recovery Plans. Ведь аварийный план восстановления теперь активен во вторичном сайте:

Обратим внимание, в консоли HP StorageWorks P4000 Centralized Management Console диски теперь представлены в несколько другом виде:

Сервер CitSea теперь напрямую использует диски с массива, а не снимки с реплики первичного сайта:

В консоли Hyper-V Manager мы видим виртуальную машину уже без постфикса «_Test»:

Вы можете запустить виртуальную машину, проверить, как работает ОС и сервисы в ней. Если ваш план восстановления включает несколько виртуальных машин, имеющих зависимости друг от друга, то выполнив действие Start Recovery Plan, вы инициируете запуск машин в том порядке, как вы это настроили при создании плана. В отличие от решения конкурента, которое поблочно реплицирует тома массива с файлами виртуальных машин, Site Recovery использует VSS, что гарантирует вам целостность данных ОС и всех прикладных сервисов, имеющих свой компонент записи VSS, например Exchange, SQL, Oracle и так далее. Когда ваш основной сайт вновь станет работать нормально, вы можете вернуть все машины, выполнив действие Activate for Failback и проведя сам Failback.

На этом я заканчиваю цикл статей, описывающих пошаговый процесс установки и настройки Site Recovery for Hyper-V. Надеюсь, что этот лабораторный сценарий будет вам полезен. Поговорим о Site Recovery через месяц после Microsoft Management Summit. У меня есть масса приятных новостей!