Готовность к аварии: проверка отработки отказа Azure Site Recovery

В предыдущей статье здесь, в TechGenix, мы рассмотрели все шаги, необходимые для репликации рабочей нагрузки (в этой серии — простая виртуальная машина CentOS с веб-сервером Apache) в другой регион Azure. В этой статье мы собираемся протестировать и выполнить процесс отработки отказа, а также ознакомиться с возможностями и функциями, доступными с помощью Azure Site Recovery. Имейте в виду, что мы создаем процесс для запуска тестирования и аварийного переключения серверов, но это еще не все. Чтобы получить надежный и беспрепятственный процесс аварийного восстановления между регионами, нам придется работать с дополнительными функциями Azure, которые могут включать диспетчер трафика, модули Runbook и т. д.

Проверка сценария и существующей среды

Небольшое обновление для читателя: у нас есть эта простая среда, развернутая на нашем арендаторе. Мы собираемся настроить виртуальную машину Linux для запуска веб-сервера и выполнения теста и полного аварийного переключения.

Это были шаги, которые мы выполнили на сервере Linux, чтобы полностью исправить сервер и запустить веб-сервер. Мы создали простую страницу , чтобы показать Интернету, что сервер запущен и работает.

sudo yum update sudo yum install httpd sudo vi /var/www/html/index.html sudo systemctl status httpd sudo systemctl start httpd

В приведенном ниже примере мы можем видеть последние две команды выше, где мы проверяли состояние службы и запускали ее позже. Виртуальная машина была настроена с общедоступным IP-адресом и параметром DNS (vm001.canadacentral.cloudapp.azure.com — если вы не знаете, как это сделать, мы рассмотрели эту удобную функцию в этой записи блога здесь).

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

Использование портала аварийного восстановления

Существует несколько способов управления возможностями аварийного переключения с защищенной виртуальной машины. Самый простой способ — перейти к свойствам виртуальной машины, а затем к аварийному восстановлению. Мы также можем найти ту же панель мониторинга, перейдя в Azure Site Recovery на портале Azure. Щелкните Реплицированные элементы и выберите одну из доступных репликаций. Оба варианта появятся на панели инструментов, показанной на изображении ниже.

Эта информационная панель предоставит практически всю информацию для управления процессом отработки отказа. В пункте 1 у нас есть возможность инициировать процессы Failover или Test Failover. В пункте 2 мы можем проверить состояние репликации и RPO (целевую точку восстановления).

В пункте 3 у нас есть варианты проверки свойств репликации на нескольких уровнях: «Свойства», «Вычисления и сеть» и «Диски». У нас также есть возможность проверить Последние точки восстановления (пункт 4), что принесет новый блейд со списком всех доступных точек восстановления. Эти точки восстановления будут указаны как устойчивые к сбоям или приложениям.

У нас есть две области для перечисления всех и , которые находятся на расстоянии одного клика от администратора для получения необходимой информации.

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

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

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

Чтобы начать новую тестовую отработку отказа, нажмите Test Failover, а на новом блейде нам нужно выбрать точку восстановления и виртуальную сеть Azure и нажать OK.

Процесс может занять несколько минут, и результатом будет новая виртуальная машина, работающая в целевом местоположении (в нашем случае: восток США).

Обе виртуальные машины работают одновременно, и некоторые элементы необходимо решить в новой виртуальной машине, а именно:

• NSG не реплицируется, а только виртуальные машины, поэтому нам нужно связать или создать одну и ту же NSG и применить ее к виртуальной сети сайта аварийного восстановления.
• Общедоступный IP-адрес не реплицируется на новую виртуальную машину, и мы должны создать новый и назначить его соответствующим образом.
• Репликации DNS-имени нет, и мы можем связать новое имя для тестирования.
• Убедитесь, что служба запущена и работает на отказоустойчивой виртуальной машине, как только завершится .

На всякий случай после назначения общедоступного IP-адреса отказоустойчивой виртуальной машине мы отредактировали файл и добавили некоторую информацию в конец тестовой страницы ( ).

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

При выборе «Очистка тестовой отработки отказа » нам нужно объяснить процесс, и есть флажок для очистки виртуальных машин, который удалит все ресурсы.

Если мы выберем Disable Replication, то виртуальная машина будет сохранена, но репликация будет удалена из Azure Site Recovery.

Создание плана аварийного восстановления

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

Чтобы создать план восстановления, который будет использоваться во время отработки отказа, щелкните элемент Планы восстановления (Восстановление сайта) при проверке основного блейда Azure Site Recovery. Назначьте имя (исходное и целевое и выберите виртуальные машины, которые будут частью этого плана), нажмите OK.

При управлении планом восстановления администратор облака может добавлять задачи и связывать эти задачи с модулями Runbook, связанными с учетной записью службы автоматизации Azure. Мы можем выполнить тестовую отработку отказа, используя .

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

Выполнение аварийного переключения

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

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

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

Проверка процесса Azure Site Recovery

Общий вопрос заключается в том, чтобы узнать, что происходит с Azure Site Recovery, и в колонке Azure Site Recovery есть множество вариантов.

Первый — это задания по восстановлению сайта, которые будут отображать все выполненные задания с их статусом. Администратор облака может проверить каждое из заданий, чтобы получить более подробную информацию, загрузив электронную таблицу Excel со сводкой задания. Мы также можем использовать события восстановления сайта, чтобы увидеть события, связанные с Azure Site Recovery, в частности. Другой вариант — настроить уведомление по электронной почте от того же блейда.