Развертывание экземпляра службы "Управление API Azure" в нескольких регионах Azure

ОБЛАСТЬ ПРИМЕНЕНИЯ: Премиум

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

При добавлении региона вы настраиваете:

• Количество единиц масштабирования, которое будет размещаться в регионе.

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

• Параметры виртуальной сети в добавленном регионе, если сеть настроена в существующем регионе или регионах.

Сведения о развертывании в нескольких регионах

• Только компонент шлюза вашего экземпляра управления API реплицируется в несколько регионов. Плоскость управления экземпляра и портал разработчика остаются размещенными только в основном регионе, регионе, где изначально развернута служба.

• Если вы хотите настроить дополнительное расположение для экземпляра службы управления API при его развертывании (интеграции) в виртуальной сети, виртуальная сеть и регион субсети должны соответствовать дополнительному расположению, которое вы хотите настроить. Если вы добавляете, удаляете или включаете зону доступности в основной регион, или если вы изменяете подсеть основного региона, VIP-адрес вашего экземпляра API Management изменится. Дополнительные сведения см. в разделе IP-адреса службы Управление API Azure. Однако если вы добавляете дополнительный регион, ВИП основного региона не изменится, так как у каждого региона есть свой собственный частный виртуальный IP-адрес.

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

• Когда система управления API получает общедоступные HTTP-запросы к конечной точке диспетчера трафика (это актуально для внешних виртуальных сетей и несетевых режимов системы управления API), трафик направляется к региональному шлюзу с наименьшей задержкой, что помогает снизить задержку, которую испытывают географически распределенные потребители API. В режиме внутренней виртуальной сети клиенты должны настроить собственное решение для маршрутизации и балансировки нагрузки трафика через региональные шлюзы. Дополнительные сведения см. в разделе "Рекомендации по работе с сетями".

• Шлюз в каждом регионе (включая основной регион) имеет региональное DNS-имя, которое следует шаблону https://<service-name>-<region>-01.regional.azure-api.netURL-адреса, например https://contoso-westus2-01.regional.azure-api.net.

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

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

• Если настроено, количество вызовов политик ограничения скорости и ограничения скорости по ключу по каждому региональному шлюзу в развертывании. Политики не агрегируют все данные вызова для экземпляра. Аналогичным образом, политики azure-openai-token-limit и llm-token-limit учитывают использование маркеров отдельно на каждом региональном шлюзе в процессе развертывания.

Предпосылки

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

• Если вы не создали экземпляр службы управления API, см. статью "Создание экземпляра службы управления API". Выберите уровень служб "Премиум".

• Если экземпляр управления API развернут в виртуальной сети, убедитесь, что вы настроили виртуальную сеть и подсеть в расположении, которое планируется добавить, и в той же подписке. См. предварительные требования к виртуальной сети.

Развертывание службы Управление API в дополнительном регионе

1. На портале Azure перейдите в службу управления API и выберите "Расположения " в меню слева.
2. Нажмите кнопку +Добавить в верхней строке.
3. Выберите добавленное место из списка.
4. Выберите количество единиц шкалы в указанном месте.
5. Если регион поддерживает зоны доступности, оставьте параметр "Автоматический " (рекомендуется) или выберите одну или несколько зон. При выборе определенных зон количество единиц, которые вы выбрали, должно равномерно распределяться по зонам доступности. Например, при выборе трех единиц необходимо выбрать три зоны, чтобы каждая зона размещала одну единицу.
6. Если экземпляр службы управления API развертывается в виртуальной сети, настройте параметры виртуальной сети в расположении, включая виртуальную сеть, подсеть и общедоступный IP-адрес.
7. Нажмите кнопку "Добавить ", чтобы подтвердить.
8. Повторите этот процесс, пока не настроите все расположения.
9. Нажмите кнопку "Сохранить " на верхней панели, чтобы запустить процесс развертывания.

Удаление региона службы управления API

1. На портале Azure перейдите в службу управления API и выберите "Расположения " в меню слева.
2. Чтобы удалить позицию, выберите контекстное меню с помощью кнопки ... в правом конце таблицы. Нажмите кнопку "Удалить".
3. Подтвердите удаление и нажмите кнопку "Сохранить ", чтобы применить изменения.

Маршрутизация вызовов API в региональные серверные службы

По умолчанию каждый API направляет запросы на один URL-адрес серверной службы. Даже если вы настраиваете шлюзы управления API в различных регионах, шлюз API по-прежнему перенаправляет запросы в ту же серверную службу, которая развертывается только в одном регионе. В этом случае улучшенная производительность происходит только из ответов, кэшированных в службе управления API в регионе, конкретном запросу. Связь с серверной частью по всему миру может по-прежнему вызвать высокую задержку.

Чтобы воспользоваться преимуществами географического распределения системы, необходимо развернуть внутренние службы в тех же регионах, что и экземпляры службы управления API. Затем с помощью политик и @(context.Deployment.Region) свойства можно перенаправлять трафик в локальные экземпляры серверной части.

1. Перейдите к экземпляру службы управления API и выберите API в меню слева.

2. Выберите нужный API.

3. На вкладке "Конструктор " в разделе " Входящий процесс обработки " выберите редактор кода.

   

4. set-backend Используйте комбинацию условных choose политик, чтобы создать правильную политику маршрутизации в разделе <inbound> </inbound> файла.

   Например, следующий XML-файл будет работать для регионов западной части США и Восточной Азии:

   <policies>
       <inbound>
           <base />
           <choose>
               <when condition="@("West US".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                   <set-backend-service base-url="http://contoso-backend-us.com/" />
               </when>
               <when condition="@("East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                   <set-backend-service base-url="http://contoso-backend-asia.com/" />
               </when>
               <otherwise>
                   <set-backend-service base-url="http://contoso-backend-other.com/" />
               </otherwise>
           </choose>
       </inbound>
       <backend>
           <base />
       </backend>
       <outbound>
           <base />
       </outbound>
       <on-error>
           <base />
       </on-error>
   </policies>
   

Использование диспетчера трафика для маршрутизации в региональные серверы

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

• Для распределения трафика и обеспечения отказоустойчивости рекомендуется использовать Traffic Manager с методом географической маршрутизации. Не рекомендуется использовать Traffic Manager с методом взвешенной маршрутизации вместе с серверными частями API Management.

• Для управления трафиком во время операций обслуживания рекомендуется использовать метод маршрутизации приоритета.

Использование пользовательской маршрутизации для региональных шлюзов управления API

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

1. Создайте собственный диспетчер трафика.
2. Если вы используете личный домен, используйте его с диспетчером трафика вместо службы управления API.
3. Настройте региональные конечные точки управления API в диспетчере трафика. Региональные конечные точки соответствуют шаблону https://<service-name>-<region>-01.regional.azure-api.netURL-адреса, например https://contoso-westus2-01.regional.azure-api.net.
4. Настройте конечные точки регионального состояния управления API в диспетчере трафика. Конечные точки состояния региона следуют шаблону URL-адреса https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, например, https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.
5. Укажите метод маршрутизации диспетчера трафика.

Отключение маршрутизации в региональный шлюз

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

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

Чтобы отключить маршрутизацию к региональному шлюзу в экземпляре службы управления API, обновите значение свойства шлюза disableGateway до true. Значение можно задать с помощью REST API создания или обновления службы , команды az apim update в Azure CLI, командлета Azure PowerShell set-azapimanagement Azure или других средств Azure.

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

1. Используйте команду az apim show , чтобы отобразить расположения, состояние шлюза и региональные URL-адреса, настроенные для экземпляра службы управления API.

   az apim show --name contoso --resource-group apim-hello-world-resource \
       --query "additionalLocations[].{Location:location,Disabled:disableGateway,Url:gatewayRegionalUrl}" \
       --output table
   

   Пример выходных данных:

   Location    Disabled    Url
   ----------  ----------  ------------------------------------------------------------
   West US 2   True        https://contoso-westus2-01.regional.azure-api.net
   West Europe True        https://contoso-westeurope-01.regional.azure-api.net
   

2. Используйте команду az apim update , чтобы отключить шлюз в доступном расположении, например западная часть США 2.

   az apim update --name contoso --resource-group apim-hello-world-resource \
   --set additionalLocations[location="West US 2"].disableGateway=true
   

   Обновление может занять несколько минут.

3. Убедитесь, что трафик, направленный на URL-адрес регионального шлюза, перенаправляется в другой регион.

Чтобы восстановить маршрутизацию к региональному шлюзу, установите значение disableGateway в false.

Виртуальная сеть

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

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

IP-адреса

• Общедоступный виртуальный IP-адрес создается в каждом регионе, созданном посредством виртуальной сети. Для виртуальных сетей в внешнем иливнутреннем режиме этот общедоступный IP-адрес используется для трафика управления через порт 3443.

  • Режим внешней виртуальной сети: Общедоступные IP-адреса также необходимы для маршрутизации общедоступного HTTP-трафика в шлюзы API.

  • Внутренний режим виртуальной сети: Частный IP-адрес также создается в каждом регионе, добавленном с виртуальной сетью. Используйте эти адреса для подключения в сети к конечным точкам управления API в основных и вторичных регионах.

Маршрутизация

• Режим внешней виртуальной сети: Маршрутизация общедоступного HTTP-трафика в региональные шлюзы обрабатывается автоматически так же, как и для экземпляра управления API, отличного от сети.

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

Связанный контент

• Дополнительные сведения о надежности в службе управления API

• Дополнительные сведения о включении поддержки зон доступности для экземпляра службы управления API.

• Дополнительные сведения о виртуальных сетях и управлении API см. в следующем разделе:

  • Подключение к виртуальной сети с помощью управления API

  • Подключение к виртуальной сети в внутреннем режиме с помощью управления API

  • IP-адреса управления API