Развертывание с помощью Azure Resource Manager и классическое развертывание: сведения о моделях развертывания и состоянии ресурсов

  • Статья

Примечание.

Сведения в этой статье применимы только при миграции из классической модели развертывания в развертывание Azure Resource Manager.

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

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

Если вы еще не работали с Resource Manager, то сначала рекомендуется ознакомиться с терминологией в статье Общие сведения об Azure Resource Manager.

История моделей развертывания

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

С появлением Resource Manager (в 2014 г.) было добавлено понятие группы ресурсов. Группа ресурсов — это контейнер для ресурсов с общим жизненным циклом. Модель развертывания диспетчера ресурсов предоставляет несколько преимуществ.

  • Вы можете осуществлять развертывание, управление и мониторинг всех служб вашего решения как единой группы вместо того, чтобы работать с ними по отдельности.
  • Вы можете повторно развертывать решение на протяжении всего его жизненного цикла и гарантировать, что ресурсы развертываются в согласованном состоянии.
  • Вы можете применить контроль доступа ко всем ресурсам в группе, и эти политики будут автоматически применяться ко всем новым ресурсам, добавленным в группу.
  • Для логического упорядочивания всех ресурсов в вашей подписке к ним можно применять теги.
  • Для определения инфраструктуры решения можно использовать нотацию объектов JavaScript (JSON). Файл JSON представляет собой шаблон Resource Manager.
  • Вы можете определять зависимости между ресурсами, чтобы их развертывание выполнялось в правильном порядке.

При появлении диспетчера ресурсов все ресурсы были добавлены в группы ресурсов по умолчанию. Теперь при классическом развертывании ресурсы будут автоматически создаваться в группе ресурсов, заданной для этой службы по умолчанию. Указывать ее не нужно. Но только принадлежность к группе ресурсов не означает, что ресурс был преобразован в модель Resource Manager.

Общие сведения о поддержке моделей развертывания

Существуют три сценария, о которых важно знать:

  1. Облачные службы (классические) не поддерживают модель развертывания с помощью Resource Manager. Облачные службы (расширенная поддержка) поддерживают модель развертывания с помощью Resource Manager.
  2. Виртуальные машины, учетные записи хранения и виртуальные сети поддерживают как модель развертывания с помощью Resource Manager, так и классическую модель.
  3. Все остальные службы Azure поддерживают модель Resource Manager.

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

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

Get-AzResource -ResourceGroupName ExampleGroup -ResourceType Microsoft.ClassicCompute/virtualMachines

Она возвращает виртуальную машину:

Name              : ExampleClassicVM
ResourceId        : /subscriptions/{guid}/resourceGroups/ExampleGroup/providers/Microsoft.ClassicCompute/virtualMachines/ExampleClassicVM
ResourceName      : ExampleClassicVM
ResourceType      : Microsoft.ClassicCompute/virtualMachines
ResourceGroupName : ExampleGroup
Location          : westus
SubscriptionId    : {guid}

Однако командлет Resource Manager Get-AzVM возвращает только виртуальные машины, развернутые с помощью Resource Manager. Следующая команда не вернет виртуальную машину, созданную с помощью классического развертывания.

Get-AzVM -ResourceGroupName ExampleGroup

Теги поддерживаются только ресурсами, созданными с помощью диспетчера ресурсов. К классическим ресурсам невозможно применить теги.

Изменения для вычислительных, сетевых ресурсов и ресурсов хранения

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

Diagram that shows Resource Manager architecture with SRP, CRP, and NRP.

SRP: поставщик ресурсов хранилища, CRP: поставщик ресурсов вычислений, NRP: поставщик сетевых ресурсов

Обновленная схема решения виртуальной машины, использующего управляемые диски, см. в статье "Запуск виртуальной машины Windows в Azure".

Обратите внимание на следующие связи между ресурсами:

  • Все ресурсы существуют в одной группе ресурсов.
  • Виртуальная машина зависит от определенной учетной записи хранения, определенной в поставщике ресурсов хранилища для хранения ее дисков в хранилище BLOB-объектов (обязательном).
  • Виртуальная машина ссылается на конкретную сетевую карту, определенную в поставщике сетевых ресурсов (обязательно), и группу доступности, определенную в поставщике вычислительных ресурсов (необязательно).
  • Сетевая карта ссылается на назначенный виртуальной машине IP-адрес (обязательно), подсеть виртуальной сети для виртуальной машины (обязательно) и группу сетевой безопасности (необязательно).
  • Подсеть в виртуальной сети ссылается на группу сетевой безопасности (необязательную).
  • Экземпляр подсистемы балансировки нагрузки ссылается на внутренний пул IP-адресов, которые включают сетевую карту виртуальной машины (необязательно), и ссылается на общедоступный или частный IP-адрес (необязательно) подсистемы балансировки нагрузки.

Ниже перечислены компоненты и их связи для классического развертывания.

Diagram that shows classic architecture for hosting a virtual machine.

Классическое решение для размещения виртуальной машины включает в себя следующие компоненты:

  • Облачные службы (классические) работают как контейнер для размещения виртуальных машин (вычислений). Виртуальным машинам автоматически предоставляется сетевая карта и IP-адрес, назначаемый Azure. Кроме того, облачная служба содержит экземпляр внешней подсистемы балансировки нагрузки, общедоступный IP-адрес и конечные точки по умолчанию, чтобы разрешить трафик удаленного рабочего стола и удаленный трафик PowerShell для виртуальных машин на основе Windows, а также трафик Secure Shell (SSH) для виртуальных машин на основе Linux.
  • Обязательная учетная запись хранения, в которой хранятся виртуальные жесткие диски виртуальной машины, включая диск операционной системы, а также временные и дополнительные диски данных (хранилище).
  • Необязательная виртуальная сеть, выступающая в качестве дополнительного контейнера, в котором можно создать структуру подсетей и назначить подсеть, в которой находится виртуальная машина (сеть).

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

Товар Классическое Resource Manager
Облачная служба для виртуальных машин Облачная служба представляла собой контейнер для хранения виртуальных машин, которым требовались доступность использования на платформе и балансировка нагрузки. Облачная служба больше не является объектом, необходимым для создания виртуальной машины в новой модели.
Виртуальные сети Создание виртуальной сети для виртуальной машины является необязательным. Если виртуальная сеть включена, то ее невозможно развернуть с помощью Resource Manager. Для виртуальной машины необходима виртуальная сеть, развернутая с помощью Resource Manager.
Учетные записи хранения Для виртуальной машины необходима учетная запись хранения, в которой хранятся виртуальные жесткие диски для операционной системы, а также временные и дополнительные диски данных. Для виртуальной машины необходима учетная запись хранения для хранения ее дисков в хранилище BLOB-объектов.
Группы доступности Доступность на платформе указывалась путем задания одного и того же параметра AvailabilitySetName на виртуальных машинах. Максимальное число доменов сбоя — 2. Группа доступности — это ресурс, предоставляемый поставщиком Microsoft.Compute. Виртуальные машины, требующие высокого уровня доступности, должны быть включены в группу доступности. Теперь максимальное число доменов сбоя — 3.
Территориальные группы Территориальные группы требовались для создания виртуальных сетей. Но с появлением региональных виртуальных сетей необходимость в них отпала. Для упрощения концепция территориальных групп больше не применяется в интерфейсах API, предоставляемых в Azure Resource Manager.
Балансировка нагрузки При создании облачных служб предоставляется скрытая подсистема балансировки нагрузки для развернутых виртуальных машин. Подсистема балансировки нагрузки — это ресурс, предоставляемый поставщиком Microsoft.Network. Основной сетевой интерфейс виртуальных машин, для которых необходимо сбалансировать нагрузку, должен ссылаться на подсистему балансировки нагрузки. Подсистемы балансировки нагрузки могут быть внутренними или внешними. Экземпляр подсистемы балансировки нагрузки ссылается на пул внутренних IP-адресов, который включают сетевую карту виртуальной машины (необязательно), и ссылается на общедоступный или частный IP-адрес (необязательно) подсистемы балансировки нагрузки.
Виртуальный IP-адрес При добавлении виртуальной машины в облачную службу облачные службы получают виртуальный IP-адрес по умолчанию. Виртуальный IP-адрес — это адрес, связанный со скрытой подсистемой балансировки нагрузки. Общедоступный IP-адрес — это ресурс, предоставляемый поставщиком Microsoft.Network. Общедоступный IP-адрес может быть статическим (зарезервированным) или динамическим. Динамические общедоступные IP-адреса могут быть назначены подсистеме балансировки нагрузки. Их можно защитить с помощью групп безопасности.
Зарезервированный IP-адрес Вы можете зарезервировать IP-адрес в Azure и связать его с облачной службой, чтобы убедиться, что его можно назначить. Общедоступный IP-адрес можно создать в статическом режиме, который предлагает те же возможности, что и зарезервированный IP-адрес.
Отдельный общедоступный IP-адрес для каждой виртуальной машины Общедоступные IP-адреса можно также связать с виртуальной машиной напрямую. Общедоступный IP-адрес — это ресурс, предоставляемый поставщиком Microsoft.Network. Общедоступный IP-адрес может быть статическим (зарезервированным) или динамическим.
Конечные точки Чтобы входные конечные точки служили в качестве открытых элементов, обеспечивающих подключение, в определенных портах, их необходимо было настроить в виртуальной машине. Один из распространенных способов подключения к виртуальным машинам — это настройка входных конечных точек. В подсистеме балансировки нагрузки можно настроить правила преобразования сетевых адресов (NAT) для входящих подключений, чтобы получить ту же возможность включения конечных точек в определенных портах для подключения к виртуальным машинам.
DNS-имя Облачная служба получит скрытое глобальное уникальное DNS-имя. Например: mycoffeeshop.cloudapp.net. DNS-имена являются необязательными параметрами, которые можно указать в ресурсе общедоступного IP-адреса. Формат полного доменного имени — <domainlabel>.<region>.cloudapp.azure.com.
Сетевые интерфейсы Первичный и вторичный сетевой интерфейс и их свойства были определены в качестве конфигурации сети виртуальной машины. Сетевой интерфейс — это ресурс, предоставляемый поставщиком Microsoft.Network. Жизненный цикл сетевого интерфейса не связан с виртуальной машиной. Он ссылается на назначенный виртуальной машине IP-адрес (обязательный), подсеть виртуальной сети для виртуальной машины (обязательную) и группу сетевой безопасности (необязательную).

Сведения о подключении виртуальных сетей с помощью различных моделей развертывания см. в статье Создание подключения между виртуальными сетями из разных моделей развертывания с помощью портала.

Миграция с классической модели развертывания на модель Resource Manager

Дополнительные сведения о переходе с классической модели развертывания на модель Resource Manager см. в следующих источниках:

  1. Техническое руководство по поддерживаемому платформой переносу из классической модели в модель Azure Resource Manager
  2. Поддерживаемый платформой перенос ресурсов IaaS из классической модели в модель Azure Resource Manager
  3. Перенос ресурсов IaaS из классической модели в модель Azure Resource Manager с помощью Azure PowerShell
  4. Перенос ресурсов IaaS из классического развертывания в развертывание с помощью Azure Resource Manager с использованием Azure CLI

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

Могу ли я создать виртуальную машину с помощью Resource Manager для развертывания в виртуальной сети, которая создана с помощью классической модели развертывания?

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

Могу ли я создать виртуальную машину с помощью Resource Manager, применив пользовательский образ, который создан с помощью классической модели развертывания?

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

Как использование новых ресурсов влияет на квоту моей подписки?

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

Могу ли я продолжить использовать свои автоматизированные сценарии для подготовки виртуальных машин, виртуальных сетей и учетных записей хранения с помощью новых интерфейсов API Resource Manager?

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

Где можно найти примеры шаблонов диспетчера ресурсов Azure?

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

Следующие шаги