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

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

  • Статья

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

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

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

Внимание

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

Внимание

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

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

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

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

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

  • Используйте среду 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.

Перенос экземпляра на платформу stv2

Параметры общедоступного IP-адреса

Вы можете выбрать, изменится ли виртуальный IP-адрес Управление API или сохранить исходный IP-адрес.

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

  • Сохраните IP-адрес. При сохранении IP-адреса запросы API не будут отвечать примерно на 15 минут, пока IP-адрес переносится в новую инфраструктуру. Конфигурация инфраструктуры (например, пользовательские домены, расположения и сертификаты ЦС) будет заблокирована в течение 45 минут. После миграции дополнительная конфигурация не требуется.

Предварительно созданный 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-адрес.

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

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

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

  3. На странице миграции платформы выберите один из двух вариантов миграции:

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

    • Сохраните IP-адрес. Виртуальный IP-адрес экземпляра Управление API не изменится. У экземпляра будет время простоя до 15 минут.

      Снимок экрана: миграция платформы Управление API на портале.

  4. Ознакомьтесь с рекомендациями по процессу миграции и подготовьте среду.

  5. После завершения подготовки выберите "Я прочитал" и понять влияние процесса миграции. Выберите "Миграция".

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

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

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

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

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

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

Обновление зависимостей сети

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

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

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

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

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

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

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

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

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

    Для экземпляров, не внедренных в виртуальную сеть, предварительные требования не требуются. Если вы переносите сохранение общедоступного IP-адреса, это приведет к отрисовке экземпляра Управление API не отвечать примерно на 15 минут. Если выбрать параметр "Новый виртуальный IP-адрес", который делает Управление API доступным на новом IP-адресе, может не быть простоем. Экземпляры, настроенные с помощью пользовательского домена с помощью записи A и (или) имеющих сетевые зависимости от общедоступного виртуального IP-адреса, будут иметь время простоя при запросе нового виртуального IP-адреса.

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

    Для экземпляров, не внедренных в виртуальную сеть, время простоя составляет около 15 минут, только если вы решили сохранить исходный IP-адрес. Однако при миграции с новым IP-адресом нет простоев и нет зависимостей сети от нового IP-адреса. Сетевые зависимости включают имя личного домена без CNAME, разрешенного IP-адреса, правил брандмауэра и виртуальных сетей.

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

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

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

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

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

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

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

    Да, IP-адрес можно сохранить, но время простоя составляет около 15 минут.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Чтобы Управление API, которые не внедрялись в виртуальную сеть, выполните действия по миграции с помощью портала или Azure CLI. Все регионы будут перенесены stv2в .

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

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

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

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

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

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

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

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

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