Техническое руководство по поддерживаемому платформой переносу из классической модели в модель Azure Resource Manager

Область применения: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows

Важно!

Сегодня примерно на 90 % виртуальных машин IaaS используется служба Azure Resource Manager. По состоянию на 28 февраля 2020 г. классические виртуальные машины устарели и будут полностью прекращены 6 сентября 2023 г. Узнайте больше об этом устаревании и о том, как оно влияет на вас.

Давайте подробно рассмотрим миграцию из классической модели развертывания Azure в модель развертывания с помощью Azure Resource Manager. Мы рассмотрим ресурсы на уровне ресурсов и функций. Это поможет вам понять, как платформа Azure переносит ресурсы между двумя моделями развертывания. Чтобы получить дополнительную информацию, прочтите статью с объявлением о выпуске службы Поддерживаемый платформой перенос ресурсов IaaS из классической модели в модель Azure Resource Manager.

Перенос ресурсов IaaS из классической модели развертывания в модель развертывания с помощью Azure Resource Manager

Во-первых, важно понимать разницу между операциями плоскости данных и плоскости управления в инфраструктуре как услуге (IaaS).

• Плоскость управления описывает вызовы, поступающие в плоскость управления или API для изменения ресурсов. Например, такие операции, как создание виртуальной машины, перезапуск виртуальной машины и добавление в виртуальную сеть новой подсети, оперируют работающими ресурсами. Они не оказывают непосредственного влияния на подключение к виртуальным машинам.
• Плоскость данных (приложение) описывает среду выполнения приложения, включая взаимодействие с экземплярами, которое не осуществляется через API Azure. Например, доступ к веб-сайту или извлечение данных из работающего экземпляра SQL Server или сервера MongoDB считаются операциями в плоскости данных или взаимодействием с приложением. К другим примерам относятся копирование большого двоичного объекта из учетной записи хранения и доступ к общедоступному IP-адресу для подключения к виртуальной машине с помощью протокола удаленного рабочего стола (RDP) или Secure Shell (SSH). Эти операции обеспечивают рабочее состояние приложения для вычислительных и сетевых ресурсов, а также ресурсов хранения.

В классической модели развертывания и стеках Resource Manager используется одна и та же плоскость данных. Разница в том, что в процессе переноса Майкрософт преобразует представление ресурсов из классической модели развертывания в представление в стеке Resource Manager. Поэтому для управлениями ресурсами в стеке Resource Manager необходимо использовать новые средства, API-интерфейсы и пакеты SDK.

Примечание.

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

Процесс миграции

Перед началом миграции сделайте следующее:

• Убедитесь, что ресурсы, которые вы хотите перенести, не используют какие-либо неподдерживаемые компоненты или конфигурации. Обычно платформа обнаруживает такие проблемы и выдает ошибку.
• В ходе подготовки виртуальные машины, которые не находятся в виртуальной сети, останавливаются, а их распределение отменяется. Если вы не хотите потерять общедоступный IP-адрес, зарезервируйте его, прежде чем начать подготовку. Если виртуальные машины расположены в виртуальной сети, они не будут остановлены и их распределение не будет отменено.
• Планируйте провести миграцию в нерабочее время, чтобы справиться с любыми непредвиденными сбоями, которые могут возникнуть.
• Скачайте текущую конфигурацию виртуальных машин с помощью PowerShell, команд интерфейса командной строки или интерфейсов REST API, чтобы упростить проверку после завершения подготовки.
• Обновите скрипты автоматизации и ввода в эксплуатацию для работы с моделью развертывания с помощью Resource Manager, прежде чем начать миграцию. При необходимости можно выполнять операции GET, пока ресурсы находятся в состоянии подготовки.
• Оцените политики управления доступом на основе ролей Azure (Azure RBAC), настроенные для ресурсов IaaS, развернутых с помощью классической модели, и составьте план на период после завершения миграции.

Ниже представлен рабочий процесс переноса:

Примечание.

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

Проверить

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

Выберите виртуальную сеть или облачную службу (если она не является виртуальной сетью), которую нужно проверить перед переносом. Если ресурс нельзя перенести, Azure указывает причину.

Операция проверки ничего не проверяет

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

Операция проверки не проверяет работу сети.
Наличие шлюза ER и VPN-шлюза в виртуальной сети.
Отсутствие подключения к шлюзу виртуальной сети.
Все каналы ER, которые предварительно перенесены в стек Azure Resource Manager.
Проверки квот Azure Resource Manager на наличие сетевых ресурсов. Например: статический общедоступный IP-адрес, динамические общедоступные IP-адреса, подсистема балансировки нагрузки, группы безопасности сети, таблицы маршрутов и сетевые интерфейсы.
Проверка на допустимость всех правил подсистемы балансировки нагрузки в развернутой службе и в виртуальной сети.
Проверка на наличие конфликтующих частных IP-адресов на остановленных (освобожденных) виртуальных машинах в одной виртуальной сети.

Подготовить

Операция подготовки — это второй шаг в процессе переноса. На этом этапе моделируется преобразование ресурсов IaaS из классической модели развертывания в ресурсы Azure Resource Manager. Затем ресурсы отображаются на экране рядом для наглядности.

Примечание.

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

Выберите виртуальную сеть или облачную службу (если она не является виртуальной сетью), которую нужно подготовить к переносу.

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

Затем Azure начнет перенос метаданных переносимых ресурсов из классической модели развертывания в модель развертывания с помощью Resource Manager.

После завершения подготовки можно будет визуализировать ресурсы в классической модели развертывания и в модели развертывания с помощью Resource Manager. Для каждой облачной службы в классической модели развертывания платформа Azure создает имя группы ресурсов по шаблону cloud-service-name>-Migrated.

Примечание.

Нельзя выбрать имя группы ресурсов, созданной для перенесенных ресурсов (то есть -Migrated). Но после завершения переноса можно использовать функцию Azure Resource Manager для перемещения ресурсов в нужную группу ресурсов. Дополнительные сведения см. в статье Перемещение ресурсов в новую группу ресурсов или подписку.

Ниже приведены два снимка экрана, на которых показан результат успешной операции подготовки. На первом показана группа ресурсов, содержащая исходную облачную службу. На втором — группа ресурсов -Migrated, содержащая эквивалентные ресурсы Azure Resource Manager.

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

Примечание.

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

Проверка (вручную или с помощью сценария)

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

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

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

Длительность переноса не фиксирована. В этом состоянии время не ограничено. Тем не менее плоскость управления для этих ресурсов будет заблокирована, пока не будет выполнено прерывание или фиксация.

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

Abort

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

Примечание.

Эту операцию нельзя выполнить, если вы начали фиксацию.

Commit

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

Примечание.

Эта идемпотентная операция. Если не удалось выполнить операцию, повторите ее. Если проблема не будет устранена, создайте запрос в службу поддержки или опубликуйте вопрос на странице Microsoft Q&A.

Блок-схема миграции

Ниже представлена блок-схема, на которой показано, как выполнить перенос:

Преобразование ресурсов классической модели развертывания в ресурсы модели развертывания с помощью Resource Manager

В таблице ниже представлены ресурсы в классической модели развертывания и в модели развертывания с помощью Resource Manager. Остальные функции и ресурсы в настоящий момент не поддерживаются.

Представление классической модели	Представление Resource Manager	Примечания.
Имя облачной службы (имя размещенной службы)	DNS-имя	Во время миграции для каждой облачной службы создается новая группа ресурсов, которая именуется по шаблону <cloudservicename>-migrated. Эта группа ресурсов содержит все ваши ресурсы. Имя облачной службы становится DNS-именем, связанным с общедоступным IP-адресом.
Виртуальная машина	Виртуальная машина	Свойства, относящиеся к виртуальной машине, переносятся без изменений. Определенные данные osProfile, например имя компьютера, не хранятся в классической модели развертывания. После миграции они остаются пустыми.
Ресурсы дисков, подключенные к виртуальной машине	Скрытые диски, подключенные к виртуальной машине	Диски не моделируются в виде ресурсов верхнего уровня в модели развертывания с помощью Resource Manager. Они переносятся в качестве скрытых дисков в виртуальной машине. В настоящее время поддерживаются только диски, подключенные к виртуальной машине. Теперь виртуальные машины Resource Manager могут использовать учетные записи хранения в классической модели развертывания, что позволяет легко перенести диски без изменений.
Расширения виртуальной машины	Расширения виртуальной машины	Все расширения ресурсов (кроме расширений XML) переносятся из классической модели развертывания.
Сертификаты виртуальных машин	Сертификаты в хранилище ключей Azure	Если облачная служба содержит сертификаты службы, процесс миграции создаст новое хранилище ключей Azure для каждой облачной службы и переместит сертификаты в это хранилище ключей. В виртуальных машинах будут обновлены ссылки на сертификаты из хранилища ключей. Не удаляйте хранилище ключей. Если это сделать, виртуальная машина может перестать работать.
Конфигурация WinRM	Конфигурация WinRM в osProfile	Конфигурация службы удаленного управления Windows в ходе миграции перемещается без изменений.
Свойство группы доступности	Ресурс группы доступности	Спецификация группы доступности является свойством виртуальной машины в классической модели развертывания. Группы доступности становятся ресурсами верхнего уровня в ходе миграции. Не поддерживаются следующие конфигурации: несколько групп доступности на одну облачную службу либо одна или несколько групп доступности с виртуальными машинами, которые не находятся в какой-либо группе доступности в облачной службе.
Конфигурация сети в виртуальной машине	Основной сетевой интерфейс	Конфигурация сети в виртуальной машине после миграции представлена ресурсом основного сетевого интерфейса. У виртуальных машин, которые не находятся в виртуальной сети, при миграции изменится внутренний IP-адрес.
Несколько сетевых интерфейсов в виртуальной машине	Сетевые интерфейсы	Если с виртуальной машиной связано несколько сетевых интерфейсов, в ходе миграции каждый из них (и все соответствующие свойства) становится ресурсом верхнего уровня.
Набор конечных точек с балансировкой нагрузки	Подсистема балансировки нагрузки	В классической модели развертывания платформа назначает скрытый балансировщик нагрузки для каждой облачной службы. Во время миграции создается новый ресурс балансировщика нагрузки, а набор конечных точек с балансировкой нагрузки преобразовывается в правила балансировщика нагрузки.
Правила NAT для входящего трафика	Правила NAT для входящего трафика	При миграции входные конечные точки, определенные на виртуальной машине, преобразовываются в правила преобразования сетевых адресов для входящих подключений в балансировщике нагрузки.
Виртуальный IP-адрес	Общедоступный IP-адрес с DNS-именем	Виртуальный IP-адрес становится общедоступным IP-адресом, связанным с подсистемой балансировки нагрузки. Виртуальный IP-адрес можно перенести только в том случае, если ему назначена входная конечная точка. Чтобы хранить IP-адрес, его можно преобразовать в зарезервированный IP-адрес перед миграцией. Во время этого изменения будет время простоя примерно 60 секунд.
Виртуальная сеть	Виртуальная сеть	Виртуальная сеть и все ее свойства переносятся в модель развертывания с помощью Resource Manager. Создается новая группа ресурсов с именем -migrated.
Зарезервированные IP-адреса	Общедоступный IP-адрес с методом статического выделения	Зарезервированные IP-адреса, связанные с балансировщиком нагрузки, переносятся вместе с облачной службой или виртуальной машиной. Несвязанные зарезервированные IP-адреса можно перенести с помощью командлета Move-AzureReservedIP.
Общедоступный IP-адрес для каждой виртуальной машины	Общедоступный IP-адрес с методом динамического выделения	Общедоступный IP-адрес, связанный с виртуальной машиной, преобразуется в ресурс общедоступного IP-адреса с динамическим методом выделения.
Группы безопасности сети	Группы безопасности сети	Группы безопасности сети, связанные с виртуальной машиной или подсетью, в ходе миграции клонируются в модель развертывания с помощью Resource Manager. Группа безопасности сети в классической модели развертывания не удаляется в ходе миграции. Однако на период миграции для группы безопасности сети блокируются операции в плоскости управления. Несвязанные группы безопасности сети можно перенести с помощью командлета Move-AzureNetworkSecurityGroup.
Серверы DNS	Серверы DNS	DNS-серверы, связанные с виртуальной сетью или виртуальной машиной, переносятся в ходе миграции соответствующего ресурса вместе со всеми свойствами.
определяемые пользователем маршруты	определяемые пользователем маршруты	Определяемые пользователем маршруты, связанные с подсетью, в ходе миграции клонируются в модель развертывания с помощью Resource Manager. Определяемый пользователем маршрут (UDR) в классической модели развертывания не удаляется в ходе миграции. На период миграции для определяемого пользователем маршрута блокируются операции в плоскости управления. Несвязанные определяемые пользователем маршруты можно перенести с помощью командлета Move-AzureRouteTable.
Свойство IP-пересылки в конфигурации сети виртуальной машины	Свойство IP-пересылки в сетевой карте	Свойство IP-пересылки в виртуальной машине во время миграции преобразуется в свойство в сетевом интерфейсе.
Балансировщик нагрузки с несколькими IP-адресами	Балансировщик нагрузки с несколькими ресурсами IP-адресов	Каждый общедоступный IP-адрес, связанный с подсистемой балансировки нагрузки, после миграции преобразуется в ресурс общедоступного IP-адреса и связывается с подсистемой балансировки нагрузки.
Внутренние DNS-имена в виртуальной машине	Внутренние DNS-имена в сетевой карте	Во время миграции внутренние DNS-суффиксы виртуальных машин переносятся в свойство только для чтения InternalDomainNameSuffix в сетевой карте. После миграции суффикс не изменяется. Разрешение виртуальной машины также не должно измениться.
Шлюз виртуальной сети	Шлюз виртуальной сети	Свойства шлюза виртуальной сети переносятся без изменений. Виртуальный IP-адрес, связанной со шлюзом, также не меняется.
Сайт локальной сети	Шлюз локальной сети	Свойства сайта локальной сети переносятся без изменений в новый ресурс — шлюз локальной сети. Это касается префиксов локальных адресов и IP-адреса удаленного шлюза.
Ссылки на подключения	Connection	Ссылки на подключения между шлюзом и сайтом локальной сети в конфигурации сети представлены новым ресурсом, который называется "Подключение". Все свойства ссылки на подключение в файлах конфигурации сети копируются без изменений в ресурс "Подключение". Возможность подключения между виртуальными сетями в классической модели развертывания обеспечивается благодаря созданию двух туннелей IPsec к сайтам локальной сети, представляющим виртуальные сети. Это преобразуется в подключение типа "виртуальная сеть — виртуальная сеть" в модели Resource Manager, для которого не нужны шлюзы локальной сети.

Изменение возможностей автоматизации и набора инструментов после миграции

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

Следующие шаги

• Обзор поддерживаемого платформой переноса ресурсов IaaS из классической модели в модель Azure Resource Manager
• Planning for migration of IaaS resources from classic to Azure Resource Manager (Планирование переноса ресурсов IaaS из классической модели в модель Azure Resource Manager)
• Перенос ресурсов IaaS из классической модели в модель Azure Resource Manager с помощью Azure PowerShell
• Перенос ресурсов IaaS из классической модели в модель Azure Resource Manager с помощью интерфейса командной строки Azure
• Перенос VPN-шлюза из классической модели развертывания в модель Resource Manager
• Перенос связанных виртуальных сетей ExpressRoute из классической модели на модель Resource Manager
• Community tools to migrate IaaS resources from classic to Azure Resource Manager (Инструменты сообщества для перемещения ресурсов IaaS из классической модели в модель Azure Resource Manager)
• Распространенные ошибки миграции
• Часто задаваемые вопросы о миграции из классической модели в модель Azure Resource Manager