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

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

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

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

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

• Необязательные зоны доступности, если этот регион поддерживает его.

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

Это важно

Функция хранения данных клиентов в одном регионе в настоящее время доступна только для региона "Юго-Восточная Азия (Сингапур)" в Азиатско-Тихоокеанском географическом регионе. Для всех других регионов данные клиента хранятся в геообъектах.

Это важно

Изменения инфраструктуры службы управления API (например, настройка пользовательских доменов, добавление сертификатов ЦС, масштабирование, конфигурация виртуальной сети, изменения зоны доступности и дополнения регионов) могут занять 15 минут или больше времени, в зависимости от уровня служб и размера развертывания. Ожидается больше времени для экземпляра с большим числом единиц масштабирования или конфигурацией с несколькими регионами. Изменения в управлении API внедряются постепенно и тщательно для сохранения производительности и доступности.

В то время как служба обновляется, другие изменения инфраструктуры служб не могут быть сделаны. Однако вы можете настроить API, продукты, политики и параметры пользователя. Служба не столкнется с простоем шлюза, а управление 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 в дополнительном регионе

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.

Замечание

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

Чтобы отключить региональный шлюз с помощью 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 в виртуальную сеть.

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

Это важно

При настройке в режиме внутренней виртуальной сети каждый региональный шлюз также должен иметь исходящее подключение через порт 1433 к базе данных SQL Azure, настроенной для экземпляра управления API, который находится только в основном регионе. Убедитесь, что вы разрешаете подключение к полному доменному имени или IP-адресу этой базы данных Azure SQL в любых маршрутах или правилах брандмауэра, которые вы настраиваете для сетей во вторичных регионах; тег службы Azure SQL нельзя использовать в этом сценарии. Чтобы найти имя базы данных SQL Azure в основном регионе, перейдите на страницусостояния сети> экземпляра службы управления API на портале.

IP-адреса

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

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

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

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

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

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

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

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

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

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

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

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

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