Поделиться через

Техническое подробное руководство по модерируемой платформой миграции с классической версии на 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 — это плоскость данных или взаимодействие приложений. Другие примеры включают копирование объекта BLOB из учетной записи хранения и доступ к общедоступному IP-адресу для использования протокола удаленного рабочего стола (RDP) или Secure Shell (SSH) для подключения к виртуальной машине. Эти операции поддерживают работу приложения в областях вычислений, сетевых соединений и хранения данных.

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

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

Замечание

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

Опыт миграции

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

  • Убедитесь, что ресурсы, которые вы хотите перенести, не используют неподдерживаемые функции или конфигурации. Обычно платформа обнаруживает эти проблемы и создает ошибку.
  • Если у вас есть виртуальные машины, которые не входят в виртуальную сеть, они остановлены и освобождены в рамках операции подготовки. Если вы не хотите потерять общедоступный IP-адрес, попробуйте зарезервировать IP-адрес перед активацией операции подготовки. Если виртуальные машины находятся в виртуальной сети, они не выключены и не деактивированы.
  • Запланируйте миграцию в нерабочие часы, чтобы учесть непредвиденные сбои, которые могут произойти во время миграции.
  • Скачайте текущую конфигурацию виртуальных машин с помощью PowerShell, команд интерфейса командной строки (CLI) или 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 из классической модели развертывания в ресурсы Resource Manager. Кроме того, операция подготовки позволяет вам визуализировать это в параллельном режиме.

Замечание

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

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

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

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

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

Замечание

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

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

Снимок экрана: исходная облачная служба

Снимок экрана: ресурсы Azure Resource Manager в операции подготовки

Предлагаем взглянуть за кулисы на ваши ресурсы после завершения подготовительного этапа. Обратите внимание, что ресурс в плоскости данных совпадает. Он представлен как в плоскости управления (классическая модель развертывания), так и в плоскости контроля (Resource Manager).

Схема этапа подготовки

Замечание

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

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

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

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

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

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

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

Отмена

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

Снимок экрана, показывающий шаг прерывания.

Замечание

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

Зафиксировать

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

Замечание

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

Скриншот, показывающий шаг фиксации.

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

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

Снимок экрана: этапы миграции.

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

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

Классическое представление Представление диспетчера ресурсов Примечания.
Имя облачной службы (имя размещенной службы) DNS-имя Во время миграции создается новая группа ресурсов для каждой облачной службы с шаблоном <cloudservicename>-migratedименования. Эта группа ресурсов содержит все ресурсы. Имя облачной службы становится DNS-именем, связанным с общедоступным IP-адресом.
Виртуальная машина Виртуальная машина Свойства, относящиеся к виртуальной машине, переносятся без изменений. Некоторые сведения osProfile, такие как имя компьютера, не хранятся в классической модели развертывания и остаются пустыми после миграции.
Ресурсы диска, подключенные к виртуальной машине Неявные диски, подключенные к виртуальной машине Диски не моделироваются как ресурсы верхнего уровня в модели развертывания Resource Manager. Они переносятся как неявные диски под виртуальной машиной. Сейчас поддерживаются только диски, подключенные к виртуальной машине. Теперь виртуальные машины Resource Manager могут использовать учетные записи хранения в классической модели развертывания, что позволяет легко перенести диски без каких-либо обновлений.
Расширения виртуальной машины Расширения виртуальной машины Все расширения ресурсов, кроме расширений XML, переносятся из классической модели развертывания.
Сертификаты виртуальных машин Сертификаты в Azure Key Vault Если облачная служба содержит сертификаты службы, миграция создает новое хранилище ключей Azure для каждой облачной службы и перемещает сертификаты в хранилище ключей. Виртуальные машины обновляются, чтобы ссылаться на сертификаты из хранилища ключей.

Не удаляйте хранилище ключей. Это может привести к тому, что виртуальная машина перейдет в состояние сбоя.
Конфигурация WinRM Конфигурация WinRM в osProfile Конфигурация удаленного управления Windows перемещается без изменений в процессе миграции.
Свойство availability-set Ресурс группы доступности Спецификация набора доступности — это свойство виртуальной машины в классической модели развертывания. Группы доступности становятся ресурсом верхнего уровня в рамках миграции. Следующие конфигурации не поддерживаются: несколько наборов доступности для каждой облачной службы или один или несколько наборов доступности вместе с виртуальными машинами, не входящие в группу доступности в облачной службе.
Конфигурация сети на виртуальной машине Основной сетевой интерфейс Конфигурация сети на виртуальной машине представлена в качестве основного ресурса сетевого интерфейса после миграции. Для виртуальных машин, не входящих в виртуальную сеть, внутренний IP-адрес изменяется во время миграции.
Несколько сетевых интерфейсов на виртуальной машине Сетевые интерфейсы Если у виртуальной машины есть несколько сетевых интерфейсов, каждый сетевой интерфейс становится ресурсом верхнего уровня в рамках миграции, а также всеми свойствами.
Набор конечных точек с балансировкой нагрузки Подсистема балансировки нагрузки В классической модели развертывания платформа назначила неявную подсистему балансировки нагрузки для каждой облачной службы. Во время миграции создается новый ресурс подсистемы балансировки нагрузки, а набор конечных точек балансировки нагрузки становится правилами балансировки нагрузки.
Правила NAT для входящего трафика Правила NAT для входящего трафика Входные конечные точки, определенные на виртуальной машине, преобразуются в правила преобразования входящих сетевых адресов в подсистеме балансировки нагрузки во время миграции.
VIP-адрес Общедоступный 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 не удаляется во время миграции. Операции уровня управления для UDR блокируются в процессе миграции. Неассоциированные UDR можно перенести с помощью Move-AzureRouteTable.
Свойство IP-пересылки в конфигурации сети виртуальной машины Свойство IP-маршрутизации сетевого адаптера Свойство IP-пересылки на виртуальной машине преобразуется в свойство сетевого интерфейса во время миграции.
Подсистема балансировки нагрузки с несколькими IP-адресами Подсистема балансировки нагрузки с несколькими общедоступными IP-ресурсами Каждый общедоступный IP-адрес, связанный с подсистемой балансировки нагрузки, преобразуется в ресурс общедоступного IP-адреса и связан с подсистемой балансировки нагрузки после миграции.
Внутренние DNS-имена на виртуальной машине Внутренние DNS-имена в сетевом адаптере Во время миграции внутренние суффиксы DNS для виртуальных машин переносятся в свойство только для чтения с именем InternalDomainNameSuffix в сетевом адаптере. Суффикс остается неизменным после миграции, и разрешение виртуальной машины должно работать так же, как и раньше.
Шлюз виртуальной сети Шлюз виртуальной сети Свойства шлюза виртуальной сети переносятся без изменений. Виртуальный IP-адрес, связанный с этим шлюзом, также не изменяется.
Локальный сетевой сайт Шлюз локальной сети Свойства сайта локальной сети переносятся без изменений в новый ресурс, называемый локальным сетевым шлюзом. Это представляет префиксы локальных адресов и IP-адрес удаленного шлюза.
Ссылки на подключения Подключение Ссылки на подключения между шлюзом и сайтом локальной сети в конфигурации сети представлены новым ресурсом с именем Connection. Все свойства ссылки на подключение в файлах конфигурации сети копируются без изменений в ресурс подключения. Подключение между виртуальными сетями в классической модели развертывания достигается путем создания двух туннелей IPsec на локальные сетевые сайты, представляющие виртуальные сети. Это преобразуется в тип подключения виртуальной сети к виртуальной сети в модели Resource Manager, не требуя шлюзов локальной сети.

Изменения в автоматизации и инструментах после миграции

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

Дальнейшие шаги