Устранение неполадок работоспособности ресурсов и доступности входящего трафика
Эта статья поможет вам изучить проблемы, влияющие на доступность внешних IP-адресов и внутренних ресурсов подсистемы балансировки нагрузки.
Вы можете использовать функцию работоспособности ресурсов в Azure Load Balancer для определения работоспособности подсистемы балансировки нагрузки. Он анализирует метрику доступности пути данных, чтобы определить, доступны ли конечные точки балансировки нагрузки, интерфейсный IP-адрес и интерфейсный порт с правилами балансировки нагрузки.
Примечание.
Базовая подсистема балансировки нагрузки не поддерживает функцию работоспособности ресурсов.
В следующей таблице описана логика определения состояния работоспособности подсистемы балансировки нагрузки.
| Состояние работоспособности ресурсов | Описание |
|---|---|
| Доступно | Ресурс подсистемы балансировки нагрузки является работоспособным и доступным. |
| Деградация | Подсистема балансировки нагрузки имеет события, инициируемые пользователем или платформой, которые влияют на производительность. Метрика доступности пути данных сообщила менее 90 %, но больше 25 % работоспособности по крайней мере за две минуты. Возможно, вы столкнулись с умеренным снижением производительности. |
| Недоступна | Ресурс подсистемы балансировки нагрузки не работоспособна. Метрика доступности пути данных сообщила менее чем на 25 % работоспособности по крайней мере за две минуты. Возможно, вы столкнулись с значительным снижением производительности или отсутствием доступности для входящего подключения. События пользователя или платформы могут привести к недоступности. |
| Unknown | Состояние работоспособности ресурсов для ресурса подсистемы балансировки нагрузки не обновило или не получило сведения о доступности пути к данным за последние 10 минут. Это состояние может быть временным, или подсистема балансировки нагрузки может не поддерживать функцию работоспособности ресурсов. |
Мониторинг доступности подсистемы балансировки нагрузки
Две метрики, которые Azure Load Balancer использует для проверки работоспособности ресурсов, — доступность пути к данным и состояние пробы работоспособности. Важно понимать их смысл, чтобы получить правильные аналитические сведения.
Data Path Availability (Доступность пути к данным)
Tcp-связь создает метрику доступности пути данных каждые 25 секунд на всех интерфейсных портах, где настроены правила балансировки нагрузки. Эта проверка связи TCP направляется на любой из работоспособных (пробных) экземпляров серверной части. Метрика представляет собой агрегированную процентную процентную частоту успешных подключений TCP для каждой комбинации интерфейсных IP-адресов и портов для каждого из правил балансировки нагрузки в течение выборочного периода времени.
Health Probe Status (Состояние пробы работоспособности)
Проверка подлинности протокола, определенного в пробе работоспособности, создает метрику состояния проверки работоспособности. Эта проверка связи отправляется на каждый экземпляр во внутреннем пуле и порт, определенный в пробе работоспособности. Для проб HTTP и HTTPS для успешной HTTP 200 OK проверки связи требуется ответ. При использовании проб TCP любой ответ считается успешным.
Azure Load Balancer определяет работоспособность каждого внутреннего экземпляра, когда проба достигает количества последовательных успешных или неудачных попыток, настроенных для свойства порогового значения пробы. Состояние работоспособности каждого внутреннего экземпляра определяет, разрешено ли экземпляр серверной части получать трафик.
Как и метрика доступности пути к данным, метрика состояния пробы работоспособности агрегирует среднее успешное и общее число оповещения во время интервала выборки. Значение состояния пробы работоспособности указывает на работоспособность серверной части в изоляции от подсистемы балансировки нагрузки, проверив внутренние экземпляры без отправки трафика через интерфейс.
Внимание
Состояние пробы работоспособности выполняется по одной минуте. Эта выборка может привести к незначительным колебаниям в противном случае устойчивого значения.
Например, рассмотрим активные и пассивные сценарии, в которых есть два внутренних экземпляра, одно пробное и одно проверенное. Служба проб работоспособности может записать семь примеров для работоспособного экземпляра и шесть для неработоспособного экземпляра. Эта ситуация приводит к ранее устойчивому значению 50, отображаемого как 46,15 за один минутный интервал.
Диагностика неработоспособных и недоступных подсистем балансировки нагрузки
Как описано в этой статье о работоспособности ресурсов, подсистема балансировки нагрузки снижается в диапазоне от 25 до 90 % для доступности пути к данным. Недоступная подсистема балансировки нагрузки составляет менее 25 % для доступности пути к данным в течение двух минут.
Вы можете выполнить те же действия, чтобы изучить сбой, который отображается в любых оповещениях о состоянии пробы работоспособности или доступности пути данных, настроенных вами. В следующих шагах описано, что делать, если проверить работоспособность ресурсов и найти подсистему балансировки нагрузки, чтобы быть недоступной со значением доступности пути данных 0%. Служба отключена.
В портал Azure перейдите к подробному представлению метрик страницы для аналитики подсистемы балансировки нагрузки. Перейдите к представлению со страницы ресурса подсистемы балансировки нагрузки или из ссылки в сообщении о работоспособности ресурсов.
Перейдите на вкладку для доступности внешнего интерфейса и серверной части и просмотрите 30-минутное окно периода времени, когда произошло снижение или недоступность состояния. Если значение доступности пути к данным равно 0%, вы знаете, что что-то предотвращает трафик для всех правил балансировки нагрузки. Вы также можете увидеть, сколько времени эта проблема длилась.
Проверьте метрику состояния пробы работоспособности, чтобы определить, недоступен ли путь к данным, так как у вас нет здоровых экземпляров серверной части для обслуживания трафика. Если у вас есть хотя бы один здоровый внутренний экземпляр для всех правил балансировки нагрузки и входящих подключений, вы знаете, что конфигурация не является причиной недоступности путей к данным. Этот сценарий указывает на проблему платформы Azure. Хотя проблемы платформы редки, они активируют автоматическое оповещение для нашей команды для быстрого решения.
Диагностика сбоев пробы работоспособности
Если метрика состояния пробы работоспособности указывает на неработоспособные экземпляры серверной части, рекомендуется использовать следующий контрольный список, чтобы исключить распространенные ошибки конфигурации:
Проверьте загрузку ЦП для ресурсов, чтобы определить, находитесь ли они под высокой нагрузкой.
Вы можете проверить, просмотрев метрику процента ЦП ресурса на странице метрик . Дополнительные сведения см. в статье "Устранение проблем с высокой загрузкой ЦП для виртуальных машин Windows Azure".
Если вы используете пробу 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 (цен. категория ".