Переход существующей среды Azure в концептуальную архитектуру целевой зоны Azure

  • Статья

Многие организации имеют существующий объем ресурсов Azure, одну или несколько подписок и потенциально существующую структуру группы управления. В зависимости от бизнес-требований и сценариев они могут развертывать ресурсы Azure, такие как Azure VPN-шлюз или Azure ExpressRoute для гибридного подключения.

В этой статье приведены рекомендации, помогающие организации перемещать изменения на основе существующей среды Azure, которая переходит в концептуальную архитектуру целевой зоны Azure. В этой статье также описываются рекомендации по перемещению ресурсов в Azure, например перемещение подписки из одной существующей группы управления в другую группу управления. Рассмотрим эти рекомендации, которые помогут вам оценить и спланировать переход существующей среды Azure.

Перемещение ресурсов в Azure

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

Область Назначение Pro Против
Ресурсы в группах ресурсов. Вы можете перейти в новую группу ресурсов в той же или другой подписке. После развертывания можно изменить композицию ресурсов в группе ресурсов. Не поддерживается всеми типами ресурсов.

Некоторые resourceTypes имеют определенные ограничения или требования.

Идентификаторы ресурсов обновляются и влияют на существующие операции мониторинга, оповещений и плоскости управления.

Группы ресурсов блокируются в течение периода перемещения.

Требуется оценка политик и RBAC перед перемещением и операцией после перемещения.
Подписки в клиенте. Вы можете перейти к разным группам управления. Не влияет на существующие ресурсы в подписке, так как значения resourceId не изменяются. Требуется оценка политик и RBAC перед перемещением и операцией после перемещения.

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

Перемещение подписок

Как правило, вы перемещаете подписки, чтобы упорядочить их в группы управления или перенести подписки в новый клиент Идентификатора Microsoft Entra. Перемещение подписки в новый клиент в основном предназначено для передачи прав на выставление счетов. Дополнительные сведения о перемещении подписок между группами управления в одном клиенте см. в статье "Перемещение групп управления и подписок".

Требования Azure RBAC

Чтобы оценить подписку перед перемещением, важно, чтобы пользователь получил соответствующий azure RBAC. Пользователь может быть владельцем подписки (назначение прямой роли) и иметь разрешение на запись в целевой группе управления. Встроенные роли, поддерживающие разрешение на запись в целевой группе управления, являются ролью владельца, ролью участник и ролью группы управления участник.

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

Политики

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

С помощью Azure Resource Graph можно выполнить инвентаризацию существующих ресурсов и сравнить их конфигурацию с политиками, существующими в месте назначения.

После перемещения подписок в группу управления с существующими политиками Azure RBAC и политиками рассмотрите следующие факторы:

  • Для любого RBAC Azure, унаследованного от перемещаемых подписок, маркеры пользователей в кэше группы управления могут занять до 30 минут. Чтобы ускорить этот процесс, вы можете обновить маркер, выйдя и запросить новый маркер.

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

    • DeployIfNotExists Эффект политики отображается как несоответствующий и не исправлен автоматически. Пользователь должен вручную выполнить исправление.

    • Deny Эффект политики отображается как несоответствующий и не отклоняется. Пользователь должен вручную устранить этот результат соответствующим образом.

    • Append и Modify эффект политики отображается как несоответствующий и требует, чтобы пользователь смягчился.

    • Audit и AuditIfNotExist эффект политики отображается как несоответствующий и требует, чтобы пользователь смягчился.

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

Перемещение ресурсов

Как правило, ресурсы перемещаются при необходимости консолидации ресурсов в одну и ту же группу ресурсов, если они используют один и тот же жизненный цикл. Или если вы хотите переместить ресурсы в другую подписку из-за затрат, владения или требований Azure RBAC.

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

Дополнительные сведения о том, как перемещать ресурсы между группами ресурсов и подписками в одном клиенте, см. в статье "Перемещение ресурсов в новую группу ресурсов или подписку".

Совет

Чтобы свести к минимуму влияние региональных сбоев, рекомендуется разместить ресурсы в том же регионе, что и группа ресурсов. Дополнительные сведения см. в разделе "Выравнивание расположения группы ресурсов".

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

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

Перед перемещением ресурсов

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

После перемещения ресурсов

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

Сценарии

В следующих сценариях описывается перенос и переход существующей среды в концептуальную архитектуру целевой зоны Azure.

Переход к целевой архитектуре