Развертывание экземпляра службы "Управление 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 развернут в виртуальной сети, убедитесь, что вы настроили виртуальную сеть и подсеть в расположении, которое планируется добавить, и в той же подписке. См. предварительные требования к виртуальной сети.

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

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

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

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

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

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

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

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

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. Создайте собственный диспетчер трафика Azure.
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" Azure

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

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