Сценарий. Переход среды путем дедупликации группы управления целевой зоной

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

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

Перед реализацией этого подхода ознакомьтесь с концептуальной архитектурой целевой зоны Azure, принципами проектирования целевой зоны Azure и областями проектирования целевой зоны Azure.

Используйте этот подход для перехода в концептуальную архитектуру целевой зоны Azure:

1. Разверните акселератор целевой зоны Azure в одном клиенте идентификатора Microsoft Entra ID параллельно с текущей средой. Этот метод обеспечивает плавное и поэтапное переход к новой архитектуре целевой зоны с минимальным нарушением активных рабочих нагрузок.

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

   Сведения о минимизации нарушений работы приложений и служб во время миграции см. в разделе "Внедрение управляемых политикой охранников".

2. Чтобы дублировать группу управления целевой зоной и ее дочерними объектами (corp и online на следующей схеме), включая все назначения политик, настройте их для аудита только в режиме. Для назначений политик задайте для DoNotEnforce свойства enforcementMode значение или Disabled.

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

   

   Примечание.

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

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

   Сведения о влиянии на ресурсы при миграции см. в разделе "Политики".

   В конечном итоге можно отменить существующую подписку Azure и поместить ее в удаленную группу управления.

   Примечание.

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

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

   Дополнительные сведения см. в статье "Подготовка целевой зоны" для руководства по миграции.

На следующей схеме показано состояние этого сценария во время миграции.

Итоги

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