Перенос виртуальной сети Azure из классической среды в Resource Manager с помощью Azure PowerShell
В этой статье вы узнаете, как перейти от классической модели развертывания к новой модели развертывания Resource Manager.
Миграция из классической в Resource Manager выполняется одновременно по одной виртуальной сети. Дополнительных требований для инструментов или предварительных условий для миграции нет, кроме требований Azure PowerShell. Миграция — это миграция уровня управления для ресурса виртуальной сети. Во время миграции не существует простоя пути к данным. Существующие рабочие нагрузки будут продолжать функционировать без потери подключения во время миграции. Любые общедоступные IP-адреса, связанные с виртуальной сетью, не изменяются во время миграции.
После завершения миграции все операции управления должны выполняться с помощью модели Resource Manager. Операции управления доступны только с помощью модели развертывания Resource Manager. Изменения в подсети или ресурсе виртуальной сети больше не будут доступны с помощью старой модели развертывания.
При переносе виртуальной сети из классической в модель Resource Manager поддерживаемые ресурсы в виртуальной сети автоматически переносятся в новую модель.
Необходимые условия
- Учетная запись Azure с активной подпиской. Создайте бесплатно.
- Действия и примеры, описанные в этой статье, используют модуль Azure PowerShell Az. Чтобы установить модули Az локально на вашем компьютере, см. Установить Azure PowerShell. Дополнительные сведения о новом модуле Az см. в статье Знакомство с новым модулем Azure PowerShell Az. Командлеты PowerShell часто обновляются. Если вы не используете последнюю версию, значения, указанные в инструкциях, могут не работать корректно. Чтобы найти установленные версии PowerShell в системе, используйте командлет Get-Module -ListAvailable Az.
- Чтобы перенести виртуальную сеть с шлюзом приложений, удалите шлюз перед запуском операции подготовки для перемещения сети. После завершения миграции повторно подключите шлюз в Azure Resource Manager.
- Убедитесь, что на вашем компьютере установлены классические и Az модули Azure PowerShell. Дополнительные сведения см. в статье Установка и настройкаAzure PowerShell.
- Шлюзы Azure ExpressRoute, подключающиеся к каналам ExpressRoute в другой подписке, не могут быть перенесены автоматически. В этих случаях удалите шлюз ExpressRoute, перенесите виртуальную сеть и повторно создайте шлюз.
Поддерживаемые сценарии
Для классической миграции с Resource Manager поддерживаются следующие сценарии:
Классические виртуальные сети, содержащие виртуальные машины.
Классические виртуальные сети не более чем с одним набором доступности для каждой облачной службы.
Классические виртуальные сети, содержащие доменные службы Microsoft Entra.
Классические виртуальные сети с одним VPN-шлюзом или одним каналом Express Route.
Неподдерживаемые сценарии
Следующие сценарии не поддерживаются для миграции:
Управление жизненным циклом виртуальной сети из классической модели развертывания.
Поддержка управления доступом на основе ролей Azure для классической модели развертывания.
Миграция виртуальной сети с помощью шлюза ExpressRoute и VPN-шлюза.
Миграция виртуальных сетей с несколькими группами доступности в одной облачной службе.
Миграция виртуальных сетей с одной или несколькими группами доступности и виртуальными машинами, которые не включены в группу доступности, в рамках одной облачной службы.
Миграция шлюза приложений с классической модели на Resource Manager.
Регистрация поставщика ресурсов
В этом разделе вы войдете в свою подписку, используя командлеты Resource Manager, и зарегистрируете поставщика ресурсов миграции.
Войдите в Azure PowerShell:
Connect-AzAccount
Зарегистрируйте поставщика ресурсов миграции:
Register-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
Подождите пять минут, пока регистрация завершится. Проверьте состояние регистрации с помощью следующей команды:
Get-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
Убедитесь, что RegistrationState
Registered
, прежде чем продолжить.Заметка
Регистрация — это однократный шаг, но перед попыткой миграции необходимо сделать это один раз. Без регистрации вы увидите следующее сообщение об ошибке:
BadRequest: подписка не зарегистрирована для миграции.
Получение имени виртуальной сети для переноса
В этом разделе вы войдите в классическую модель развертывания PowerShell и получите имя виртуальной сети, которую необходимо перенести.
Выполните вход в устаревшую среду развертывания PowerShell.
Add-AzureAccount
Выполните следующую команду, чтобы получить имя классической виртуальной сети:
Get-AzureVnetSite | Select -Property Name
Запишите имя виртуальной сети для следующего раздела.
Перенос виртуальной сети
В этом разделе вы проверите, что миграция может быть выполнена, а затем подготовите её.
Поместите имя виртуальной сети, которую вы указали в предыдущем разделе, в переменную для использования командами. Замените myVNet именем виртуальной сети, полученной в предыдущем разделе:
$vnetname = "myVNet"
Проверьте, можно ли перенести виртуальную сеть, выполнив следующую команду:
Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName
Команда отобразит все предупреждения или ошибки, которые блокируют миграцию. Если проверка выполнена успешно, выполните следующий шаг подготовки.
Заметка
Если виртуальная сеть содержит веб-роли или рабочие роли или виртуальные машины с неподдерживаемых конфигураций, вы получите сообщение об ошибке проверки.
Выполните следующую команду, чтобы подготовить виртуальную сеть к миграции:
Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName
Если вы не готовы к миграции и хотите вернуться в старое состояние, используйте следующую команду:
Move-AzureVirtualNetwork -Abort -VirtualNetworkName $vnetName
Завершить миграцию
Если все выглядит хорошо в подготовленной конфигурации, можно зафиксировать миграцию, выполнив следующую команду:
Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName
Дальнейшие действия
Дополнительные сведения о переносе ресурсов в Azure из классической модели в Resource Manager см. в следующем разделе: