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

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

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

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

Внимание

Поддержка экземпляров Управления API, размещенных на платформе stv1, будет прекращена 31 августа 2024 г. Если у вас есть экземпляры, размещенные на stv1 платформе, перенесите их на stv2 платформу до этой даты, чтобы избежать сбоев в обслуживании. Подробнее.

Внимание

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

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

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

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

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

• Экземпляр Управление API, размещенный на вычислительной stv1 платформе. Чтобы убедиться, что экземпляр размещен на stv1 платформе, см. Разделы справки узнать, какая платформа размещает свой экземпляр Управление API? Экземпляр должен быть внедрен в виртуальную сеть.

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

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

  Внимание

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

• (Необязательно) Обратитесь к поддержка Azure, чтобы запросить, что исходная инфраструктура служб поддерживается параллельно до 48 часов после успешной миграции. Этот параметр расширяет период, когда старая инфраструктура доступна после миграции за пределами по умолчанию 15 минут до очистки. Этот параметр доступен только для служб, внедренных в виртуальную сеть, чтобы владельцы служб могли обновлять параметры сети и тестировать приложения для использования новой инфраструктуры. Этот запрос расширения применяется ко всем экземплярам Управление API в подписке.

  Примечание.

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

Активация миграции внедренного в сеть экземпляра Управление API

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

Вы также можете перейти на stv2 платформу, включив избыточность зоны, доступную на уровне "Премиум ".

Внимание

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

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

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

Например, чтобы использовать портал:

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

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

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

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

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

Внимание

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

Примечание.

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

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

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

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

  Внимание

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

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

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

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

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

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

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

После успешной миграции экземпляра виртуальной сети, внедренного Управление API, старые и новые вычислительные ресурсы, созданные во время миграции, сосуществуют в течение короткого периода времени, примерно 15 минут, что является небольшим периодом времени, которое можно использовать для проверки развертывания и правильности работы приложений. (Это окно может быть продлено до 48 часов, связався с поддержка Azure заранее.)

• В этом окне старые и новые шлюзы находятся как в сети, так и в режиме обслуживания трафика. Вы не выставляете счета в течение этого времени.
• Используйте это окно для обновления любых зависимостей сети, включая 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-адресам?
  • Это развертывание с несколькими регионами?
  • Можно ли изменить существующий экземпляр или требуется ли параллельная настройка?
  • Может ли быть простой?
  • Можно ли выполнить миграцию в нерабочие часы?

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

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

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

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

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

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

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

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

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

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

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

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

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

  В настоящее время нет способа сохранить IP-адрес, если экземпляр внедряется в виртуальную сеть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Невозможно перенести экземпляр в одну подсеть в одном проходе без простоя stv1 . Однако при необходимости можно переместить перенесенный экземпляр обратно в исходную подсеть. Дополнительные сведения см. здесь.
  • Старый шлюз занимает от 15 минут до 45 минут, чтобы освободить подсеть, чтобы можно было инициировать перемещение. Однако вы можете запросить увеличение этого времени до 48 часов по запросу в службу поддержки.
  • Убедитесь, что сеть старой подсети для группы безопасности сети и брандмауэра обновлена для stv2 зависимостей.
  • Выделение IP-адресов подсети не является детерминированным, поэтому исходный IP-адрес подсистемы балансировки нагрузки (входящего трафика) для развертываний "внутреннего режима" может измениться при переходе к исходной подсети. Это потребует изменения DNS, если вы используете записи A.

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

  • По умолчанию старые и новые управляемые шлюзы сосуществуют в течение 15 минут, что является небольшим периодом времени для проверки развертывания. Вы можете запросить увеличение этого времени до 48 часов через поддержка Azure билет. Это изменение сохраняет старые и новые управляемые шлюзы активными для получения трафика и упрощения проверки.
  • Процесс миграции автоматически обновляет доменные имена по умолчанию и, если используется, трафик направляется к новым шлюзам немедленно.
  • Если пользовательские доменные имена используются, соответствующие записи 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

Видео

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

• Как узнать, на какой платформе размещен мой экземпляр Управления API?

• Преимущества вычислительной платформы stv2 для Управление API

• Узнайте о выходе на пенсию платформы stv1 в августе 2024 г.