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

Диспетчер трафика 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 секунд;
• TTL для 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 и будут направлены к другим конечным точкам. Длительность кэширования контролируется настройкой TTL в профиле диспетчера трафика, например, 30 секунд.

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

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

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

    Внимание

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

    Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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