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

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

  • Статья

Это важно

По состоянию на 31 марта 2025 г. облачные службы (классические) устарели и будут полностью прекращены 31 марта 2027 г. Learn more about this deprecation and how to migrate.

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

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

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

В следующей таблице показано сравнение этих двух параметров.

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

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

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

– повторно использовать файлы конфигурации и определения службы с минимальными изменениями.		 For in-place migration, the platform:

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

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

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

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

Depending on the application, Cloud Services (extended support) may require substantially less effort to move to Azure Resource Manager compared to other options. Если приложение не развивается, Облачные службы (расширенная поддержка) — это жизнеспособный вариант, который можно рассмотреть, так как он предоставляет быстрый путь миграции. И наоборот, если ваше приложение постоянно совершенствуется и ему требуется более современный набор функций, ознакомьтесь с другими службами Azure для более эффективного выполнения текущих и будущих требований.

Redeploy Overview

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

  • Поддерживает веб- и рабочие роли, аналогично облачным службам (классическая модель).
  • В конструировании, архитектуре или компонентах веб- и рабочих ролей изменений нет.
  • Изменения в коде среды выполнения не требуются, так как уровень данных остается таким же, как и в облачных сервисах.
  • Выпуски и связанные обновления гостевой ОС Azure согласованы с Облачными службами (классические).
  • Underlying update process with respect to update domains, how upgrade proceeds, rollback, and allowed service changes during an update remains unchanged.

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

Обзор инструмента миграции

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

  • Обеспечивает простую, поддерживаемую платформой миграцию без простоев для большинства сценариев. См. дополнительные сведения о поддерживаемых сценариях.
  • Существующие облачные службы переносятся в три простых шага: проверка, подготовка, выполнение (или отмена). Узнайте больше о том, как работает средство миграции.
  • Offers testing for migrated deployments after successful preparation. Commit and finalize the migration while abort rolls back the migration.

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

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

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

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

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

  3. Find the appropriate subscription entry, and then look at the MY ROLE field. Для соадминистратора значение должно быть "Account admin." Если вы не можете добавить соадминистратора, обратитесь к администратору службы или соадминистратору подписки, чтобы вас добавили.

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

    Register-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

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

    Get-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

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

Azure Service Manager поддерживает два разных вычислительных продукта: виртуальные машины Azure (классические) и облачные службы Azure (классические) или роли веб-пользователей/рабочих. Эти два продукта отличаются в зависимости от типа развертывания в облачной среде. Azure Cloud Services (classic) uses Cloud Service containing deployments with Web/Worker roles. Виртуальные машины Azure (классические) используют облачную службу, содержащую развертывания с виртуальными машинами IaaS.

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

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

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

  1. Проверка миграции . Проверяет, что распространенные неподдерживаемые сценарии не будут препятствовать миграции.
  2. Подготовка миграции — дублирует метаданные ресурсов в Azure Resource Manager. Все ресурсы заблокированы для операций создания, обновления и удаления, чтобы гарантировать синхронизацию метаданных ресурсов в Azure диспетчер сервера и Azure Resource Manager. Все операции чтения работают с помощью API Облачные службы (классические) и Облачные службы (расширенная поддержка).
  3. Прервать миграцию — удаляет метаданные ресурсов из Azure Resource Manager. Разблокирует все ресурсы для операций создания, обновления и удаления.
  4. Подтверждение миграции — удаляет метаданные ресурсов из Azure Service Manager. Разблокирует ресурс для операций создания, обновления и удаления. Abort is no longer allowed after commit attempts.

Примечание.

Prepare, Abort and Commit are idempotent and therefore, if failed, a retry should fix the issue.

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

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

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

  • Учетные записи хранения
  • виртуальная сеть (пакетная служба Azure не поддерживается)
  • группы сетевой безопасности;
  • Зарезервированные общедоступные IP-адреса
  • Списки управления доступом (ACL) для конечной точки
  • Определяемые пользователем маршруты
  • Внутренняя подсистема балансировки нагрузки
  • Certificate migration to key vault
  • Plugins and Extension (XML and JSON based)
  • Задачи при запуске и остановке
  • Развертывания с функцией ускоренной работы сети
  • Deployments using single or multiple roles
  • Базовый балансировщик нагрузки
  • Input, Instance Input, Internal Endpoints
  • Статические общедоступные IP-адреса
  • DNS-имя
  • Правила сетевого трафика

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

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

Сервис Настройка Комментарии
Microsoft Entra Domain Services Виртуальные сети, содержащие доменные службы Microsoft Entra. Поддерживается виртуальная сеть, содержащая развертывание облачной службы и доменные службы Microsoft Entra. Сначала клиенту необходимо отдельно перенести доменные службы Microsoft Entra, а затем перенести виртуальную сеть, оставленную только при развертывании облачной службы.
Облачные службы Облачный сервис с развертыванием только в одном слоте. Cloud Services containing a prod slot deployment can be migrated. It isn't recommended to migrate staging slot as this process can result in issues with retaining service FQDN. To migrate staging slot, first promote staging deployment to production and then migrate to Azure Resource Manager.
Облачные службы Развертывание не в общедоступной виртуальной сети (развертывание виртуальной сети по умолчанию) Облачная служба может находиться в общедоступной виртуальной сети, в скрытой виртуальной сети или не в какой-либо виртуальной сети. Облачные службы в скрытой виртуальной сети и общедоступные виртуальные сети поддерживаются для миграции. Клиент может использовать 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/vnet-name)

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

Файл .cscfg, использующий старую схему именования, не проходит проверку.
Виртуальная сеть Migration of deployment with roles in different subnet. Для миграции поддерживается облачная служба с разными ролями в разных подсетях.

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