Методы маршрутизации трафика в источник

Внимание

Azure Front Door (классическая версия) будет прекращена 31 марта 2027 г. Чтобы избежать нарушений работы служб, важно перенести профили Azure Front Door (классический) на уровень Azure Front Door standard или Premium к марту 2027 года. Дополнительные сведения см. в статье azure Front Door (классическая версия) для выхода на пенсию.

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

Примечание.

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

Четыре метода маршрутизации трафика:

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

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

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

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

Примечание.

Имя конечной точки в Azure Front Door категории "Стандартный" и "Премиум" называется интерфейсным узлом в Azure Front Door (классическая версия).

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

Примечание.

При использовании обработчика правил Front Door можно настроить правило для переопределения конфигураций маршрутов в Azure Front Door категории "Стандартный" и "Премиум" или переопределения серверного пула в Azure Front Door (классическая версия) для запроса. Группа источников или серверный пул, заданный обработчиком правил, переопределяет процесс маршрутизации, описанный в этой статье.

Общий поток принятия решений

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

Схема, объясняющая, как источники выбираются на основе приоритетов, задержки и весовых параметров в Azure Front Door.

Ниже приведены действия по принятию решений.

  1. Доступные источники: выберите все источники, которые включены и возвращены работоспособно (200 ОК) для пробы работоспособности.
    • Пример. Предположим, что существует шесть источников A, B, C, D, E и F, и среди них C является неработоспособным, и E отключен. Список доступных источников будет содержать A, B, D и F.
  2. Приоритет: выбраны основные источники приоритета среди доступных.
    • Пример. Предположим, что источник A, B и D имеют приоритет 1 и источник F имеет приоритет 2. Затем выбранные источники — A, B и D.
  3. Сигнал задержки (на основе пробы работоспособности): выберите источники в допустимом диапазоне задержки из среды Front Door, в которой поступил запрос. Этот сигнал основан на настройке конфиденциальности задержки в группе источников и задержке более близких источников.
    • Пример. Предположим, Front Door измеряла задержку из среды, в которой запрос прибыл в источник A в 15 мс, а задержка для B составляет 30 мс и D составляет 60 мс. Если конфиденциальность задержки группы источников имеет значение 30 мс, то наименьший пул задержки состоит из источников A и B, так как D превышает 30 мс от ближайшего источника, то есть A.
  4. Весы: Наконец, Azure Front Door округляет трафик среди последней выбранной группы источников в соотношении заданных весов.
    • Пример. Если источник A имеет вес 3 и источник B имеет вес 7, трафик распределяется 3/10 по источникам A и 7/10 к источнику B.

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

Маршрутизация трафика на основе минимальной задержки

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

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

Каждая среда Front Door измеряет задержку источника отдельно. Это означает, что разные пользователи в разных расположениях направляются в источник с оптимальной производительностью для этой среды.

Примечание.

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

Маршрутизация трафика по приоритету

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

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

Настройка приоритета источников

Каждый из источников в группе источников Azure Front Door имеет свойство Приоритет, которое может принимать значения от 1 до 5. В Azure Front Door вы можете явным образом настроить приоритет каждого источника, задав это свойство. Это свойство может принимать значения от 1 до 5. Чем меньше значение, тем выше приоритет. У источников могут быть одинаковые значения приоритета.

Метод маршрутизации трафика со взвешиванием

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

При использовании метода маршрутизации трафика со взвешиванием каждому источнику в конфигурации группы источников Azure Front Door присваивается определенный вес. Это целое число в диапазоне от 1 до 1000. По умолчанию для параметра задается вес 50.

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

Метод взвешивания позволяет реализовать некоторые полезные сценарии.

  • Постепенное обновление приложения. Часть трафика направляется в новый источник, и постепенно объем трафика доводится до 100 %, чтобы соблюсти паритет с остальными источниками.
  • Перенос приложений в Azure. Создайте группу источников, которая включает источники, расположенные в среде Azure и за ее пределами. Настройте значения веса источников таким образом, чтобы приоритет отдавался новым источникам. Это можно делать постепенно, начиная с отключенных новых источников, а затем назначая им наименьшие веса, медленно увеличивая их до уровня, при котором они будут принимать большую часть трафика. Затем можно будет отключить менее предпочтительные источники и удалить их из группы.
  • Переход в облако для получения дополнительной емкости. Быстро расширьте локальное развертывание в облако, воспользовавшись службой Front Door. Если вам требуется дополнительная емкость в облаке, можно добавить или включить дополнительные источники и указать, какая часть трафика направляется в каждый источник.

Сходство сеансов

По умолчанию без сходства сеансов Azure Front Door перенаправляет запросы, поступающие от одного и того же клиента, в различные источники. Для определенных приложений с отслеживанием состояния и сценариев предпочтительно, чтобы последующие запросы от одного пользователя поступали в один и тот же источник для обработки исходного запроса. Функция сходства сеансов на основе файлов cookie удобна, если нужно, чтобы сеанс пользователя выполнялся в одном и том же источнике. Если вы используете управляемые файлы cookie с SHA256 URL-адреса источника в качестве идентификатора в файле cookie, Azure Front Door может направить последующий трафик из сеанса пользователя в тот же источник для обработки.

Сходство сеансов можно включить на уровне группы источников в Azure Front Door категории "Стандартный" и "Премиум" и уровне интерфейсного узла в Azure Front Door (классическая версия) для каждого из ваших настроенных доменов (или поддоменов). После включения служба Azure Front Door добавляет файл cookie в сеанс пользователя. Файлы cookie называются ASLBSA и ASLBSACORS. Используя сходство сеансов на основе файлов cookie, служба Front Door может идентифицировать различных пользователей, даже если они используют один и тот же IP-адрес. В свою очередь, это обеспечивает более равномерное распределение трафика между различными источниками.

Время существования файла cookie и сеанса пользователя одинаковы, так как сейчас Front Door поддерживает только файл cookie сеанса.

Примечание.

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

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

Сходство сеансов будет установлено в следующих случаях за пределами стандартных не кэшируемых сценариев:

  • Ответ должен содержать следующий заголовок Cache-Control: no-store.
  • Если ответ содержит заголовок Authorization, у него не должен быть истекшим срок действия.
  • Ответ — это код состояния HTTP 302.

Следующие шаги