Схема определения LoadBalancerProbe для Облачных служб Azure (классических)

Статья
07/24/2024

Внимание

Облачные службы (классическая версия) теперь устарела для всех клиентов с 1 сентября 2024 года. Все существующие запущенные развертывания будут остановлены и завершены корпорацией Майкрософт, и данные будут постоянно потеряны начиная с октября 2024 года. Для новых развертываний следует использовать Облачные службы Azure с расширенной поддержкой. Это новая модель развертывания на основе Azure Resource Manager.

Проверка подсистемы балансировки нагрузки — пользовательский процесс проверки работоспособности конечных точек UDP и конечных точек в экземплярах ролей. Он LoadBalancerProbe не является автономным элементом. Он сочетается с веб-ролью или рабочей ролью в файле определения службы. Несколько ролей могут использовать LoadBalancerProbe.

По умолчанию определения службы хранятся в файле с расширением .csdef.

Функционирование проверки подсистемы балансировки нагрузки

Azure Load Balancer отвечает за маршрутизацию входящего трафика к экземплярам ролей. Подсистема балансировки нагрузки определяет, какие экземпляры могут принимать трафик. Она регулярно проверяет каждый экземпляр, чтобы определить его работоспособность. Эта подсистема проверяет все экземпляры по несколько раз в минуту. Существуют два различных варианта, используя которые подсистема балансировки нагрузки может узнать о работоспособности экземпляров: проверка по умолчанию и пользовательская проверка, для реализации которой нужно определить LoadBalancerProbe в CSDEF-файле.

Проба подсистемы балансировки нагрузки по умолчанию использует гостевой агент внутри виртуальной машины, который прослушивает и реагирует на ответ HTTP 200 OK только в том случае, если экземпляр находится в состоянии готовности (например, если экземпляр не находится в состоянии "Занят", "Перезапуск", "Остановка" и т. д.). Если гостевой агент не отправляет ответ HTTP 200 ОК, Azure Load Balancer отмечает экземпляр как неотвечающий и перестает отправлять к нему трафик. Azure Load Balancer продолжит проверять связь с экземпляром и снова направит трафик к нему, если агент даст ответ HTTP 200. При использовании веб-роли код веб-сайта обычно выполняется в w3wp.exe, которые структура Azure и гостевой агент не отслеживают. Сбои в w3wp.exe (например, ответы HTTP 500) не передаются гостевой агенту, а подсистема балансировки нагрузки не знает, чтобы этот экземпляр не был вращаем.

Пользовательская проверка подсистемы балансировки нагрузки переопределяет проверку гостевого агента по умолчанию и позволяет создать собственную пользовательскую логику для определения работоспособности экземпляра роли. Подсистема балансировки нагрузки по умолчанию регулярно проверяет конечную точку каждые 15 секунд. Экземпляр считается в повороте, если он отвечает с помощью TCP ACK или HTTP 200 в течение периода ожидания (по умолчанию составляет 31 секунд). Этот процесс может быть полезен для реализации собственной логики для удаления экземпляров из смены подсистемы балансировки нагрузки (например, возвращая состояние, отличное от 200, если экземпляр превышает 90 % ЦП). Для веб-ролей с помощью w3wp.exe эта настройка также означает, что вы получаете автоматический мониторинг веб-сайта, так как сбои в коде веб-сайта возвращают состояние, отличное от 200, в пробу подсистемы балансировки нагрузки. Если вы не определяете LoadBalancerProbe в csdef-файле, используется поведение подсистемы балансировки нагрузки по умолчанию (как описано ранее).

Если вы определили пользовательскую проверку подсистемы балансировки нагрузки, необходимо убедиться, что логика учитывает метод RoleEnvironment.OnStop. При использовании пробы подсистемы балансировки нагрузки по умолчанию экземпляр удаляется из поворота перед вызовом OnStop, но пользовательская проба подсистемы балансировки нагрузки может продолжать возвращать 200 ОК во время события OnStop. Если вы используете событие OnStop для очистки кэша, остановки службы или изменения, которые могут повлиять на поведение среды выполнения службы, необходимо убедиться, что логика пробы пользовательской подсистемы балансировки нагрузки удаляет экземпляр из поворота.

Базовая схема определения службы для проверки подсистемы балансировки нагрузки

Ниже приведен базовый формат файла определения службы, содержащий проверку подсистемы балансировки нагрузки.

<ServiceDefinition …>
   <LoadBalancerProbes>
      <LoadBalancerProbe name="<load-balancer-probe-name>" protocol="[http|tcp]" path="<uri-for-checking-health-status-of-vm>" port="<port-number>" intervalInSeconds="<interval-in-seconds>" timeoutInSeconds="<timeout-in-seconds>"/>
   </LoadBalancerProbes>
</ServiceDefinition>

Элементы схемы

Элемент LoadBalancerProbes файла определения службы содержит следующее:

элемент LoadBalancerProbes;
элемент LoadBalancerProbe.

Элемент LoadBalancerProbes

LoadBalancerProbes описывает коллекцию проверок подсистемы балансировки нагрузки. Это родительский элемент для LoadBalancerProbe.

Элемент LoadBalancerProbe

LoadBalancerProbe определяет проверку работоспособности для модели. Вы можете указать несколько проверок подсистемы балансировки нагрузки.

В таблице ниже описаны атрибуты элемента LoadBalancerProbe.

Атрибут	Тип	Описание
`name`	`string`	Обязательное. Имя проверки подсистемы балансировки нагрузки. Имя должно быть уникальным.
`protocol`	`string`	Обязательный. Указывает протокол конечной точки. Возможные значения: `http` или `tcp`. Если указано значение `tcp`, чтобы проверка считалась успешной, требуется ответ ACK. Если указано `http`, проверка считается успешной, если от ресурса с указанным URI получен ответ 200 ОК.
`path`	`string`	URI используется, чтобы запросить состояние работоспособности у виртуальной машины. Атрибут `path` обязателен, если для `protocol` задано значение `http`. В противном случае это не разрешено. Значение по умолчанию отсутствует.
`port`	`integer`	Необязательно. Порт связи с проверкой. Этот атрибут является необязательным для любой конечной точки, так как для пробы используется тот же порт. Вы также можете настроить другой порт для их проверки. Диапазон возможных значений: от 1 до 65 535 включительно. Значение по умолчанию, заданное конечной точкой.
`intervalInSeconds`	`integer`	Необязательно. Интервал в секундах, определяющий частоту, с которой проверяется состояние работоспособности конечной точки. Обычно интервал немного меньше, чем половина выделенного времени ожидания (в секундах), что позволяет провести две полные проверки, прежде чем исключить экземпляр из работы. Значение по умолчанию ― 15. Минимальное значение равно 5.
`timeoutInSeconds`	`integer`	Необязательно. Период времени ожидания (в секундах) применяется к пробе, в которой ответ не приводит к остановке дальнейшего трафика от доставки в конечную точку. Это значение позволяет изымать конечные точки из работы раньше или позже, чем это произошло бы при использовании обычного параметра количества попыток в Azure (для которого используется значение по умолчанию). Значение по умолчанию — 31. Минимальное значение равно 11.

См. также

Схема определения облачных служб (классических).

Поделиться через