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

В этой статье описываются рекомендации и инструкции по переносу среды Azure в концептуальную архитектуру целевой зоны Azure. Этот сценарий охватывает региональную организацию с группами управления, разделенными на среды разработки, тестирования и рабочей среды (dev/test/prod).

В этом сценарии клиент имеет большое количество ресурсов в Azure. У них есть иерархия групп управления, упорядоченная средами dev/test/prod, а затем по регионам. Их текущая реализация ограничивает масштабируемость и рост. У них есть приложения, развернутые по всему миру. Центральная ИТ-группа управляет каждым регионом. В этом сценарии регионы — Америка; Европа, Ближний Восток и Африка (EMEA); и Азиатско-Тихоокеанский регион (APAC).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Примечание.

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

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

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

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

Итоги

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