балансировщик нагрузки Azure, как он узнает, что приложение в виртуальной машине с балансировкой нагрузки не работает?

Как балансировщик нагрузки Azure узнает, не работает ли приложение - приложение Spring MVC, развернутое на виртуальной машине с балансировкой нагрузки? Возможно, виртуальная машина работает, но приложение не работает. Нужно ли вносить какие-либо изменения в свое приложение - внедрять эхо-службу? Что хорошего в «Пробах здоровья», если, скажем, мы определяем порт 80, TCP - хорошо, это работает, а приложение - нет.

Я прочитал это, но все еще не мог понять проблему: https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension < / а>


azure azure-load-balancer
person Subhendu Mahanta    schedule 11.09.2019    source источник
comment
Полезен ли ответ? У вас есть вопросы в ответе?   -  person Nancy Xiong    schedule 17.09.2019
comment
@ Нэнси, ответ оказался полезным в том смысле, что он расширил мое понимание. Но моя ИТ-команда вернулась с комментарием, что виртуальная машина никогда не выходит из строя, они никогда не видели, чтобы виртуальная машина Azure выходила из строя, и они не будут тратить деньги на покупку другой виртуальной машины, поэтому я предложил перейти на вертикальную кластеризацию Tomcat в 1 ВМ с использованием балансировщика нагрузки Nginx. Таким образом, только HA, без масштабирования - и они говорят, что текущий трафик для моего приложения не оправдывает покупку другой виртуальной машины.   -  person Subhendu Mahanta    schedule 17.09.2019

Ответы (1)


arrow_upward
0
arrow_downward

Балансировщик нагрузки Azure предоставляет пробы работоспособности для использования с правилами балансировки нагрузки. Зонды работоспособности могут поддерживать протоколы в зависимости от SKU балансировщика нагрузки. введите здесь описание изображения

Для TCP-зонд, он инициирует соединение, выполняя трехстороннее открытое установление связи TCP с определенным портом. Зонды TCP завершают соединение с помощью четырехстороннего рукопожатия TCP.

Для зонда HTTP / HTTPS, он основывается на зондировании TCP и выдает HTTP GET с указанным путем. Оба этих зонда поддерживают относительные пути для HTTP GET. Зонд работоспособности помечается, когда экземпляр отвечает с HTTP-статусом 200 в течение периода ожидания. По умолчанию проверка работоспособности пытается проверять настроенный порт проверки работоспособности каждые 15 секунд. Минимальный интервал проверки составляет 5 секунд. Общая продолжительность всех интервалов не может превышать 120 секунд.

Зонды работоспособности TCP, HTTP и HTTPS считаются работоспособными и помечают экземпляр роли как работоспособный в следующих случаях:

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

Поведение зонда зависит от:

  • Количество успешных зондов, позволяющих пометить экземпляр как активный.
  • Количество отказавших зондов, из-за которых экземпляр помечается как неработающий.
  • Указанные значения тайм-аута и интервала определяют, помечен ли экземпляр как работающий или неработающий.

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

В целом вы можете обратиться к руководство по проектированию для разработки зонда работоспособности в соответствии с вашим сценарием, порт приложения и порт зонда не обязательно должны совпадать. В некоторых сценариях может быть желательно, чтобы порт пробы отличался от порта, на котором ваше приложение предоставляет услуги. В вашем случае, я думаю, что если у вас есть TCP-порт 3389 или SSH 22 для успешной проверки вашей внутренней виртуальной машины, тогда HTTP-проверка не работает с портом 80, это может быть сценарий «виртуальная машина может работать, но приложение может не работать. "

person Nancy Xiong    schedule 12.09.2019