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

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

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

Примечание

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

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

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

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

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

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

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

  • Выполнение проверки, подготовки и прерывания пробного запуска. Это, наверное, самый важный шаг в обеспечении успешной миграции из классической модели в модель Azure Resource Manager. API миграции выполняет три основных этапа: проверку, подготовку и фиксацию. Проверка будет считывать состояние классической среды и возвращать сведения обо всех неполадках. Однако, так как в стеке Resource Manager Azure могут возникнуть некоторые проблемы, проверка не будет перехватывать все. Следующим шагом является процедура подготовки. Подготовка переместит метаданные из классической модели в 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 . Если миграция останавливается из-за неизвестного сообщения об ошибке состояния роли, проверьте виртуальную машину с помощью портала и убедитесь, что она работает. Обычно через несколько минут такая ошибка самоустраняется (не нужны никакие дополнительные действия). Это ошибка временного типа, которая происходит во время таких операций виртуальной машины, как запуск, останов, перезапуск. Рекомендация. Повторите попытку миграции через несколько минут.

  • Кластер структуры не существует . В некоторых случаях некоторые виртуальные машины невозможно перенести по разным нечетным причинам. Одним из таких известных случаев является то, если виртуальная машина была создана недавно (в течение последней недели или более того) и попала в кластер 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, например шифрование и переход на управляемые диски.
  • Вернитесь к техническим и бизнес-причинам для Resource Manager Azure; включите дополнительные службы, доступные только в Azure Resource Manager, которые применяются к вашей среде.
  • Модернизируйте среду с помощью служб PaaS.

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

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

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

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

Дальнейшие действия