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

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

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

В рамках этого расширения они планируют перенести их из локальных центров обработки данных и в Azure. Во время миграции они ведут к модернизации и преобразованию своих приложений или служб для использования облачных технологий, где это возможно. Например, они могут использовать базу данных SQL Azure и Службу Azure Kubernetes (AKS). Они знают, что это занимает значительное время и усилия, поэтому они планируют поднять и перейти к началу. Изначально этот план требует гибридного подключения через службы, такие как Azure VPN-шлюз или Azure ExpressRoute.

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

Текущее состояние

В этом сценарии текущее состояние среды Azure клиента состоит из следующих элементов:

• Одна или несколько групп управления.
• Иерархия групп управления, основанная на организационной структуре или географическом расположении.
• Подписка Azure для каждой среды приложения, например разработка, тестирование или рабочая среда (dev/test/prod).
• Распределение неуниформных ресурсов. Ресурсы платформы и рабочей нагрузки для одной среды развертываются в одной подписке Azure.
• Назначения политик с эффектами аудита и запретить эффекты, назначенные на уровне группы управления и подписки.
• Назначения ролей управления доступом на основе ролей на основе ролей для каждой подписки и группы ресурсов.
• Виртуальная сеть концентратора, например Azure VPN-шлюз или Azure ExpressRoute, для гибридного подключения.
• Виртуальная сеть для каждой среды приложения.
• Приложения, развернутые в соответствующей подписке на основе их классификации среды, например разработки, тестирования или рабочей среды.
• Центральная ИТ-группа, которая управляет средой и управляет ею.

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

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

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

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

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

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

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

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

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

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

   Примечание.

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

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

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

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

Итоги

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