Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Управление API Azure — это полностью управляемая служба, которая помогает организациям публиковать, защищать, преобразовывать, поддерживать и отслеживать API. Как служба Azure, управление API предоставляет ряд возможностей для поддержки ваших требований к надежности.
При использовании Azure надежность является общей ответственностью. Корпорация Майкрософт предоставляет ряд возможностей для поддержки устойчивости и восстановления. Вы несете ответственность за понимание того, как работают эти возможности во всех используемых вами службах, а также за выбор возможностей, необходимых для достижения бизнес-целей и целей бесперебойной работы.
В этой статье описывается, как обеспечить устойчивость управления API к различным потенциальным сбоям и проблемам, включая временные сбоя, сбоя зоны доступности, сбоя регионов и обслуживание служб. В нем также описывается, как использовать резервные копии для восстановления из других типов проблем и выделяет некоторые ключевые сведения о соглашении об уровне обслуживания управления API (SLA).
Обзор архитектуры надежности
Управление API использует архитектуру на основе единиц масштабирования для обеспечения встроенной избыточности и масштабируемости. При развертывании экземпляра API Management вы настраиваете одну или несколько единиц масштабирования или структурных единиц. Каждое подразделение представляет собой логическое представление емкости, содержащей необходимые вычислительные ресурсы для обработки запросов API.
Единицы
Каждая единица состоит из двух вычислительных ресурсов (виртуальных машин или аналогичных серверов в зависимости от уровня служб), обрабатывающих запросы API вместе. Эти виртуальные машины или другие серверы не отображаются. Платформа автоматически управляет их созданием и мониторингом работоспособности. Если один вычислительный ресурс выходит из строя, система продолжает работать, но с пониженной производительностью, обеспечивая некоторую встроенную надежность.
При настройке экземпляра с двумя или более единицами доступные единицы работают вместе для обработки запросов и обеспечения автоматической балансировки нагрузки. Если один из единиц становится недоступным, остальные единицы продолжают обрабатывать трафик, но с потенциально уменьшенной емкостью.
Для повышения надежности управление API поддерживает распределение единиц между зонами доступности в пределах региона и в нескольких регионах.
Замечание
Управление API использует модульные единицы для компонентов шлюза. Единицы не применимы к порталу разработчика или плоскости управления.
Уровни обслуживания
Уровни служб управления API обеспечивают различные уровни надежности:
Уровень "Премиум" (классический): Поддерживает несколько единиц, которые можно распределить между зонами доступности и регионами для максимальной устойчивости.
Уровень "Премиум" версии 2. Поддерживает несколько единиц, которые могут быть распределены по зонам доступности. В настоящий момент не предусмотрена поддержка развертываний с несколькими регионами.
Уровни "Базовый" версии 2, "Стандартный" и "Стандартный" версии 2: Все поддерживают несколько единиц в одном центре обработки данных. Они не поддерживают зоны доступности или развертывания с несколькими регионами.
Уровень разработчика: Поддерживает только одну единицу и не обеспечивает поддержку зоны доступности или нескольких регионов. Этот уровень предназначен для сценариев разработки и тестирования. Он не подходит для рабочих нагрузок.
Уровень потребления: Имеет встроенные возможности устойчивости и устойчив к различным сбоям в одном центре обработки данных Azure. Тарифный план Consumption не поддерживает зоны доступности или развертывания в нескольких регионах. Чтобы понять ожидаемое время простоя экземпляра управления API уровня потребления, ознакомьтесь с соглашением об уровне обслуживания (SLA).
Замечание
Уровни разработчика и уровня "Премиум" службы "Управление API" поддерживают локальные шлюзы, которые можно запускать в собственной инфраструктуре. При использовании локально размещенных шлюзов вы несете ответственность за настройку шлюзов в соответствии с требованиями к надежности. Локальные шлюзы находятся вне области этой статьи.
Рекомендации по развертыванию в производственной среде
Платформа Azure Well-Architected предоставляет рекомендации по надежности, производительности, безопасности, затратам и операциям. Чтобы понять, как эти области влияют друг на друга и вносят свой вклад в надежное решение для управления API, см. рекомендации по архитектуре для управления API.
Устойчивость к временным сбоям
Временные ошибки являются короткими, периодическими сбоями в компонентах. Они часто происходят в распределенной среде, такой как облачная платформа, и являются обычной частью операций. Временные ошибки исправляют себя через короткий период времени. Важно, чтобы приложения могли обрабатывать временные ошибки, обычно повторяя затронутые запросы.
Все облачные приложения должны следовать рекомендациям по обработке временных ошибок Azure при обмене данными с любыми размещенными в облаке API, базами данных и другими компонентами. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.
При использовании управления API перед API может потребоваться повторить запросы, которые завершаются сбоем из-за временных сбоев. Чтобы защитить внутренний API от перегрузки слишком большого количества запросов, управление API предоставляет повторные попытки, ограничение скорости и политики квот. Вы также можете настроить возможности балансировки нагрузки и разбиения цепи с помощью внутренних ресурсов.
Устойчивость к сбоям зоны доступности
Зоны доступности — это физически отдельные группы центров обработки данных в регионе Azure. При сбое одной зоны службы могут переключиться на одну из оставшихся зон.
Чтобы просмотреть сведения о поддержке зоны доступности для уровней Premium и Premium версии 2, обязательно выберите соответствующий уровень служб в начале этой страницы.
Управление API предоставляет два типа поддержки зоны доступности при развертывании экземпляра управления API класса Premium (классической) в поддерживаемом регионе:
Автоматическое (рекомендуемое): управление API обеспечивает автоматическую поддержку зоны доступности, если не указать, какие зоны доступности следует использовать.
Вручную: Управление API обеспечивает поддержку зоны доступности вручную при явном указании используемых зон доступности.
Благодаря поддержке зоны доступности управление API реплицирует компоненты службы в разных зонах для обеспечения высокой доступности. В основном регионе эти компоненты включают шлюз (единицы масштабирования), плоскость управления и портал разработчика. В вторичных регионах реплицируются только устройства шлюза. Дополнительные сведения о дополнительных регионах см. в статье об устойчивости к сбоям на уровне региона.
Поддержка автоматической зоны доступности
Вы можете использовать поддержку автоматической зоны доступности, чтобы выбрать одну единицу или конфигурацию нескольких экземпляров для обеспечения избыточности зоны:
Конфигурация с несколькими единицами (рекомендуется). Если у экземпляра есть два или более единиц, управление API пытается распределить единицы экземпляра между зонами доступности региона. Вы не можете определить, в какие зоны доступности помещаются ваши ресурсы. Разверните не менее двух единиц, которые можно распределить между двумя зонами.
На следующей схеме показан экземпляр службы управления API с тремя единицами, настроенными для поддержки зоны автоматической доступности:
На схеме показаны три поля, помеченные как Unit 1, Unit 2 и Unit 3, развернутые в экземпляре управления API. Каждая коробка блока содержит два значка виртуальной машины, представляющие вычислительные ресурсы. Три больших поля помечены как зона доступности 1, зона доступности 2 и зона доступности 3. Зона 1 содержит единицу 1, зона 2 содержит единицу 2, а зона 3 содержит единицу 3.
Конфигурация с одним узлом: Если у экземпляра есть один узел, его базовые вычислительные ресурсы распределены по двум зонам доступности. Вы не можете определить, в какие зоны доступности помещаются вычислительные ресурсы единицы.
На схеме показано одно поле с меткой Unit 1, развернутое в экземпляре службы управления API. Поле единицы содержит два значка виртуальной машины, представляющих вычислительные ресурсы. Три больших поля помечены как зона доступности 1, зона доступности 2 и зона доступности 3. Поле "Единица 1" охватывает зоны 1 и 2. Зона 3 пуста.
Поддержка зоны доступности вручную
Если вы хотите явно выбрать используемые зоны доступности, можно выбрать между зонально-избыточными и зональными конфигурациями:
Избыточность между зонами: Вручную настройте избыточность зоны для экземпляра службы управления API в поддерживаемом регионе, чтобы обеспечить избыточность компонентов службы. При выборе двух или нескольких зон доступности Azure автоматически реплицирует компоненты службы в выбранных зонах.
На схеме показаны три поля, помеченные как Unit 1, Unit 2 и Unit 3, развернутые в экземпляре управления API. Каждый блок содержит два значка VM, представляющие вычислительные ресурсы. Три больших поля помечены как зона доступности 1, зона доступности 2 и зона доступности 3. Зона 1 содержит единицу 1, зона 2 содержит единицу 2, а зона 3 содержит единицу 3.
Зональный: Компоненты службы управления API развертываются в одной зоне, выбранной в регионе Azure. Все единицы помещаются в одну зону доступности.
На схеме показаны два поля с метками Unit 1 и Unit 2, развернутые в экземпляре службы управления API. Коробка каждой единицы содержит две иконки виртуальной машины, которые представляют вычислительные ресурсы. Три больших поля помечены как зона доступности 1, зона доступности 2 и зона доступности 3. Зона 1 содержит поля "Единица 1" и "Единица 2". Зона 2 и Зона 3 не содержат никаких единиц.
Это важно
Закрепление к одной зоне доступности только в том случае, если задержка между зонами слишком высока для ваших потребностей, и после проверки того, что задержка не соответствует вашим требованиям. По себе зональный экземпляр не обеспечивает устойчивость к сбоям зоны доступности. Чтобы повысить устойчивость развертывания управления API зональной архитектуры, необходимо явно развернуть отдельные экземпляры в разных зонах доступности и настроить маршрутизацию трафика и резервирование на случай отказа.
В пакете Premium v2 можно включить зональную избыточность для экземпляра службы управления API в поддерживаемом регионе.
С поддержкой зоны доступности управление API реплицирует шлюз (единицы масштабирования), плоскость управления и портал разработчика. Вы можете выбрать либо конфигурацию одного узла, либо нескольких узлов для обеспечения избыточности зоны.
Конфигурация с несколькими единицами (рекомендуется). Если у экземпляра есть два или более единиц, управление API пытается распределить единицы экземпляра между зонами доступности региона. Вы не можете определить, в какие зоны доступности размещаются ваши технические единицы. Разверните не менее двух единиц, которые можно распределить между двумя зонами.
На следующей схеме показан экземпляр службы управления API с тремя единицами, настроенными для поддержки зоны доступности:
На схеме показаны три поля, помеченные как Unit 1, Unit 2 и Unit 3, развернутые в экземпляре управления API. Каждая коробка содержит два значка виртуальных машин, представляющие вычислительные ресурсы. Три больших поля помечены как зона доступности 1, зона доступности 2 и зона доступности 3. Зона 1 содержит единицу 1, зона 2 содержит единицу 2, а зона 3 содержит единицу 3.
Конфигурация с одним блоком: Если у инстанции есть один модуль, базовые вычислительные ресурсы модуля распределяются по двум зонам доступности. Вы не можете определить, в какие зоны доступности помещаются вычислительные ресурсы единицы.
На схеме показано одно поле с меткой Unit 1, развернутое в экземпляре службы управления API. Блок содержит два значка ВМ, символизирующие вычислительные ресурсы. Три больших поля помечены как зона доступности 1, зона доступности 2 и зона доступности 3. Поле "Единица 1" охватывает зоны 1 и 2. Зона 3 пуста.
Требования
Поддержка региона: Управление API поддерживает зоны доступности для уровней "Премиум" (классическая) и "Премиум" версии 2 в регионах, где доступен уровень управления API, а регион поддерживает зоны доступности.
Требование уровня: Для настройки поддержки зоны доступности необходимо использовать уровень "Премиум" (классическая) или "Премиум" версии 2. Управление API в настоящее время не поддерживает зоны доступности в классических уровнях "Потребление", "Разработчик", "Базовый" и "Стандартный" или на уровнях "Базовый" версии 2 и "Стандартный". Сведения о параметрах обновления см. в статье об обновлении и масштабировании экземпляра службы управления API.
Соображения
Количество единиц для зонально-избыточных экземпляров: Если вы вручную настроите зональную избыточность для экземпляра, необходимо также настроить количество единиц API Management, которые можно равномерно распределять во всех выбранных зонах доступности. Например, если выбрать две зоны, необходимо сконфигурировать по крайней мере две единицы. Вместо этого можно настроить четыре единицы или еще несколько из двух единиц. При выборе трех зон доступности необходимо настроить три единицы, шесть единиц или другое количество, кратное трем единицам.
Если вы используете поддержку автоматической зоны доступности, не требуется использовать определенное количество единиц. Развернутые единицы распределяются между зонами доступности наилучшим образом. Для обеспечения максимальной избыточности зоны используйте не менее двух единиц, чтобы сбой зоны доступности не влиял на производительность шлюза.
Чтобы определить количество единиц, которые обеспечивают необходимую производительность шлюза, используйте метрики емкости и собственное тестирование. Дополнительные сведения о масштабировании и обновлении экземпляра службы см. в статье Об обновлении и масштабировании экземпляра службы управления API.
Автомасштабирование: Если вы вручную настраиваете зоны доступности в экземпляре службы управления API, настроенном с автомасштабированием, может потребоваться настроить параметры автомасштабирования после настройки. В этом случае количество единиц управления API в правилах автомасштабирования и ограничениях должно быть кратным числом зон. Если вы используете поддержку автоматической зоны доступности, вам не нужно настраивать параметры автомасштабирования.
Требования к IP-адресу: Если включить поддержку зоны доступности в экземпляре службы управления API, развернутом во внешней или внутренней виртуальной сети, необходимо указать ресурс общедоступного IP-адреса для использования экземпляра. В внутренней виртуальной сети общедоступный IP-адрес используется только для операций управления, а не для запросов API. Дополнительные сведения см. в разделе "IP-адреса" в службе "Управление API".
Соображения
Количество единиц для экземпляров с зональной избыточностью: В версии Premium v2 нет необходимости использовать определенное количество единиц. Развернутые единицы распределяются между зонами доступности наилучшим образом. Для обеспечения максимальной избыточности зоны используйте не менее двух единиц, чтобы обеспечить достаточную емкость, чтобы сбой зоны доступности не влиял на производительность шлюза.
Чтобы определить количество единиц, которые обеспечивают необходимую производительность шлюза, используйте метрики емкости и собственное тестирование. Дополнительные сведения о масштабировании и обновлении экземпляра службы см. в статье Об обновлении и масштабировании экземпляра службы управления API.
Автомасштабирования: На уровне "Премиум" версии 2 не требуется настраивать параметры автомасштабирования при включении поддержки зоны доступности.
Себестоимость
Независимо от конфигурации зоны доступности, при добавлении дополнительных единиц вам потребуется больше затрат. Для получения информации см. Цены на управление API.
Настройка поддержки зоны доступности
В этом разделе объясняется, как настроить поддержку зоны доступности для экземпляра службы управления API. Дополнительные сведения см. в разделе "Включение поддержки зоны доступности" в экземплярах управления API.
Создайте экземпляр службы управления API, поддерживающий зоны доступности: При создании экземпляра управления API класса Premium (классической) в регионе, поддерживающем зоны доступности, экземпляр поддерживает зоны доступности по умолчанию. Вы можете выбрать автоматическую поддержку зон доступности или вручную настроить зональную либо избыточную поддержку.
Замечание
При выборе используемых зон доступности вы фактически выбираете логическую зону доступности. При развертывании других компонентов рабочей нагрузки в другой подписке Azure они могут использовать другой номер логической зоны доступности для доступа к той же физической зоне доступности. Дополнительные сведения см. в разделе "Физические и логические зоны доступности".
Включение или перенастройка поддержки зоны доступности: Можно изменить конфигурацию зоны доступности для экземпляра службы управления API, включая добавление зональных зон доступности и перемещение зонального экземпляра между зонами доступности. Сведения о настройке поддержки зоны доступности в экземпляре службы управления API см. в статье "Включение поддержки зоны доступности" в экземплярах управления API. Ни один из параметров конфигурации не требует простоя.
При изменении конфигурации зоны доступности изменения могут занять 15–45 минут или более. Шлюз Управление API может продолжать обрабатывать запросы API в течение этого времени.
Изменение конфигурации зоны доступности активирует изменение общедоступного и частного IP-адреса.
Настройка поддержки зоны доступности
В этом разделе объясняется, как настроить поддержку зоны доступности для экземпляра службы управления API. Дополнительные сведения см. в разделе "Включение поддержки зон доступности на экземплярах управления API".
Создайте экземпляр службы управления API, поддерживающий зоны доступности: На уровне "Премиум" версии 2 при необходимости включите избыточность зоны при создании экземпляра службы управления API в регионе, поддерживающем зоны доступности. Если отказоустойчивость зоны не может быть включена из-за ограничений емкости или других проблем, развертывание службы будет неуспешным.
Включение или перенастройка поддержки зоны доступности: После создания экземпляра невозможно изменить конфигурацию зоны доступности.
Планирование ресурсов и управление ими
В сценарии уменьшения зоны не гарантируется, что запросы на дополнительную емкость в другой зоне доступности успешно выполнены. Резервное заполнение потерянных единиц происходит на основе лучших усилий. Если вам нужна гарантированная емкость при сбое зоны доступности, создайте и настройте экземпляр службы управления API для учета потери зоны, выполнив все следующие действия:
Переоставьте единицы экземпляра службы управления API.
Используйте конфигурацию зоны доступности, избыточной по зонам автоматического или избыточного между зонами.
Дополнительные сведения см. в разделе Управление емкостью с помощью чрезмерного выделения.
Используйте метрики емкости и собственное тестирование, чтобы определить количество единиц, которые обеспечивают необходимую производительность шлюза. Дополнительные сведения о масштабировании и обновлении экземпляра службы см. в статье Об обновлении и масштабировании экземпляра службы управления API.
Поведение, когда все зоны работоспособны
В этом разделе описывается, что ожидать, когда экземпляры службы управления API настроены с поддержкой зоны доступности и всеми зонами доступности работают.
Маршрутизация трафика между зонами: Во время обычных операций трафик направляется между всеми доступными единицами управления API во всех выбранных зонах доступности.
Репликация данных между зонами: Управление API хранит и реплицирует следующие данные.
Конфигурация шлюза, например API и определения политик, регулярно синхронизируется между зонами доступности, которые вы выбираете для экземпляра. Распространение обновлений между зонами доступности обычно занимает менее 10 секунд.
Данные во внутреннем кэше, если используется внутренний кэш, который предоставляет управление API. Записи кэша распределяются между зонами доступности. Внутренний кэш нестабилен, и не гарантируется сохранение данных. Рекомендуется использовать внешний кэш, если необходимо сохранить кэшированные данные.
Счетчики ограничений скорости, если вы используете возможности ограничения скорости, которые предоставляет управление API. Счетчики ограничений скорости асинхронно реплицируются между зонами доступности, которые вы выбираете для экземпляра.
Поведение во время сбоя зоны
В этом разделе описывается, что ожидать, когда экземпляры службы управления API настроены с поддержкой зоны доступности, а также возникает сбой зоны доступности.
Обнаружение и ответ: Ответственность за обнаружение и ответ зависит от конфигурации зоны доступности, используемой экземпляром.
Автоматическое и избыточное между зонами: Для экземпляров, настроенных для использования поддержки автоматической зоны доступности или вручную настроенных для использования избыточности зоны, платформа управления API отвечает за обнаружение сбоя в зоне доступности и реагирование. Вам не нужно ничего делать, чтобы инициировать переключение зоны.
Зональный: Для экземпляров, настроенных как зональные, необходимо обнаружить потерю зоны доступности и инициировать переключение на резервный экземпляр, который создан в другой зоне доступности.
Активные запросы: Если зона доступности недоступна, все выполняемые запросы, которые подключены к блоку управления API в недоступной зоне доступности, завершаются и должны быть повторно выполнены.
- Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Однако вы можете использовать Azure Resource Health для отслеживания работоспособности отдельного ресурса и настроить оповещения о работоспособности ресурсов , чтобы уведомить вас о проблемах. Вы также можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, включая любые сбои зоны, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.
Ожидаемая потеря данных: Управление API хранит следующие данные.
Изменения конфигурации шлюза, которые реплицируются в каждую выбранную зону доступности в течение примерно 10 секунд. Если возникает сбой зоны доступности, изменения конфигурации, которые не реплицируются.
Данные во внутреннем кэше, если вы используете функцию внутреннего кэша. Внутренний кэш нестабилен, и не гарантируется сохранение данных. Во время сбоя зоны доступности некоторые или все кэшированные данные могут быть потеряны. Рекомендуется использовать внешний кэш, если необходимо сохранить кэшированные данные.
Счетчики ограничений скорости, если вы используете функцию ограничения скорости. Во время сбоя зоны доступности счетчики ограничений скорости могут не быть up-to-date в выживших зонах.
Ожидаемое время простоя: Ожидаемое время простоя зависит от конфигурации зоны доступности, используемой экземпляром.
Автоматически: Вы можете ожидать, что экземпляры, использующие поддержку автоматической зоны доступности, не имеют простоя во время сбоя зоны доступности. Единицы в небезопасной зоне или зонах продолжают работать.
Кроме того, можно ожидать, что экземпляры, использующие поддержку зоны автоматической доступности, но имеют одну единицу, чтобы не было простоя. В этом случае управление API распределяет базовые вычислительные ресурсы единицы в две зоны. Ресурс в непострадавшей зоне продолжает работать.
Избыточность между зонами: Вы можете ожидать, что экземпляры, избыточные между зонами, не имеют простоя во время сбоя зоны доступности.
Зональный: Для зональных экземпляров, когда зона недоступна, экземпляр недоступен до восстановления зоны доступности.
Перенаправка трафика: Поведение перенаправки трафика зависит от конфигурации зоны доступности, которую использует ваш экземпляр.
Автоматическое и избыточное между зонами: Для экземпляров, настроенных для использования поддержки автоматической зоны доступности или настроенных вручную для использования избыточности зоны, если зона недоступна, все единицы в затронутой зоне также недоступны. Вы можете масштабировать экземпляр, чтобы добавить дополнительные единицы.
Зональный: Для зональных экземпляров, когда зона недоступна, экземпляр недоступен. Если у вас есть вторичный экземпляр в другой зоне доступности, вы несете ответственность за перенаправку трафика в этот дополнительный экземпляр.
Поведение во время сбоя зоны
В этом разделе описывается, что ожидать, когда экземпляры службы управления API настроены с поддержкой зоны доступности, а также возникает сбой зоны доступности.
Обнаружение и ответ: На уровне "Премиум" версия 2 платформа управления API отвечает за обнаружение сбоя в зоне доступности и реагирование. Вам не нужно ничего делать, чтобы инициировать переключение зоны.
Активные запросы: Если зона доступности недоступна, все выполняемые запросы, которые подключены к блоку управления API в недоступной зоне доступности, завершаются и должны быть повторно выполнены.
- Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Однако вы можете использовать Azure Resource Health для отслеживания работоспособности отдельного ресурса и настроить оповещения о работоспособности ресурсов , чтобы уведомить вас о проблемах. Вы также можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, включая любые сбои зоны, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.
Ожидаемая потеря данных: Управление API хранит следующие данные.
Изменения конфигурации шлюза, которые реплицируются в каждую выбранную зону доступности в течение примерно 10 секунд. Если возникает сбой зоны доступности, изменения конфигурации, которые не реплицируются.
Данные во внутреннем кэше, если вы используете функцию внутреннего кэша. Внутренний кэш нестабилен, и не гарантируется сохранение данных. Во время сбоя зоны доступности некоторые или все кэшированные данные могут быть потеряны. Рекомендуется использовать внешний кэш, если необходимо сохранить кэшированные данные.
Счетчики ограничений скорости, если вы используете функцию ограничения скорости. Во время сбоя зоны доступности счетчики ограничений скорости могут не быть up-to-date в выживших зонах.
Ожидаемое время простоя: Вы можете ожидать, что экземпляры не будут иметь времени простоя во время сбоя зоны доступности. Единицы в небезопасной зоне или зонах продолжают работать.
Кроме того, можно ожидать, что экземпляры, имеющие одну единицу, не имеют простоя. В этой конфигурации управление API распределяет базовые вычислительные ресурсы единицы в две зоны. Ресурс в непострадавшей зоне продолжает работать.
Перенаправка трафика: Если зона недоступна, все единицы в затронутой зоне также недоступны. Вы можете масштабировать инстанцию, чтобы добавить дополнительные единицы.
Восстановление зоны
Автоматическое и избыточное между зонами: Для экземпляров, настроенных для использования поддержки автоматической зоны доступности или настроенных вручную для использования избыточности зоны, когда зона доступности восстанавливается, управление API автоматически восстанавливает единицы в зоне доступности и перенаправляет трафик между единицами в обычном режиме.
Зональный: Для зональных экземпляров вы несете ответственность за перенаправку трафика в экземпляр в исходной зоне доступности после восстановления зоны доступности.
Восстановление зоны
На уровне "Премиум" версии 2 при восстановлении зоны доступности управление API автоматически восстанавливает единицы в зоне доступности и перенаправляет трафик между единицами в обычном режиме.
Тестирование на сбои в зоне
Автоматическое и избыточное между зонами: Для экземпляров, настроенных для использования поддержки автоматической зоны доступности или настроенных вручную для использования избыточности зоны, платформа управления API управляет маршрутизацией трафика, отработкой отказа и восстановлением размещения. Эта функция полностью управляется, поэтому не требуется инициировать или проверять процессы сбоя зоны доступности.
Зональный: Для зональных экземпляров вы не можете имитировать сбой зоны доступности, содержащей ваш экземпляр управления API. Однако можно вручную настроить вышестоящие шлюзы или системы балансировки нагрузки для перенаправления трафика в другой экземпляр в другой зоне доступности.
Тестирование на сбои в зоне
На уровне Premium v2 платформа управления API осуществляет маршрутизацию трафика, обработку отказа и восстановление после сбоя. Эта функция полностью управляется, поэтому не требуется инициировать или проверять процессы сбоя зоны доступности.
Устойчивость к сбоям на уровне региона
С помощью развертывания с несколькими регионами можно добавить региональные шлюзы API в существующий экземпляр службы управления API в одном или нескольких поддерживаемых регионах Azure. Развертывание с несколькими регионами помогает снизить задержку запросов, которая воспринимается потребителями географически распределенных API. Развертывание с несколькими регионами также улучшает доступность сервиса, если один регион переходит в автономный режим.
Это важно
Развертывания с несколькими регионами поддерживаются только на уровне "Премиум" (классическая версия) управления API.
Чтобы просмотреть сведения о поддержке в нескольких регионах, обязательно выберите уровень "Премиум" (классический) в начале этой страницы.
Развертывание с несколькими регионами, управляемое корпорацией Майкрософт
При добавлении региона вы настраиваете:
Количество единиц, которые размещаются в регионе.
Устойчивость к сбоям зоны доступности, если этот регион предоставляет зоны доступности.
Параметры виртуальной сети в добавленном регионе, если сеть настроена в существующем регионе или регионах.
Требования
Поддержка региона: Вы можете создавать развертывания с несколькими регионами на уровне "Премиум" (классический) с любым регионом Azure, поддерживающим управление API. Сведения о том, какие регионы поддерживают развертывания в нескольких регионах, см. в разделе "Доступность продукта по регионам".
Требование уровня: Для настройки поддержки нескольких регионов необходимо использовать уровень "Премиум" (классический). Сведения об обновлении экземпляра до уровня "Премиум" (классический) см. в разделе "Обновление до уровня "Премиум".
Соображения
Только шлюз: Только компонент шлюза экземпляра службы управления API реплицируется в несколько регионов. Плоскость управления экземпляра и портал разработчика остаются размещенными только в первичном регионе, где служба была изначально развернута.
Требования к сети: Если вы хотите настроить дополнительное расположение для экземпляра службы управления API при развертывании (внедрение) в виртуальной сети, регион виртуальной сети и подсети должен совпадать с настроенным дополнительным расположением. При добавлении, удалении или включении зоны доступности в основном регионе или при изменении подсети основного региона виртуальный IP-адрес экземпляра службы управления API изменяется. Дополнительные сведения см. в разделе "Изменения IP-адресов". Однако при добавлении дополнительного региона виртуальный IP-адрес основного региона не изменяется, так как каждый регион имеет собственный частный IP-адрес.
Имена системы доменных имен (DNS): Шлюз в каждом регионе, включая основной регион, имеет региональное DNS-имя, которое следует шаблону
https://<service-name>-<region>-01.regional.azure-api.netURL-адреса, напримерhttps://contoso-westus2-01.regional.azure-api.net.
Себестоимость
Добавление регионов повлечет за собой затраты. Для получения информации см. Цены на управление API.
Настройка поддержки нескольких регионов
Сведения о настройке поддержки нескольких регионов в экземпляре службы "Управление API" см. в статье "Развертывание экземпляра службы "Управление API" в нескольких регионах Azure.
Чтобы удалить регион из экземпляра службы управления API, см. раздел "Удалить регион службы управления API".
Планирование ресурсов и управление ими
В сценарии уменьшения региона не гарантируется, что запросы на увеличение емкости в другом регионе выполнены успешно. Если вам нужна гарантированная емкость при сбое региона, необходимо создать и настроить экземпляр службы управления API для учета потери региона. Это можно сделать, переописав емкость экземпляра службы управления API. Дополнительные сведения о принципе чрезмерного резервирования см. в разделе "Управление ресурсами при чрезмерном резервировании".
В развертываниях с несколькими регионами автомасштабирование применяется только к основному региону. Для дополнительных регионов требуются корректировки масштабирования вручную или настраиваемые инструменты, которыми вы управляете.
Поведение, когда все регионы работоспособны
В этом разделе описывается, что ожидать, когда экземпляры управления API настроены с поддержкой нескольких регионов и все регионы работают.
Маршрутизация трафика между регионами: Управление API автоматически направляет входящие запросы в региональный шлюз. Запрос направляется в региональный шлюз с наименьшей задержкой от клиента. Если вам нужно использовать другой подход к маршрутизации, можно настроить собственный диспетчер трафика с помощью пользовательских правил маршрутизации. Дополнительные сведения см. в разделе "Использование пользовательской маршрутизации для региональных шлюзов управления API".
Когда запрос достигает регионального шлюза управления API, он направляется в внутренний API, если политика не возвращает ответ непосредственно из шлюза, например кэшированный ответ или код ошибки. В решении с несколькими регионами необходимо направить трафик к экземпляру серверного API, который соответствует вашим требованиям к производительности. Дополнительные сведения см. в разделе "Маршрутизация вызовов API" к региональным внутренним службам.
Репликация данных между регионами: Конфигурация шлюза, например API и определения политик, регулярно синхронизируются между основными и дополнительными регионами, которые вы добавляете. Распространение обновлений на региональные шлюзы обычно занимает менее 10 секунд.
Счетчики ограничений скорости и данные во внутреннем кэше зависят от региона, поэтому они не реплицируются между регионами.
Поведение во время сбоя региона
В этом разделе описывается, что ожидать, когда экземпляры службы управления API настроены с поддержкой нескольких регионов, и в одном из используемых регионов возникает сбой.
Обнаружение и ответ: Управление API отвечает за обнаружение сбоя в регионе и автоматическую отработку отказа в шлюз в одном из других регионов, настроенных вами.
Активные запросы: Все активные запросы, обрабатываемые в неисправном регионе, могут быть удалены, и клиент должен повторить их.
Ожидаемая потеря данных: Управление API не сохраняет данные, за исключением конфигурации, кэша и счетчиков ограничения скорости.
Изменения конфигурации реплицируются в каждый регион примерно в 10 секунд. Если происходит сбой основного региона, вы можете потерять изменения конфигурации, которые не реплицируются.
Счетчики ограничений скорости и данные во внутреннем кэше зависят от региона, поэтому они не реплицируются между регионами.
Ожидаемое время простоя: Время простоя шлюза не ожидается.
Если основной регион переходит в автономный режим, плоскость управления API и портал разработчика становятся недоступными. Однако вторичные регионы продолжают обслуживать запросы API с помощью последней конфигурации шлюза.
Перенаправка трафика: Если регион переходит в автономный режим, запросы API автоматически направляются по региону сбоя в следующий ближайший шлюз.
Восстановление региона
Когда основной регион восстанавливается, управление API автоматически восстанавливает единицы в регионе и перенаправляет трафик между единицами.
Проверка сбоев в регионе
Чтобы быть готовым к непредвиденным сбоям в регионе, регулярно тестируйте ваши реакции на сбои в регионе. Вы можете имитировать некоторые аспекты сбоя региона, отключив маршрутизацию в региональный шлюз.
Резервное копирование и восстановление
Управление API не сохраняет большинство данных среды выполнения. Однако вы можете создать резервную копию конфигурации службы управления API. Вы также можете использовать операции резервного копирования и восстановления для репликации конфигураций службы управления API между операционными средами, такими как разработка и промежуточное хранение.
Это важно
В процедуре резервного копирования включены такие данные среды выполнения, как пользователи и подписки, которые не всегда являются желательными.
Резервное копирование поддерживается на уровнях Developer, Basic, Standard и Premium.
Дополнительные сведения см. в статье "Реализация аварийного восстановления с помощью резервного копирования службы и восстановления в службе "Управление API".
Для резервного копирования или восстановления некоторых компонентов или ресурсов службы можно также рассмотреть варианты, управляемые клиентом, такие как средства APIOps и инфраструктура как решения кода (IaC).
Устойчивость к обслуживанию служб
Управление API выполняет регулярные обновления служб и другие формы обслуживания.
На уровнях "Базовый", "Стандартный" и "Премиум" (классический) можно настроить, когда ваш экземпляр получает обновление в процессе обновления. Если необходимо проверить влияние обновлений на рабочую нагрузку, рассмотрите возможность настройки тестового экземпляра для получения обновлений в начале цикла обновления и задания экземпляра рабочей среды для получения обновлений в конце цикла. Кроме того, можно указать период обслуживания, который является временем дня, в течение которого экземпляр будет применять обновления служб.
Дополнительные сведения см. в разделе "Настройка параметров обновления службы" для экземпляров службы "Управление API".
Соглашение об уровне обслуживания
Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.
При развертывании экземпляра службы управления API в нескольких зонах доступности или регионах процент простоя, определенный в уровне обслуживания, увеличивается.
Служба предоставляет собственное соглашение об уровне обслуживания, но также необходимо учитывать ожидаемую надежность других компонентов рабочей нагрузки, таких как серверные части API.