Диспетчер трафика Azure: вопросы и ответы

  • Статья

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

Какой 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.

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

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

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

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

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

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

В обзоре диспетчера трафика How Traffic Manager Works объясняется, что диспетчер трафика работает на уровне 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-серверах. Это влияет на ответы следующим образом:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Представление трафика

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

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

  • Регионы, в которых находятся пользователи, подключающиеся к конечным точкам в Azure.
  • количество пользователей из каждого региона;
  • Регионы Azure, в которые они направляются.
  • Задержка пользователей в этих регионах Azure.

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

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

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

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

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

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

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

За какой срок отображаются данные в представлении трафика?

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

Как представление трафика обрабатывает внешние конечные точки

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мониторинг конечных точек Диспетчера трафика

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

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

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

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

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

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

Для Azure Resource 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-адрес.

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

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

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

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

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

Входящий запрос Тип конечной точки Предоставленный ответ
ЛЮБАЯ A / AAAA / CNAME Целевая конечная точка
а A / CNAME Целевая конечная точка
а AAAA; NODATA
AAAA; AAAA / CNAME Целевая конечная точка
AAAA; а NODATA
CNAME CNAME Целевая конечная точка
CNAME A / AAAA NODATA

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

Входящий запрос Тип конечной точки Предоставленный ответ
ЛЮБАЯ Сочетание A и AAAA Целевые конечные точки
а Сочетание A и AAAA Только целевые конечные точки типа A
AAAA; Сочетание A и AAAA Только целевые конечные точки типа AAAA
CNAME Сочетание A и AAAA NODATA

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

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

Работа конечной точки в веб-приложениях в профиле Диспетчера трафика была остановлена, но трафик все равно не приходит даже после перезапуска. Как это исправить?

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

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

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

Какие стоит рассмотреть ответы от конечной точки при использовании протокола ТСР как протокола мониторинга?

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

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

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

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

  • Вы можете указать частоту проверки конечных точек диспетчером трафика, задав интервал проверки в 10 секунд. Это позволит обнаружить неработоспособную конечную точку как можно скорее.
  • Вы можете указать время ожидания запроса на проверку работоспособности (минимальное значение — пять секунд).
  • Вы можете указать количество сбоев, по достижении которых конечная точка будет помечена как неработоспособная. Вы можете установить значение от 0. В таком случае конечная точка будет помечена как неработоспособная, как только произойдет первый сбой при проверке работоспособности. Тем не менее использование минимального значения 0 для допустимого числа сбоев может привести к тому, что конечные точки перестанут использоваться из-за любых временных сбоев, которые могут произойти во время проверки.
  • Вы можете указать для срока жизни ответа DNS значение от 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-адреса могут изменяться без предварительного уведомления. Обязательно извлеките актуальные сведения с помощью API обнаружения тегов служб или загружаемого JSON-файла.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее см. на странице цен для диспетчера трафика.

Снижают ли вложенные профили производительность?

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

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

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

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

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

Состояние монитора дочернего профиля Состояние монитора родительской конечной точки Примечания.
Disabled. Дочерний профиль отключен. Остановлено Состояние родительской конечной точки — «Остановлено», а не «Отключено». Состояние "Отключено" зарезервировано для указания того, что конечная точка отключена в родительском профиле.
"Пониженная функциональность". Как минимум одна конечная точка дочернего профиля находится в состоянии пониженной функциональности. "В сети": количество конечных точек в дочернем профиле, находящихся в состоянии "В сети", не меньше значения MinChildEndpoints.
"Проверка конечной точки": сумма конечных точек в дочернем профиле, находящихся в состояниях "В сети" и "Проверка конечной точки", не меньше значения MinChildEndpoints.
В противном случае: "Пониженная функциональность".		 Трафик перенаправляется к конечной точке с состоянием "Проверка конечной точки". Если задано слишком большое значение MinChildEndpoints, функциональность конечной точки будет понижена.
В сети. Как минимум одна конечная точка дочернего профиля находится в подключенном состоянии. Нет конечных точек в состоянии пониженной функциональности. См. выше.
"Проверка конечных точек". Как минимум одна конечная точка дочернего профиля находится в состоянии проверки конечной точки. Нет конечных точек в подключенном состоянии или в состоянии пониженной функциональности. То же, что выше.
"Неактивно". Все конечные точки дочернего профиля находятся в отключенном или остановленном состоянии либо в этом профиле нет конечных точек. Остановлено

Внимание

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

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

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

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

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