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

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

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

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

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

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

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

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

• Шлюз: При развертывании шлюза приложений вы развертываете шлюз, который является ресурсом Azure, с которым вы работаете.

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

  Это важно

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

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

  На следующей схеме показан шлюз с двумя инстансами.

  

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

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

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

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

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

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

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

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

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

При использовании шлюза приложений рассмотрите следующие рекомендации.

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

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

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

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

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

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

  При развертывании нового шлюза, он по умолчанию имеет зональную избыточность.

  На следующей схеме показан зонально-резервный шлюз с тремя экземплярами, распределенными по трем зонам доступности:

  

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

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

  

  Это важно

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

Требования

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

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

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

  Замечание

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

Соображения

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

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

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

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

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

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

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

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

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

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

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

    • Azure PowerShell:-Zone Используйте параметр в команде New-AzApplicationGateway . Чтобы закрепить шлюз к одной зоне, укажите номер логической зоны.

    • Шаблоны Bicep и ARM:zones Настройте свойство в определении ресурса. Чтобы закрепить шлюз к одной зоне, укажите номер логической зоны.

    Замечание

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

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

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

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

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

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

Чтобы эффективно управлять емкостью, выполните следующие действия.

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

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

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

Поведение, когда все зоны работоспособны

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

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

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

Поведение во время сбоя зоны

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

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

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

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

• • Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Тем не менее

    • Вы можете использовать Azure Resource Health для отслеживания работоспособности отдельного ресурса и настроить оповещения о работоспособности ресурсов , чтобы уведомить вас о проблемах.

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

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

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

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

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

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

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

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

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

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

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

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

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

Восстановление зоны

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

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

  • Восстанавливает экземпляры в зоне восстановления

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

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

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

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

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

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

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

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

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

Индивидуальные решения для нескольких регионов для повышения устойчивости

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

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

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

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

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

Резервное копирование и восстановление

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

Для управления конфигурацией и аварийного восстановления необходимо выполнить следующие действия.

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

• Хранение сертификатов безопасности транспортного уровня (TLS) в Azure Key Vault для безопасного управления и репликации.

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

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

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

Устойчивость к обслуживанию служб

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

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

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

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

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

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

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