Выпускная квалификационная работа. Разработка методологии автоматического аварийного восстановления гибридной инфраструктуры в Microsoft Azure (стр. 4 )

 

Рисунок 5

Для связи локальной и облачной инфраструктур используется VPN соединение (Site-To-Site). На стороне Azure развернут виртуальный шлюз, а локально – физический. Для репликации используется служба Azure Site Recovery. Далее будет подробнее рассмотрена система ее работы.

Для того чтобы автоматизировать восстановление серверов используется инструмент Azure Automation, который содержит в себе так называемые Runbook’и, которые содержат код на языке Powershell и различные настройки для этих скриптов.

Azure Site Recovery

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

Аварийное восстановление в облаке. Можно реплицировать рабочие нагрузки виртуальных машин и физических серверов в Azure, а не на вторичный сайт. Это позволит сократить затраты и отказаться от обременительного обслуживания дополнительного центра обработки данных. Гибкая репликация для гибридных сред. Можно реплицировать любые рабочие нагрузки, выполняющиеся на поддерживаемых локальных виртуальных машинах Hyper-V, виртуальных машинах VMware и физических серверах под управлением Windows и Linux. Миграция. С помощью Site Recovery можно переносить локальные экземпляры AWS на виртуальные машины Azure или переносить виртуальные машины Azure из одного региона Azure в другой. Упрощенное обеспечение непрерывности бизнеса и аварийное восстановление. Можно развернуть репликацию из одного расположения на портале Azure. При сбое одного или нескольких компьютеров можно выполнить простые операции отработки отказа и восстановления размещения. Отказоустойчивость. Site Recovery управляет репликацией и отработкой отказа, не мешая передаче данных приложений. Реплицированные данные хранятся в отказоустойчивой службе хранилища Azure. При отработке отказа виртуальные машины Azure создаются на основе реплицированных данных. Производительность репликации. Частота репликации, обеспечиваемая службой Site Recovery для Hyper-V, составляет всего 30 секунд. Для VMware поддерживается непрерывная репликация. Вы можете задать пороговые значения целевой точки восстановления (RPO), чтобы управлять частотой создания точек восстановления данных, и можете уменьшить целевое время восстановления (RTO) благодаря автоматизированному процессу восстановления Site Recovery и интеграции с диспетчером трафика Azure. Согласованность на уровне приложений. Компьютеры реплицируются с использованием моментальных снимков, согласованных на уровне приложений. В моментальных снимках, согласованных на уровне приложений, сохраняются не только данные, хранящиеся на диске, но и все данные в памяти и все выполняемые транзакции. Тестирование без прерывания работы. Можно легко выполнять тестовые отработки отказа в рамках учений по аварийному восстановлению, не затрагивая на рабочие среды. Гибкие отработка отказа и восстановление. Можно запускать плановые отработки отказа без потери данных при ожидаемых простоях, а также внеплановые отработки отказа с минимальной потерей данных (в зависимости от частоты репликации) на случай непредвиденных аварий. Вы можете легко восстановить размещение на первичном сайте, как только он снова станет доступен. Пользовательские планы восстановления. Планы восстановления позволяют моделировать и настраивать процедуры отработки отказа и восстановления многоуровневых приложений, которые распределены между несколькими виртуальными машинами. В планах можно упорядочивать группы и добавлять сценарии и ручные действия. Планы восстановления можно интегрировать с модулями Runbook службы автоматизации Azure. Многоуровневые приложения. Можно создать планы восстановления для последовательной отработки отказа и восстановления многоуровневых приложений. В плане восстановления можно сгруппировать компьютеры, размещенные на различных уровнях (например, база данных, Интернет, приложение), и настроить отработку отказа и запуск для каждой такой группы. Интеграция с имеющимися технологиями BCDR. Служба Site Recovery успешно интегрируется с другими технологиями BCDR. Например, можно использовать Site Recovery для защиты серверной части SQL Server корпоративных рабочих нагрузок, включая встроенную поддержку для SQL Server AlwaysOn для управления отработкой отказа групп доступности. Интеграция с библиотекой службы автоматизации. Обширная библиотека службы автоматизации Azure содержит готовые к работе и учитывающие особенности приложений сценарии, которые можно скачать и интегрировать с Site Recovery. Простое управление сетью. Дополнительные функции управления сетью в Site Recovery и Azure упрощают сетевые требования к приложениям, включая резервирование IP-адресов, настройку балансировщиков нагрузки и интеграцию диспетчера трафика Azure для эффективного переключения сетей.

Как работает данная служба?

Для работы со службой ASR необходимо следующее:

Учетная запись Azure Подписка Azure Сеть Azure Конфигурационный сервер, который используется для управления обменом данными между локальным источником и Azure, а также репликацией данных. Сервер обработки. Выступает в качестве шлюза репликации. Получает данные репликации, оптимизирует их путем кэширования, сжатия и шифрования и отправляет эти данные в службу хранилища Azure.
Сервер обработки также обеспечивает принудительную установку службы Mobility Service на защищенные компьютеры и выполняет автоматическое обнаружение виртуальных машин VMware. Главный целевой сервер. Обрабатывает данные репликации при восстановлении размещения с переносом из Azure. Сервера VMWare или физические сервера для репликации

На рисунке 6 хорошо показана схема работы службы Azure Site Recovery, где СО – это сервер обработки, СК – сервер конфигурации, ГЦС – главный целевой сервер. Все эти серверные роли могут стоять на одной виртуальной машине (или физическом сервере).

Рисунок 6

На следующем рисунке отражена схема конкретно данной работы с именами серверов.

Рисунок 7

Автоматизация восстановления

Далее будет рассмотрена система автоматического восстановления инфраструктуры. Следует учитывать, что нижеописанная система применима как для облачной инфраструктуры, так и для локальной. Для удобства разделим ее на 3 части:

Восстановление инфраструктуры (кроме виртуальных машин) Восстановление отдельных серверов в исходном ЦОД Восстановление всех серверов в новом ЦОД

Рассмотрим подробнее каждую из них.

Восстановление инфраструктуры (без виртуальных машин)

Для того чтобы восстановить всю инфраструктуру Azure нам необходимо каким-то образом хранить ее в отдельном файле или составить документ LLD5. К счастью, Azure предлагает использовать шаблоны, которые в формате JSON могут хранить всю информацию о существующей инфраструктуре. Также Azure может использовать такого типа файлы для создания инфраструктуры с нуля. Таким образом, мы можем выгружать всю информацию об инфраструктуре с некоторой периодичностью и получать самую актуальную информацию о существующей инфраструктуре.

Для этой цели был написан скрипт, который выгружает JSON файл конфигурации и хранит его в другом ЦОД. Выгрузка файла происходит на сервере, который располагается в дополнительном ЦОД. Вот алгоритм работы по выгрузке:

Подключение к ресурсам Azure через Powershell Экспортирование всех ресурсов, находящихся в Azure в виде JSON файлов Импорт файлов в дополнительное расположение (ЦОД) для дальнейшего хранения

При возникновении необходимости развернуть инфраструктуру заново нужно будет использовать этот JSON файл и инструмент Azure для развертывания инфраструктуры через файл конфигурации (JSON Template). Так как этот файл содержит в себе всю инфраструктуру, из него необходимо удалить такие ресурсы, как виртуальные машины и сетевые интерфейсы, для того чтобы такие же ресурсы не развернулись в новой локации. JSON файл, упомянутый в Приложении 1, изменен уже для разворачивания в новой локации (новом ЦОД).

Восстановление отдельных серверов в исходном ЦОД

Может возникнуть такая ситуация, при которой окажутся недоступными отдельные сервера в инфраструктуре. Чтобы быстро восстановить каждый из них, была разработана система автоматического восстановления серверов. Схема работы данной системы показана ниже на рисунке 8.

 

Рисунок 8

Данная система подразумевает, что не весь ЦОД оказался недоступным, а лишь отдельные сервера, которые можно автоматически восстановить, причем в параллельном режиме. Для этого используется описанный выше инструмент – Azure Automation.

Схема работы следующая:

Служба Automation с определенной периодичностью запускает скрипт6, который проверяет (например, 5 мин) доступность всех серверов в ЦОД с помощью PowerShell командлета (Test-Connection) в параллельном режиме. Если после трех проверок какие-то сервера остаются недоступны, скрипт перезапускает эти виртуальные машины. Если после следующих трех проверок сервера все еще недоступны, то происходит операция Redeploy. Данная операция подразумевает под собой пересоздание виртуальной машины на другом физическом хосте в ЦОД Azure. Если после следующих трех проверок сервера все еще недоступны, то скрипт оповещает инженера о данной проблеме, который должен принять решение о дальнейших действиях. В частности, принимается решение о пересоздании виртуальной машины с тех же виртуальных дисков в том же регионе.

Восстановление всех серверов в новом ЦОД

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