Часто задаваемые вопросы (FAQ) о Диспетчере трафика

Основные сведения о диспетчере трафика

Какой IP-адрес использует диспетчер трафика?

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

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

Какого типа трафик можно маршрутизировать с помощью диспетчера трафика?

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

Поддерживает ли Диспетчер трафика прикрепленные сеансы?

Как объясняется в How Traffic Manager Works, диспетчер трафика работает на уровне DNS. Он использует ответы DNS для направления клиентов на соответствующую конечную точку службы. Клиенты подключаются к конечной точке службы напрямую, а не через диспетчер трафика. Поэтому Диспетчер трафика не видит HTTP-трафик между клиентом и сервером.

Кроме того, исходный IP-адрес, откуда диспетчер трафика получает запрос DNS, принадлежит рекурсивной службе DNS, а не клиенту. Таким образом, Диспетчер трафика не имеет способа отслеживать отдельных клиентов и не может реализовывать "липкие" сеансы. Это ограничение является общим для всех систем управления трафиком на основе DNS и не является специфичным для Диспетчера трафика.

Почему при использовании диспетчера трафика отображается HTTP-ошибка?

Как объясняется в разделе How Traffic Manager Works, диспетчер трафика работает на уровне DNS. Он использует ответы DNS для направления клиентов на соответствующую конечную точку службы. Клиенты подключаются непосредственно к конечной точке службы, а не через диспетчер трафика. Диспетчер трафика не отображает HTTP-трафик между клиентом и сервером. Это значит, что все отображаемые HTTP-ошибки создаются приложением. Если клиент подключился к приложению, значит все действия по разрешению имен DNS уже успешно выполнены. Сюда входят также действия, выполняемые диспетчером в отношении трафика приложения.

Таким образом, вам следует проанализировать возможные проблемы на уровне приложения.

Чаще всего проблемы возникают из-за HTTP-заголовка Host в запросе, который отправляет браузер пользователя. Убедитесь, что приложение настроено на прием правильного заголовка узла для используемого доменного имени. Если конечная точка размещается в службе приложений Azure, см. статью Настройка личного доменного имени для веб-приложения в службе приложений Azure, использующей диспетчер трафика.

Как устранить проблему с 500 (внутренняя ошибка сервера) при использовании Диспетчер трафика?

Если клиент или приложение получает ошибку HTTP 500 при использовании Диспетчер трафика, это может быть вызвано устаревшим DNS-запросом. Чтобы устранить проблему, снимите кэш DNS и разрешите клиенту выдавать новый DNS-запрос.

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

Также см. следующие часто задаваемые вопросы в этой статье:

• Что такое TTL DNS и как это влияет на моих пользователей?
• Какой максимальный или минимальный TTL я могу установить для ответов Диспетчера трафика?
• Как понять объем запросов, поступающих к моему профилю?

Как сказывается на производительности использование диспетчера трафика?

В документе How Traffic Manager Works объясняется, что диспетчер трафика работает на уровне DNS. Поскольку клиенты подключаются напрямую к конечным точкам службы, использование Диспетчера трафика после установления соединения не влияет на производительность.

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

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

Какие протоколы приложения пригодны для использования с диспетчером трафика?

Как объяснено в обзоре "Как работает диспетчер трафика", диспетчер трафика работает на уровне DNS. После завершения поиска DNS клиенты подключаются к конечной точке приложения напрямую, а не через диспетчер трафика. Следовательно, это подключение может использовать любой протокол приложения. Если выбрать протокол ТСР в качестве протокола мониторинга, мониторинг работоспособности конечной точки диспетчера трафика можно выполнить без использования любых протоколов приложения. Если для проверки работоспособности вы выбираете протокол приложения, конечная точка должна отвечать на HTTP- или HTTPS-запросы GET.

Можно ли использовать Диспетчер трафика с доменным именем без префикса?

Да. Сведения о создании записи псевдонима для вашего вершинного доменного имени для ссылки на профиль диспетчера трафика Azure см. в разделе Настройка записи псевдонима для поддержки вершинных доменных имен с помощью диспетчера трафика.

Учитывает ли диспетчер трафика адрес подсети клиента при обработке запросов DNS?

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

Что такое срок жизни DNS и как он влияет на пользователей?

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

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

Каковы минимальное и максимальное значение TTL, которые можно задать для ответов диспетчера трафика?

Для каждого уровня профиля вы можете задать срок жизни DNS от 0 до 2 147 483 647 секунд (максимальный диапазон согласно RFC-1035). TTL 0 означает, что подчиненные сопоставители DNS не кэшируют ответы на запросы, и все запросы, как ожидается, будут достигать Диспетчер трафика DNS-серверов для разрешения.

Что подразумевается под объемом запросов, поступающих в мой профиль?

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

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

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

Например, если имя вашего профиля в Диспетчере трафика — label1, то label1.trafficmanager.net зарезервировано за вашим тенантом, даже если вы удалите профиль. Дочерние пространства имен, такие как xyz.label1 или 123.abc.label1 , также зарезервированы. После истечения срока действия резервирования имя становится доступным для других клиентов. Имя, связанное с отключенным профилем, зарезервировано на неопределенный срок. Для получения вопросов о продолжительности зарезервированного имени обратитесь к представителю учетной записи.

Какая версия TLS требуется у Диспетчера трафика?

Реализация Microsoft более старых версий TLS, как известно, не уязвима, однако TLS 1.2 и более поздних версий обеспечивает улучшенную безопасность с такими функциями, как идеальная секретность пересылки и более сильные наборы шифров. Чтобы повысить безопасность и обеспечить лучшее в своем классе шифрование данных, Диспетчер трафика требует, чтобы взаимодействие со службами было защищено с использованием протокола безопасной передачи (TLS) версии 1.2 или более поздней до 28 февраля 2025 года. Поддержка менеджера трафика для TLS 1.0 и 1.1 завершится с этой даты. Эта дата может отличаться от даты завершения использования TLS 1.0 и TLS 1.1 во всей системе Azure.

Рекомендуемое действие

Чтобы избежать сбоев в обслуживании, ресурсы, взаимодействующие с Диспетчер трафика, должны использовать TLS 1.2 или более поздней версии.

• Если ресурсы уже используют протокол TLS 1.2 или более поздней версии, вам не нужно выполнять дальнейшие действия.
• Если ресурсы по-прежнему зависят от TLS 1.0 или 1.1, переключите их на TLS 1.2 или более поздней версии 28 февраля 2025 г.

Сведения о миграции с TLS 1.0 и 1.1 на TLS 1.2 см. в разделе "Решение проблемы TLS 1.0".

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

В каких случаях следует использовать географическую маршрутизацию?

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

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

Ключевое различие между этими двумя распространенными методами маршрутизации заключается в том, что в методе маршрутизации по производительности ваша основная цель — отправить трафик в конечную точку, которая может обеспечить самую низкую задержку для вызывающего объекта, тогда как в методе географической маршрутизации основная цель — принудительно обеспечить георазграничения для вызывающих объектов, чтобы вы могли преднамеренно направлять их в определенную конечную точку. Наложение происходит из-за корреляции между географической близостью и меньшей задержкой, хотя это не всегда верно. В другом географическом регионе может находиться конечная точка, которая может обеспечить более низкую задержку для пользователя, и в этом случае маршрутизация по производительности направляет пользователя на эту конечную точку, но географическая маршрутизация всегда отправляет их на конечную точку, сопоставленную с их географическим регионом. Чтобы как следует разобраться, рассмотрим следующий пример. С помощью географической маршрутизации вы можете реализовывать необычные сопоставления, например отправлять весь трафик из Азии в конечные точки в США и наоборот. В этом случае географическая маршрутизация намеренно делает именно то, что вы настроили для этого, и оптимизация производительности не учитывается.

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

Иерархию стран или регионов, которую использует диспетчер трафика, см. здесь. Эта страница регулярно дополняется при внесении изменений, но эту же информацию можно получить программными средствами с помощью REST API Диспетчера трафика Azure.

Как диспетчер трафика определяет, откуда пользователь обращается к приложению?

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

Есть ли гарантия, что диспетчер трафика правильно определит точное географическое расположение пользователя во всех случаях?

Нет, Диспетчер трафика не может гарантировать, что географический регион, который мы выводим из исходного IP-адреса DNS-запроса, всегда соответствует расположению пользователя из-за следующих причин:

• Во-первых, как описано в предыдущем вопросе, полученный нами исходный IP-адрес обычно принадлежит сопоставителю DNS, который выполняет поиск от имени пользователя. Географическое расположение резольвера DNS может достаточно точно обозначать географическое местоположение пользователя, но они могут и различаться в зависимости от охвата резольвера DNS и конкретной службы резольвера DNS, выбранной пользователем. Например, клиент из Малайзии может явным образом указать в настройках устройства некоторую службу сопоставителя DNS, обработку запросов к которой для этого пользователя или устройства будет обрабатывать DNS-сервер, расположенный в Сингапуре. В этом случае Диспетчер трафика может только увидеть IP-адрес сопоставителя и определить, что он расположен в Сингапуре. Также смотрите предыдущий раздел вопросов и ответов о поддержке адресов подсети клиента на этой странице.

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

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

Нет, расположение конечной точки не влияет на регионы, с которыми она может быть сопоставлена. Например, на конечную точку в регионе Azure "Центральная часть США" могут быть направлены все пользователи из Индии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IP-адреса для связи с конечной точкой можно указать двумя способами. Во-первых, можно использовать нотацию из четырех цифр с точками, чтобы задать начальный и конечный адреса диапазона (например, 1.2.3.4–5.6.7.8 или 3.4.5.6–3.4.5.6). Во-вторых, можно использовать нотацию CIDR для указания диапазона (например, 1.2.3.0/24). Можно указать несколько диапазонов и использовать оба типа нотаций в наборе диапазонов. Существуют некоторые ограничения.

• Нельзя перекрывать диапазоны адресов, так как каждый IP-адрес необходимо сопоставить только с одной конечной точкой.
• Начальный адрес не может быть больше конечного адреса
• Для нотации CIDR IP-адрес перед "/" должен быть сетевым адресом этого диапазона (например, 1.2.3.0/24 является допустимым, но 1.2.3.4.4/24 недействителен).

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

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

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

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

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

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

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

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

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

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

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

Измерения реальных пользователей

Каковы преимущества при использовании реальных измерений пользователя?

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

Можно ли использовать реальные измерения пользователя для регионов, отличных от регионов Azure?

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

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

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

Нужно ли включать реальные измерения пользователя для каждого профиля отдельно?

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

Как отключить реальные измерения пользователя для подписки?

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

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

Можно ли использовать реальные измерения пользователя в других клиентских приложениях, кроме веб-страниц?

Да, система Реальных пользовательских измерений предназначена для сбора данных от различных типов клиентов конечных пользователей. Это часто задаваемые вопросы обновляется, так как поддерживаются новые типы клиентских приложений.

Сколько измерений выполняется при каждом отображении страницы, для которой включены реальные измерения пользователя?

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

Существует ли задержка перед запуском скрипта реальных измерений пользователя на веб-странице?

Нет, перед вызовом скрипта не запрограммирована задержка.

Можно ли настроить измерения на стороне пользователя так, чтобы они выполнялись только для нужных мне регионов Azure?

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

Можно ли ограничить число измерений?

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

Можно ли увидеть измерения, которые выполняет клиентское приложение в рамках реальных измерений пользователя?

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

Можно ли изменить скрипт измерения, полученный из диспетчера трафика?

Хотя вы контролируете то, что внедрено на веб-странице, мы настоятельно не рекомендуем вносить изменения в скрипт измерения, чтобы убедиться, что он измеряет и сообщает задержки правильно.

Могут ли другие лица увидеть ключ, который я использую для реальных измерений пользователя?

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

Могут ли злоумышленники использовать ключ RUM?

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

Нужно ли размещать скрипт измерений JavaScript на всех веб-страницах?

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

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

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

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

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

Нужно ли размещать службы в регионах Azure, чтобы использовать реальные измерения пользователя?

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

Увеличится ли мой трафик в Azure при использовании реальных измерений пользователя?

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

Вид трафика

Что делает просмотр трафика?

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

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

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

Какую пользу можно получить от представления трафика?

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

Чем представление трафика отличается от метрик диспетчера трафика, доступных через монитор Azure?

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

Использует ли представление трафика сведения о подсети клиента EDNS?

В DNS-запросах, обслуживаемых диспетчером трафика Azure, учитываются сведения ECS для повышения точности маршрута. Но при создании набора данных, который показывает, откуда подключаются пользователи, в представлении трафика используется только IP-адрес сопоставителя DNS.

Сколько дней данных использует представление трафика?

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

Как Traffic View обрабатывает внешние конечные точки?

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

Нужно ли включать просмотр трафика для каждого профиля в подписке?

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

Как отключить представление трафика?

Представление трафика можно отключить для любого профиля с помощью портала или REST API.

Как устроена система начисления за Traffic View?

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

Конечные точки диспетчера трафика

Можно ли использовать в диспетчере трафика конечные точки из нескольких подписок?

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

Для других типов конечных точек можно использовать Диспетчер трафика с конечными точками из нескольких подписок. В Resource Manager в диспетчер трафика можно добавить конечные точки из любой подписки при условии, что у пользователя, настраивающего профиль диспетчера трафика, есть доступ на чтение к этим конечным точкам. Эти разрешения можно предоставить с помощью управления доступом на основе ролей Azure (роли Azure RBAC). Конечные точки из других подписок можно добавлять с помощью Azure PowerShell или Azure CLI.

Можно ли использовать диспетчер трафика с слотами "стадии" облачной службы?

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

Поддерживает ли диспетчер трафика конечные точки IP версии 6?

Да, Диспетчер трафика полностью поддерживает конечные точки IPv6. Диспетчер трафика предоставляет серверы имен, доступные для IPv4 и IPv6, что позволяет клиентам легко подключаться с помощью любого протокола. Клиенты IPv6 могут выполнять DNS-запросы непосредственно через рекурсивные службы DNS с поддержкой IPv6, и Диспетчер трафика могут реагировать с помощью DNS-имени или IP-адреса конечной точки IPv6, обеспечивая полную совместимость с сетями IPv6.

Можно ли использовать в диспетчере трафика несколько веб-приложений в одном и том же регионе?

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

Как переместить конечные точки Azure профиля диспетчера трафика в другую группу ресурсов или подписку?

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

Дополнительные сведения см. в разделе "Перемещение конечной точки".

Поддерживает ли Диспетчер трафика Azure механизмы расширения IPv6 для DNS (ECS)?

Диспетчер трафика Azure поддерживает IPv6-адреса с механизмами расширения для DNS (ECS). Это означает, что если DNS-запрос содержит сведения ECS, Диспетчер трафика Azure может использовать исходный IP-адрес в ECS для принятия интеллектуальных решений по маршрутизации.

Поддержка IPv6 ECS обеспечивает несколько преимуществ:

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

При использовании IPv6 ECS важно убедиться, что конечные точки правильно настроены для обработки трафика IPv6. Кроме того, убедитесь, что инфраструктура DNS, включая рекурсивные сопоставители, может обрабатывать сведения ECS с помощью IPv6-адресов.

Мониторинг конечных точек Менеджера трафика

Устойчив ли диспетчер трафика к сбоям в регионе Azure?

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

По умолчанию компоненты диспетчера трафика отказоустойчивы к полному сбою любого региона Azure. Эта устойчивость применяется ко всем компонентам диспетчера трафика: DNS-серверам, API-интерфейсам, уровню хранилища и службе мониторинга конечных точек.

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

Как выбор расположения группы ресурсов влияет на Traffic Manager?

Диспетчер трафика — это единая глобальная служба. Это не относится к региону. Выбор расположения группы ресурсов никак не влияет на профили диспетчера трафика, развернутые в этой группе ресурсов.

Для Azure Resource Manager требуется, чтобы все группы ресурсов указывали расположение, которое определяет расположение по умолчанию для ресурсов, развернутых в этой группе ресурсов. При создании профиля Traffic Manager он создаётся в группе ресурсов. Во всех профилях диспетчера трафика в качестве расположения задано значение Глобальный (тем самым переопределяется группа ресурсов по умолчанию).

Как определить текущую работоспособность каждой конечной точки?

На портале управления Azure отображается текущее состояние мониторинга для каждой конечной точки, а также всего профиля. Эти сведения также можно получить с помощью монитора трафика REST API, командлетов PowerShell и кроссплатформенного интерфейса командной строки Azure.

Azure Monitor может использоваться для отслеживания работоспособности конечных точек и просмотра их визуального представления. Дополнительные сведения об использовании Azure Monitor см. в статье Обзор метрик в Microsoft Azure.

Можно ли отслеживать конечные точки HTTPS?

Да. Диспетчер трафика поддерживает проверку по протоколу HTTPS. Настройте HTTPS в качестве протокола в конфигурации мониторинга.

Диспетчер трафика не может предоставить проверку сертификата, в том числе:

• Сертификаты на стороне сервера не проверяются
• Сертификаты на стороне сервера SNI не проверяются
• Сертификаты клиента не поддерживаются

Необходимо использовать IP-адрес или имя DNS при добавлении конечной точки?

Диспетчер трафика поддерживает добавление конечных точек тремя способами ссылки на них.

• DNS-имя
• Как IPv4-адрес
• IPv6-адрес

Если конечная точка добавляется в качестве адреса IPv4 или IPv6, ответ запроса имеет тип записи A или AAAA соответственно. Если конечная точка была добавлена как DNS-имя, то ответ на запрос имеет тип записи CNAME. Добавление конечных точек как IPv4- или IPv6-адресов разрешается только для внешних конечных точек.

Эти три типа адресов конечных точек поддерживают все методы маршрутизации и параметры мониторинга.

Какие типы IP-адресов можно использовать при добавлении конечной точки?

Диспетчер трафика позволяет использовать адреса IPv4 или IPv6 для указания конечных точек. Ниже перечислено несколько ограничений:

• Адреса, соответствующие зарезервированным частным IP-адресам, не допускаются. К этим адресам относятся те, которые были вызваны в RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 и RFC 5771.
• IP-адрес не должен содержать номера портов (можно указать порты, которые будут использоваться в параметрах конфигурации профиля).
• Ни одна конечная точка в одном профиле не может иметь один и тот же целевой IP-адрес.

Можно ли использовать разные типы адресов конечной точки в одном профиле?

№ Диспетчер трафика не позволяет смешивать типы адресации конечных точек в профиле, за исключением профиля с типом маршрутизации MultiValue, где можно смешивать типы адресации IPv4 и IPv6.

Что происходит, когда тип записи входящего запроса отличается от типа записи, связанного с типом адреса конечных точек?

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

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

Для профилей с маршрутизацией с несколькими значениями:

Можно ли использовать профиль с конечными точками с адресами IPv4/IPv6 во вложенном профиле?

Да, за исключением того, что профиль типа MultiValue не может быть родительским профилем в вложенном наборе профилей.

Я остановил конечную точку веб-приложения в профиле Traffic Manager, но трафик все равно не поступает, даже после того как я перезапустил её. Как это исправить?

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

Можно ли использовать Диспетчер трафика, даже если приложение не поддерживает протоколы HTTP и HTTPS?

Да. Вы можете указать протокол ТСР как протокол мониторинга. Диспетчер трафика запустит подключение TCP и будет ожидать ответ от конечной точки. Если конечная точка отвечает на запрос на подключение ответом на установку подключения (в течение периода ожидания), тогда такая конечная точка помечается как работоспособная.

Какие конкретные ответы требуются от конечной точки при использовании мониторинга по протоколу TCP?

При использовании мониторинга TCP диспетчер трафика инициирует трехсторонний обмен пакетами TCP, отправляя запрос SYN в конечную точку на указанном порте. Затем он в течение определенного периода (указанного в параметрах времени ожидания) ожидает ответ SYN-ACK от конечной точки.

• Если в течение периода ожидания, указанного в параметрах мониторинга, поступает ответ SYN-ACK, то такая конечная точка считается работоспособной. Ожидаемым ответом от диспетчера трафика, когда он регулярно завершает сокет, является протокол FIN или FIN-ACK.
• Если ответ SYN-ACK получен после указанного времени ожидания, Диспетчер трафика отвечает на запрос RST для сброса подключения.

Насколько быстро диспетчер трафика перемещает пользователей из неработоспособной конечной точки?

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

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

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

Как я могу указать в профиле другие параметры мониторинга для других конечных точек?

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

Как можно назначить заголовки HTTP для проверок работоспособности моих конечных точек диспетчером трафика?

Диспетчер трафика позволяет указывать настраиваемые заголовки в проверках работоспособности HTTP(S) для конечных точек. Если вы хотите указать пользовательский заголовок, можно сделать это на уровне профиля (для всех конечных точек) или на уровне конечной точки. Если заголовок определен на обоих уровнях, то указанный на уровне конечной точки имеет приоритет над уровнем профиля 1. Один из распространённых случаев использования этого — указание заголовков хоста, чтобы запросы Диспетчера трафика могли быть правильно направлены к конечной точке, размещённой в мультитенантной среде. Другой пример использования — это идентификация запросов к диспетчеру трафика в журналах HTTP(S) запросов конечной точки.

Какой заголовок хоста используется для проверки работоспособности конечной точки?

Если вы не указали настраиваемый заголовок узла, диспетчер трафика использует в качестве заголовка узла имя DNS целевой конечной точки, настроенное в профиле, если есть.

С каких IP-адресов выполняются проверки работоспособности?

См. эту статью, чтобы узнать, как получить списки IP-адресов, с которых могут исходить проверки работоспособности Диспетчера трафика. Для получения актуального списка можно использовать REST API, Azure CLI или Azure PowerShell. Проверьте перечисленные IP-адреса, чтобы узнать, разрешены ли входящие подключения с этих адресов на конечных точках для проверки состояния их работоспособности.

Пример использования Azure PowerShell

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

Сколько проверок работоспособности моей конечной точки я могу ожидать от диспетчера трафика?

Число проверок работоспособности конечной точки диспетчером трафика зависит от следующих условий:

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

Каким образом я получу уведомление о том, что одна из моих конечных точек вышла из строя?

Одним из показателей, предоставляемых Диспетчером трафика, является статус работоспособности конечных точек в профиле. Вы можете видеть эту метрику как совокупность конечных точек внутри профиля (например, 75 % ваших конечных точек работоспособны) или на уровне каждой отдельной конечной точки. Диспетчер трафика метрики предоставляются с помощью Azure Monitor, и вы можете использовать свои возможности оповещения для получения уведомлений при изменении состояния работоспособности конечной точки. Дополнительные сведения см. в статье Метрики и оповещения Диспетчера трафика.

Вложенные профили диспетчера трафика

Как настроить вложенные профили?

Вложенные профили диспетчера трафика можно настроить с помощью Azure Resource Manager (ARM), классических интерфейсов REST API Azure, командлетов Azure PowerShell и команд кроссплатформенного интерфейса командной строки Azure. Они также поддерживаются через новый портал Azure.

Число уровней вложенности поддерживает диспетчер трафика?

Вложенность профилей может достигать 10 уровней. "Циклы" не разрешены.

Можно ли совмещать конечные точки других типов с вложенными дочерними профилями в одном профиле диспетчера трафика?

Да. Можно без каких-либо ограничений комбинировать в профиле конечные точки разных типов.

Как модель выставления счетов применяется к вложенным профилям?

Нет негативного влияния использования вложенных профилей на цены.

При выставлении счетов за использование диспетчера трафика учитываются два фактора: проверки работоспособности конечных точек и число запросов DNS (миллионы).

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

Узнайте подробности на странице с ценами Traffic Manager.

Есть ли влияние на производительность при использовании вложенных профилей?

Использование вложенных профилей не оказывает влияния на производительность.

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

Как диспетчер трафика определяет работоспособность вложенной конечной точки в родительском профиле?

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

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

Почему я не могу добавить конечные точки расширенной поддержки Облачных служб Azure в профиль Диспетчера трафика?

Чтобы добавить конечные точки Azure Cloud Extended в профиль Диспетчер трафика, группа ресурсов должна иметь совместимость с API управления службами Azure (ASM). Профили, находящиеся в более старой группе ресурсов, должны соответствовать стандартам ASM API, которые запрещают включение конечных точек общедоступных IP-адресов или конечных точек из подписки, отличной от подписки профиля. Чтобы устранить эту проблему, рассмотрите возможность перемещения профиля Диспетчер трафика и связанных ресурсов в новую группу ресурсов, совместимую с API ASM.

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

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