Технические сведения о переходе на Облачные службы Azure Cloud Services (с расширенной поддержкой)
В этой статье рассматриваются технические сведения о средстве миграции, относящиеся к облачным службам (классическая модель).
Сведения о функциях и сценариях, поддерживаемых для миграции
Миграция расширений и подключаемых модулей
- Все включенные и поддерживаемые расширения будут перенесены.
- Отключенные расширения не будут перенесены.
- Подключаемые модули являются устаревшей концепцией и должны быть удалены перед миграцией. Они поддерживаются для миграции и после миграции, если необходимо включить расширение, подключаемый модуль необходимо удалить сначала перед установкой расширения. Это особенно скажется на подключаемых модулях и расширениях удаленного рабочего стола.
Миграция сертификата
- В облачных службах (Расширенная поддержка) сертификаты хранятся в Key Vault. В рамках миграции мы создадим Key Vault для клиентов, у которых есть имя облачной службы, и передадим все сертификаты из Service Manager Azure в Key Vault.
- Ссылка на этот Key Vault указывается в шаблоне или передается через PowerShell или Azure CLI.
Файлы конфигурации службы и определения службы
- Файлы CSCFG и CSDEF необходимо обновить для Облачные службы (расширенная поддержка) с незначительными изменениями.
- Имена ресурсов, таких как виртуальная сеть и номер SKU виртуальной машины, отличаются. См. статью Преобразование ресурсов и соглашения об именовании после миграции
- Клиенты могут получать новые развертывания с помощью PowerShell и REST API.
Облачная служба и ее развертывания
- Каждое развертывание облачных служб (расширенная поддержка) является независимой облачной службой. Развертывание больше не группируются в облачную службу с помощью слотов.
- Если у вас есть два слота в облачной службе (классическая модель), необходимо удалить один слот (промежуточный) и использовать средство миграции для перемещения другого (рабочего) слота в Azure Resource Manager.
- Общедоступный IP-адрес в развертывании облачной службы остается неизменным после миграции на Azure Resource Manager и предоставляется как базовый ресурс IP-адреса SKU (динамический или статический).
- DNS-имя и домен (cloudapp.net) для перенесенной облачной службы остается неизменным.
Миграция виртуальной сети
- Если развертывание облачных служб находится в виртуальной сети, то во время миграции все облачные службы и связанные ресурсы виртуальной сети переносятся вместе.
- После миграции виртуальная сеть помещается в другую группу ресурсов, а не в облачную службу.
- Для виртуальных сетей с несколькими облачными службами каждая облачная служба переносится одна за другой.
Миграция развертываний не в виртуальной сети
- В конце 2018 года Azure начала автоматически создавать новые развертывания (без указания клиента виртуальной сети) на платформе, созданной виртуальной сетью по умолчанию. Эти виртуальные сети по умолчанию скрыты от клиентов.
- В рамках миграции эта виртуальная сеть по умолчанию будет предоставляться клиентам в Azure Resource Manager. Чтобы управлять развертыванием или обновлять его в Azure Resource Manager, клиентам необходимо добавить эту информацию о виртуальной сети в раздел NetworkConfiguration файла .cscfg.
- Виртуальная сеть по умолчанию, если миграция выполняется в Azure Resource Manager, размещается в той же группе ресурсов, что и облачная служба.
- Облачные службы, созданные до этого времени (до конца 2018 г.), не будут находиться в какой-либо виртуальной сети и не могут быть перенесены с помощью средства. Рассмотрите возможность повторного развертывания этих облачных служб непосредственно в Azure Resource Manager. Другой подход заключается в миграции с помощью создания промежуточного развертывания и ПРОВЕРКИ дополнительных сведений здесь
- Чтобы проверить, может ли развертывание выполнить миграцию, запустите в развертывании проверку API. Результат проверки подлинности API будет содержать сообщение об ошибке, явно упоминающее, может ли это развертывание быть перенесено.
Load Balancer
- Для облачной службы, использующей общедоступную конечную точку, созданная на платформе подсистема балансировки нагрузки, связанная с облачной службой, доступна в подписке клиента в Azure Resource Manager. Балансировщик нагрузки является ресурсом только для чтения, а обновления ограничиваются только с помощью файлов конфигурации службы (cscfg) и файла определения службы (.csdef).
Key Vault
- В рамках миграции Azure автоматически создает новый Key Vault и переносит в него все сертификаты. Этот инструмент не позволяет использовать существующий Key Vault.
- Облачные службы (расширенная поддержка) требуется Хранилище ключей, расположенное в одном регионе и подписке. Этот Key Vault автоматически создается в процессе миграции.
Ресурсы и функции, недоступные для миграции
Это самые популярные сценарии, включающие сочетания ресурсов, функций и облачных служб. Этот список не является исчерпывающим.
| Ресурс | Дальнейшие действия |
|---|---|
| Правила автоматического масштабирования | Миграция проходит, но правила удаляются. Повторно создайте правила после миграции в облачных службах (расширенная поддержка). |
| видны узлы | Миграция проходит, но оповещения отбрасываются. Повторно создайте правила после миграции в облачных службах (расширенная поддержка). |
| VPN-шлюз | Удалите VPN-шлюз до начала миграции и повторно создайте его по ее завершении. |
| Шлюзы Express Route Gateway (в той же подписке, в которой находится виртуальная сеть) | Удалите шлюз Express Route Gateway до начала миграции и повторно создайте его по ее завершении. |
| Квота | Квота не переносится. Запросите новую квоту на Azure Resource Manager до миграции, чтобы проверка прошла успешно. |
| Территориальные группы | Не поддерживается. Перед миграцией удалите все территориальные группы. |
| Использование виртуальных сетей с помощью пиринга между виртуальными сетями | Перед миграцией виртуальной сети, связанной с другой виртуальной сетью, удалите пиринг, перенесите виртуальную сеть в Resource Manager и заново создайте пиринг. Это может привести к простою в зависимости от архитектуры. |
| Виртуальные сети, содержащие среды службы приложений | Не поддерживается |
| Виртуальные сети с пакетная служба Azure развертываниями | Не поддерживается |
| Виртуальные сети, содержащие службы HDInsight | Не поддерживается. |
| Виртуальные сети, содержащие развернутые службы управления API Azure. | Не поддерживается. Чтобы перенести виртуальную сеть, измените виртуальную сеть развертывания управления API. Это не операция простоя. |
| Классические каналы ExpressRoute | Не поддерживается. Эти каналы нужно перенести в Azure Resource Manager перед началом миграции PaaS. Дополнительные сведения см. в статье Перемещение каналов ExpressRoute из классической модели развертывания в модель развертывания с помощью Resource Manager. |
| Управление доступом на основе ролей | После миграции URI ресурса изменяется с Microsoft.ClassicCompute на Microsoft.Compute, политики RBAC после миграции необходимо обновить. |
| Шлюз приложений | Не поддерживается Удалите шлюз приложений до начала миграции и повторно создайте его по ее завершении |
Неподдерживаемые конфигурации и сценарии миграции
| Конфигурация/сценарий | Дальнейшие действия |
|---|---|
| Миграция некоторых старых развертываний не в виртуальной сети | Некоторые развертывания облачных служб, не входящих в виртуальную сеть, не поддерживаются для миграции. 1. Используйте API проверки, чтобы проверить, может ли развертывание выполнить миграцию. 2. при наличии права развертывания будут перемещены в Azure Resource Manager в виртуальной сети с префиксом "DefaultRdfeVnet" |
| Миграция развертываний, содержащих развертывание производственного и промежуточного слота с использованием динамических IP-адресов | Для переноса облачной службы из двух слотов требуется удаление промежуточного слота. После удаления промежуточного слота перенесите рабочий слот в качестве независимой облачной службы (расширенная поддержка) в Azure Resource Manager. Затем повторно разверните промежуточную среду как новую облачную службу (расширенная поддержка) и сделайте ее заменяемой первой. |
| Миграция развертываний, содержащих развертывание производственного и промежуточного слота с использованием зарезервированных IP-адресов | Не поддерживается. |
| Миграция рабочего и промежуточного развертывания в другой виртуальной сети | Для переноса облачной службы из двух слотов требуется удаление промежуточного слота. После удаления промежуточного слота перенесите рабочий слот в качестве независимой облачной службы (расширенная поддержка) в Azure Resource Manager. Затем новое развертывание облачных служб (расширенная поддержка) можно связать с перенесенным развертыванием с включенным свойством возможности переключения. Файлы развертывания старого промежуточного слота можно повторно использовать для создания этого нового заменяемого развертывания. |
| Миграция пустой облачной службы (облачная служба без развертывания) | Не поддерживается. |
| Миграция развертывания, содержащего подключаемый модуль удаленных рабочих столов и расширения удаленного рабочего стола | Вариант 1. Удалите подключаемый модуль удаленного рабочего стола перед миграцией. Это требует внесения изменений в файлы развертывания. Затем миграция пройдет. Вариант 2. Удалите расширение удаленного рабочего стола и перенесите развертывание. После миграции удалите подключаемый модуль и установите расширение. Это требует внесения изменений в файлы развертывания. Перед миграцией удалите подключаемый модуль и расширение. Подключаемые модули не рекомендуется использовать в Облачные службы (расширенная поддержка). |
| Виртуальные сети с развертыванием PaaS и IaaS | Не поддерживается Переместите развертывания PaaS или IaaS в другую виртуальную сеть. Это вызовет простой. |
| Развертывание облачной службы с использованием размеров устаревших ролей (например, Small или ExtraLarge). | Перед миграцией необходимо обновить размеры ролей. Обновите все артефакты развертывания, чтобы они ссылались на новые современные размеры ролей. Дополнительные сведения см. в статье Доступные размеры виртуальных машин |
| Миграция облачной службы в другую виртуальную сеть | Не поддерживается 1. Переместите развертывание в другую классическую виртуальную сеть перед миграцией. Это вызовет простой. 2. Перенесите новую виртуальную сеть в Azure Resource Manager. Или 1. Перенос виртуальной сети в Azure Resource Manager 2. Переместите облачную службу в новую виртуальную сеть. Это вызовет простой. |
| Облачная служба в виртуальной сети, но не назначена явная подсеть | Не поддерживается. Устранение рисков подразумевает перемещение роли в подсеть, для которой требуется перезапуск роли (время простоя) |
Преобразование ресурсов и соглашения об именовании после миграции
В процессе миграции имена ресурсов изменяются, а некоторые функции облачных служб представляются в виде ресурсов Azure Resource Manager. В таблице приведены изменения, относящиеся к миграции облачных служб.
| Облачные службы (классическая модель) Имя ресурса |
Облачные службы (классическая модель) Синтаксис |
Облачные службы (расширенная поддержка) Имя ресурса |
Облачные службы (расширенная поддержка) Синтаксис |
|---|---|---|---|
| Облачная служба | cloudservicename |
Не связано | Не связано |
| Развертывание (создан портал) Развертывание (не созданное порталом) |
deploymentname |
Облачные службы (расширенная поддержка) | cloudservicename |
| Виртуальная сеть | vnetname Group resourcegroupname vnetname Не связано |
виртуальная сеть (не создан портал) виртуальная сеть (создан портал) Виртуальная сеть (по умолчанию) |
vnetname group-resourcegroupname-vnetname VNet-cloudservicename |
| Не связано | Не связано | Key Vault | KV-cloudservicename |
| Не связано | Не связано | Группа ресурсов для развертываний облачных служб | cloudservicename-migrated |
| Не связано | Не связано | Группа ресурсов для виртуальной сети | vnetname-migrated group-resourcegroupname-vnetname-migrated |
| Не связано | Не связано | Общедоступный IP-адрес (динамический) | cloudservicenameContractContract |
| Имя зарезервированного IP-адреса | reservedipname |
Зарезервированный IP-адрес (не созданный портал) Зарезервированный IP-адрес (созданный порталом) |
reservedipname group-resourcegroupname-reservedipname |
| Не связано | Не связано | Load Balancer | LB-cloudservicename |
Проблемы миграции и способы их решения.
Миграция была остановлена в течение длительного времени.
- Фиксация, подготовка и прерывание могут занять много времени в зависимости от числа развертываний. Время ожидания всех операций истечет через 24 часа.
- Операции фиксации, подготовки и прерывания являются идемпотентными. Большинство проблем могут быть исправлены с помощью повторной попытки. Возможны временные ошибки, которые могут исчезнуть за несколько минут, поэтому рекомендуется повторить попытку после пропуска. Если миграция выполняется с помощью портала Azure и операция находится в состоянии "выполняется", используйте PowerShell для повторного выполнения операции.
- Обратитесь в службу поддержки, чтобы вам помогли выполнить миграцию или откат развертывания из серверной части.
Сбой в операции миграции.
- Если проверка завершилась сбоем, это связано с тем, что развертывание или виртуальная сеть содержит неподдерживаемый сценарий, компонент или ресурс. Используйте список неподдерживаемых сценариев, чтобы найти обходной вариант работы в документах.
- Сначала операция подготовки выполняет проверку, включая некоторые ресурсоемкие проверки (не рассматриваются в разделе проверка). Сбой подготовки может быть вызван неподдерживаемым сценарием. Найдите сценарий и обходной вариант работы в общедоступных документах. Чтобы вернуться к исходному состоянию и разблокировать развертывание для операций обновления и удаления, необходимо вызвать метод Abort.
- Если вызов Abort не удался, повторите операцию. Если повторные попытки завершаются неудачей, обратитесь в службу поддержки.
- Если не удалось выполнить фиксацию, повторите операцию. Если ошибка повторится, обратитесь в службу поддержки. Даже в случае сбоя фиксации в развертывании не должно быть проблем с плоскостью данных. Развертывание должно иметь возможность обрабатывать трафик клиентов без каких бы то ни было проблем.
Портал обновлен после подготовки. Перезагрузка и фиксация (Commit) или прекращение работы (Abort) больше не видны.
- На портале данные миграции хранятся локально, поэтому после обновления он начнет с этапа проверки, даже если облачная служба находится на этапе подготовки.
- Вы можете использовать портал для повторного выполнения шагов проверки и подготовки, чтобы открыть кнопку прерывания и фиксации. Это не приведет к сбоям.
- Клиенты могут использовать PowerShell или REST API для прерывания или фиксации.
Сколько времени может занять операция?
Проверка должна проходить быстро. Подготовка выполняется дольше и занимает некоторое время в зависимости от общего числа переносимых экземпляров ролей. В случае прерывания и фиксации также может потребоваться некоторое время, но для подготовки потребуется меньше времени. Время ожидания всех операций истечет через 24 часа.
Следующие шаги
Дополнительные сведения о переносе развертывания облачных служб (классическая модель) в облачные службы (расширенная поддержка) см. на главной странице сайта поддержки и устранения неполадок.