Устранение неполадок с ответами на трафик внутренней части Azure Load Balancer

На этой странице представлены сведения об устранении неполадок с Azure Load Balancer.

Виртуальные машины за подсистемой балансировки нагрузки получают трафик неравномерно

Если вы подозреваете, что члены внутреннего пула получают трафик, это может быть вызвано следующими причинами. Azure Load Balancer распределяет трафик на основе подключений. Проверяйте распределение трафика на уровне подключений, а не отдельных пакетов. Убедитесь, что на вкладке "Распределение потоков" на панели мониторинга Аналитика предварительно настроенной подсистемы балансировки нагрузки.

Azure Load Balancer не поддерживает истинный циклический перебор для балансировки нагрузки, но поддерживает режим распределения на основе хэширования.

Причина 1. Настроено сохранение сеансов

Режим сохранения сеансов для источника может привести к неравномерному распределению трафика. Если такое распределение нежелательно, установите для этого параметра значение Нет, чтобы трафик равномерно распределялся по всем работоспособным экземплярам во внутреннем пуле. Подробнее о режимах распределения трафика в Azure Load Balancer.

Причина 2. Настроен прокси-сервер

Load Balancer может считать всех клиентов, которые работают за одним прокси-сервером, одним уникальным клиентским приложением.

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

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

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

  • Группа безопасности сети блокирует порт на виртуальной машине внутреннего пула подсистемы балансировки нагрузки

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

  • Доступ к интерфейсу подсистемы балансировки нагрузки в Интернете осуществляется из виртуальной машины внутреннего пула подсистемы балансировки нагрузки

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

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

Проверка и способы устранения

  1. Войдите в виртуальную машину внутреннего пула.

  2. Откройте командную строку и выполните следующую команду, чтобы проверить, есть ли приложение, прослушивающее порт данных:

    netstat -an 
    
  3. Если для состояния порта не указано значение ОЖИДАЕТ ПЕРЕДАЧИ ДАННЫХ, настройте соответствующий порт прослушивателя.

  4. Если порт отмечен как ОЖИДАЕТ ПЕРЕДАЧИ ДАННЫХ, то проверьте наличие неполадок в целевом приложении на этом порте.

Причина 2. Группа безопасности сети блокирует порт на виртуальной машине серверного пула подсистемы балансировки нагрузки

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

В общедоступной подсистеме балансировки нагрузки для обмена данными между клиентами и серверными виртуальными машинами подсистемы балансировки нагрузки будут использоваться IP-адреса клиентов Интернета. Убедитесь, что IP-адреса клиентов разрешены в группе безопасности сети серверной виртуальной машины.

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

  2. В списке групп безопасности сети проверьте:

    • наличие помех для входящего или исходящего трафика через порт данных;

    • наличие правила групп безопасности сети Запретить все в сетевой карте виртуальной машины или подсети, которое имеет более высокий приоритет, чем правило по умолчанию, позволяющее выполнение проб и трафик подсистемы балансировки нагрузки (в группах безопасности сети необходимо разрешить IP-адрес подсистемы балансировки нагрузки 168.63.129.16, который является портом пробы).

  3. Если любое из правил блокирует трафик, то удалите и перенастройте правила, чтобы они разрешали трафик данных. 

  4. Проверьте, начала ли виртуальная машина отвечать на пробы работоспособности.

Причина 3. Доступ к внутренней подсистеме балансировки нагрузки с той же виртуальной машины и сетевого интерфейса

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

Решение

Чтобы устранить эту проблему, используйте один из указанных ниже способов:

  • Настройте для каждого приложения отдельные виртуальные машины внутреннего пула.

  • Настройте приложение в виртуальных машинах с двумя сетевыми картами, чтобы каждое приложение использовало собственные сетевой интерфейс и IP-адрес.

Причина 4. Доступ к интерфейсу внутренней подсистемы балансировки нагрузки осуществляется из виртуальной машины внутреннего пула подсистемы балансировки нагрузки

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

Решение

Существует несколько способов разблокировать этот сценарий, включая использование прокси-сервера. Оцените шлюз приложений или другие сторонние прокси-серверы (например, nginx или haproxy). Дополнительные сведения о шлюзе приложений см. в статье Обзор шлюза приложений.

Сведения

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

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

Когда поток сопоставляется с собой, исходящий поток, как представляется, исходит от виртуальной машины к интерфейсу, и соответствующий поток входящего трафика, как представляется, исходит от виртуальной машины к себе. С точки зрения гостевой операционной системы входящие и исходящие части того же потока не совпадают в виртуальной машине. Стек TCP не будет распознавать эти половины одного потока как часть того же потока. Источник и назначение не совпадают. Когда поток сопоставляется с любой другой виртуальной машиной в серверном пуле, половины потока соответствуют и виртуальная машина может реагировать на поток.

Симптомом этого сценария является периодическое истечение времени ожидания подключения, когда поток возвращается к той же серверной части, из которой он возник. К типичным обходным решениям относятся вставка уровня прокси-сервера за внутренней подсистемой балансировки нагрузки и использование правил прямого ответа от сервера (DSR). Дополнительные сведения см. в статье Несколько внешних интерфейсов для Azure Load Balancer.

Вы можете объединить внутреннюю подсистему балансировки нагрузки со сторонним прокси-сервером или использовать внутренний шлюз приложений для сценариев прокси-сервера с протоколами HTTP и HTTPS. Вы можете использовать в качестве обходного решения общедоступную подсистему балансировки нагрузки. Но такой сценарий может приводить к нехватке SNAT. Избегайте этого второго подхода, если не сможете осуществить его тщательно.

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

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