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

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

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

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

• Протокол. Выберите протокол HTTP, HTTPS или TCP, который Диспетчер трафика будет использовать при проверке работоспособности конечной точки. Мониторинг HTTPS не проверяет, является ли сертификат TLS/SSL допустимым, он проверяет только наличие сертификата.
• Порт. Выберите порт, используемый для запроса.
• Path. Этот параметр конфигурации допустим только для протоколов HTTP и HTTPS, для которых необходимо указать параметр пути. Если указать этот параметр для протокола мониторинга TCP, возникнет ошибка. Для протокола HTTP и HTTPS введите относительный путь и имя веб-страницы или файла, к которому обращается средство мониторинга. Косая черта / является допустимой записью для относительного пути. Это значение указывает, что файл находится в корневом каталоге (по умолчанию).
• Параметры пользовательского заголовка. Этот параметр конфигурации позволяет добавлять определенные HTTP-заголовки для проверки работоспособности, которые Диспетчер трафика отправляет конечным точкам в профиле. Настраиваемые заголовки можно указать на уровне профиля, применимые ко всем конечным точкам в этом профиле и (или) на уровне конечной точки, применимой только к этой конечной точке. Вы можете использовать настраиваемые заголовки для проверки работоспособности конечных точек в среде с несколькими клиентами. Таким образом, его можно правильно перенаправить в место назначения, указав заголовок узла. Этот параметр можно также использовать, добавив уникальные заголовки, которые могут использоваться для определения запросов HTTP(S) Диспетчера трафика, чтобы обрабатывать эти запросы по-разному. Можно указать до восьми header:value пар, разделенных запятой. Например: header1:value1, header2:value2.

Примечание.

Использование символов звездочки (*) в пользовательских Host заголовках не поддерживается.

• Ожидаемый диапазон кодов состояния. Этот параметр позволяет указать несколько диапазонов кодов успешного результата проверки состояния в формате: 200-299, 301-301. Если эти коды состояния будут получены в качестве ответа от конечной точки при выполнении проверки работоспособности, Диспетчер трафика отметит эти конечные точки как работоспособные. Вы можете указать не более восьми диапазонов кодов состояния. Этот параметр применим только для протокола HTTP и HTTPS, а также для всех конечных точек. Этот параметр находится на уровне профиля Диспетчера трафика, и по умолчанию в качестве кода успешного результата проверки состояния используется значение 200.

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

• Tolerated number of failures (Допустимое число сбоев). Это значение указывает количество сбоев, которое допускает агент проверки Диспетчера трафика. По достижении этого количества конечная точка будет помечена как неработоспособная. Значение должно быть в диапазоне от 0 до 9. Значение 0 означает, что конечная точка будет помечена как неработоспособная при первом сбое. Если значение не задано, используется значение по умолчанию 3.

• Время ожидания проверки. Это свойство указывает длительность времени ожидания, по истечении которого агент проверки Диспетчера трафика считает, что проверка пробы работоспособности завершилась сбоем. Если для интервала проверки задано значение 30 секунд, вы можете задать значение времени ожидания в 5–10 секунд. Если значение не задано, используется значение по умолчанию 10 секунд. Если для интервала проверки задано значение 10 секунд, вы можете задать значение времени ожидания в 5–9 секунд. Если значение времени ожидания не задано, используется значение по умолчанию, равное 9 секундам.

  

  Рис.1. Мониторинг конечных точек в диспетчере трафика

Как выполняется мониторинг конечных точек

Если в качестве протокола мониторинга используется HTTP или HTTPS, агент проверки Диспетчера трафика отправляет запрос GET в конечную точку, используя указанные протокол, порт и относительный путь. Конечная точка считается работоспособной, если агент проверки получает ответ "200-OK" или любой из ответов, настроенных в разделе Ожидаемые диапазоны кодов состояния. Если ответ имеет другое значение или в течение времени ожидания не получен ответ, агент проверки Диспетчера трафика будет повторять попытку столько раз, сколько задано параметром "Допустимое число сбоев". Если этот параметр имеет значение 0, повторные попытки не выполняются. Конечная точка помечается неработоспособным, если число последовательных сбоев превышает допустимое число сбоев .

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

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

Примечание.

На стороне конечной точки для протоколов мониторинга HTTP и HTTPS распространенной практикой является реализация пользовательской страницы в приложении, например /health.aspx. Используя этот путь для мониторинга, можно выполнить проверки для конкретного приложения, такие как проверка счетчиков производительности или проверка доступности базы данных. На основании этих пользовательских проверок страница возвращает соответствующий код состояния HTTP.

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

Состояние конечной точки и профиля

Можно включать и отключать профили и конечные точки диспетчера трафика. Однако изменение состояния конечной точки также может произойти в результате автоматической настройки и процессов Диспетчера трафика.

Состояние конечной точки

Можно включить или отключить определенную конечную точку. Это не повлияет на базовую службу, которая может остаться работоспособной. Изменение состояния конечной точки определяет ее доступность в профиле диспетчера трафика. Если состояние конечной точки отключено, Диспетчер трафика не проверяет его работоспособность, а конечная точка не включена в ответ DNS.

Состояние профиля

С помощью параметра "состояние профиля" можно включить или отключить определенный профиль. Если состояние конечной точки влияет на одну конечную точку, то состояние профиля влияет на весь профиль, включая все конечные точки. При отключении профиля конечные точки не проверяются для работоспособности, а конечные точки не включаются в ответ DNS. Для запроса DNS возвращается код ответа NXDOMAIN.

Отслеживаемое состояние конечной точки

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

Состояние профиля	Состояние конечной точки	Отслеживаемое состояние конечной точки	Примечания.
Выключено	Включен	Неактивное	Профиль отключен. Хотя конечная точка остается в состоянии "Включено", состояние профиля ("Отключено") имеет более высокий приоритет. Конечные точки в отключенных профилях не отслеживаются. Для запроса DNS возвращается код ответа NXDOMAIN.
<любой>	Выключено	Выключено	Конечная точка отключена. Отключенные конечные точки не отслеживаются. Конечная точка не включена в ответы DNS, так как она не получает трафик.
Включен	Включен	Миграция по сети	Конечная точка отслеживается и работоспособна. Она включается в ответы DNS и может получать трафик.
Включен	Включен	Деградация	Проверки работоспособности мониторинга конечной точки завершаются ошибкой. Конечная точка не включается в ответы DNS и не получает трафик. Исключением является ситуация, когда функциональность всех конечных точек снижена. В этом случае все из них считаются возвращаемыми в ответе запроса.
Включен	Включен	Проверка конечной точки	Конечная точка отслеживается, но результаты первой проверки еще не получены. CheckingEndpoint — это временное состояние, которое обычно возникает сразу же после добавления конечной точки или ее включения в профиле. Конечная точка в таком состоянии включается в ответы DNS и может получать трафик.
Включен	Включен	Остановлено	Веб-приложение, на которое указывает конечная точка, не работает. Проверьте параметры веб-приложения. Такое состояние также может возникать при проверке вложенных конечных точек, когда дочерний профиль отключен или неактивен. Конечная точка в остановленном состоянии не отслеживается. Она не включается в ответы DNS и не получает трафик. Исключением является ситуация, когда функциональность всех конечных точек снижена. В этом случае все из них считаются возвращаемыми в ответе запроса.
Включен	Включен	Не отслеживается	Конечная точка настроена для всегда обслуживать трафик. Проверки работоспособности не включены.

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

Примечание.

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

Состояние монитора профиля

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

Состояние профиля (согласно настройкам)	Отслеживаемое состояние конечной точки	Состояние монитора профиля	Примечания.
Выключено	<любой> или профиль без определенных конечных точек.	Выключено	Профиль отключен.
Включен	По крайней мере одна конечная точка находится в состоянии пониженной функциональности.	Деградация	Просмотрите значения состояния отдельных конечных точек, чтобы определить, какие конечные точки необходимо рассмотреть.
Включен	По крайней мере одна конечная точка находится в сети. Отсутствуют конечные точки в состоянии пониженной функциональности.	Миграция по сети	Служба принимает трафик. В дальнейших действиях нет необходимости.
Включен	По крайней мере одна конечная точка находится в состоянии проверки конечной точки. Нет конечных точек, находящихся в сети или в состоянии пониженной функциональности.	Проверка конечных точек	Это переходное состояние возникает при создании или включении профиля. Работоспособность конечной точки проверяется в первый раз.
Включен	Все конечные точки профиля отключены или остановлены, либо в профиле не определены конечные точки.	Неактивное	Конечные точки не активны, но профиль включен.

Отработка отказа и восстановление конечной точки

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

Конечная точка считается неработоспособной при возникновении любого из следующих событий:

• Если протокол мониторинга — HTTP или HTTPS:
  • получен ответ, отличный от 200, или ответ, который не включен в диапазон состояний, указанный в параметре Ожидаемые диапазоны кодов состояния (включая различные коды 2xx или перенаправление 301/302).
• Если протокол мониторинга является TCP:
  • в ответ на запрос SYN, отправленный Диспетчером трафика, чтобы установить подключение, получен ответ, отличный от ACK или SYN-ACK.
• Период ожидания.
• Любые другие проблемы с подключением, из-за которых невозможно получить доступ к конечной точке.

Дополнительные сведения об устранении неполадок с неудачными проверками см. в разделе "Устранение неполадок с пониженным состоянием" в Диспетчер трафика Azure.

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

• протокол мониторинга — HTTP;
• интервал проверки — 30 секунд;
• число допустимых сбоев — 3;
• значение времени ожидания — 10 секунд;
• срок жизни DNS — 30 секунд.

Рис.2. Последовательность отработки отказа и восстановления конечной точки диспетчера трафика

1. GET. Для каждой конечной точки система мониторинга Диспетчера трафика выполняет запрос GET для пути, указанного в параметрах мониторинга.

2. 200 ОК или пользовательский диапазон кодов, указанные в параметрах мониторинга профиля Диспетчера трафика. Система мониторинга ожидает, что ответ "HTTP 200 OK" или код состояния в диапазоне, заданном в параметрах мониторинга, будет возвращен в течение 10 секунд. Получив этот ответ, система распознает облачную службу как доступную.

3. 30 секунд между проверками. Проверка работоспособности конечной точки выполняется каждые 30 секунд.

4. Служба недоступна. Служба становится недоступной. Диспетчеру трафика станет известно об этом только при следующей проверке работоспособности.

5. Попытки получить доступ к пути мониторинга. Система мониторинга выполняет запрос GET, но не получает ответ в течение периода ожидания длительностью 10 секунд. Затем выполняется еще три попытки с интервалом в 30 секунд. Если одна из попыток оказывается успешной, число попыток сбрасывается.

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

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

8. Проверки работоспособности продолжаются. Диспетчер трафика продолжает проверять работоспособность конечной точки, пока она находится в состоянии пониженной функциональности. Диспетчер трафика обнаруживает, когда конечная точка восстановила работоспособность.

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

10. Возобновляется направление трафика к службе. Диспетчер трафика отправляет запрос GET и получает ответ о состоянии "200 OK". Служба вернулась в работоспособное состояние. Серверы имен диспетчера трафика снова обновляются и начинают передавать DNS-имя службы в ответах DNS. Трафик вернется к конечной точке, так как срок действия кэшированных ответов DNS, возвращающих другие конечные точки, истек и существующие подключения к другим конечным точкам завершены.

    Внимание

    Диспетчер трафика развертывает несколько проб из нескольких расположений для каждой конечной точки. Множественные пробы увеличивают устойчивость для мониторинга конечных точек. Диспетчер трафика выполняет статистическое вычисление среднего показателя работоспособности проб, а не основывается на единственном экземпляре пробы. Избыточность системы проверки запланирована при разработке. Значения конечных точек следует рассматривать комплексно, а не для каждой пробы. Число, отображаемое для работоспособности пробы, является средним значением. Состояние должно вызывать беспокойство только в том случае, если менее 50% (0,5) проб публикуют статус работает.

    Примечание.

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

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

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

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

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

Примечание.

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

Это условие обычно вызвано неправильной конфигурацией службы, например:

• проверки работоспособности диспетчера трафика блокируются списком управления доступом [ACL];
• неправильная конфигурация порта или протокола мониторинга в профиле диспетчера трафика.

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

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

Включение или отключение проверок работоспособности

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

Существует два доступных параметра для проверок работоспособности:

1. Включить (проверки работоспособности). Трафик обслуживается конечной точке на основе работоспособности. Это параметр по умолчанию.
2. Всегда обслуживать трафик. Этот параметр отключает проверки работоспособности.

Always Serve

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

Чтобы включить Always Serve, выполните приведенные действия.

1. Выберите конечные точки в разделе "Параметры" колонки профиля Диспетчер трафика.
2. Выберите конечную точку, которую требуется настроить.
3. В разделе "Проверки работоспособности" выберите "Всегда обслуживать трафик".
4. Выберите Сохранить.

См. следующий пример.

Примечание.

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

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

• Устойчивость Диспетчер трафика к сбоям региона Azure?
• Как выбор расположения группы ресурсов влияет на Диспетчер трафика?
• Разделы справки определить текущую работоспособность каждой конечной точки?
• Можно ли отслеживать конечные точки HTTPS?
• При добавлении конечной точки используется IP-адрес или DNS-имя?
• Какие типы IP-адресов можно использовать при добавлении конечной точки?
• Можно ли использовать разные типы адресации конечных точек в одном профиле?
• Что происходит, когда тип записи входящего запроса отличается от типа записи, связанного с типом адресации конечных точек?
• Можно ли использовать профиль с адресными конечными точками IPv4/ IPv6 в вложенном профиле?
• Работа конечной точки в веб-приложениях в профиле Диспетчера трафика была остановлена, но трафик все равно не приходит даже после перезапуска. Как устранить эту проблему?
• Можно ли использовать Диспетчер трафика, даже если приложение не поддерживает протоколы HTTP и HTTPS?
• Какие конкретные ответы требуются от конечной точки при использовании мониторинга TCP?
• Насколько быстро Диспетчер трафика перемещает пользователей из неработоспособной конечной точки?
• Как указать различные параметры мониторинга для разных конечных точек в профиле?
• Как назначить заголовки HTTP Диспетчер трафика проверки работоспособности конечным точкам?
• Какой заголовок узла использует проверки работоспособности конечной точки?
• Каковы IP-адреса, из которых создаются проверки работоспособности?
• Сколько проверок работоспособности для моей конечной точки можно ожидать от Диспетчер трафика?
• Как получить уведомление, если одна из моих конечных точек выходит из строя?

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

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