Устранение неполадок с работоспособностью ресурсов и доступностью входящего трафика

  • Статья

Эта статья представляет собой руководство по исследованию проблем, влияющих на доступность внешнего IP-адреса и серверных ресурсов балансировщика нагрузки.

Средство проверки работоспособности ресурсов (RHC) для Load Balancer используется для определения работоспособности балансировщика нагрузки. Оно анализирует метрику доступности пути данных в течение 2-минутного интервала, чтобы определить, доступны ли конечные точки балансировки нагрузки, а также сочетания IP-интерфейсов и интерфейсных портов с правилами балансировки нагрузки.

Примечание. RHC не поддерживается для Подсистемы балансировки нагрузки SKU уровня "Базовый"

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

Состояние работоспособности ресурсов Описание
На месте Ресурс стандартной подсистемы балансировки нагрузки работоспособен и доступен.
Деградация Стандартная подсистема балансировки нагрузки имеет инициированные платформой или пользователем события, влияющие на производительность. Метрика доступности Datapath, сообщаемая менее чем на 90%, но больше 25 % работоспособности по крайней мере за две минуты. Вы испытываете умеренное снижение производительности.
Рекомендации недоступны Стандартный ресурс подсистемы балансировки нагрузки не работоспособна. Метрика доступности Datapath сообщила менее чем на 25 % работоспособности по крайней мере за две минуты. Вы испытываете значительное снижение производительности или отсутствие доступности для входящего подключения. Могут возникать события пользователя или платформы, вызывающие недоступность.
Неизвестно Состояние работоспособности ресурсов для ресурса стандартной подсистемы балансировки нагрузки не обновило или не получило сведения о доступности пути данных за последние 10 минут. Это временное состояние и будет отражать правильное состояние сразу после получения данных.

Сведения о используемых метриках

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

Доступность пути к данным

Метрика доступности пути к данным создается с помощью TCP-проверки связи каждые 25 секунд на всех интерфейсных портах, для которых настроены правила балансировки нагрузки и входящего трафика NAT. Эта проверка связи TCP направляется на любой из работоспособных (пробных) экземпляров серверной части. Если служба получает ответ на проверку связи, это успешный ответ, и сумма метрики выполняется итерация один раз. Если ответа нет, итерация не происходит. Счетчик этой метрики составляет 1/100 общих TCP-проверок связи за период выборки. Таким образом, мы хотим рассмотреть среднее значение, которое является средним значением суммы или счетчика за период времени. В данных показана метрика доступности пути, агрегированная по среднему значению, что дает нам процентную частоту успешности для tcp-pings в интерфейсном IP:порте для каждого из правил балансировки нагрузки и входящих NAT.

Состояние проверки работоспособности

Метрика состояния проверки работоспособности формируется командой ping для протокола, определенного в пробе работоспособности. Эта проверка связи отправляется на каждый экземпляр во внутреннем пуле и порт, определенный в пробе работоспособности. Для проб HTTP и HTTPS успешная проверка связи требует наличия ответа HTTP 200 OК, в то время как при использовании проверки TCP любой ответ считается успешным. Последовательные успехи или сбои каждой пробы определяют работоспособность внутреннего экземпляра и способен ли назначенный серверный пул получать трафик. Аналогично доступности пути к данным, мы используем среднее агрегирование, которое указывает среднее количество успешных и общих проверок связи в течение интервала выборки. Это значение состояния пробы работоспособности обозначает работоспособность серверной части в изоляции от балансировщика нагрузки путем проверки серверных экземпляров без отправки трафика через интерфейс.

Внимание

Состояние пробы работоспособности выдается ежеминутно. Это может приводить к незначительным колебаниям в остальном постоянного значения. Например, если есть два экземпляра серверной части, для одного из которых проба успешна, а для другого нет, то служба проверки работоспособности может получить 7 измерений работоспособного экземпляра и 6 — для неработоспособного экземпляра. Это приведет к тому, что ранее стабильное значение 50 превратится в 46,15 для интервала в одну минуту.

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

Как описано в статье о работоспособности ресурсов, подсистема балансировки нагрузки снижается, что показывает доступность пути к данным в диапазоне от 25 до 90 %. Недоступная подсистема балансировки нагрузки — это один из них с доступностью пути к данным менее чем на 25 % за два минуты. Эти же действия можно выполнить для расследования сбоя, который вы видите в любом состоянии пробы работоспособности или оповещениях о доступности пути данных, которые вы настроили. Мы рассмотрим ситуацию, когда мы проверка работоспособность ресурсов и обнаружили, что подсистема балансировки нагрузки недоступна с доступностью пути к данным 0 % — наша служба отключена.

Во-первых, мы перейдем к подробному представлению метрик страницы аналитики подсистемы балансировки нагрузки в портал Azure. Перейдите к представлению со страницы ресурсов подсистемы балансировки нагрузки или ссылку в сообщении о работоспособности ресурсов. Затем перейдите на вкладку "Доступность внешнего интерфейса и серверной части" и просмотрите 30-минутное окно периода, когда произошло пониженное или недоступное состояние. Если мы видим, что доступность пути к данным составляет 0%, мы знаем, что существует проблема, препятствующая трафику для всех наших правил балансировки нагрузки и входящего трафика, и мы можем увидеть, как долго эта проблема длилась.

Далее нужно найти метрику состояния проверки работоспособности, чтобы определить, недоступен ли путь к данным, так как нет работоспособных серверных экземпляров для обслуживания трафика. Если у нас есть по крайней мере один здоровый внутренний экземпляр для всех правил балансировки нагрузки и входящего трафика, мы знаем, что это не наша конфигурация, из-за чего пути к данным будут недоступны. Этот сценарий указывает на проблему платформы Azure. Хотя проблемы платформы редки, автоматизированное оповещение отправляется в нашу команду, чтобы быстро устранить все проблемы платформы.

Диагностика сбоев пробы работоспособности

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

  • Проверьте использование ЦП для ресурсов, чтобы определить, находятся ли они под высокой нагрузкой.
    • Это можно проверка, просмотрев метрику процента ЦП ресурса на странице метрик. Узнайте, как устранять проблемы с высокой загрузкой ЦП для виртуальных машин Azure.
  • Если используется проба HTTP или HTTPS, проверка, если приложение работает и реагирует.
    • Проверка работоспособности приложения путем прямого доступа к приложениям через частный IP-адрес или общедоступный IP-адрес уровня экземпляра, связанный с серверным экземпляром.
  • Проверьте группы безопасности сети, применяемые к внутренним ресурсам. Убедитесь, что правила более высокого приоритета, чем AllowAzureLoadBalancerInBound , блокируют проверку работоспособности.
    • Это можно сделать, перейдя к параметрам сети внутренних виртуальных машин или Масштабируемые наборы виртуальных машин.
    • Если эта проблема NSG возникла, переместите существующее правило allow или создайте новое правило с высоким приоритетом, чтобы разрешить трафик AzureLoadBalancer.
  • Проверьте ОС. Убедитесь, что виртуальные машины прослушивают порт пробы и просматривают правила брандмауэра ОС, чтобы убедиться, что они не блокируют трафик пробы, исходящий из IP-адреса 168.63.129.16.
    • Вы можете проверка прослушивать порты, выполняя из netstat -a командной строки Windows или netstat -l из терминала Linux.
  • Убедитесь, что используется соответствующий протокол. Например, проба с помощью HTTP для проверки порта, прослушивающего приложение, отличное от HTTP, завершается ошибкой.
  • Брандмауэр Azure не следует размещать в серверном пуле подсистем балансировки нагрузки. См. статью "Интеграция Брандмауэр Azure с Azure Load Balancer (цен. категория для правильной интеграции Брандмауэр Azure с подсистемой балансировки нагрузки".

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

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