Репликация ресурсов с помощью репликатора подписки Azure Stack Hub

Статья
12/01/2023

Сценарий PowerShell репликатора подписки Azure Stack Hub можно использовать для копирования ресурсов между подписками Azure Stack Hub, метками Azure Stack Hub или между Azure Stack Hub и Azure. Сценарий репликатора считывает и перестраивает ресурсы Azure Resource Manager из разных подписок Azure и Azure Stack Hub. В этой статье мы рассмотрим, как работает сценарий, как его можно использовать, а также рекомендации для операций в сценарии.

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

Общие сведения о репликаторе подписок

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

Основной процессор состоит из следующих трех сценариев:

resource_retriever.ps1
- Создает папки для хранения выходных файлов.
- Задает контекст для исходной подписки.
- Извлекает ресурсы и передает их в resource_processor. ps1.
resource_processor.ps1
- Обрабатывает ресурс, переданный в resource_retriever. ps1.
- Определяет, какой настраиваемый процессор использовать, и передает ресурсы туда.
post_process.ps1
- Запись обрабатывает результаты, генерируемые настраиваемым процессором, для подготовки их к развертыванию в целевой подписке.
- Создает код развертывания для развертывания ресурсов в целевой подписке.

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

Пользовательские процессоры, упомянутые выше, являются файлами ps1, определяющими способ обработки определенного типа ресурсов. Имя настраиваемого процессора всегда создается с использованием типа данных ресурса. Например, если $vm содержит объект виртуальной машины, запуск $vm.Type приостановит Microsoft.Compute/virtualMachines. Это означает, что процессор для виртуальной машины будет называться virtualMachines_processor.ps1, имя должно быть точно таким же, как и в метаданных ресурса, поскольку именно так основной процессор определяет, какой именно процессор следует использовать.

Настроенный процессор предопределяет способ репликации ресурса, определяя, какие данные важны и как их следует извлекать из метаданных ресурса. Затем настроенный процессор принимает все извлеченные данные и использует их для создания файла параметров, который будет использоваться вместе с шаблоном Azure Resource Manager для развертывания ресурса в целевой подписке. Этот файл параметров хранится в Parameter_Files после того, как он повторно обрабатывается с помощью post_process.ps1.

В структуре файлов репликатора имеется папка с именем Standardized_ARM_Templates. В зависимости от исходной среды, развертывания будут использовать один из этих стандартных шаблонов Azure Resource Manager, или придется создать настраиваемый шаблон Azure Resource Manager. В этом случае настраиваемый процессор должен вызвать генератор шаблонов Azure Resource Manager. В приведенном ранее примере имя генератора шаблонов Azure Resource Manager для виртуальных машин будет называться virtualMachines_ARM_Template_Generator.ps1. Генератор шаблонов Azure Resource Manager отвечает за создание настраиваемого шаблона Azure Resource Manager в зависимости от того, какие сведения находятся в метаданных ресурса. Например, если ресурс виртуальной машины содержит метаданные, указывающие, что он является членом группы доступности, генератор шаблонов Azure Resource Manager создаст шаблон Azure Resource Manager с кодом, задающим идентификатор группы доступности, частью которой является виртуальная машина. Таким образом, при развертывании виртуальной машины в новой подписке она автоматически добавляется в группу доступности после развертывания. Эти настраиваемые шаблоны Azure Resource Manager хранятся в папке Custom_ARM_Templates, расположенной в папке Standardized_ARM_Templates. post_processor.ps1 отвечает за определение типа шаблона для развертывания (стандартизированный или настроенный шаблон Azure Resource Manager) и генерирование соответствующего кода развертывания.

Сценарий post-process.ps1 отвечает за очистку файлов параметров и создание сценариев, которые пользователь будет использовать для развертывания новых ресурсов. На этапе очистки сценарий заменяет все ссылки на идентификатор подписки источника, идентификатор арендатора и местоположение на соответствующие целевые значения. Затем файл параметров выводится в папку Parameter_Files. Затем он определяет, использует ли обрабатываемый ресурс настраиваемый шаблон Resource Manager Azure, и создает соответствующий код развертывания, который использует командлет New-AzResourceGroupDeployment. После код развертывания добавляется в файл с именем DeployResources.ps1, хранящийся в папке Deployment_Files. Наконец, сценарий определяет группу ресурсов, к которой принадлежит ресурс, и проверяет сценарий DeployResourceGroups.ps1, чтобы убедиться, что код развертывания для развертывания этой группы ресурсов уже существует. Если нет, то он добавит код к этому сценарию, чтобы развернуть группу ресурсов.

Динамическое извлечение API

Инструмент имеет встроенное динамическое извлечение API, поэтому для развертывания ресурсов в целевой подписке используется новейшая версия API поставщика ресурсов, доступная в исходной подписке:

Рис. Извлечение API

Рис. Извлечение API из resource_processor. ps1.

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

Параллельное развертывание

Для этого средства требуется параметр с именем parallel. Этот параметр принимает логическое значение, указывающее, следует ли развертывать извлеченные ресурсы параллельно. Если задано значение true, то каждый вызов Командлета New-AzResourceGroupDeployment будет иметь флаг -asJob , а блоки кода, ожидая завершения параллельных заданий, будут добавляться между наборами развертываний ресурсов на основе типов ресурсов. Это гарантирует, что все ресурсы одного типа были развернуты до развертывания следующего типа ресурса. Если для параметра parallel задано значение false, все ресурсы будут развернуты последовательно.

Добавление дополнительных типов ресурсов

Добавить новые типы ресурсов очень просто. Разработчик должен создать настраиваемый процессор и либо шаблон Azure Resource Manager, либо генератор шаблонов Azure Resource Manager. После этого разработчику нужно добавить тип ресурса в ValidateSet для параметра $resourceType и массив $resourceTypes в "Resource_retriever.ps1". Добавление типа ресурса в массив $resourceTypes нужно выполнять в правильном порядке. Порядок массива определяет порядок, в котором будут развернуты ресурсы, поэтому следует учитывать зависимости. Наконец, если настроенный процессор использует генератор шаблонов Azure Resource Manager, он должен добавить имя типа ресурса в массив $customTypes в post_process.ps1.

Выполнение репликатора подписки Azure

Для запуска средства "репликатор подписки Azure" (v3) необходимо запустить "resource_retriever.ps1", указав все параметры. Параметр resourceType позволяет выбрать все, а не один тип ресурса. Если выбрано Все, то "resource_retriever.ps1" будет обрабатывать все ресурсы по порядку, чтобы при развертывании сначала выполнялось развертывание зависимых ресурсов. Например, виртуальные сети развертываются перед виртуальными машинами, поскольку для их правильного развертывания требуется наличие виртуальной сети.

Когда выполнение сценария будет завершено, появятся три новые папки: Deployment_Files, Parameter_Files и Custom_ARM_Templates.

Примечание

Перед запуском любого из созданных сценариев необходимо задать правильную среду, войти в целевую подписку (например, в новом Azure Stack Hub) и указать в качестве рабочего каталога папку Deployment_Files.

"Deployment_Files" будет содержать два файла DeployResourceGroups.ps1 и DeployResources.ps1. Запуск "DeployResourceGroups.ps1" приведет к развертыванию группы ресурсов. При запуске "DeployResources.ps1" будут развернуты все обработанные ресурсы. В случае, если инструмент был выполнен с использованием Все или Microsoft.Compute/virtualMachines в качестве типа ресурса, "DeployResources.ps1" попросит пользователя ввести пароль администратора виртуальной машины, который будет использоваться для создания всех виртуальных машин.

Пример

Выполните скрипт.

Примечание

Не забудьте настроить исходную среду и контекст подписки для экземпляра PS.
Проверьте только что созданные папки:
Задайте контекст для целевой подписки, измените папку на Deployment_Files и разверните группы ресурсов (выполните скрипт DeployResourceGroups.ps1). Затем запустите развертывание ресурсов (выполните скрипт DeployResources.ps1).
Запустите Get-Job, чтобы проверить состояние. Get-Job | Receive-Job возвратит результаты.

Очистка

Внутри папки "replicatorV3" находится файл под названием cleanup_generated_items.ps1. Он удалит папки Deployment_Files, Parameter_Files и Custom_ARM_Templates и все их содержимое.

Операции репликатора подписки

Репликатор подписки Azure (версия 3) в настоящее время может реплицировать следующие типы ресурсов:

Microsoft.Compute/availabilitySets
Microsoft.Compute/virtualMachines
Microsoft.Network/loadBalancers
Microsoft.Network/networkSecurityGroups
Microsoft.Network/publicIPAddresses
Microsoft.Network/routeTables
Microsoft.Network/virtualNetworks
Microsoft.Network/virtualNetworkGateways
Microsoft.Storage/storageAccounts

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

Microsoft.Network/virtualNetworks
- Реплицирует: — все адресные пространства — все подсети
Microsoft.Network/virtualNetworkGateways
- Репликация: — конфигурация общедоступного IP-адреса — конфигурация подсети — тип VPN — тип шлюза.
Microsoft.Network/routeTables
Microsoft.Network/networkSecurityGroups
- Реплицирует: — все правила безопасности для входящего и исходящего трафика.
Microsoft.Network/publicIPAddresses
Microsoft.Network/loadBalancers
- Репликация: — частные IP-адреса — конфигурация общедоступного IP-адреса — конфигурация подсети.
Microsoft.Compute/availabilitySets
- Реплицирует: — количество доменов сбоя — количество доменов обновления.
Microsoft.Storage/storageAccounts
Microsoft.Compute/virtualMachines
- Реплицирует:
  – диски данных (без данных);
  – размер виртуальной машины;
  – операционную систему;
  – диагностику настройки учетной записи хранения;
  – конфигурацию общедоступных IP-адресов;
  – сетевой интерфейс;
  – частные IP-адреса сетевого интерфейса;
  – настройку группы безопасности сети;
  – настройку группы доступности.

Примечание

Создаются управляемые диски только для дисков ОС и дисков данных. В настоящее время использование учетных записей хранения не поддерживается.

Ограничения

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

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

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

Дальнейшие действия

Сети Azure Stack Hub: различия и рекомендации