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

Сводка

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

Azure Load Balancer распределяет потоки с использованием хеш-функции, а не по методу round robin. Таким образом, один клиент или один NAT либо прокси-сервер, находящийся перед системой, может направить весь трафик на один внутренний сервер. Неравномерное распределение обусловлено следующими основными причинами:

• Ожидание заказчика, что при используемом по умолчанию хешировании по 5-кортежу будет применяться round robin для каждого запроса, нереалистично.
• Низкая энтропия IP-адреса источника на стороне вышестоящего NAT или прокси-сервера приводит к тому, что множество клиентов используют один и тот же IP-адрес источника.
• Сохранение сеанса по IP-адресу источника (2-элементный или 3-элементный кортеж) настраивается, если привязка сеанса не требуется.
• Это правило применяется к протоколу, пакеты которого используют один и тот же кортеж (DHCP-ретрансляция, syslog, ловушки SNMP) и поэтому не подходит для балансировщика нагрузки на основе хэширования потока.

Симптомы

Вы можете столкнуться с одним или несколькими из следующих симптомов:

• Один серверный экземпляр показывает почти 100 % полученных байтов или потоков в Microsoft Viva Insights, тогда как у остальных экземпляров этот показатель близок к нулю.
• Определенный IP-адрес клиента, подсеть или офис всегда направляется на один и тот же бэкенд даже после перезапуска бэкенда.
• Добавление дополнительных экземпляров бэкенда не уменьшает нагрузку на перегруженный экземпляр.
• Во время тестирования распределение трафика кажется равномерным, но в рабочей среде оно нарушается после того, как перед балансировщиком нагрузки устанавливают брандмауэр, сетевое виртуальное устройство (NVA) или прокси-сервер.
• Трафик DHCP, syslog или SNMP trap-сообщений накапливается на одном внутреннем сервере. Резервные серверы ретранслятора не получают пакеты.
• Проверки работоспособности помечают все внутренние серверы как Up, хотя фактически работает только один из них.

Необходимые условия

Чтобы устранить неполадки с неравномерной распределением трафика на Load Balancer, вам потребуется следующее:

• Необходимые разрешения:Network Contributor роль в группе ресурсов балансировщика нагрузки (или эквивалентная роль, предоставляющая разрешения Microsoft.Network/loadBalancers/read, Microsoft.Network/loadBalancers/write и Microsoft.Insights/metrics/read)
• Средства: Azure CLI 2.x или агент ИИ, имеющий доступ к Azure CLI
• Обязательные переменные и примеры этих переменных, как показано в следующей таблице

Этапы диагностики

Шаг 1

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

Выполните следующие команды в Azure CLI:

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME

az network lb rule list \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, protocol:protocol, frontendPort:frontendPort, backendPort:backendPort, loadDistribution:loadDistribution, floatingIP:enableFloatingIP, idleTimeoutInMinutes:idleTimeoutInMinutes}" \
  --output table

Интерпретация результатов

Запишите имя правила как $RULE_NAME для последующих шагов.

Шаг 2

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

Выполните следующие команды в Azure CLI:

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME

LB_ID=$(az network lb show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "id" --output tsv)

echo "Backend pool members:"
az network lb address-pool list \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{pool:name, backends:loadBalancerBackendAddresses[].{ip:ipAddress, network adapter:networkInterfaceIPConfiguration.id}}" \
  --output json

echo ""
echo "Per-backend network adapter byte rate (last 60 minutes):"
network adapter_IDS=$(az network lb address-pool list \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].loadBalancerBackendAddresses[].networkInterfaceIPConfiguration.id" -o tsv \
  | sed -E 's|/ipConfigurations/.*||' | sort -u)

for network adapter in $network adapter_IDS; do
  echo "--- $(basename $network adapter) ---"
  az monitor metrics list \
    --resource "$network adapter" \
    --metrics "BytesReceivedRate" "BytesSentRate" \
    --aggregation Total \
    --interval PT1M \
    --output table
done

Интерпретация результатов

Укажите доминирующий сетевой адаптер на сервере, его процентную долю и были ли байты сгенерированы одним или несколькими IP-адресами клиентов-источников. Чтобы перейти к шагу 3, необходимо знать количество отдельных исходных IP-адресов.

Шаг 3

Проверьте, не находятся ли перед балансировщиком нагрузки NAT, брандмауэр, NVA или обратный прокси-сервер и не объединяют ли они множество IP-адресов клиентов в один исходный IP-адрес. Хэш 5-кортежа для одного исходного IP-адреса и одного IP-адреса назначения или порта назначения дает не более одного внутреннего сервера на каждый исходный порт. Стабильный клиент часто повторно использует один исходный порт. Эта ситуация означает, что хеш фактически привязывается к одному бэкенду.

Выполните следующие команды в Azure CLI:

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME

LB_ID=$(az network lb show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "id" --output tsv)

echo "Frontend configuration (public vs internal, attached IP):"
az network lb frontend-ip list \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, privateIP:privateIPAddress, publicIPId:publicIPAddress.id, subnetId:subnet.id}" \
  --output table

echo ""
echo "Packet count and SYN count on the load balancer (last 60 minutes):"
az monitor metrics list \
  --resource "$LB_ID" \
  --metrics PacketCount SYNCount \
  --aggregation Total \
  --interval PT1M \
  --output table

Затем, исходя из самого сетевого пути, ответьте на следующие вопросы, ничего не изменяя:

• Является ли балансировщик нагрузки внутренним (с частным IP-адресом в privateIPAddress)? Достигнут ли он через брандмауэр концентратора, Брандмауэр Azure, NVA или сторонний прокси-сервер? Если да, каждый клиент, проходящий через этот переход, попадает на балансировщик нагрузки с IP-адресом источника этого перехода, а не с исходным IP-адресом клиента.
• Общедоступна ли подсистема балансировки нагрузки, но опубликована через Azure Front Door, сеть доставки содержимого (CDN), шлюз приложений или Брандмауэр веб-приложений Azure (WAF)? Если да, то внешний сервис будет исходным IP-адресом, который видит балансировщик нагрузки.
• Если перед этой серверной частью развернут Брандмауэр Azure, проверьте его SNATPortUtilization или обработку IP-адреса источника, чтобы убедиться, что он выполняет SNAT в сторону этой серверной части.

Интерпретация результатов

Шаг 4

Проверьте, обслуживает ли правило протокол, пакеты которого нельзя осмысленно распределять по хэшу потока. DHCP-ретрансляция (User Datagram Protocol (UDP), порт 67 или 68), syslog (UDP 514) и ловушки SNMP (UDP 162) обычно имеют один источник на каждый агент ретрансляции, который отправляет данные на один порт назначения. Таким образом, 5 кортежей свернут в один контейнер независимо от того, что делается на уровне подсистемы балансировки нагрузки.

Выполните следующие команды в Azure CLI:

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME

az network lb rule list \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[?protocol=='Udp'].{name:name, frontendPort:frontendPort, backendPort:backendPort, loadDistribution:loadDistribution, floatingIP:enableFloatingIP}" \
  --output table

Интерпретация результатов

Карта принятия решений

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

Разрешение A

Вы сравниваете балансировщик нагрузки с устройством с циклическим распределением. Load Balancer — это балансировщик нагрузки без сохранения состояния, работающий на основе потоков. Для каждого потока вычисляется хеш по 5-элементному кортежу (исходный IP-адрес, исходный порт, IP-адрес назначения, порт назначения и протокол), чтобы выбрать бэкенд-сервер, после чего этот поток закрепляется за ним на всё время жизни потока.

Выполните следующие команды в Azure CLI.

1. Убедитесь, что правило находится в Default дистрибутиве (5 кортежей) (самый удобный для распространения режим):

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME
[ -z "$RULE_NAME" ] && read -rp "Rule Name:       " RULE_NAME

az network lb rule show \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$RULE_NAME" \
  --query "{name:name, loadDistribution:loadDistribution, protocol:protocol}" \
  --output json

Если loadDistribution это уже Defaultтак, изменение не требуется. Перейдите к следующему шагу.

2. Если для правила задано значение SourceIP или SourceIPProtocol, но закрепление сеанса на уровне приложения не требуется, задайте для него значение Default.

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME
[ -z "$RULE_NAME" ] && read -rp "Rule Name:       " RULE_NAME

az network lb rule update \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$RULE_NAME" \
  --load-distribution Default

3. Повторно выполните шаг 2 по крайней мере через 10 минут трафика.

Нормальный выходной показатель наблюдается, если ни на один отдельный сетевой адаптер серверной части BytesReceivedRate не приходится более чем примерно 60 % от общего значения по всем сетевым адаптерам серверной части за интервал. Если перекос сохраняется и на пути трафика есть NAT или прокси, стоящий перед сервисом, перейдите к разделу B. Если основную часть нагрузки создает один клиент, даже используя много исходных портов, значит, сама рабочая нагрузка сосредоточена, и для распределения по отдельным запросам требуется дополнительный параллелизм на стороне клиента (или балансировщик нагрузки уровня 7, например шлюз приложений).

Разрешение B

Энтропия исходного IP-адреса на уровне балансировщика нагрузки слишком низка, чтобы 5-кортежный хэш мог распределять потоки. Вышестоящее устройство NAT (например, Брандмауэр Azure, NVA в концентраторе, сторонний брандмауэр, Front Door или обратный прокси-сервер) представляет множество исходных клиентов для балансировщика нагрузки как один исходный IP-адрес. С одним исходным IP-адресом и одним конечным IP-адресом или портом хэш-пространство уменьшается до вариантов исходного порта и стабильных клиентов, которые повторно используют один и тот же пин-порт источника для одной серверной части.

1. Проверьте входной узел, отследив, где запросы поступают в балансировщик нагрузки:

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME

az network lb frontend-ip list \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, privateIP:privateIPAddress, publicIPId:publicIPAddress.id, subnetId:subnet.id}" \
  --output json

Если внешний интерфейс использует частный IP-адрес, определите вышестоящее устройство, интерфейс которого указывает на эту виртуальную сеть (VNet) или подсеть. Если внешний интерфейс использует публичный IP-адрес, определите, есть ли перед ним CDN, Front Door, WAF или NVA. Зафиксируйте границу между устройством и арендатором.

2. Удалите fronting NAT из пути хеширования. Поддерживаемые параметры в порядке предпочтения:

• Обходить исходный NAT на переднем устройстве. Настройте вышестоящий брандмауэр или NVA для перенаправления трафика клиента в подсистему балансировки нагрузки, сохранив исходный IP-адрес источника клиента (без преобразования сетевых адресов источника (SNAT). Это действие восстанавливает энтропию хэша клиента без изменения приложения.
• Переместите переднее устройство за подсистемой балансировки нагрузки , а не перед ним, чтобы клиентские IP-адреса напрямую достигли подсистемы балансировки нагрузки.
• Перейдите на шлюз приложений (уровень 7) для рабочей нагрузки. Шлюз приложений распределяет трафик на уровне HTTP-запросов, а не на уровне потоков. Таким образом, одно клиентское подключение по-прежнему распределяет запросы между внутренними серверами и не подвергается сворачиванию кортежей 5.

Этот последний вариант является подходящим исправлением, если вышестоящий NAT должен оставаться на месте, а рабочая нагрузка — HTTP/S.

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$AGW_NAME" ] && read -rp "New App Gateway Name: " AGW_NAME
[ -z "$AGW_VNET" ] && read -rp "VNet for App Gateway: " AGW_VNET
[ -z "$AGW_SUBNET" ] && read -rp "Dedicated subnet for App Gateway: " AGW_SUBNET
[ -z "$AGW_PUBIP" ] && read -rp "Public IP name (Standard SKU): " AGW_PUBIP

az network application-gateway create \
  --name "$AGW_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --vnet-name "$AGW_VNET" \
  --subnet "$AGW_SUBNET" \
  --public-ip-address "$AGW_PUBIP" \
  --sku Standard_v2 \
  --priority 100

3. Повторно выполните шаг 2.

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

Резолюция C

Правило настраивается путем задания для loadDistribution значения SourceIP (2-кортеж — это исходный IP-адрес и IP-адрес назначения) или SourceIPProtocol (3-кортеж — это исходный IP-адрес, IP-адрес назначения и протокол). Оба режима намеренно закрепляют каждый поток от заданного клиента (или клиента и протокола) к одной серверной части. Такое поведение корректно для рабочих нагрузок с сохранением состояния, которым действительно требуется клиентская привязка, однако именно оно чаще всего становится причиной жалоб на то, что «один внутренний сервер перегружен», если задать это значение в правиле без реальной необходимости.

Выполните следующие команды в Azure CLI:

1. Убедитесь, что сохраняемость сеанса включена, и зафиксировать текущее значение перед его изменением:

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME
[ -z "$RULE_NAME" ] && read -rp "Rule Name:       " RULE_NAME

az network lb rule show \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$RULE_NAME" \
  --query "{name:name, loadDistribution:loadDistribution, protocol:protocol}" \
  --output json

Если loadDistribution — SourceIP или SourceIPProtocol, правило использует привязку к IP-адресу источника. Прежде чем переходить к следующему шагу, убедитесь, что рабочая нагрузка не требует привязки к бэкенду (например, отсутствует состояние сеанса в памяти, которое не реплицируется между узлами бэкенда), и что привязка сеанса не является функциональным требованием.

2. Переключите правило на Default распределение (5‑кортежное).

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME
[ -z "$RULE_NAME" ] && read -rp "Rule Name:       " RULE_NAME

az network lb rule update \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$RULE_NAME" \
  --load-distribution Default

Существующие потоки продолжают поступать в текущую серверную часть до тех пор, пока они не завершаются. Новые потоки распределяются по хэшу между всеми исправными серверами.

3. Повторно выполните шаг 2 после не менее 10 минут нового трафика.

Исправное состояние считается признаком того, что сетевой адаптер серверной части BytesReceivedRate распределён между несколькими серверами серверной части. Если для рабочей нагрузки действительно требуется привязка сеанса, оставьте постоянство включённым и вместо этого используйте Application Gateway с привязкой на основе файлов cookie. Эта конфигурация обеспечивает распределение для каждого запроса в сочетании с привязкой к сеансу.

Разрешение D

Это правило применяется к протоколу, пакеты которого используют тот же 5-элементный кортеж. Распространенными примерами являются ретрансляция DHCP (UDP 67 или 68), системный журнал (UDP 514) и ловушки SNMP (UDP 162 или 161). Агент ретрансляции или устройство отправляет один поток из одного исходного IP-адреса в один целевой IP-адрес и порт. Хэшу потока не по чему различаться. Поэтому все пакеты попадают в один контейнер каждый раз, независимо от режима распространения. Load Balancer не является правильным приложением для этого трафика.

Выполните следующие команды в Azure CLI.

1. Определите параметры высокого уровня доступности для затронутой службы и удалите подсистему балансировки нагрузки из распространения этих пакетов. Ниже приведены распространенные примеры:

• DHCP-ретрансляция: Используйте отказоустойчивость DHCP в Windows или разделение области DHCP между двумя серверами. Добавьте сетевой адаптер каждого сервера как доступный для прямой адресации агентом ретрансляции DHCP. Не перенаправьте их с помощью подсистемы балансировки нагрузки для самого трафика DHCP.
• Syslog: Настройте клиент syslog (rsyslog, syslog-ng, переадресатор событий Windows) для отправки в несколько точек назначения с циклическим распределением либо в активном или резервном режиме на уровне клиента. Такие средства, как rsyslog и omfwd, изначально поддерживают несколько целевых платформ.
• Ловушки SNMP: Настройте источник ловушки для отправки всем сборщикам параллельно или используйте управляющую программу пересылки ловушки (например snmptrapd, для распределения на стороне получателя).

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

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME
[ -z "$RULE_NAME" ] && read -rp "Rule Name:       " RULE_NAME

az network lb rule delete \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$RULE_NAME"

3. Убедитесь, что правило исчезло:

# -- Collect inputs (cached if already set in this session) --
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:  " RG
[ -z "$RESOURCE_NAME" ] && read -rp "Load Balancer Name: " RESOURCE_NAME

az network lb rule list \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, protocol:protocol, frontendPort:frontendPort}" \
  --output table

Убедитесь, что трафик протокола теперь достигает целевых объектов высокой доступности напрямую.

References

• Режимы распределения для Azure Load Balancer
• Настройка режима распространения для Azure Load Balancer
• Метрики и журналы диагностики Azure Load Balancer
• Что такое Шлюз приложений Azure?
• Привязка сеанса на основе файлов cookie в шлюзе приложений
• Ценовые категории Azure Load Balancer