Надежность в службе управления API Azure

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

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

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

Обзор архитектуры надежности

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

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

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

Уровни служб управления API обеспечивают различные уровни надежности:

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

• Уровни "Базовый" версии 2, "Стандартный", "Стандартный" версии 2 и "Премиум" версии 2 (предварительная версия): Все поддерживают несколько единиц в одном центре обработки данных. Они не поддерживают зоны доступности или развертывания с несколькими регионами.

• Уровень разработчика: Поддерживает только одну единицу и не обеспечивает поддержку зоны доступности или нескольких регионов. Этот уровень предназначен для сценариев разработки и тестирования. Он не подходит для рабочих нагрузок.

• Уровень потребления: Имеет встроенные возможности устойчивости и устойчив к различным сбоям в одном центре обработки данных Azure. Тарифный план Consumption не поддерживает зоны доступности или развертывания в нескольких регионах. Чтобы понять ожидаемое время простоя экземпляра управления API уровня потребления, ознакомьтесь с соглашением об уровне обслуживания (SLA).

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

Рекомендации по развертыванию в производственной среде

Платформа Azure Well-Architected предоставляет рекомендации по надежности, производительности, безопасности, затратам и операциям. Чтобы понять, как эти области влияют друг на друга и вносят свой вклад в надежное решение для управления API, см. рекомендации по архитектуре для управления API.

Устойчивость к временным сбоям

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

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

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

Устойчивость к сбоям зоны доступности

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

Управление API предоставляет два типа поддержки зоны доступности при развертывании экземпляра управления API класса Premium (классической) в поддерживаемом регионе:

• Автоматически: Управление API обеспечивает автоматическую поддержку зоны доступности, если не указать, какие зоны доступности следует использовать.

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

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

Поддержка автоматической зоны доступности

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

• Конфигурация multiunit (рекомендуется). Если у экземпляра есть два или более единиц, управление 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. Каждое поле единицы содержит два значка, представляющих виртуальные машины. Три больших поля помечены как зона доступности 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 зональной архитектуры, необходимо явно развернуть отдельные экземпляры в разных зонах доступности и настроить маршрутизацию трафика и резервирование на случай отказа.

Требования

• Поддержка региона: Управление API поддерживает зоны доступности для уровня "Премиум" (классический) во всех регионах Azure, поддерживающих зоны доступности.

• Требование уровня: Для настройки поддержки зоны доступности необходимо использовать уровень "Премиум" (классический). Управление API в настоящее время не поддерживает зоны доступности в классических уровнях потребления, разработчика, уровня "Базовый" и "Стандартный" или на уровнях "Базовый" версии 2, "Стандартный" и "Премиум" версии 2. Сведения об обновлении экземпляра до уровня "Премиум" (классический) см. в разделе "Обновление до уровня "Премиум".

Соображения

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

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

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

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

• Требования к IP-адресу: Если включить поддержку зоны доступности в экземпляре службы управления API, развернутом во внешней или внутренней виртуальной сети, необходимо указать ресурс общедоступного IP-адреса для использования экземпляра. В внутренней виртуальной сети общедоступный IP-адрес используется только для операций управления, а не для запросов API. Дополнительные сведения см. в разделе "IP-адреса" в службе "Управление API".

Себестоимость

Независимо от конфигурации зоны доступности, при добавлении дополнительных единиц вам потребуется больше затрат. Для получения информации см. Цены на управление API.

Настройка поддержки зоны доступности

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

• Создайте экземпляр службы управления API, поддерживающий зоны доступности: При создании экземпляра управления API класса Premium (классической) в регионе, поддерживающем зоны доступности, экземпляр поддерживает зоны доступности по умолчанию. Вы можете выбрать автоматическую поддержку зон доступности или вручную настроить зональную либо избыточную поддержку.

• Включение или перенастройка поддержки зоны доступности: Можно изменить конфигурацию зоны доступности для экземпляра службы управления API, включая добавление зональных зон доступности и перемещение зонального экземпляра между зонами доступности. Сведения о настройке поддержки зоны доступности в экземпляре службы управления API см. в статье "Включение поддержки зоны доступности" в экземплярах управления API. Отсутствуют требования к простою для любого из параметров конфигурации.

  При изменении конфигурации зоны доступности изменения могут занять 15–45 минут или более. Шлюз Управление API может продолжать обрабатывать запросы API в течение этого времени.

  Изменение конфигурации зоны доступности активирует изменение общедоступного и частного IP-адреса.

Планирование ресурсов и управление ими

В сценарии уменьшения зоны не гарантируется, что запросы на дополнительную емкость в другой зоне доступности будут успешными. Резервное заполнение потерянных единиц происходит на основе лучших усилий. Если вам нужна гарантированная емкость при сбое зоны доступности, необходимо создать и настроить экземпляр службы управления 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 автоматически восстанавливает единицы в зоне доступности и перенаправляет трафик между единицами в обычном режиме.

• Зональный: Для зональных экземпляров вы несете ответственность за перенаправку трафика в экземпляр в исходной зоне доступности после восстановления зоны доступности.

Тестирование на сбои в зоне

Параметры тестирования сбоев зоны зависят от конфигурации зоны доступности, которую использует экземпляр.

• Автоматическое и избыточное между зонами: Для экземпляров, настроенных для использования поддержки автоматической зоны доступности или настроенных вручную для использования избыточности зоны, платформа управления API управляет маршрутизацией трафика, отработкой отказа и восстановлением размещения. Эта функция полностью управляется, поэтому не требуется инициировать или проверять процессы сбоя зоны доступности.

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

Устойчивость к сбоям на уровне региона

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

Развертывание с несколькими регионами, управляемое корпорацией Майкрософт

Управление API поддерживает только развертывания с несколькими регионами на уровне "Премиум" (классическая модель). Он не поддерживает многорегиональные развертывания на уровнях "Потребление", "Разработчик", "Базовый", "Базовый" версии 2, "Стандартный", "Стандартный" версии 2 и "Премиум" версии 2 (предварительная версия). Дополнительные сведения см. в разделе "Требования".

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

• Количество единиц, которые размещаются в регионе.

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

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

Требования

• Поддержка региона: Вы можете создавать развертывания с несколькими регионами на уровне "Премиум" (классический) с любым регионом 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.

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

• Аварийное восстановление и непрерывность бизнес-процессов для управления API
• Использование зон доступности в службе управления API
• Развертывание управления API в нескольких регионах
• Мониторинг управления API
• Планирование емкости управления API
• Рекомендации по архитектуре для управления API