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

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

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

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

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

• Ожидаемый диапазон кодов состояния. Этот параметр позволяет указать несколько успешных диапазонов кодов в формате: 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, повторные попытки не выполняются. Если число последовательных сбоев превышает значение параметра Допустимое число сбоев , эта конечная точка помечается как неработоспособная.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-адресом. 

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

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

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

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

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

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

Всегда служить

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

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

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

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

Часто задаваемые вопросы

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

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

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