Диспетчер трафика 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), Диспетчер трафика учитывает адрес подсети клиента (если сопоставитель, выполняющий запрос от имени пользователя, включил эти данные в запрос).
В частности, стандарт 7871 RFC — подсеть клиента в запросах DNS, который предоставляет механизм расширения для DNS (EDNS0), позволяет сопоставителю передавать адрес поддерживаемых подсетей клиента на DNS-сервер.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете указать максимальное число конечных точек, и маршрутизация с несколькими значениями вернет это количество исправных конечных точек при получении запроса. Максимально возможное значение для этой конфигурации — 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-адрес.

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

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

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

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

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

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

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

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

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

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

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

После остановки конечной точки в веб-приложении 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 для каждого профиля в иерархии.

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

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

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

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

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