Развертывание экземпляра Управления 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 в виртуальную сеть.

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

Внимание

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