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

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

  • Статья

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

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

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

Внимание

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

Внимание

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

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

Управление API миграция платформы из stv1stv2 нее включает обновление базовых вычислительных ресурсов и не влияет на конфигурацию службы или 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-адрес Управление API или сохранить исходный IP-адрес.

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

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

  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.

Видео

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