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

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

В диспетчере трафика доступны следующие методы маршрутизации трафика:

• Приоритет: выберите приоритетную маршрутизацию, если требуется создать основную конечную точку службы для всего трафика. Можно указать несколько резервных конечных точек в случае недоступности основной или одной из резервных конечных точек.
• Взвешенный: выберите взвешенную маршрутизацию, если необходимо распределить трафик по набору конечных точек в зависимости от их веса. Задайте одинаковый вес для равномерного распределения по всем конечным точкам.
• Производительность: выберите метод Производительность, если конечные точки размещены в разных географических расположениях и нужно, чтобы клиенты использовали "ближайшие" конечные точки для минимизации задержек сети.
• Географическая: выберите географическую маршрутизацию для направления пользователей к конкретным конечным точкам (Azure, внешним или вложенным) в зависимости от географического расположения, из которого исходят запросы DNS. Этот метод маршрутизации обеспечивает соответствие таким сценариям, как мандаты независимости данных, локализация содержимого и взаимодействия с пользователем и измерения трафика из разных регионов.
• Многозначный: выберите Многозначный для профилей диспетчера трафика, которые могут иметь конечные точки только в виде IPv4- или IPv6-адресов. При получении запроса для этого профиля возвращаются все работоспособные конечные точки.
• Подсеть: выберите метод маршрутизации трафика Подсеть для сопоставления наборов диапазонов IP-адресов конечных пользователей с определенной конечной точкой. При получении запроса возвращаемая конечная точка будет сопоставлена с этим исходным IP-адресом запроса. 

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

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

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

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

Настройка конечных точек

В Azure Resource Manager можно явно указать приоритет для каждой конечной точки, изменяя значение свойства priority. Допускаются значения в диапазоне от 1 до 1000. Более низкое значение представляет более высокий приоритет. Нельзя использовать одинаковые значения приоритетов для нескольких конечных точек. Это необязательное свойство. Если оно не указано, для конечной точки задается приоритет по умолчанию в соответствии с ее расположением в профиле.

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

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

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

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

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

• Постепенное обновление приложения: направляйте часть трафика в новую конечную точку и постепенно доведите объем трафика до 100 %.
• Миграция приложений в Azure: создайте профиль, который включает конечные точки, расположенные в среде Azure и за ее пределами. Настройте весовые коэффициенты так, чтобы приоритет отдавался новым конечным точкам.
• Выход в облако для получения дополнительной емкости: быстро расширьте локальное развертывание в облако, изменив профиль диспетчера трафика. Если вам требуется дополнительная емкость в облаке, добавьте конечные точки и укажите, какая часть трафика направляется на ту или иную конечную точку.

Весовые коэффициенты можно настроить с помощью портала Azure, Azure PowerShell, интерфейса командной строки и интерфейсов REST API.

Важно помнить, что ответы DNS кэшируются клиентами. Также они кэшируются рекурсивными DNS-серверами, которые используются клиентами для разрешения DNS-имен. Это кэширование может повлиять на распределение трафика по приоритетам. При большом числе клиентов и рекурсивных DNS-серверов распределение трафика работает ожидаемым образом. Но если клиентов и (или) рекурсивных DNS-серверов мало, кэширование может ощутимо исказить распределение трафика.

Типичные примеры такой ситуации:

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

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

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

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

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

Для каждого входящего запроса DNS он находит в таблице задержек Интернета строки, соответствующие IP-адресу клиента. Затем диспетчер трафика выбирает доступную конечную точку, расположенную в центре обработки данных Azure с наименьшей задержкой для этого диапазона IP-адресов. Затем диспетчер трафика возвращает эту конечную точку в ответе DNS.

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

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

Примечания:

• Если профиль содержит несколько конечных точек, которые входят в один регион Azure, диспетчер трафика распределяет трафик равномерно между всеми доступными конечными точками в этом регионе. Если вы предпочитаете распределение трафика в пределах региона, используйте вложенные профили диспетчера трафика.
• Если работоспособность всех задействованных конечных точек в ближайших регионах Azure снижена, диспетчер трафика перенаправляет трафик к конечным точкам в следующем ближайшем регионе Azure. Если вы хотите определить свою логику отработки сбоя, используйте вложенные профили диспетчера трафика.
• Чтобы использовать маршрутизацию трафика по производительности между внешними или вложенными конечными точками, нужно вручную указать их расположение. Выберите ближайший к вашему развертыванию регион Azure. Именно эти расположения отслеживаются в таблице задержек Интернета.
• Алгоритм выбора конечной точки детерминирован. Повторные запросы DNS от одного клиента будут направляться к той же конечной точке. Обычно клиенты используют разные рекурсивные серверы DNS, когда путешествуют. Возможно, в этом случае клиент будет перенаправлен к другой конечной точке. Кроме того, на маршрутизацию могут влиять изменения в таблице задержек Интернета. Поэтому маршрутизация трафика по производительности не гарантирует, что клиент всегда будет обращаться к одной конечной точке.
• При изменении таблицы задержек Интернета вы можете заметить, что некоторые клиенты переключились на другую конечную точку. Такие изменения маршрутизации основываются на свежих данных о задержках и потому более точны. Данные обновления необходимы, чтобы обеспечить точность маршрутизации трафика для повышения производительности, так как Интернет постоянно развивается.

Метод географической маршрутизации трафика

Диспетчер трафика профили можно настроить для использования метода географической маршрутизации, чтобы пользователи могли направляться на определенные конечные точки: Azure, External или Nested. Сопоставление основано на географическом расположении, из которого исходит запрос DNS. Этот метод маршрутизации обеспечивает соответствие требованиям для мандатов независимости данных, локализации содержимого и взаимодействия с пользователем и измерения трафика из разных регионов. Если в профиле настроена географическая маршрутизация, то каждой конечной точке, связанной с профилем, необходимо назначить набор географических регионов. Ниже приведены возможные уровни детализации географических регионов.

• Мир — любой регион.
• Группа регионов — например, Африка, Ближний Восток, Австралия и Тихоокеанский регион и т. д.
• Страна или регион — например, Ирландия, Перу, Гонконг, САР и т. д.
• Область, штат, провинция — например, Калифорния (США), Квинсленд (Австралия), Альберта (Канада) и т. д. (Обратите внимание: этот уровень детализации поддерживается только для штатов и провинций в Австралии, Канаде и США.)

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

Диспетчер трафика считывает исходный IP-адрес DNS-запроса и определяет, из какого географического региона он поступил. Затем он определяет, имеется ли конечная точка, с которой сопоставлен этот географический регион. Эта подстановка начинается на самом низком уровне детализации (сначала на уровне штата или провинции, где она поддерживается, далее на уровне страны или региона) и идет вплоть до самого высокого уровня, который является миром. Первая найденная соответствующая конечная точка при этом обходе будет возвращена в ответе на запрос. При совпадении запроса с конечной точкой вложенного типа возвращается конечная точка в этом дочернем профиле на основе метода маршрутизации. В такой ситуации возможно следующее.

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

• Если регион пользователя указан в географическом сопоставлении двух разных конечных точек, диспетчер трафика выбирает конечную точку с наименьшей степенью детализации. Диспетчер трафика не учитывает запросы маршрутизации из этого региона к другой конечной точке. Рассмотрим пример профиля с географической маршрутизацией и двумя конечными точками: Endpoint1 и Endpoint2. Endpoint1 настроена для приема трафика из Ирландии, а Endpoint2 — для приема трафика из Европы. Если запрос исходит из Ирландии, он всегда будет направляться к Endpoint1.

• Так как регион может быть сопоставлен только с одной конечной точкой, диспетчер трафика возвращает ответ независимо от того, является ли эта конечная точка работоспособной или нет.

  Важно!

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

• Если найдена соответствующая конечная точка, которая остановлена, то диспетчер трафика вернет ответ NODATA. В этом случае поиски не продолжаются вверх по иерархии географических регионов. Это также относится к конечным точкам вложенного типа, когда дочерний профиль остановлен или отключен.

• Если конечная точка отключена, она не участвует в процессе сопоставления с регионом. Это также относится к конечным точкам вложенного типа, когда конечная точка отключена.

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

Как описано в статье Как работает диспетчер трафика, запросы DNS поступают к нему не напрямую от клиентов. Запросы DNS отправляет рекурсивная служба DNS, которую используют клиенты. Поэтому для определения региона используется не IP-адрес клиента, а IP-адрес рекурсивной службы DNS. Этот IP-адрес — удачный посредник для клиента.

Вопросы и ответы

• Каковы некоторые варианты использования географической маршрутизации?

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

• Какие регионы поддерживаются Диспетчер трафика для географической маршрутизации?

• Как диспетчер трафика определяет, откуда запрашивается пользователь?

• Гарантируется ли, что Диспетчер трафика правильно определить точное географическое расположение пользователя в каждом случае?

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

• Можно ли назначить географические регионы конечным точкам в профиле, в котором не настроена географическая маршрутизация?

• Почему при попытке изменить метод маршрутизации существующего профиля на Geograph возникает ошибка?

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

• Существуют ли ограничения на версию API, поддерживающую этот тип маршрутизации?

Метод маршрутизации трафика "Многозначный"

Метод маршрутизации трафика Многозначный позволяет получить несколько работоспособных конечных точек в одном ответе на запрос DNS. Эта конфигурация позволяет вызывающему объекту совершать повторные попытки на стороне клиента с другими конечными точками, если возвращенная конечная точка не отвечает. Эта модель может повысить доступность службы и сократить задержки, связанные с новым запросом DNS на получение работоспособной конечной точки. Метод маршрутизации "Многозначный" работает только в том случае, если все конечные точки внешние и являются IPv4- или IPv6-адресами. При получении запроса для этого профиля все работоспособные конечные точки возвращаются на основе настраиваемого максимального числа записей в ответе.

Вопросы и ответы

• В каких случаях используется маршрутизация MultiValue?

• Сколько конечных точек возвращаются при использовании маршрутизации MultiValue?

• Будет ли я получить тот же набор конечных точек при использовании маршрутизации MultiValue?

Метод маршрутизации трафика "Подсеть"

Метод маршрутизации трафика Подсеть позволяет сопоставить набор диапазонов IP-адресов пользователя с определенными конечными точками в профиле. Если диспетчер трафика получит запрос DNS для этого профиля, он проверит исходный IP-адрес этого запроса. Затем он определит, с какой конечной точкой он сопоставлен, и вернет эту конечную точку в ответе на запрос. В большинстве случаев исходный IP-адрес — это сопоставитель DNS, используемый вызывающим объектом.

IP-адрес для сопоставления с конечной точкой может быть указан в виде диапазонов CIDR (например, 1.2.3.0/24) или диапазона адресов (например, 1.2.3.4–5.6.7.8). Диапазоны IP-адресов, связанные с конечной точкой, должны быть уникальными в пределах данного профиля. Диапазон адресов не может перекрываться набором IP-адресов другой конечной точки в том же профиле. Если вы определяете конечную точку без диапазона адресов, она работает в качестве резервного копирования и принимает трафик из любой оставшейся подсети. Если резервная конечная точка отсутствует, диспетчер трафика отправляет ответ NODATA для всех неопределенных диапазонов. Настоятельно рекомендуется определить резервную конечную точку, чтобы обеспечить указание всех возможных диапазонов IP-адресов в конечных точках.

Маршрутизацию подсети можно использовать для предоставления различных возможностей для пользователей, подключающихся из определенного пространства IP-адресов. Например, можно сделать так, чтобы все запросы из корпоративного офиса направлялись на другую конечную точку. Этот метод маршрутизации особенно полезен, если нужно протестировать только внутреннюю версию приложения. Другой сценарий — если вы хотите указать другие возможности для пользователей, подключающихся из конкретного поставщика услуг Интернета (например, заблокировать пользователей данного поставщика услуг Интернета).

Вопросы и ответы

• Каковы некоторые варианты использования маршрутизации подсети?

• Как Диспетчер трафика знать IP-адрес конечного пользователя?

• Как указать IP-адреса при использовании маршрутизации подсети?

• Как указать резервную конечную точку при использовании маршрутизации подсети?

• Что произойдет, если конечная точка отключена в профиле типа маршрутизации подсети?

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

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