Пробы работоспособности Azure Load Balancer

  • Статья

Проба работоспособности Azure Load Balancer — это функция, которая обнаруживает состояние работоспособности экземпляров приложения. Он отправляет запрос экземплярам проверка, если они доступны и отвечают на запросы. Проба работоспособности может быть настроена для использования различных протоколов, таких как TCP, HTTP или HTTPS. Это важная функция, так как она помогает обнаруживать сбои приложений, управлять нагрузкой и планировать время простоя.

Чтобы правила Azure Load Balancer могли определить состояние конечной точки, требуется проба работоспособности. Конфигурация проверки работоспособности и ответов пробы определяет, какие экземпляры серверного пула получают новые подключения. Используйте пробы работоспособности для обнаружения сбоя приложения. Создайте пользовательский ответ для пробы работоспособности. Используйте пробу работоспособности для управления потоком, чтобы управлять нагрузкой или плановым простоем. При сбое пробы работоспособности подсистема балансировки нагрузки останавливает отправку новых подключений в соответствующий неработоспособный экземпляр. Исходящие подключения не затрагиваются. Затрагиваются только входящие.

Протоколы пробы

Пробы работоспособности поддерживают множественные протоколы. Доступность конкретного протокола проб работоспособности зависит от номера SKU Load Balancer. Кроме того, поведение службы зависит от номера SKU Load Balancer, как показано в таблице ниже.

SKU "Стандартный" SKU "Базовый"
Протокол пробы TCP, HTTP, HTTPS TCP, HTTP
Реакция на сбой пробы При сбое всех проб работоспособности потоки TCP продолжаются. При сбое всех проб срок действия потоков TCP истекает.

Свойства пробы

Пробы работоспособности имеют следующие свойства:

Имя свойства пробы работоспособности Сведения
Имя. Имя пробы работоспособности. Это имя, необходимо определить для пробы работоспособности.
Протокол Протокол пробы работоспособности. Это тип протокола, который будет использоваться пробой работоспособности. Параметры: TCP, HTTP, HTTPS
Порт Порт пробы работоспособности. Целевой порт, который будет использоваться пробой работоспособности при подключении к виртуальной машине для проверка работоспособности.
Интервал (в секундах) Интервал пробы работоспособности. Время (в секундах) между различными пробами на двух последовательных проверка пытается выполнить попытку на виртуальную машину
Где используется Список правил подсистемы балансировки нагрузки с помощью этой конкретной пробы работоспособности. Для его эффективной работы должно быть по крайней мере одно правило с помощью пробы работоспособности.

Конфигурация пробы

Конфигурация пробы работоспособности состоит из следующих элементов:

Конфигурация пробы работоспособности Сведения
Протокол Протокол пробы работоспособности. Это тип протокола, который будет использоваться пробой работоспособности. Доступны следующие варианты: TCP, HTTP, HTTPS
Порт Порт пробы работоспособности. Целевой порт, который вы хотите использовать пробу работоспособности при подключении к виртуальной машине, чтобы проверка состояние работоспособности виртуальной машины. Необходимо убедиться, что виртуальная машина также прослушивает этот порт (т. е. открытый порт).
Интервал Интервал пробы работоспособности. Время (в секундах) между последовательными попытками работоспособности проверка пытается использовать виртуальную машину.

Протокол пробы

Протокол, используемый пробой работоспособности, можно настроить на один из следующих вариантов: TCP, HTTP, HTTPS.

Сценарий Проба TCP Проба HTTP/HTTPS
Обзор Проверки TCP инициализируют подключение, выполняя трехстороннее подтверждение по открытому TCP-протоколу на определенном порту. Пробы протокола TCP завершают подключение с помощью закрытого четырехстороннего подтверждения протокола TCP. HTTP и HTTPS выдает HTTP GET с указанным путем. Обе пробы поддерживают относительные пути для HTTP GET. Пробы HTTPS аналогичны пробам HTTP, но к ним добавлен протокол TLS. С помощью проб HTTP/HTTPS удобно реализовать собственную логику для удаления экземпляров из подсистемы балансировки нагрузки, если порт для пробы также является прослушивателем службы.
Поведение сбоя пробы Проверка TCP завершается ошибкой, когда: 1. Прослушиватель TCP в экземпляре не отвечает в течение периода времени ожидания. Проба отмечается как неработоспособная в зависимости от количества запросов на пробу с превышением времени ожидания, которых достаточного для того, чтобы проба была отмечена как неработоспособная. 2. Проба получает сброс TCP-соединения от экземпляра. Проба HTTP/HTTPS завершается ошибкой, если: 1. Конечная точка пробы возвращает код ответа HTTP, отличный от 200 (например, 403, 404 или 500). 2. Конечная точка пробы вообще не реагирует на запросы в течение минимального интервала пробы и 30-секундного периода ожидания. Множество запросов на пробу могут оставаться без ответа до того, как проба будет отмечена как неработоспособная, и пока не будет достигнуто суммы всех интервалов времени ожидания. 3. Конечная точка пробы закрывает подключение путем сброса TCP-соединения.
Поведение при работоспособной пробе Пробы работоспособности TCP считаются работоспособными и помечают серверную конечную точку как работоспособную, если: 1. Проба работоспособности выполнена успешно уже после загрузки виртуальной машины. 2. Любая конечная точка серверной части в работоспособном состоянии может получать новые потоки. Проба работоспособности отмечается как работоспособная, когда экземпляр отвечает с HTTP-состоянием 200 в течение периода ожидания. Пробы работоспособности HTTP/HTTPS считаются работоспособными и помечают серверную конечную точку как работоспособную, если: 1. Проба работоспособности выполнена успешно уже после загрузки виртуальной машины. 2. Любая конечная точка серверной части в работоспособном состоянии может получать новые потоки.

Примечание.

Проба HTTPS требует использования сертификатов на основе минимального хэша сигнатуры SHA256 во всей цепочке.

Реакция на сбой пробы

Сценарий TCP-подключения Датаграммы UDP
Пробы одного экземпляра вниз Новые TCP-подключения успешно остаются работоспособными серверной конечной точкой. Установленные TCP-подключения к этой серверной конечной точке продолжаются. Существующие потоки UDP перемещаются в другой здоровый экземпляр в серверном пуле.
Проверка всех экземпляров вниз Новые потоки не отправляются в внутренний пул. Load Balancer (цен. категория позволяет установленным потокам TCP продолжать работу, учитывая, что серверный пул имеет несколько экземпляров серверной части. Базовая подсистема балансировки нагрузки завершает все существующие потоки TCP в серверный пул. Все существующие потоки UDP завершаются.

Интервал пробы и время ожидания

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

Чтобы обеспечить своевременное получение ответа, пробы работоспособности HTTP/S имеют встроенные тайм-ауты. Ниже приведены сроки ожидания для проб TCP и HTTP/S:

  • Длительность времени ожидания пробы TCP: N/A (пробы завершаются сбоем после прохождения настроенного интервала пробы и отправки следующей пробы).
  • Длительность времени ожидания пробы HTTP/S: 30 секунд

Для проб HTTP/S, если настроенный интервал превышает указанный выше период времени ожидания, проба работоспособности завершится сбоем, если ответ не получен в течение периода ожидания. Например, если проба работоспособности HTTP настроена с интервалом пробы в 120 секунд (каждые 2 минуты), а ответ пробы не получен в течение первых 30 секунд, проба достигнет своего периода времени ожидания и завершится сбоем.

Руководство по проектированию

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

  • Может быть полезно, если ваше приложение создаст ответ для пробы работоспособности и отправит сигнал подсистеме балансировки нагрузки о том, следует ли вашему экземпляру принимать новые подключения. Вы можете управлять ответом пробы, чтобы регулировать доставку новых подключений экземпляру, заблокировав ответ пробе работоспособности. Вы можете подготовить обслуживание приложения и инициировать сток подключений к приложению. Сигнал вниз пробы всегда позволяет потокам TCP продолжаться до истечения времени ожидания простоя или закрытия подключения в Load Balancer (цен. категория .

  • Для приложения с балансировкой нагрузки UDP создайте настраиваемый сигнал пробы работоспособности из серверной конечной точки. Используйте TCP, HTTP или HTTPS для пробы работоспособности с учетом соответствующего прослушивателя.

  • Правила балансировки нагрузки для портов с высоким уровнем доступности с Load Balancer (цен. категория «Стандартный»). На всех портах выполняется балансировка нагрузки, а в одном ответе пробы работоспособности должно отражаться состояние всего экземпляра.

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

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

  • Обратите внимание, что определение пробы не является обязательным или проверка при использовании Azure PowerShell, Azure CLI, шаблонов или API. Тесты проверки проб выполняются только при использовании портал Azure.

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

  • Убедитесь, что запущены экземпляры виртуальных машин. Для каждого запущенного экземпляра в серверном пуле проба работоспособности проверка для доступности. Если экземпляр остановлен, он не будет проверяться до тех пор, пока он не будет запущен снова.

  • Не настраивайте свою виртуальную сеть с диапазоном IP-адресов, принадлежащим корпорации Майкрософт, который содержит адрес 168.63.129.16. Конфигурация сталкивается с IP-адресом пробы работоспособности и может привести к сбою сценария.

  • Чтобы протестировать сбой пробы работоспособности или пометить отдельный экземпляр, используйте группу безопасности сети для явной блокировки пробы работоспособности. Создайте правило группы безопасности сети для блокировки порта назначения или исходный IP-адрес для моделирования сбоя пробы.

Наблюдение

Load Balancer (цен. категория предоставляет состояние проверки работоспособности конечной точки и серверной конечной точки с помощью Azure Monitor. Другие службы Azure или партнерские приложения могут использовать эти метрики. Журналы Azure Monitor не поддерживаются для Basic Load Balancer.

IP-адрес источника пробы

Для проверки работоспособности Load Balancer для разметки экземпляра необходимо разрешить ip-адрес 168.63.129.16 в любых группах безопасности сети Azure и локальных политиках брандмауэра. Тег службы AzureLoadBalancer определяет этот исходный IP-адрес в ваших группах безопасности сети и разрешает трафик пробы работоспособности по умолчанию. Дополнительные сведения об этом IP-адресе см. здесь.

Если вы не разрешаете исходный IP-адрес пробы в политиках брандмауэра, проба работоспособности завершается ошибкой, так как не удается связаться с экземпляром. В свою очередь, Azure Load Balancer помечает экземпляр как вниз из-за сбоя пробы работоспособности. Эта неверная конфигурация может привести к сбою сценария приложения с балансировкой нагрузки. Все пробы работоспособности Подсистемы балансировки нагрузки IPv4 исходят из IP-адреса 168.63.129.16 в качестве источника. Пробы IPv6 используют локальный адрес ссылки в качестве источника.

Ограничения

  • Пробы HTTPS не поддерживают взаимную проверку подлинности с помощью сертификата клиента.

  • Предполагается, что пробы работоспособности завершаются сбоем при включении меток времени TCP.

  • Проба работоспособности подсистемы балансировки нагрузки с номером SKU «Базовый» не поддерживается масштабируемым набором виртуальных машин.

  • Из соображений безопасности HTTP-пробы не поддерживают проверку на следующих портах: 19, 21, 25, 70, 110, 119, 143, 220, 993.

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