Сценарий: переход среды путем дублирования группы управления посадочной зоной

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

Переход к эталонной архитектуре зоны высадки Azure

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

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

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

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

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

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

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

   

   Замечание

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

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

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

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

   Замечание

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

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

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

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

Сводка

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