Поделиться через

Регионы целевой зоны

  • Статья

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

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

Дополнительные сведения см. в разделе "Выбор регионов Azure".

Целевые зоны и регионы Azure

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

Другие ресурсы развертываются в регионе. В зависимости от собственной конфигурации целевой зоны у вас могут быть некоторые или все перечисленные ниже региональные ресурсы:

  • Рабочая область журналов Azure Monitor, включая выбранные решения
  • учетную запись службы автоматизации Azure;
  • Группы ресурсов для других ресурсов

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

  • Azure Виртуальная глобальная сеть, включая центр Виртуальная глобальная сеть
  • Виртуальные сети Azure
  • VPN-шлюз
  • Шлюз Azure ExpressRoute
  • Брандмауэр Azure
  • Планы защиты от атак DDoS Azure
  • Частные зоны DNS Azure, включая зоны для Приватный канал Azure
  • Группы ресурсов, содержащие предыдущие ресурсы

Примечание.

Чтобы свести к минимуму влияние региональных сбоев, рекомендуется разместить ресурсы в том же регионе, что и группа ресурсов. Дополнительные сведения см. в разделе "Выравнивание расположения группы ресурсов".

Добавление нового региона в существующую целевую зону

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

Площадь Рекомендация
Группы управления Никаких действий не требуется. Группы управления не привязаны к региону. Не следует создавать структуру группы управления на основе регионов.
Подписки Подписки не привязаны к региону.
Политика Azure Внесите изменения в Политика Azure, если вы назначили политики, чтобы запретить развертывание ресурсов всем регионам, указав список разрешенных регионов Azure. Обновите эти назначения, чтобы разрешить развертывания ресурсов в новом регионе, который вы хотите включить.
Управление доступом на основе ролей (RBAC) Никаких действий не требуется. Функция RBAC Azure не привязана к региону.
Мониторинг и ведение журналов Решите, следует ли использовать одну рабочую область журналов Azure Monitor для всех регионов или создать несколько рабочих областей для покрытия различных географических регионов. Каждый подход имеет преимущества и недостатки, включая потенциальные расходы на сеть между регионами. Дополнительные сведения см. в разделе "Проектирование архитектуры рабочей области Log Analytics".
Сеть При развертывании сетевой топологии, Виртуальная глобальная сеть или традиционного концентратора и периферийных устройств разверните сеть в новом регионе Azure. Создайте другой сетевой концентратор, развернув необходимые сетевые ресурсы в существующей подписке на подключение в новом регионе Azure. Диспетчер виртуальная сеть Azure может упростить развертывание виртуальных сетей и управление ими в большом масштабе в нескольких регионах. С точки зрения системы доменных имен (DNS) также может потребоваться развернуть серверы пересылки, если вы их используете, в новом регионе Azure. Используйте серверы пересылки для периферийных виртуальных сетей в новом регионе для разрешения. Зоны Azure DNS — это глобальные ресурсы, которые не привязаны к одному региону Azure, поэтому они не требуют каких-либо действий.
Идентификация Если вы развернули домен Active Directory службы или доменные службы Microsoft Entra в подписке удостоверения или периферийных службах, разверните службу в новом регионе Azure.

Примечание.

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

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

Обобщенный подход

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

Сеть

Традиционная архитектура концентратора и периферийной архитектуры

Совет

См. традиционную архитектуру концентратора и периферийной архитектуры.

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

  2. В рамках подписки создайте новую группу ресурсов в новом целевом регионе.

  3. Создайте виртуальную сеть концентратора в новом целевом регионе.

  4. При необходимости разверните виртуальные Брандмауэр Azure или виртуальные сетевые (модуль) (NVA) в новой виртуальной сети концентратора.

  5. При необходимости разверните шлюзы виртуальной сети для подключения VPN или ExpressRoute и установите подключения. Убедитесь, что каналы ExpressRoute и локальные расположения соответствуют рекомендациям по устойчивости Майкрософт. Дополнительные сведения см. в статье "Проектирование аварийного восстановления с помощью частного пиринга ExpressRoute".

  6. Установите пиринг между новой виртуальной сетью концентратора и другими виртуальными сетями концентратора.

  7. Создайте и настройте любую необходимую маршрутизацию, например Azure Route Server или определяемые пользователем маршруты.

  8. При необходимости разверните dns-серверы пересылки для нового целевого региона и свяжите все частные зоны DNS, чтобы включить разрешение имен.

    • Некоторые клиенты могут настроить разрешение имен на контроллерах домена Windows Server Active Directory в подписке целевой зоны платформы удостоверений .

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

Совет

виртуальная сеть Manager может упростить развертывание виртуальных сетей и управление ими в большом масштабе в нескольких регионах.

Архитектура Виртуальной глобальной сети

Совет

См. архитектуру Виртуальная глобальная сеть.

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

  2. Разверните Брандмауэр Azure или другие поддерживаемые виртуальные (модуль) сети (NVA) в новом виртуальном концентраторе. Настройте Виртуальная глобальная сеть намерения маршрутизации и политики маршрутизации для маршрутизации трафика через новый защищенный виртуальный концентратор.

  3. При необходимости разверните шлюзы виртуальной сети для подключения VPN или ExpressRoute в новом виртуальном концентраторе и установите подключения. Убедитесь, что каналы ExpressRoute и локальные расположения соответствуют рекомендациям по устойчивости Майкрософт. Дополнительные сведения см. в статье "Проектирование аварийного восстановления с помощью частного пиринга ExpressRoute".

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

  5. При необходимости разверните серверы пересылки DNS для нового целевого региона и свяжите все частные зоны DNS для включения разрешения.

    • Некоторые клиенты могут настроить разрешение имен на контроллерах домена Active Directory в подписке целевой зоны платформы удостоверений .

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

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

Идентификация

Совет

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

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

  2. Создайте новую группу ресурсов в новом целевом регионе.

  3. Создайте виртуальную сеть в новом целевом регионе.

  4. Создайте пиринг виртуальной сети обратно в только что созданную виртуальную сеть регионального концентратора в подписке Подключение ivity.

  5. Развертывание рабочих нагрузок удостоверений, таких как виртуальные машины контроллера домена Active Directory, в новой виртуальной сети.

    • Возможно, потребуется выполнить дополнительную настройку рабочих нагрузок после их подготовки, например следующие действия по настройке:

      • Повышение уровня виртуальных машин контроллера домена Active Directory до существующего домена Active Directory.

      • Создайте новые сайты и подсети Active Directory.

      • Настройте параметры DNS-сервера, такие как условные серверы пересылки.

Перемещение своего имущества Azure в новый регион

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

Примечание.

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

Конфигурация глобальной целевой зоны

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

Ресурсы региональной целевой зоны

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

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

  2. Развертывание централизованных компонентов в целевом регионе: например, разверните новую рабочую область журналов Azure Monitor в целевом регионе, чтобы рабочие нагрузки могли начать использовать новый компонент после переноса рабочей нагрузки.

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

  4. Отмена эксплуатации ресурсов в исходном регионе после завершения миграции.

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

  • Используйте инфраструктуру в качестве кода: используйте Bicep, шаблоны Azure Resource Manager (шаблоны ARM), Terraform, скрипты или аналогичный подход к экспорту и повторному использованию сложных конфигураций, таких как правила для Брандмауэр Azure.

  • Автоматизация. Использование скриптов для переноса ресурсов службы автоматизации между регионами.

  • ExpressRoute: рассмотрите, можно ли использовать локальный номер SKU ExpressRoute в целевом регионе. Если локальные среды находятся в той же городской области, что и регион Azure, ExpressRoute Local может предоставить более низкий вариант по сравнению с другими номерами SKU ExpressRoute.

Следующий шаг

Улучшение управления целевой зоной