Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Сводка
Эта статья поможет вам изучить проблемы, влияющие на доступность внешних IP-адресов и внутренних ресурсов подсистемы балансировки нагрузки.
Вы можете использовать функцию resource health в Azure Load Balancer для определения работоспособности подсистемы балансировки нагрузки. Он анализирует метрику доступности пути данных, чтобы определить, доступны ли конечные точки балансировки нагрузки, интерфейсный IP-адрес и интерфейсный порт с правилами балансировки нагрузки.
Замечание
Базовый балансировщик нагрузки не поддерживает возможность проверки работоспособности ресурсов.
В следующей таблице описана логика определения состояния работоспособности подсистемы балансировки нагрузки.
| Состояние работоспособности ресурсов | Описание |
|---|---|
| Доступно | Ресурс подсистемы балансировки нагрузки является работоспособным и доступным. |
| Деградация | Подсистема балансировки нагрузки имеет события, инициируемые пользователем или платформой, которые влияют на производительность. Метрика доступности канала передачи данных зафиксировала уровень работоспособности менее 90%, но более 25% на протяжении как минимум двух минут. Возможно, вы столкнулись с умеренным снижением производительности. |
| недоступно | Ресурс балансировщика нагрузки не работоспособен. Метрика доступности пути данных показала менее 25% работоспособности в течение не менее двух минут. Возможно, вы столкнулись с значительным снижением производительности или отсутствием доступности для входящего подключения. События пользователя или платформы могут вызывать недоступность. |
| Неизвестный | Состояние работоспособности вашего ресурса балансировщика нагрузки не обновилось и не получило информацию о доступности пути данных за последние 10 минут. Это состояние может быть временным, или подсистема балансировки нагрузки может не поддерживать функцию работоспособности ресурсов. |
Мониторинг доступности подсистемы балансировки нагрузки
Две метрики, которые Azure Load Balancer используются для проверки работоспособности ресурсов, — Data Path Availability и Health Probe Status. Важно понимать их смысл, чтобы получить правильные аналитические сведения.
Data Path Availability (Доступность пути к данным)
TCP-пинг формирует метрику доступности пути данных каждые 25 секунд на всех фронтенд-портах, где настроены правила балансировки нагрузки. Эта проверка связи TCP направляется на любой из работоспособных (пробных) экземпляров серверной части. Метрика представляет собой агрегированную процентную процентную частоту успешных подключений TCP для каждой комбинации интерфейсных IP-адресов и портов для каждого из правил балансировки нагрузки в течение выборочного периода времени.
Статус проверки работоспособности
Пинг протокола, определенного в проверке работоспособности, генерирует метрику состояния проверки работоспособности. Этот ping отправляется каждому экземпляру в серверном пуле и на порту, определённом в пробе работоспособности. Для проб HTTP и HTTPS для успешного пинга требуется ответ HTTP 200 OK. При использовании проб TCP любой ответ считается успешным.
Azure Load Balancer определяет работоспособность каждого экземпляра в серверной группе, когда количество последовательных успешных или неудачных результатов проверки достигает установленного порогового значения. Состояние работоспособности каждого экземпляра серверной части определяет, разрешено ли принимать трафик.
Как и метрика доступности пути к данным, метрика состояния пробы работоспособности агрегирует среднее успешное и общее число оповещения во время интервала выборки. Значение статуса пробы здоровья указывает на состояние серверной части независимо от балансировщика нагрузки путем проверки экземпляров серверной части без направления трафика через фронтенд.
Это важно
Статус проверки работоспособности опрашивается с интервалом в одну минуту. Эта выборка может привести к незначительным колебаниям в иначе постоянном значении.
Например, рассмотрим активные и пассивные сценарии, в которых есть два внутренних экземпляра, одно пробное и одно проверенное. Сервис проверки работоспособности может собирать семь снимков для работоспособного экземпляра и шесть для неработоспособного экземпляра. Эта ситуация приводит к ранее устойчивому значению 50, отображаемого как 46,15 за один минутный интервал.
Диагностика деградированных и недоступных подсистем балансировки нагрузки
Как описано в этой статье о работоспособности ресурсов, деградированная балансировка нагрузки показывает значение между 25% и 90% для доступности пути передачи данных. Недоступным считается балансировщик нагрузки, у которого доступность канала данных составляет менее 25% в течение двух минут.
Вы можете выполнить те же действия, чтобы изучить сбой, который отображается в любых оповещениях о состоянии пробы работоспособности или доступности пути данных, настроенных вами. Ниже описываются шаги, которые нужно предпринять, если вы проверяете работоспособность ваших ресурсов и обнаруживаете, что подсистема балансировки нагрузки недоступна при значении доступности пути данных 0%. Ваша служба не работает.
На портале Azure перейдите к подробному представлению метрик страницы для аналитики подсистемы балансировки нагрузки. Перейдите к представлению со страницы ресурса подсистемы балансировки нагрузки или из ссылки в сообщении о работоспособности ресурсов.
Перейдите на вкладку, посвященную доступности интерфейса и серверной части, и просмотрите 30-минутное окно времени, в течение которого происходило ухудшение состояния или его недоступность. Если значение доступности пути к данным равно 0%, вы знаете, что что-то предотвращает трафик для всех правил балансировки нагрузки. Вы также можете увидеть, сколько времени эта проблема длилась.
Проверьте метрику статуса пробы работоспособности, чтобы определить, недоступен ли путь передачи данных, потому что у вас нет работоспособных экземпляров серверной части для обслуживания трафика. Если у вас есть хотя бы один работоспособный внутренний экземпляр для всех правил балансировки нагрузки и входящих подключений, вы знаете, что конфигурация не является причиной недоступности маршрутов передачи данных. Этот сценарий указывает на проблему платформы Azure. Хотя проблемы платформы редки, они активируют автоматическое оповещение нашей команде для быстрого устранения.
Диагностика сбоев проверок работоспособности
Если метрика состояния проверки работоспособности указывает на то, что экземпляры серверной части неисправны, мы рекомендуем использовать следующий контрольный список, чтобы исключить распространенные ошибки конфигурации.
Проверьте загрузку ЦП ваших ресурсов, чтобы определить, находятся ли они под высокой нагрузкой.
Вы можете проверить, просмотрев метрику процента ЦП ресурса на странице метрик . Для получения дополнительной информации см. Устранение проблем с высокой нагрузкой на ЦП для виртуальных машин Azure Windows.
Если вы используете пробу HTTP или HTTPS, проверьте работоспособность и реагирование приложения.
Проверьте, что ваше приложение функционально, напрямую получив к нему доступ через частный IP-адрес или публичный IP-адрес уровня экземпляра, связанный с вашей серверной частью.
Просмотрите группы безопасности сети (NSG), применяемые к ресурсам бэкенда. Убедитесь, что нет правил с более высоким приоритетом, чем у
AllowAzureLoadBalancerInBound, которые блокируют проверку работоспособности.Эту задачу можно выполнить, перейдя к параметрам сети внутренних виртуальных машин или масштабируемых наборов виртуальных машин. Если вы обнаружите, что проблема связана с NSG, переместите существующее правило
Allowили создайте новое правило с высоким приоритетом, чтобы разрешить прохождение трафика Azure Load Balancer.Проверьте операционную систему. Убедитесь, что виртуальные машины прослушивают порт пробы. Также просмотрите правила брандмауэра ОС для виртуальных машин, чтобы убедиться, что они не блокируют трафик пробы, исходящий из IP-адреса
168.63.129.16.Вы можете проверить порты прослушивания, выполнив
netstat -aиз командной строки Windows илиnetstat -lиз терминала Linux.Убедитесь, что вы используете правильный протокол. Например, проба, использующая HTTP для проверки порта, прослушивающего не http-приложение, завершается ошибкой.
Не размещайте Брандмауэр Azure в серверном пуле подсистем балансировки нагрузки. Дополнительные сведения см. в разделе Интеграция Брандмауэр Azure с Azure Load Balancer (цен. категория "Стандартный").