Обеспечение доступности и надежности Управление API

  • Статья

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

В этой статье представлен обзор возможностей службы, чтобы убедиться, что экземпляр Управление API продолжает обслуживать запросы API, если происходит сбой Azure.

Управление API предоставляет следующие возможности для надежных и устойчивых решений Azure. Используйте их по отдельности или вместе для повышения доступности:

  • Зоны доступности: устойчивость к сбоям на уровне центра обработки данных

  • Развертывание в нескольких регионах: устойчивость к региональным сбоям

Примечание.

Зоны доступности

Зоны доступности Azure — это физически отдельные расположения в регионе Azure, которые терпимы к сбоям на уровне центра обработки данных. Каждая зона состоит из одного или нескольких центров обработки данных, оснащенных независимыми системами электроснабжения и охлаждения, а также сетевыми инфраструктурами. Чтобы обеспечить устойчивость, в всех регионах с поддержкой зон доступности присутствует не менее 3 отдельных зон доступности. Подробнее

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

При включении избыточности зоны в регионе следует учитывать количество единиц масштабирования Управление API, которые необходимо распределить. Минимально настройте то же количество единиц, что и количество зон доступности, или несколько, чтобы единицы распределялись равномерно по зонам. Например, если выбрать 3 зоны доступности в регионе, можно иметь 3 единицы, чтобы каждая зона размещала одну единицу.

Примечание.

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

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

При развертывании с несколькими регионами можно добавить региональные шлюзы 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 предоставляет соглашение об уровне обслуживания 99,99 % при развертывании по крайней мере одного урока в двух или нескольких зонах доступности или регионах. Дополнительные сведения см. на странице цен.

Примечание.

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

Доступность серверной части

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

Региональные серверные части

Вы можете управлять региональными серверными службами и обрабатывать отработку отказа с помощью Управление API для поддержания доступности. Например:

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

  • Настройте политики для маршрутизации запросов условно в разные серверные части, если в определенном регионе произошел сбой серверной части.

  • Используйте кэширование для уменьшения неудачных вызовов.

Дополнительные сведения см. в записи блога о избыточности внутреннего API с помощью диспетчера API Azure.

Настройка свойств серверной части для доступности

Управление API сущности серверной части позволяют управлять и применять внутренние свойства для повышения доступности внутренних компонентов. Например:

  • Распределение и балансировка нагрузки трафика в пул URL-адресов
  • Настройка правил разбиения цепи для применения шаблона разбиения цепи для защиты серверной части от слишком большого количества запросов

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