Переход с классических Облачных служб Azure на Облачные службы Azure (с расширенной поддержкой)

  • Статья

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

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

Облачные службы (расширенная поддержка) предоставляют два пути для миграции клиентов из Azure Service Manager в Azure Resource Manager: повторное развертывание и миграция на месте.

В таблице ниже представлено сравнение двух вариантов.

Повторное развертывание Миграция на месте
Клиенты могут развернуть новую облачную службу непосредственно в Azure Resource Manager, а затем удалить старую облачную службу в Azure Service Manager после тщательной проверки. Средство миграции на месте обеспечивает простой, подготовленный с помощью платформы перенос существующих развертываний облачных служб (классическая модель) в облачные службы (расширенная поддержка).
Повторное развертывание позволяет клиентам:

– определять имена ресурсов;

– упорядочивать или повторно использовать ресурсы в зависимости от предпочтений;

– повторно использовать файлы конфигурации и определения службы с минимальными изменениями.		 Для миграции на месте платформа:

– определяет имена ресурсов;

– упорядочивает каждое развертывание и связанные ресурсы в отдельные группы ресурсов;

– изменяет существующий файл конфигурации и определения для Azure Resource Manager.
Клиентам необходимо отправлять трафик на новое развертывание. При миграции сохраняется IP-адрес, а путь к данным остается неизменным.
Клиентам необходимо удалить старые облачные службы в Azure Resource Manager. Платформа удаляет ресурсы облачных служб (классическая модель) после миграции.
Это миграция по методу lift-and-shift, которая обеспечивает большую гибкость, но требует дополнительного времени на перенос. Это автоматизированная миграция, которая обеспечивает быстрый перенос, но меньшую гибкость.

При оценке планов миграции из Облачных служб (классические) в Облачные службы (расширенная поддержка) вам может потребоваться изучить дополнительные службы Azure, такие как Масштабируемые наборы виртуальных машин, Службу приложений, Службу Azure Kubernetesи Azure Service Fabric. Эти службы будут по-прежнему работать с дополнительными возможностями, а Облачные службы (расширенная поддержка) в первую очередь сохранят равенство функций с Облачными службами (классические)

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

Обзор повторного развертывания

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

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

Новую облачную службу (расширенная поддержка) можно развернуть непосредственно в Azure Resource Manager с помощью следующих клиентских средств:

Обзор средства миграции

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

  • Обеспечивает простую, поддерживаемую платформой миграцию без простоев для большинства сценариев. См. дополнительные сведения о поддерживаемых сценариях.
  • Существующие облачные службы переносятся в три простых шага: проверка, подготовка, фиксация (или прерывание). Узнайте больше о том, как работает средство миграции.
  • Позволяет протестировать перенесенные развертывания после успешной подготовки. Зафиксируйте и завершите миграцию, пока прерывание откатывает ее.

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

Настройка доступа для миграции

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

  1. Войдите на портал Azure.

  2. В меню Центр выберите Подписка. Если вы не видите этот пункт, щелкните Все службы.

  3. Найдите нужную запись подписки, а затем посмотрите на поле MY ROLE. Для соадминистратора это значение должно быть администратором учетной записи. Если вы не можете добавить соадминистратора, обратитесь к администратору службы или соадминистратору, чтобы получить возможность добавить подписку.

  4. Регистрация подписки на пространство имен Microsoft.ClassicInfrastructureMigrate с помощью портала, PowerShell или интерфейса командной строки

    Register-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

  5. Проверьте состояние регистрации. Этот шаг может занять несколько минут.

    Get-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

Как миграция для облачных служб (классическая модель) отличается от виртуальных машин (классическая модель)?

Azure Service Manager поддерживает два разных вычислительных продукта: виртуальные машины Azure (классические) и облачные службы Azure (классические) или роли веб-пользователей/рабочих. Эти два продукта отличаются в зависимости от типа развертывания, который находится в облачной службе. Облачные службы Azure (классические) используют облачную службу, содержащую развертывания с веб-ролями и рабочими ролями. Виртуальные машины Azure (классические) используют облачную службу, содержащую развертывания с виртуальными машинами IaaS.

Список поддерживаемых сценариев отличается между облачными службами (классическая модель) и виртуальными машинами (классическая модель) из-за различий в типах развертывания.

Шаги миграции

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

  1. Проверка миграции — проверяет, что миграция не будет предотвращена распространенными неподдерживаемыми сценариями.
  2. Подготовка миграции — дублирует метаданные ресурсов в Azure Resource Manager. Все ресурсы заблокированы для операций создания, обновления и удаления, чтобы гарантировать синхронизацию метаданных ресурсов в Azure диспетчер сервера и Azure Resource Manager. Все операции чтения будут работать с помощью API-интерфейсов облачных служб (классическая модель) и облачных служб (расширенная поддержка).
  3. Прервать миграцию — удаляет метаданные ресурсов из Azure Resource Manager. Разблокирует все ресурсы для операций создания, обновления и удаления.
  4. Фиксация миграции — удаляет метаданные ресурсов из Service Manager Azure. Разблокирует ресурс для операций создания, обновления и удаления. Прерывание больше не разрешено после попытки фиксации.

Примечание.

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

На рисунке изображена схема действий, связанных с миграцией.

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

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

  • Учетные записи хранения
  • виртуальная сеть (пакетная служба Azure не поддерживается)
  • группы сетевой безопасности;
  • Зарезервированные общедоступные IP-адреса
  • Списки управления доступом (ACL) для конечной точки
  • Определяемые пользователем маршруты
  • Внутренняя подсистема балансировки нагрузки
  • Миграция сертификатов в хранилище ключей
  • Подключаемые модули и расширение (на основе XML и JSON)
  • Задачи запуска и завершения
  • Развертывания с ускоренной сетью
  • Развертывания с использованием одной или нескольких ролей
  • Load Balancer ("Базовый")
  • Вход, входные данные экземпляра, внутренние конечные точки
  • Статические общедоступные IP-адреса
  • DNS-имя
  • Правила сетевого трафика

Поддерживаемые конфигурации и сценарии миграции

Это самые популярные сценарии, включающие сочетания ресурсов, функций и облачных служб. Этот список не является исчерпывающим.

Service Настройка Комментарии
Доменные службы Microsoft Entra Виртуальные сети, содержащие доменные службы Microsoft Entra. Поддерживается виртуальная сеть, содержащая развертывание облачной службы и доменные службы Microsoft Entra. Сначала клиенту необходимо отдельно перенести доменные службы Microsoft Entra, а затем перенести виртуальную сеть, оставленную только при развертывании облачной службы.
Облачная служба Облачная служба с развертыванием только в одном слоте. Облачные службы с развертыванием слота prod можно перенести. Не рекомендуется перенести промежуточный слот, так как это может привести к проблемам с сохранением полного доменного имени службы. Чтобы перенести промежуточный слот, сначала продвигайте промежуточное развертывание в рабочую среду, а затем перейдите в ARM.
Облачная служба Развертывание не в общедоступной виртуальной сети (развертывание виртуальной сети по умолчанию) Облачная служба может находиться в общедоступной виртуальной сети, в скрытой виртуальной сети или не в какой-либо виртуальной сети. Облачные службы в скрытой виртуальной сети и общедоступные виртуальные сети поддерживаются для миграции. Клиент может использовать API проверки, чтобы определить, находится ли развертывание в виртуальной сети по умолчанию или нет, и таким образом определить, можно ли его перенести.
Облачная служба Расширения виртуальной машины XML (BGInfo, Visual Studio Debugger, Web Deploy, и Remote Debugging). Все расширения XML поддерживаются для миграции
Виртуальная сеть Виртуальная сеть, содержащая несколько облачных служб. Виртуальная сеть содержит несколько облачных служб, которые поддерживаются для миграции. Виртуальная сеть и все облачные службы внутри нее будут перенесены в Azure Resource Manager.
Виртуальная сеть Миграция виртуальных сетей, созданных с помощью портала (требуется "Group Resource-Group-Name VNet-Name" в файле .cscfg) В процессе миграции имя виртуальной сети в CSCFG будет изменено для использования идентификатора виртуальной сети Azure Resource Manager. (subscription/subscription-id/resource-group/resource-group-name/resource/resource/vnet-name)

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

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

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