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

Перенос внедренного виртуальной сети экземпляра Управление API, размещенного на платформе stv1, на stv2

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: Разработчик | Премия

В этой статье приведены шаги по переносу экземпляра Управление API, размещенного на stv1 вычислительной платформе на местеstv2, на платформу при внедрении экземпляра (развернутого) во внешней или внутренней виртуальной сети. Узнайте, нужно ли это сделать.

Примечание.

Новые возможности в августе 2024 г.: чтобы помочь вам перенести экземпляр виртуальной сети, мы улучшили параметры миграции на портале! Теперь вы можете перенести экземпляр на месте и сохранить одну подсеть и IP-адрес.

Для экземпляра виртуальной сети у вас есть следующие варианты миграции:

  • Вариант 1. Сохраните ту же подсеть . Перенос экземпляра на месте и сохранение существующей конфигурации подсети экземпляров. Можно выбрать, сохраняется ли исходный IP-адрес экземпляра Управление API (рекомендуется) или будет ли создан новый ВИРТУАЛЬНЫй IP-адрес.

  • Вариант 2. Изменение новой подсети . Перенос экземпляра путем указания другой подсети в той же или другой виртуальной сети. После миграции при необходимости вернитесь в исходную подсеть экземпляра. Процесс миграции изменяет IP-адреса экземпляра. После миграции необходимо обновить все сетевые зависимости, включая DNS, правила брандмауэра и виртуальные сети для использования новых ВИРТУАЛЬНЫх IP-адресов.

Если вам нужно перенести неинперционную виртуальную сеть Управление API, размещенную на stv1 платформе, см. статью "Миграция экземпляра, отличного от виртуальной сети" Управление API на платформу stv2.

Внимание

Поддержка Управление API экземпляров, размещенных на stv1 платформе, прекращена. В глобальной среде Azure дата выхода на пенсию — 31 августа 2024 года. В Azure для государственных организаций и в Azure, управляемых 21Vianet (Azure в Китае), дата выхода на пенсию — 24 февраля 2025 года. Если у вас есть экземпляры, размещенные на stv1 платформе, перенесите их на stv2 платформу до даты выхода на пенсию, чтобы избежать сбоев в обслуживании.

Внимание

  • Перенос экземпляра Управление API на stv2 платформу является длительной операцией.
  • stv2 Миграция в не является обратимой.

Что происходит во время миграции?

Управление API миграция платформы из stv1 stv2 нее включает обновление базовых вычислительных ресурсов и не влияет на конфигурацию службы или API, сохраненную на уровне хранилища.

  • Процесс обновления включает создание новых вычислений параллельно с старыми вычислениями, которые могут занять до 45 минут. Планирование более длительного времени для развертываний в нескольких регионах и в сценариях, связанных с изменением подсети более одного раза.
  • Состояние Управление API в портал Azure будет обновлено.
  • Для определенных вариантов миграции можно сохранить ВИРТУАЛЬНЫй IP-адрес или создать новый общедоступный ВИРТУАЛЬНЫЙ IP-адрес.
  • Для сценариев миграции при создании нового IP-адреса:
    • Azure управляет миграцией.
    • DNS шлюза по-прежнему указывает на старые вычислительные ресурсы, если используется личный домен.
    • Если пользовательский DNS не используется, шлюз и портал DNS указывают на новые вычислительные ресурсы немедленно.
    • Для экземпляра в режиме внутренней виртуальной сети клиент управляет DNS, поэтому записи DNS продолжают указывать на старые вычислительные ресурсы до обновления клиентом.
    • Это DNS, указывающий либо на новые, либо старые вычислительные ресурсы, поэтому время простоя в API не выполняется.
    • Изменения необходимы для правил брандмауэра, если таковые имеются, чтобы разрешить новой подсети вычислений доступ к серверным службам.
    • После успешной миграции старый вычислительный ресурс автоматически удаляется после короткого периода. При переходе на новую подсеть с помощью колонки миграции платформы на портале можно включить параметр миграции для сохранения старого шлюза в течение 48 часов. Параметр задержки в 48 часов доступен только для служб, внедренных в виртуальную сеть.

Необходимые компоненты

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

Вариант 1. Миграция и сохранение одной подсети

Вы можете перенести экземпляр Управление API на stv2 платформу, сохраняя существующую конфигурацию подсети, что упрощает миграцию. Вы можете перенести с помощью колонки миграции платформы в портал Azure или REST API миграции на Stv2.

Необходимые компоненты

  • Группу безопасности сети необходимо подключить к каждой подсети, а правила NSG для Управление API на stv2 платформе должны быть настроены. Ниже приведены минимальные параметры подключения:

    • Исходящий трафик к служба хранилища Azure через порт 443
    • Исходящий трафик в SQL Azure через порт 1433
    • Исходящий трафик в Azure Key Vault через порт 443
    • Входящий трафик из Azure Load Balancer через порт 6390
    • Входящий из тега службы ApiManagement через порт 3443
    • Входящий трафик через порт 80/443 для клиентов, вызывающих службу Управление API
    • Подсеть должна иметь конечные точки службы, включенные для служба хранилища Azure, SQL Azure и Azure Key Vault

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

  • Другие рекомендации по сети:

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

  • Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см . в кратком руководстве по Bash в Azure Cloud Shell.

  • Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.

    • Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, см. в статье Вход с помощью Azure CLI.

    • Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений с Azure CLI.

    • Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

Параметры общедоступного IP-адреса — миграция с одной подсетью

Можно выбрать, сохраняется ли исходный IP-адрес экземпляра Управление API (рекомендуется) или будет ли создан новый ВИРТУАЛЬНЫй IP-адрес.

  • Сохранение виртуального IP-адреса. Если вы сохраняете ВИРТУАЛЬНЫЙ IP-адрес в виртуальной сети во внешнем режиме, запросы API могут оставаться адаптивными во время миграции (см . ожидаемый простой); для виртуальной сети в внутреннем режиме ожидается временное простое. Конфигурация инфраструктуры (например, пользовательские домены, расположения и сертификаты ЦС) будет заблокирована в течение 45 минут. После миграции дополнительная конфигурация не требуется.

    С помощью этого параметра вычислительные stv1 ресурсы удаляются окончательно после завершения миграции. Нет возможности временно сохранить его.

    На следующем рисунке показан общий обзор того, что происходит при сохранении IP-адреса.

    Схема миграции на месте в одну подсеть и сохранение IP-адреса.

  • Новый виртуальный IP-адрес. Если выбрать этот параметр, Управление API создает новый ВИРТУАЛЬНЫй IP-адрес для вашего экземпляра. Запросы API остаются адаптивными во время миграции. Конфигурация инфраструктуры (например, пользовательские домены, расположения и сертификаты ЦС) будет заблокирована в течение 30 минут. После миграции необходимо обновить все сетевые зависимости, включая DNS, правила брандмауэра и виртуальные сети, чтобы использовать новый ВИРТУАЛЬНЫй IP-адрес.

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

    На следующем рисунке показан общий обзор того, что происходит при создании нового IP-адреса.

    Схема миграции на месте в одну подсеть и создание нового IP-адреса.

Предварительно созданный IP-адрес для миграции

Для Управление API экземпляров, доступных по общедоступному IP-адресу, Управление API предварительно создается общедоступный IP-адрес для процесса миграции. Найдите готовый IP-адрес в выходных данных JSON свойств экземпляра Управление API. В разделе customPropertiesпредварительно созданного IP-адреса используется значение Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps свойства. Для развертывания с несколькими регионами значение представляет собой разделенный запятыми список предварительно созданных IP-адресов.

Используйте готовый IP-адрес (или адреса), чтобы управлять процессом миграции:

  • При миграции и сохранении IP-адреса предварительно созданного IP-адреса временно назначается новому stv2 развертыванию, прежде чем исходный IP-адрес назначается развертыванию stv2 . Если у вас есть правила брандмауэра, ограничивающие доступ к экземпляру Управление API, например, можно добавить предварительно созданный IP-адрес в список разрешений, чтобы сохранить непрерывность доступа клиента во время миграции. После завершения миграции можно удалить предварительно созданный IP-адрес из списка разрешений.
  • При миграции и создании нового IP-адреса предварительно созданного IP-адреса назначается новому stv2 развертыванию во время миграции и сохраняется после завершения миграции. Используйте готовый IP-адрес для обновления зависимостей сети, таких как правила DNS и брандмауэра, чтобы указать на новый IP-адрес.

Ожидаемое время простоя и хранение вычислений

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

Режим виртуальной сети Параметр общедоступного IP-адреса Ожидаемое время простоя stv1 хранение вычислений
Внешняя. Сохранение ВИРТУАЛЬНОГО IP-адреса Нет простоя; трафик обслуживается на временном IP-адресе до 20 минут во время миграции в новое stv2 развертывание. Без хранения
Внешняя. Новый ВИРТУАЛЬНЫЙ IP-адрес время простоя отсутствует. Сохраняется по умолчанию в течение 15 минут, чтобы можно было обновить сетевые зависимости.
Внутренняя Сохранение ВИРТУАЛЬНОГО IP-адреса Время простоя в течение примерно 20 минут во время миграции, пока существующий IP-адрес назначается новому stv2 развертыванию. Без хранения
Внутренняя Новый ВИРТУАЛЬНЫЙ IP-адрес время простоя отсутствует. Сохраняется по умолчанию в течение 15 минут, чтобы позволить обновлять сетевые зависимости; Может быть продлено до 48 часов при использовании портала

Действия по миграции— сохранение одной подсети

  1. Перейдите к экземпляру Управления API на портале Azure.
  2. В меню слева в разделе "Параметры" выберите "Миграция платформы".
  3. В разделе "Выбор параметра миграции" выберите "Сохранить ту же подсеть".
  4. В разделе " Выбор IP-адреса" выберите один из двух вариантов IP-адресов.

    Примечание.

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

  5. (Для экземпляров, внедренных в внутренний режим и переход на новый ВИРТУАЛЬНЫй IP-адрес) В разделе "Выбор сценария, который соответствует вашим требованиям", выберите один из двух вариантов в зависимости от того, хотите ли вы поддерживать исходные stv1 вычислительные ресурсы в течение определенного периода после миграции.
  6. Выберите "Проверить" , чтобы запустить автоматические проверки в подсети. Если обнаружены проблемы, настройте конфигурацию подсети и снова выполните проверки. Для других зависимостей сети, таких как правила DNS и брандмауэра, проверьте вручную.
  7. Убедитесь, что вы хотите перенести и нажмите кнопку "Начать миграцию". Состояние Управление API экземпляра изменяется на обновление. Процесс миграции занимает около 45 минут. Когда состояние изменится на Online, миграция завершится.

Вариант 2. Миграция и изменение новой подсети

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

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

Схема миграции на месте в новую подсеть.

Необходимые компоненты

  • Новая подсеть в текущей виртуальной сети в каждом регионе, где развертывается экземпляр Управление API. (Кроме того, настройте подсеть в другой виртуальной сети в тех же регионах и подписке, что и экземпляр Управление API. Группу безопасности сети необходимо подключить к каждой подсети, а правила NSG для Управление API на stv2 платформе должны быть настроены.

  • (Необязательно) Новый общедоступный ресурс IPv4-адресов стандартного номера SKU в тех же регионах и подписке, что и ваш экземпляр Управление API. Дополнительные сведения см. в разделе "Предварительные требования для сетевых подключений".

Внимание

  • Начиная с мая 2024 г. ресурс общедоступного IP-адреса больше не требуется при развертывании (внедрении) экземпляра Управление API в виртуальной сети в внутреннем режиме или переносе конфигурации внутренней виртуальной сети в новую подсеть. В режиме внешней виртуальной сети указание общедоступного IP-адреса является необязательным. Если он не указан, управляемый Azure общедоступный IP-адрес автоматически настраивается и используется для трафика API среды выполнения. Укажите только общедоступный IP-адрес, если вы хотите владеть общедоступным IP-адресом, используемым для входящего или исходящего подключения к Интернету.
  • В настоящее время если включить избыточность зоны для экземпляра Управление API в виртуальной сети в внутреннем или внешнем режиме, необходимо указать новый общедоступный IP-адрес.

Этапы миграции— изменение новой подсети

  1. Перейдите к экземпляру Управления API на портале Azure.

  2. В меню слева в разделе "Параметры" выберите "Миграция платформы".

  3. В разделе "Выбор параметра миграции" выберите "Изменить" в новую подсеть.

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

    Снимок экрана: параметры хранения вычислений stv1 на портале.

  5. В разделе " Определение параметров миграции" для каждого расположения:

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

    Снимок экрана: выбор параметров миграции сети на портале.

  6. В разделе "Проверка соответствия подсети требованиям к миграции" выберите "Проверить , чтобы выполнить автоматические проверки в подсети". Если обнаружены проблемы, настройте конфигурацию подсети и снова выполните проверки. Для других зависимостей сети, таких как правила DNS и брандмауэра, проверьте вручную.

  7. Убедитесь, что вы хотите перенести и выберите "Миграция". Состояние Управление API экземпляра изменяется на обновление. Процесс миграции занимает около 45 минут. Когда состояние изменится на Online, миграция завершится.

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

(Необязательно) Миграция обратно в исходную подсеть

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

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

Схема миграции на месте обратно в исходную подсеть.

Внимание

Если виртуальная сеть и подсеть заблокированы (так как развернуты другие stv1 экземпляры Управление API платформы) или группа ресурсов, в которой развернута исходная виртуальная сеть, имеет блокировку ресурсов, обязательно удалите блокировку перед переносом обратно в исходную подсеть. Дождитесь завершения удаления блокировки перед попыткой миграции в исходную подсеть. Подробнее.

Дополнительные требования

  • Разблокированная исходная подсеть в каждом регионе, где развертывается экземпляр Управление API. Группу безопасности сети необходимо подключить к подсети, а правила NSG для Управление API должны быть настроены.

  • (Необязательно) Новый общедоступный ресурс IPv4-адресов стандартного номера SKU в тех же регионах и подписке, что и ваш экземпляр Управление API.

    Внимание

    • Начиная с мая 2024 г. ресурс общедоступного IP-адреса больше не требуется при развертывании (внедрении) экземпляра Управление API в виртуальной сети в внутреннем режиме или переносе конфигурации внутренней виртуальной сети в новую подсеть. В режиме внешней виртуальной сети указание общедоступного IP-адреса является необязательным. Если он не указан, управляемый Azure общедоступный IP-адрес автоматически настраивается и используется для трафика API среды выполнения. Укажите только общедоступный IP-адрес, если вы хотите владеть общедоступным IP-адресом, используемым для входящего или исходящего подключения к Интернету.
    • В настоящее время если включить избыточность зоны для экземпляра Управление API в виртуальной сети в внутреннем или внешнем режиме, необходимо указать новый общедоступный IP-адрес.

Обновление конфигурации виртуальной сети

  1. На портале перейдите к исходной виртуальной сети.
  2. В меню слева выберите подсети и исходную подсеть.
  3. Убедитесь, что исходные IP-адреса были выпущены Управление API. В разделе "Доступные IP-адреса" обратите внимание на количество IP-адресов, доступных в подсети. Все адреса (кроме зарезервированных адресов Azure) должны быть доступны. При необходимости дождитесь освобождения IP-адресов.
  4. Перейдите к экземпляру Управления API.
  5. В меню слева в разделе "Сеть" выберите "Виртуальная сеть".
  6. Выберите сетевое подключение в расположении, которое вы хотите обновить.
  7. Выберите исходную сеть и подсеть виртуальной сети. При необходимости выберите новый общедоступный IP-адрес. Выберите Применить.
  8. Если экземпляр Управление API развернут в нескольких регионах, продолжайте настраивать параметры виртуальной сети для остальных расположений вашего экземпляра.
  9. В верхней панели навигации нажмите кнопку "Сохранить".

После обновления конфигурации виртуальной сети состояние экземпляра Управление API изменяется на обновление. Процесс миграции занимает около 45 минут. Когда состояние изменится на Online, миграция завершится.

Проверка миграции

Чтобы убедиться, что миграция выполнена успешно, когда состояние изменяется в Online, проверьте версию платформы вашего Управление API экземпляра. После успешной миграции значение равно stv2 или stv2.1.

Подтверждение параметров перед очисткой старого шлюза

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

  • В этом окне старые и новые шлюзы находятся как в сети, так и в режиме обслуживания трафика. Вы не выставляете счета в течение этого времени.
  • Используйте это окно для обновления любых зависимостей сети, включая DNS, правила брандмауэра и виртуальные сети, чтобы использовать новый ВИРТУАЛЬНЫй IP-адрес и адресное пространство подсети.
  • Кроме того, проверьте состояние сети обновленного экземпляра, чтобы обеспечить подключение экземпляра к его зависимостям. На портале в меню слева в разделе Развертывание и инфраструктура выберите Сеть>Состояние сети. При необходимости обновите такие параметры, как UDR и правила NSG.
  • После этого старый шлюз будет выведен из эксплуатации, и новый шлюз является единственным обслуживающим трафиком.

Автоматическое восстановление при сбое миграции

Если во время миграции произошел сбой, экземпляр автоматически вернется к stv1 платформе. Если миграция завершена успешно (версия платформы экземпляра отображается как stv2 или stv2.1 состояние как Online), вы не сможете откатить на платформу stv1 .

Если миграция завершится ошибкой, обратитесь к поддержка Azure.

Если вам нужна возможность отката вручную, рекомендуется развернуть новый stv2 экземпляр параллельно с исходным экземпляром Управление API.

Справка и поддержка

Мы здесь, чтобы помочь вам перейти на stv2 платформу с минимальными нарушениями в ваших службах.

Если у вас есть вопросы, получите быстрые ответы от экспертов сообщества в Microsoft Q&A. Если у вас есть план поддержки и вам нужна техническая помощь, создайте запрос на поддержку:

  1. В поле Сводка введите описание проблемы, например "Прекращение поддержки stv1".
  2. В поле Тип проблемы укажите Техническая.
  3. В разделе Подписка выберите свою подписку.
  4. В разделе Служба выберите Мои службы и щелкните Служба Управления API.
  5. В разделе Ресурс выберите ресурс Azure, для которого вы создаете запрос в службу поддержки.
  6. В поле Тип проблемы выберите Администрирование и управление.
  7. В поле Подтип проблемы выберите Обновление, масштабирование или изменение SKU.

Часто задаваемые вопросы

  • Какие сведения нам нужно выбрать путь миграции?

    • Что такое сетевой режим экземпляра Управление API?
    • Настроены ли пользовательские домены?
    • Участвует ли брандмауэр?
    • Какие-либо известные зависимости, принятые вышестоящим или подчиненным ip-адресам?
    • Это развертывание с несколькими регионами?
    • Можно ли изменить существующий экземпляр или требуется ли параллельная настройка?
    • Может ли быть простой?
    • Можно ли выполнить миграцию в нерабочие часы?

  • Каковы необходимые условия для миграции?

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

  • Приведет ли миграция к простою?

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

    При миграции и переходе на новый ВИРТУАЛЬНЫй IP-адрес не должно быть простоя, если используются имена узлов по умолчанию. Очень важно, чтобы все сетевые зависимости были выполнены заранее, чтобы затронутые API были функциональными. Однако если личные домены используются, они будут указывать на удаленные вычисления, пока они не будут обновлены, что может привести к простою. Кроме того, для определенных вариантов миграции включите параметр миграции, чтобы сохранить старый шлюз в течение 48 часов. Наличие старых и новых вычислительных ресурсов упрощает проверку, а затем можно обновить пользовательские записи DNS.

  • Мой трафик принудительно туннелируется через брандмауэр. Какие изменения требуются?

    • Прежде всего, убедитесь, что подсети, используемые для миграции, сохраняют следующую конфигурацию (они должны быть уже настроены при миграции и сохранении текущей подсети):
      • Включение конечных точек службы, как описано здесь
      • UDR (определяемый пользователем маршрут) имеет прыжки из тега службы ApiManagement , заданного как "Интернет" и не только для адреса брандмауэра.
    • Требования к конфигурации NSG для stv2 остаются неизменными независимо от того, есть ли у вас брандмауэр. Убедитесь, что у вашей новой подсети она есть.
    • Правила брандмауэра, ссылающиеся на текущий диапазон IP-адресов экземпляра Управление API, следует обновить, чтобы использовать диапазон IP-адресов новой подсети.

  • Могут ли данные или конфигурации возникать по или во время миграции?

    stv1 для stv2 миграции требуется обновление вычислительной платформы только и внутренний уровень хранилища не изменяется. Поэтому все конфигурации безопасно во время процесса миграции. Сюда входит управляемое удостоверение, назначаемое системой, которое при включении сохраняется.

  • Как убедиться, что миграция завершена и успешно выполнена

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

  • Можно ли выполнить миграцию с помощью портала?

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

  • Можно ли сохранить IP-адрес экземпляра?

    Да, колонка миграции платформы на портале и REST API имеют параметры сохранения IP-адреса.

  • Существует ли путь миграции без изменения существующего экземпляра?

    Да, вам потребуется параллельное перемещение. Это означает, что вы создаете новый экземпляр Управление API параллельно с текущим экземпляром и копируете конфигурацию в новый экземпляр.

  • Что произойдет, если миграция завершается ошибкой?

    Если экземпляр Управление API не отображает версию платформы как stv2 или stv2.1 состояние как Online после начала миграции, вероятно, произошел сбой. Служба автоматически откатывается к старому экземпляру, и изменения не вносятся.

  • Какие функции недоступны во время миграции?

    Запросы API остаются адаптивными во время миграции. Конфигурация инфраструктуры (например, пользовательские домены, расположения и сертификаты ЦС) заблокирована в течение 30 минут.

  • Сколько времени займет миграция?

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

  • Существует ли способ проверить конфигурацию виртуальной сети перед попыткой миграции?

    Если вы планируете изменить подсеть во время миграции, можно развернуть новый экземпляр Управление API с виртуальной сетью, подсетью и (необязательно) ресурсом IP-адреса, который будет использоваться для фактической миграции. Перейдите на страницу состояния сети после завершения развертывания и проверьте, является ли состояние подключения к каждой конечной точке зеленым. Если да, вы можете удалить этот новый экземпляр Управление API и продолжить миграцию с исходной stv1размещенной службой.

  • Можно ли выполнить откат миграции при необходимости?

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

  • Требуется ли изменение в пользовательских доменах или частных зонах DNS?

    При внедрении виртуальных сетей экземпляров во внутреннем режиме и переходе на новый ВИРТУАЛЬНЫЙ IP-адрес необходимо обновить частные зоны DNS до нового IP-адреса виртуальной сети, полученного после миграции. Обратите внимание на обновление зон DNS, отличных от Azure(например, локальные DNS-серверы, указывающие на Управление API частный IP-адрес). Однако во внешнем режиме процесс миграции автоматически обновляет домены по умолчанию при использовании.

  • Экземпляр stv1 развертывается в нескольких регионах Azure (с несколькими регионами). Разделы справки обновление до stv2?

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

  • Можно ли обновить экземпляр stv1 до той же подсети?

    Да, используйте колонку миграции платформы на портале или используйте REST API миграции на stv2.

  • Можно ли протестировать новый шлюз в новой подсети перед переключением динамического трафика?

    • При миграции в новую подсеть по умолчанию старые и новые управляемые шлюзы сосуществуют в течение 15 минут, что является небольшим периодом времени для проверки развертывания. Вы можете включить параметр миграции, чтобы сохранить старый шлюз в течение 48 часов. Это изменение сохраняет старые и новые управляемые шлюзы активными для получения трафика и упрощения проверки.
    • Процесс миграции автоматически обновляет доменные имена по умолчанию и, если используется, трафик направляется к новым шлюзам немедленно.
    • Если пользовательские доменные имена используются, соответствующие записи DNS могут быть обновлены с новым IP-адресом, если не используется CNAME. Клиенты могут обновить файл узлов до нового IP-адреса Управление API и проверить экземпляр перед переходом. Во время этого процесса проверки старый шлюз продолжает обслуживать динамический трафик.

  • Существуют ли какие-либо рекомендации при использовании доменного имени по умолчанию в новой подсети?

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

  • Что следует учитывать для локальных шлюзов?

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

  • Как портал разработчика влияет на миграцию?

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

  • Есть ли влияние на стоимость после миграции на stv2?

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

  • Какие разрешения RBAC требуются для миграции stv1 на stv2?

    Пользователю или процессу миграции потребуется доступ на запись к экземпляру Управление API. Кроме того, требуются следующие два разрешения:

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/publicIPAddresses/join/action

Связанный контент