Надежность в Шлюзе приложений Azure версии 2

Шлюз приложений Azure версии 2 — это подсистема балансировки нагрузки веб-трафика, которая позволяет управлять трафиком в веб-приложения. Она предоставляет расширенные функции, такие как автомасштабирование, избыточность зон, статические VIP-адреса и интеграция брандмауэра веб-приложений (WAF) для предоставления высокодоступных и безопасных услуг по доставке приложений.

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

Надежность — это общая ответственность между вами и корпорацией Майкрософт. Это руководство позволяет определить, какие варианты надежности соответствуют конкретным бизнес-целям и целям простоя.

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

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

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

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

• Экземпляр:Экземпляр — это единица на уровне виртуальной машины (VM) шлюза. Каждый экземпляр представляет выделенную виртуальную машину, которая обрабатывает трафик. Один экземпляр равен одной виртуальной машине.

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

• Масштабирование: Важным аспектом надежности шлюза является масштабирование для удовлетворения спроса на трафик. Если шлюз не масштабирован надлежащим образом, трафик не может проходить, и приложение может испытывать простой. Шлюз приложений Azure настроен для использования одного из следующих режимов масштабирования:

  • Автомасштабирование: Автоматически настраивает количество экземпляров в заданном диапазоне. Автомасштабирование масштабирует количество экземпляров на основе текущего спроса на трафик.
  • Масштабирование вручную: Требуется указать точное количество экземпляров. Вы несете ответственность за выбор количества экземпляров, соответствующего вашим запросам по трафику.

  Единица емкости представляет объем емкости, которую может обрабатывать шлюз. Единица емкости — это синтетическая мера, которая включает трафик, количество подключений и вычислительных ресурсов. Каждый экземпляр может обрабатывать не менее 10 единиц емкости. Дополнительные сведения см. в разделе Масштабирование шлюза приложений версии 2 и WAF v2.

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

Временные сбои

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

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

При использовании шлюза приложений Azure:

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

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

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

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

Шлюз приложений Azure предлагает два типа поддержки зоны доступности при развертывании шлюза Standard_v2 или WAF_v2 в поддерживаемом регионе:

• Зонально-избыточный: Azure автоматически распределяет экземпляры между двумя или несколькими зонами доступности.

• Зональный: Azure развертывает все экземпляры Шлюза приложений в одной зоне, выбранной в выбранном регионе Azure.

  Это важно

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

Поддержка регионов

Шлюз приложений Azure поддерживает зоны доступности для уровней Standard_v2 и WAF_v2 во всех регионах Azure, поддерживающих зоны доступности.

Требования

• Чтобы включить поддержку зоны доступности, необходимо использовать номер SKU Standard_v2 или WAF_v2.

• Шлюз должен иметь по крайней мере две инстанции.

  Замечание

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

Соображения

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

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

Поддержка зоны доступности для Шлюза приложений версии 2 не взимает дополнительные расходы за пределы стандартных цен на единицу емкости. Сведения о ценах см. в разделе "Общие сведения о ценах на шлюз приложений Azure" и "Брандмауэр веб-приложений" и "Шлюз приложений".

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

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

• Создайте новый шлюз приложений версии 2 с поддержкой зоны доступности: Подход, используемый для настройки зон доступности, зависит от того, хотите ли вы создать зональный или зональный шлюз.

  • Зонально-избыточные: По умолчанию новые шлюзы создаются зонально-избыточными. Экземпляры распределяются по нескольким зонам доступности и могут быть размещены в двух или более зонах в регионе.

    Чтобы развернуть новый шлюз, см. Краткое руководство: Управление веб-трафиком с помощью шлюза приложений Azure - портал Azure.

    Замечание

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

    При использовании Azure CLI, Azure PowerShell, Bicep, шаблонов ARM или Terraform можно также указать зоны доступности для развертывания шлюза. Вы можете развернуть шлюз с избыточностью по зонам, указав две или более зон. Однако рекомендуется опустить список зон, чтобы шлюз может использовать все зоны доступности, если у вас нет определенной причины не использовать определенную зону.

  • Зональный: Вы можете развернуть зональный шлюз с помощью следующих средств:

    • Azure CLI: Необходимо явно выбрать зоны с помощью --zones параметра в команде az network application-gateway create . Чтобы закрепить шлюз к одной зоне, укажите номер логической зоны.
    • Azure PowerShell:-Zone Используйте параметр в команде New-AzApplicationGateway . Чтобы закрепить шлюз к одной зоне, укажите номер логической зоны.
    • Шаблоны Bicep/ARM:zones Настройте свойство в определении ресурса. Чтобы закрепить шлюз к одной зоне, укажите номер логической зоны.

    Замечание

    При выборе используемых зон доступности вы фактически выбираете логическую зону доступности. При развертывании других компонентов рабочей нагрузки в другой подписке Azure они могут использовать другой номер логической зоны доступности для доступа к той же физической зоне доступности. Дополнительные сведения см. в разделе "Физические и логические зоны доступности".

• Измените конфигурацию зоны доступности существующего шлюза приложений версии 2: Корпорация Майкрософт автоматически обновляет все существующие незональные шлюзы, чтобы быть избыточными по зонам, без каких-либо действий от вас. Ожидается, что это обновление будет завершено в 2025 году.

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

• Отключите поддержку зоны доступности: Поддержка зоны доступности не может быть отключена. Все шлюзы в регионах с зонами доступности должны быть зонально-избыточными или зональными.

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

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

Эффективное управление емкостью:

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

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

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

Нормальная работа

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

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

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

Опыт понижения зоны

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

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

  • Зональная избыточность: Корпорация Майкрософт управляет обнаружением сбоев зоны и автоматически инициирует переключение на резервное копирование. Вмешательство пользователя не требуется.

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

• Уведомление. События сбоя зоны можно отслеживать с помощью службы "Работоспособность служб Azure" и "Работоспособность ресурсов". Настройте оповещения в этих службах для получения уведомлений о проблемах уровня зоны.

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

• Ожидаемая потеря данных: Сбой зон не должен приводить к потере данных, так как шлюз приложений является службой без состояния.

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

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

  • Зональный: Если зона недоступна, шлюз недоступен до восстановления зоны доступности.

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

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

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

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

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

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

  • Зональный: Если зона недоступна, шлюз недоступен. Если у вас есть вторичный шлюз в другой зоне доступности, вы несете ответственность за перенаправку трафика в этот вторичный шлюз.

Возврат к исходному состоянию

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

• Зональная избыточность: При восстановлении затронутой зоны доступности шлюз приложений автоматически:

  • Восстанавливает экземпляры в зоне восстановления
  • Удаляет любые временные экземпляры, созданные в других зонах во время сбоя
  • Возвращается к нормальному распределению трафика во всех доступных зонах

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

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

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

• Зонально-избыточный: Платформа Azure Application Gateway полностью управляет маршрутизацией трафика, переключением при отказе и возвратом для зонально-избыточных шлюзов. Так как корпорация Майкрософт управляет этой функцией, вам не нужно инициировать или проверить процессы сбоя зоны доступности. Платформа прозрачно обрабатывает все сценарии отказа зоны.

• Зональный: Вы можете имитировать некоторые аспекты сбоя зоны доступности, явно остановив шлюз. Остановив шлюз приложений, вы можете проверить, как другие системы и подсистемы балансировки нагрузки обрабатывают сбой в шлюзе. Дополнительные сведения см. в статье "Как остановить и запустить шлюз приложений?".

Поддержка нескольких регионов

Шлюз приложений Azure версии 2 — это служба с одним регионом. Если регион становится недоступным, шлюз приложений также недоступен.

Альтернативные подходы с несколькими регионами

Чтобы обеспечить устойчивость нескольких регионов с помощью Шлюза приложений версии 2, необходимо развернуть отдельные шлюзы в каждом нужном регионе и реализовать управление трафиком в разных регионах. Вы несете ответственность за развертывание и настройку каждого шлюза, а также маршрутизацию трафика и резервирование. Рассмотрим следующие моменты:

• Настройте согласованные правила и политики шлюза приложений в разных регионах. Инфраструктуру можно определить как код с помощью таких средств, как Bicep или Terraform, чтобы упростить развертывания и конфигурации в разных регионах.

• Разверните глобальное решение балансировки нагрузки, которое может отправлять трафик между региональными шлюзами. Глобальные службы балансировки нагрузки в Azure — диспетчер трафика Azure и Azure Front Door. Каждая служба направляет трафик на основе проверок работоспособности, географического расположения или метрик производительности. Azure Front Door также предоставляет ряд других возможностей, включая защиту от атак DDoS, возможности брандмауэра веб-приложения и расширенные правила и функции маршрутизации.

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

Пример подхода см. в статье "Использование шлюза приложений Azure" с диспетчером трафика Azure.

Резервные копии

Шлюз приложений Azure версии 2 — это сервис без состояния, который не требует традиционных операций резервного копирования и восстановления. Все данные конфигурации хранятся в Azure Resource Manager и могут быть развернуты с помощью подходов инфраструктуры как кода (IaC), таких как файлы Bicep или шаблоны Azure Resource Manager (шаблоны ARM).

Для управления конфигурацией и аварийного восстановления:

• Определение конфигурации развертывания Шлюза приложений с помощью файлов Bicep или шаблонов ARM или экспорта конфигурации существующего шлюза
• Хранение сертификатов TLS в Azure Key Vault для безопасного управления и репликации
• Пользовательские конфигурации, правила и политики управления документами и версиями
• Реализация конвейеров автоматического развертывания для согласованной подготовки шлюза

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для Шлюза приложений Azure описывает ожидаемую доступность службы. В нем также описываются условия, которые должны быть выполнены для достижения этого ожидаемого уровня доступности. Чтобы понять эти условия, важно ознакомиться с соглашениями об уровне обслуживания (SLA) для веб-служб.

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

• Обзор надежности Azure