Сценарий: Переход среды региональной организации к эталонной архитектуре посадочной зоны Azure

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

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

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

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

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

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