Клонирование сред Azure с помощью службы автоматизации Azure.

Опубликовано: 1 Марта, 2023

Один из моих клиентов попросил процедуру клонирования сред Azure. Среда — это группа ресурсов с несколькими виртуальными машинами Windows. Поскольку я не впервые вижу подобные запросы, я хотел бы поделиться сценарием с использованием службы автоматизации Azure, который может помочь облачным администраторам, которые могут столкнуться с той же проблемой. (Чтобы обновить эту статью со сценарием для клонирования только одной виртуальной машины, перейдите сюда.)

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

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

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

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

Создайте новую группу ресурсов для клонированной среды, добавив префикс _<CloneName>_Bubble.
Создайте новую виртуальную сеть и структуру подсети в целевом объекте. Мы скопируем все соглашения об именах и настройки IP из исходной виртуальной сети.
Создайте моментальный снимок всех дисков ВМ в исходной группе ресурсов и создайте управляемые диски в целевой группе ресурсов.
Создайте новые виртуальные машины, используя информацию из исходных виртуальных машин. Подключите новые управляемые диски к новым виртуальным машинам.

Процесс сценария начался с нескольких функций в PowerShell, большого количества проверок и тестов в различных типах сред. Когда было достигнуто хорошее рабочее состояние, мы поняли, что среда (среда и группы ресурсов будут использоваться в этой статье взаимозаменяемо) может иметь от нескольких до 50 виртуальных машин.

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

Из-за этого нового требования мы представили на рисунке рабочие процессы PowerShell, которые поддерживаются в службе автоматизации Azure и позволяют выполнять задачи параллельно с некоторыми оговорками.

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

Скрипт: Проверка среды

Сценарий проверит несколько элементов в среде, прежде чем перейти к созданию виртуальной сети и виртуальных машин. Эти следующие условия будут проверены как часть процесса. Если они есть, то скрипт не будет выполняться и потребуется ручная очистка.

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

Использование рабочих процессов PowerShell

При использовании рабочего процесса PowerShell есть некоторые преимущества, такие как многопоточность (параллельность) и возможность создания контрольных точек, что позволяет возобновить рабочий процесс. Но есть также некоторые предостережения при использовании рабочих процессов PowerShell, и мы рассмотрим некоторые из них в отдельной статье здесь, в TechGenix.

Вам может быть интересно, как служба автоматизации Azure различает рабочие процессы и обычные сценарии PowerShell. Рабочий процесс PowerShell имеет другую структуру, как указано ниже.

Рабочий процесс <Глагол-Noum> { <код скрипта, включая параметры> }

Весь код рабочих процессов PowerShell выполняется в Windows Workflow Foundation. Единственное исключение — когда мы используем InlineScript, который выполняет код в нашей традиционной Windows PowerShell.

Действие InlineScript может извлекать информацию из рабочего процесса, ссылаясь на переменные в следующем формате $Using:<VariableName>, что помогает передавать значения между рабочим процессом и обычной оболочкой PowerShell.

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

Вот как макет действия InlineScript использовался в нашем скрипте до того, как мы достигли этапа подготовки клонированных виртуальных машин.

$tControl = InlineScript { Область функций Область тела сценария $tControl #--> последняя строка блока для возврата значения переменной в рабочем процессе }

Примечание. Функции, созданные в области рабочего процесса, нельзя использовать в InlineScript. Мы должны объявить функцию в блоке InlineScript, и именно поэтому вы видите одну и ту же функцию в коде дважды.

Мы также установили для переменной предпочтения $PSRunInProcessPreference значение $True в начале скрипта, и тем самым заставляем все действия выполняться в одном и том же процессе. Для получения дополнительной информации о переменных предпочтений можно использовать следующую ссылку.

Функции

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

VMInventory($VMName): эта функция получит имя виртуальной машины и создаст массив со всей информацией, относящейся к виртуальной машине, включая диски, размер виртуальной машины и информацию о сети. Используйте эту функцию, чтобы добавить любую дополнительную информацию, которая может вам понадобиться, из исходной виртуальной машины.
VMSnapshot($vmInfo,$HashTable): он получит массив, содержащий информацию о виртуальной машине, и массив со всей информацией об окружении. Он создаст моментальные снимки существующих виртуальных машин в целевой группе ресурсов.
VMRestoreSnap($vminfo,$HashTable): она получит ту же информацию из предыдущей функции и создаст управляемые диски всех моментальных снимков, созданных в целевой группе ресурсов.
CloneVM($VMInfo,$HashTable): последняя часть головоломки, она соберет всю информацию о виртуальной машине, объединит ее с совершенно новыми управляемыми дисками и создаст новую виртуальную машину, подключенную к клонированной виртуальной сети и подсети.

Основная часть скрипта

Здесь мы достигаем цели многопоточности и можем запускать несколько экземпляров клонирования виртуальных машин, используя переключатель -Parallel в операторе . По моим наблюдениям, при использовании службы автоматизации Azure оптимальное значение составляло около шести экземпляров одновременно, и для соответствующего регулирования количества экземпляров мы использовали переключатель -ThrottleLimit.

ForEach -Parallel -ThrottleLimit 6 ($vm в $VM) {

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

Клонирование сред Azure: подведение итогов

Цель этой статьи — продемонстрировать, как использовать автоматизацию Azure с рабочими процессами PowerShell для клонирования сред Azure.

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

Есть несколько вещей, о которых вы должны знать при создании текущего скрипта клонирования:

Мы не принимаем во внимание другие распространенные ресурсы, которые могут легко стать частью вашего приложения/среды, такие как балансировщики нагрузки, шлюзы приложений Azure, хранилища ключей, учетные записи хранения и т. д.
Мы не берем все свойства ВМ: диагностику загрузки, IP-адреса и расширения. Мы просто следим за тем, чтобы у нас был одинаковый размер ВМ, одинаковые диски и ОС (в нашем случае только Windows).
При создании виртуальных машин Windows используется параметр для использования существующих лицензий. (Возможно, это не подходит для вашей подписки.)
Мы не тестировали сценарий на виртуальных машинах Linux и зашифрованных дисках.
Если в этой «пузырьковой» сети требуются ваши контроллеры домена или любая вспомогательная система, ваш скрипт должен иметь возможность клонировать их как часть процесса.
В этой новой виртуальной сети нет подключения, и я рекомендую использовать службу Azure Bastion, чтобы разрешить доступ к этой среде.