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

Planning for migration of IaaS resources from classic to Azure Resource Manager (Планирование переноса ресурсов IaaS из классической модели в модель Azure Resource Manager)

  • Статья

Область применения: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows

Это важно

Сегодня примерно на 90 % виртуальных машин IaaS используется служба Azure Resource Manager. По состоянию на 28 февраля 2020 г. классические виртуальные машины устарели и будут полностью прекращены 6 сентября 2023 г. Узнайте больше об этом устаревании и о том, как оно влияет на вас.

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

Замечание

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

Перенос ресурсов состоит из четырех основных этапов.

Снимок экрана: этапы миграции.

Планирование

Технические вопросы и компромиссы

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

  1. Почему ваша организация хочет перейти на использование Azure Resource Manager? По каким коммерческим соображениям требуется перенести ресурсы?
  2. Каковы технические причины использования Azure Resource Manager? Что (если есть) другие службы Azure, которые вы хотите использовать?
  3. Какое приложение или какие наборы виртуальных машин участвуют в переносе ресурсов?
  4. Какие сценарии поддерживает API миграции? Ознакомьтесь со списком возможностей и конфигураций, которые не поддерживаются.
  5. Поддерживают ли рабочие группы приложения и виртуальные машины в классической модели и модели Azure Resource Manager?
  6. Каким образом Azure Resource Manager изменяет процессы развертывания, администрирования, мониторинга виртуальной машины и отправки отчетов? Нужно ли обновлять сценарии развертывания?
  7. Что такое план связи для оповещения заинтересованных лиц (конечных пользователей, владельцев приложений и владельцев инфраструктуры)?
  8. Учитывая сложность среды, предусмотрен ли какой-либо период обслуживания, в течение которого приложение недоступно для пользователей и его владельцев? Если да, то как долго?
  9. Каков план обучения заинтересованных лиц работе с Azure Resource Manager?
  10. Что представляет собой план управления программой или проектом для переноса?
  11. Сколько времени занимает переход на Azure Resource Manager и планируемое внедрение связанных технологий? Согласованы ли они друг с другом оптимальным образом?

Рекомендации для удачного перемещения

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

Типичные недочеты

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

Лабораторный анализ

Репликация среды и выполнение тестового переноса

Замечание

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

Проведение лабораторного анализа конкретного сценария (вычислительных, сетевых ресурсов и ресурсов хранения) — залог успешного переноса ресурсов. Это помогает обеспечить следующее:

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

  • Хорошая идея — создать лабораторную среду в отдельной подписке. Так как лабораторная среда будет несколько раз удаляться, отдельная, изолированная подписка снизит вероятность ненамеренного удаления каких-нибудь существенных элементов.

    Для этого вы можете использовать инструмент AsmMetadataParser. См. дополнительные сведения о нем здесь.

Рекомендации для удачного перемещения

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

  • Выполнение проверки, подготовки и прерывания пробного запуска. Это, наверное, самый важный шаг в обеспечении успешной миграции из классической модели в модель Azure Resource Manager. API миграции состоит из трех основных этапов: Проверка, подготовка и фиксация. Проверка будет считывать состояние классической среды и возвращать сведения обо всех неполадках. Однако, поскольку некоторые проблемы могут существовать в стеке Azure Resource Manager, проверка не будет перехватывать все. Следующим шагом является процедура подготовки. Подготовка переместит метаданные из классической модели в Azure Resource Manager, но не зафиксируют перемещение и не удалят или не изменят ничего на классической стороне. Сухой запуск включает подготовку миграции, а затем прерывание (не фиксация) подготовки миграций. Целью проверки, подготовки и отмены пробного запуска является просмотр всех метаданных в стеке Azure Resource Manager, их анализ (программным образом или на портале), а также проверка корректности переноса всех компонентов и устранение технических неполадок. Таким образом вы также узнаете о продолжительности переноса, что позволит спланировать время простоя. Проверка и подготовка и прерывание не приводит к простою пользователя; Таким образом, это неразрывно для использования приложений.

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

  • Каналы ExpressRoute и VPN. В настоящее время шлюзы Express Route со ссылками авторизации не могут быть перенесены без простоя. Обходные пути описываются в статье Перенос каналов ExpressRoute и связанных виртуальных сетей из классической модели развертывания на модель Resource Manager.

  • Расширения виртуальной машины. Расширения виртуальной машины потенциально являются одним из наибольших препятствий для миграции запущенных виртуальных машин. Учтите при планировании, что исправление расширений виртуальной машины может занять до 1–2 дней. Для сообщения состояния расширения виртуальной машины на запущенных виртуальных машин требуется работающий агент Azure. Если состояние оценивается как плохое для работающей виртуальной машины, это приводит к остановке миграции. Сам агент не должен работать в рабочем порядке, чтобы включить миграцию, но если расширения существуют на виртуальной машине, для перемещения вперед потребуется как рабочий агент, так и исходящий интернет-подключение (с DNS).

    • Если подключение к DNS-серверу потеряно во время миграции, все расширения виртуальных машин, кроме BGInfo версии 1.* необходимо сначала удалить с каждой виртуальной машины перед подготовкой миграции, а затем повторно добавить на виртуальную машину после миграции Azure Resource Manager. Это необходимо сделать только для запущенных виртуальных машин. Если виртуальные машины остановлены, расширения виртуальных машин не нужно удалять. Примечание. Многие расширения, такие как Azure диагностика и Defender для облака мониторинг переустановят себя после миграции, поэтому удаление их не является проблемой.

    • Кроме того, убедитесь, что группы безопасности сети не ограничивают исходящий доступ к Интернету. что возможно в некоторых конфигурациях групп безопасности сети. Исходящий доступ к Интернету (и DNS) необходим для переноса расширений виртуальной машины в модель Azure Resource Manager.

    • Существуют две версии расширения BGInfo: версий 1 и 2. Если виртуальная машина создана с помощью портала Azure или PowerShell, на ней, вероятнее всего, будет установлено одно расширение — версии 1. Это расширение не нужно удалять и пропускать (не переносить) API миграции. Но если классическая виртуальная машина была создана с помощью нового портала Azure, она, вероятно, будет содержать версию 2 на основе JSON, которую можно переместить в Azure Resource Manager при наличии работающего агента и исходящего доступа к Интернету (и DNS).

    • Способ исправления 1. Если у виртуальных машин нет исходящего доступа к Интернету, рабочей службы DNS и рабочих агентов Azure на виртуальных машинах, удалите все расширения виртуальных машин в рамках миграции перед подготовкой, а затем переустановите расширения виртуальной машины после миграции.

    • Способ исправления 2. Если расширения виртуальных машин слишком сложны, еще один вариант — это выключение и деактивация всех виртуальных машин перед миграцией. Перенесите освобожденные виртуальные машины, а затем перезапустите их в модели Azure Resource Manager. Преимущество заключается в том, что расширения виртуальных машин переносятся. Недостатком является то, что все общедоступные виртуальные IP-адреса будут потеряны (это может быть неприемлемым), и, очевидно, виртуальные машины отключаются, что приводит к более значительному влиянию на работающие приложения.

      Замечание

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

  • Группы доступности. Чтобы переместить виртуальную сеть в Azure Resource Manager, все виртуальные машины, которые содержит классическое развертывание (например, облачная служба), должны либо находиться в одной группе доступности, либо не принадлежать ни к одной из групп. Наличие нескольких групп доступности в облачной службе несовместимо с Azure Resource Manager и остановит миграцию. Кроме того, в группе доступности не может быть несколько виртуальных машин, а некоторые виртуальные машины не в группе доступности. Чтобы устранить эту проблему, необходимо исправить или перенаправить облачную службу. Это может занять некоторое время, что следует учесть при планировании.

  • Развертывания веб-или рабочей роли. Облачные службы, содержащие веб-роли и рабочие роли, не могут перенестися в Azure Resource Manager. Их необходимо удалить из виртуальной сети до начала переноса. Стандартным решением является обычное перемещение экземпляров веб-ролей и рабочих ролей в отдельную классическую виртуальную сеть, которая также связана с каналом ExpressRoute. Или же можно переместить код в более новые службы приложений PaaS (что не относится к теме данного руководства). Как и в предыдущем случае повторного развертывания, вам необходимо создать новую классическую виртуальную сеть, переместить и повторно развернуть веб-роли или рабочие роли в этой сети, а затем удалить развернутые службы из перемещаемой виртуальной сети. Никаких изменений кода не требуется. Вы можете использовать новую функцию пиринга между виртуальными сетями, чтобы установить пиринг между классической виртуальной сетью, содержащей веб-роли и рабочие роли, и другими виртуальными сетями в одном регионе Azure (например, это может быть уже перемещенная виртуальная сеть, так как пиринговые виртуальные сети переместить невозможно). Это не повлияет на возможности и не приведет к потере производительности или штрафам за задержки или пропускную способность. С помощью пиринга между виртуальными сетями теперь можно легко переносить развертывания веб-ролей и рабочих ролей, не вызывая блокирование миграции в модель Azure Resource Manager.

  • Квоты Azure Resource Manager. У регионов Azure есть отдельные квоты и ограничения для классической модели и модели Azure Resource Manager. Несмотря на то, что в сценарии перемещения мы не используем новое оборудование (мы переключаем существующие виртуальные машины из классической модели в модель Azure Resource Manager), квоты Azure Resource Manager все равно должны выполняться, чтобы можно было начать перемещение. Основные ограничения, вызывающие проблемы, приведены ниже. Отправьте запрос на квоту в службу поддержки, чтобы увеличить значения ограничений.

    Замечание

    Это нужно сделать в том же регионе, в который будет перемещена текущая среда.

    • Сетевые интерфейсы

    • Подсистемы балансировки нагрузки

    • Общедоступные IP-адреса

    • Статические общедоступные IP-адреса.

    • Ядра

    • Группы сетевой безопасности

    • Таблицы маршрутов

      Используйте команды, приведенные ниже, в последней версии Azure CLI, чтобы проверить текущие квоты Azure Resource Manager.

      Вычисления(ядра, группы доступности)

      az vm list-usage -l <azure-region> -o jsonc

      Сеть(виртуальная сеть, статические общедоступные IP-адреса, общедоступные IP-адреса, группы безопасности сети, сетевые интерфейсы, подсистемы балансировки нагрузки, таблицы маршрутов)

      az network list-usages -l <azure-region> -o jsonc

      Хранилище(учетная запись хранения)

      az storage account show-usage

  • Ограничения регулирования API Azure Resource Manager. Если среда достаточно большая (например, > 400 виртуальных машин в виртуальной сети), вы можете достигнуть ограничения регулирования по умолчанию API для операций записи (сейчас это 1200 операций записи в час) в Azure Resource Manager. Перед началом переноса создайте запрос в службу поддержки, чтобы увеличить это ограничение для подписки.

  • Состояние времени ожидания подготовки виртуальной машины— если у любой виртуальной машины истекло время ожидания подготовки, необходимо устранить предварительную настройку. Единственный способ — это использовать режим простоя. Необходимо отозвать процесс подготовки виртуальной машины или повторно запустить его (удалить виртуальную машину, сохранить диск и снова создать виртуальную машину).

  • Состояние виртуальной машины RoleStateUnknown. Если миграция останавливается из-за неизвестного сообщения об ошибке состояния роли, проверьте виртуальную машину с помощью портала и убедитесь, что она запущена. Обычно через несколько минут такая ошибка самоустраняется (не нужны никакие дополнительные действия). Это ошибка временного типа, которая происходит во время таких операций виртуальной машины, как запуск, останов, перезапуск. Рекомендуется выполнить повторную миграцию через несколько минут.

  • Кластер Fabric не существует . В некоторых случаях некоторые виртуальные машины нельзя перенести по различным странным причинам. Один из этих известных случаев заключается в том, что виртуальная машина была недавно создана (в течение последней недели или около того) и произошла приземлиться в кластере Azure, который еще не оснащен для рабочих нагрузок Azure Resource Manager. Вы получите ошибку, которая говорит, что кластер структуры не существует , и виртуальная машина не может быть перенесена. Обычно эту ошибку удается устранить в течение нескольких дней, когда для кластера будет включена поддержка Azure Resource Manager. Самый быстрый обходной путь — выполнить операцию stop-deallocate с виртуальной машиной, затем продолжить миграцию, а после ее завершения выполнить архивацию виртуальной машины в Azure Resource Manager.

Типичные недочеты

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

Миграция

Технические вопросы и компромиссы

Теперь вы готовы, так как вы работали с известными проблемами с вашей средой.

Для выполнения фактической миграции следует учесть приведенные ниже рекомендации.

  1. Планируйте перенос виртуальных сетей (наименьших элементов при переносе) в порядке приоритета. Рекомендуется начать с простых виртуальных сетей, постепенно переходя к более сложным.
  2. Большинство клиентов имеют непроизводственные и производственные среды. Выполняйте перенос рабочей среды в последнюю очередь.
  3. (Необязательно.) Спланируйте время планового обслуживания, оставив достаточный буфер на случай непредвиденных ошибок.
  4. Обращайтесь к службам поддержки и принимайте во внимание рекомендации в случае проблем.

Рекомендации для удачного перемещения

Технические рекомендации, описанные в разделе о лабораторном анализе, необходимо учесть и выполнить до фактической миграции. При достаточном тестировании миграция на самом деле пройдет без каких-либо значительных событий. Для рабочих сред может оказаться полезной поддержкой, например доверенным партнером Майкрософт или службами Microsoft Premier.

Типичные недочеты

Неполная проверка может вызвать проблемы и задержку миграции.

Вспомогательные вопросы миграции

Технические вопросы и компромиссы

Теперь, когда вы переместили ресурсы в Azure Resource Manager, максимально используйте возможности платформы. Сведения о дополнительных преимуществах см. в обзоре Azure Resource Manager.

Необходимо учитывать следующее:

  • Совместите миграцию с другими действиями. Большинство пользователей использует окно обслуживания приложений. В таком случае вы можете использовать простой, чтобы включить другие возможности Azure Resource Manager, например шифрование и переход на управляемые диски.
  • Вернитесь к техническим и бизнес-причинам Для Azure Resource Manager; включите дополнительные службы, доступные только в Azure Resource Manager, которая применяется к вашей среде.
  • Модернизируйте среду с помощью служб PaaS.

Рекомендации для удачного перемещения

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

Типичные недочеты

Не забывайте об основной цели миграции из классической модели в модель Azure Resource Manager. Каковы были первоначальные коммерческие соображения? Достигли ли вы этих целей?

Дальнейшие шаги