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

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

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

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

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

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

Примечание

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

Подход

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

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

Приватный канал подключения к серверам-источникам

Azure Front Door premium предоставляет Приватный канал подключения к источникам, что сокращает общедоступную поверхность решения, доступную к Интернету.

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

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

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

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

Кэширование

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

Предупреждение

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

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

Дальнейшие действия

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