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

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

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

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

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

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

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

• Одна подписка Azure.
• Нет пользовательских групп управления.
• Распределение неуниформных ресурсов. Ресурсы платформы и рабочей нагрузки развертываются в одной подписке Azure.
• Минимальное использование политики Azure. Назначения политик, такие как эффекты аудита и эффекты запрета, выполняются для каждой группы ресурсов с исключениями.
• Группы ресурсов, которые рассматриваются как единицы управления и масштабирования.
• Назначения ролей управления доступом на основе ролей на основе ролей для каждой группы ресурсов.
• Одна виртуальная сеть.
  • Гибридное подключение через службы, такие как Azure VPN-шлюз или Azure ExpressRoute.
  • Для каждого приложения создается новая подсеть.
• Несколько автономных приложений в каждой из групп ресурсов app-xx-rg . Приложения управляются различными командами приложений или служб и управляются ими.

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

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

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

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

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

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

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

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

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

   Примечание.

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

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

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

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

Итоги

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