Критически важный глобальный вход HTTP

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

Как упоминалось в предыдущей статье в этой серии, Azure Front Door предназначена для обеспечения максимальной устойчивости и доступности не только для наших внешних клиентов, но и для множества служб в компании Майкрософт. Хотя корпорация Майкрософт предлагает соглашение об уровне обслуживания (SLA) для Azure Front Door, если у вас есть критически важное приложение, требующее более высокого уровня обслуживания, вам потребуется реализовать дополнительные пути входящего трафика.

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

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

• Azure Front Door для глобальной маршрутизации трафика. Это может означать, что у вас несколько экземпляров приложения в отдельных регионах Azure или вы обслуживаете всех глобальных пользователей из одного региона.
• Брандмауэр веб-приложения (WAF) для защиты приложения независимо от пути, который следует трафику, чтобы добраться до серверов-источников.

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

Подход

Это решение балансировки нагрузки на основе DNS использует несколько профилей диспетчера трафика Azure. В маловероятном случае проблемы с доступностью в Azure Front Door диспетчер трафика Azure перенаправляет трафик через шлюз приложений.

Решение включает следующие компоненты:

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

  Во время обычных операций диспетчер трафика отправляет все входящие запросы через Azure Front Door.

  Если Azure Front Door становится недоступным, отключите конечную точку Azure Front Door. Второй профиль диспетчера трафика определяет, куда направлять запрос. В следующем разделе описывается эта конфигурация.

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

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

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

• Серверы приложений-источника должны быть готовы к приему трафика из Azure Front Door и Шлюза приложений Azure в любое время.

Соображения

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

Конфигурация диспетчера трафика

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

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

Региональное распределение

Azure Front Door — это глобальная служба, а шлюз приложений — это региональная служба.

Точки присутствия Azure Front Door развертываются глобально, а подключения TCP и TLS завершаются в оптимальной точке присутствия. Это поведение повышает производительность приложения. В отличие от этого, когда клиенты подключаются к шлюзу приложений, их TCP-подключения и TLS завершаются на шлюзе приложений, получающего запрос, независимо от того, где произошел трафик.

Подключения от клиентов

В качестве глобальной мультитенантной службы Azure Front Door обеспечивает неотъемлемую защиту от различных угроз. Azure Front Door принимает только допустимый трафик HTTP и HTTPS и не принимает трафик по другим протоколам. Корпорация Майкрософт управляет общедоступными IP-адресами, которые Azure Front Door использует для входящих подключений. Из-за этих характеристик Azure Front Door может помочь защитить источник от различных типов атак, а источники можно настроить для использования Private Link подключения.

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

Подключения Private Link к серверам-источникам

Azure Front Door Premium обеспечивает подключение через "Private Link" к вашим источникам, что сокращает поверхность, доступную из интернета, вашего решения.

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

Масштабирование

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

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

Кэширование

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

Если вы зависите от кэширования в вашем решении, рассмотрите глобальную критически важную доставку контента как альтернативный подход, использующий альтернативную сеть доставки содержимого (CDN) в качестве резерва для Azure Front Door.

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

Компромиссы

Этот тип архитектуры наиболее полезен, если вы хотите, чтобы альтернативный путь трафика использовал такие функции, как правила обработки запросов, разгрузка WAF и TLS. Azure Front Door и Шлюз приложений предоставляют аналогичные возможности.

Однако существуют компромиссы:

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

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

  Шлюз приложений не обеспечивает кэширование. Дополнительные сведения об этом различии см. в разделе "Кэширование".

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

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

  Если затраты являются значительным фактором для вашего решения, ознакомьтесь с критически важным глобальным подходом к доставке контента , который использует альтернативную сеть доставки содержимого (CDN) в качестве резервного варианта в Azure Front Door. Некоторые CDN выставляют счета за трафик на основе использования, поэтому этот подход может оказаться более экономичным. Однако вы можете потерять некоторые из других преимуществ использования шлюза приложений для вашего решения.

  Кроме того, можно рассмотреть возможность развертывания альтернативной архитектуры, в которой диспетчер трафика может направлять трафик непосредственно в службы приложений как услуга (PaaS), избегая необходимости шлюза приложений и снижения затрат. Этот подход можно рассмотреть, если вы используете службу, например Службу приложений Azure или приложения контейнеров Azure для вашего решения. Однако, если вы следуйте этому подходу, существует несколько важных компромиссов, которые следует учитывать:

  • WAF: Azure Front Door и Шлюз приложений предоставляют возможности WAF. Если вы предоставляете службы приложений непосредственно в Интернете, возможно, вы не сможете защитить приложение с помощью WAF.
  • Разгрузка TLS: Azure Front Door и Шлюз приложений завершают подключения TLS. Службы приложений должны быть настроены для завершения подключений TLS.
  • Маршрутизация: Azure Front Door и Шлюз приложений выполняют маршрутизацию между несколькими источниками или внутренними серверами, включая маршрутизацию на основе путей, и поддерживают сложные правила маршрутизации. Если службы приложений предоставляются непосредственно в Интернете, невозможно выполнить маршрутизацию трафика.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

• Дэйв Беркхардт | Главный диспетчер программ, Azure Front Door
• Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure
• Акхил Кармелькар | Главный диспетчер программ, Azure Front Door
• Приянка Уилкинс | Разработчик основного содержимого, шаблоны и практики Azure

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Дальнейшие шаги

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