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

ОБЛАСТЬ ПРИМЕНЕНИЯ: Premium

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

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

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

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

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

Внимание

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

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

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

• Если вы хотите настроить дополнительное расположение для экземпляра Управление API при его развертывании (внедрение) в виртуальной сети, виртуальная сеть и регион подсети должны соответствовать дополнительному расположению, которое вы настраиваете. Если вы добавляете, удаляете или включаете зону доступности в основном регионе или изменяете подсеть основного региона, ip-адрес вашего экземпляра Управление API изменится. Дополнительные сведения см. в разделе IP-адреса службы azure Управление API. Однако если вы добавляете дополнительный регион, ip-адрес основного региона не изменится, так как каждый регион имеет собственный частный ВИРТУАЛЬНЫЙ 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 с использованием последней конфигурации шлюза.

Необходимые компоненты

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

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

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

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

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

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

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

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

1. Перейдите к экземпляру Azure Управление 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 в диспетчер трафика и разрешить автоматическую маршрутизацию.

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

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

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

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

1. Создайте собственный диспетчер трафика Azure.
2. Если вы используете личный домен, используйте его с Диспетчер трафика вместо службы Управление API.
3. Настройте в диспетчере трафика региональные конечные точки управления API. Региональные конечные точки соответствуют шаблону URL-адреса https://<service-name>-<region>-01.regional.azure-api.net, например 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-адрес регионального шлюза, перенаправляется в другой регион.

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

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

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

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

Внимание

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

IP-адреса

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

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

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

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

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

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

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

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

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

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

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

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

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