Устранение неполадок, связанных с ограничениями Azure Load Balancer

Сводка

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

Azure Load Balancer — это служба уровня 4 (TCP/UDP). Многие обращения в поддержку не связаны с проблемами продукта. Это запросы на функции, которые Load Balancer по своей архитектуре не поддерживает: маршрутизацию уровня 7 (по пути, хосту или URL), терминацию TLS или индикацию имени сервера (SNI), липкие сеансы на основе cookie, hairpin-сценарий (когда бэкенд обращается к собственному VIP-адресу фронтенда), произвольное каскадирование балансировщиков нагрузки, журналы приложений или журналы доступа, а также распределение round robin для отдельных запросов.

Симптомы

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

• Вы настраиваете правило Load Balancer и ожидаете, что он будет направляться по URL-пути или имени узла (например, /api к одному пулу и /web другому), но весь трафик передается в одну серверную часть.
• Вы ожидаете, что балансировщик нагрузки будет завершать TLS или выбирать бэкенд на основе имени хоста TLS SNI, но соответствующая настройка отсутствует.
• Вы включаете сохраняемость сеанса, но приложение по-прежнему теряет состояние сеанса, так как нет параметра сопоставления на основе файлов cookie.
• Внутренняя виртуальная машина не может подключиться к внешнему виртуальному IP-адресу балансировщика нагрузки, который обслуживается этой же виртуальной машиной (превышено время ожидания подключения или подключение отклонено).
• Вы последовательно соединяете два балансировщика нагрузки, а трафик проходит не так, как ожидается.
• Вы ищете журналы http-доступа или журналы запросов на Load Balancer и находите только метрики и журналы событий работоспособности.
• Трафик не разделяется равномерно между внутренними серверами (например, одна или две серверные части получают большинство подключений), даже если все серверные части являются работоспособными.

Prerequisites

Чтобы устранить эту проблему, вам потребуется следующее:

• Необходимые разрешения:Reader роль для Load Balancer и группы ресурсов для выполнения всех диагностических действий; Network Contributor роль (или эквивалентная) требуется только в том случае, если вы применяете решение, выполняющее операцию записи, например включаете журналы потоков виртуальной сети (VNet).
• Средства: Azure CLI 2.x или агент ИИ с доступом Azure MCP или CLI.
• Обязательные переменные и примеры этих переменных, как показано в следующей таблице

СОВЕТ: Каждый скрипт, предоставленный в следующих разделах, запрашивает необходимые значения в интерактивном режиме. Чтобы открыть Cloud Shell и ответить на запросы, нажмите кнопку "Попробовать". Значения кэшируются для этого сеанса. Поэтому вы вводите их только один раз.

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

Шаг 1

Проверьте SKU балансировщика нагрузки, является ли он общедоступным или внутренним, а также какие правила для него настроены. Эта базовая проверка показывает, что ресурс является балансировщиком нагрузки 4-го уровня с поддержкой только TCP или User Datagram Protocol (UDP), и сообщает имена правил, которые проверяются на последующих шагах.

Выполните следующие команды с 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 show \
  --name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "{sku:sku.name, tier:sku.tier, frontends:frontendIPConfigurations[].{name:name, privateIp:privateIPAddress, publicIp:publicIPAddress.id}, rules:loadBalancingRules[].name}" \
  --output json

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

Шаг 2

Проверьте, какая возможность вы пытаетесь получить от Load Balancer. Load Balancer работает только на уровне 4 (TCP или UDP). Сопоставьте свою цель в следующей таблице с диагностическим шагом, который подтверждает, столкнулись ли вы с предусмотренным архитектурой ограничением 4-го уровня.

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

Интерпретация целей

Шаг 3

Проверьте, относятся ли ваши правила только к уровню 4 (TCP или UDP). Если это так, маршрутизация на основе пути, маршрутизация на основе имени хоста, перезапись URL-адресов, терминация TLS и SNI недоступны. Проверьте также, существует ли уже в группе ресурсов шлюз приложений, через который можно вместо этого направить трафик.

Выполните следующие команды с 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}" \
  --output table

Затем проверьте, существует ли служба уровня 7 в группе ресурсов:

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

az network application-gateway list \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, tier:sku.tier}" \
  --output table

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

Столбец protocol правила балансировки нагрузки может быть только Tcp, Udp или All. Нет ни протокола HTTP или HTTPS, ни пути прослушивателя, ни условия хоста. Это значение протокола является детерминированным сигналом, что правило не может принимать решения по маршрутизации уровня 7.

Шаг 4

Проверьте режим сохраняемости сеанса (сходство) для каждого правила. Балансировщик нагрузки поддерживает только привязку на основе хэша (Default — это 5-компонентный кортеж, SourceIP — это 2-компонентный кортеж, SourceIPProtocol — это 3-компонентный кортеж). Ни один из этих вариантов не является привязкой к приложению на основе cookie.

Выполните следующие команды с 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, loadDistribution:loadDistribution, protocol:protocol}" \
  --output table

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

Значением loadDistribution является детерминированный сигнал. Каждое возможное значение — это хеш сетевого кортежа. В схеме Load Balancer нет параметра cookie.

Шаг 5

Проверьте, является ли клиент, который не может получить доступ к внешнему VIP-адресу, участником серверного пула балансировщика нагрузки. Подключение экземпляра серверной части к внешнему VIP-адресу, который он сам же обслуживает (например, в сценарии hairpin или loopback), конструктивно не поддерживается балансировщиком нагрузки.

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

Перечислите внешние IP-адреса и участников внутреннего пула, а затем сравните их с исходным узлом, которому не удается подключиться:

# ── 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

# Frontend VIPs (the addresses the backend is trying to reach)
az network lb frontend-ip list \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, privateIp:privateIPAddress, publicIp:publicIPAddress.id}" \
  --output table

# ── 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

# Backend pool members (the hosts the LB sends traffic to)
az network lb address-pool list \
  --lb-name "$RESOURCE_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{pool:name, members:loadBalancerBackendAddresses[].{name:name, ip:ipAddress, nic:networkInterfaceIPConfiguration.id}}" \
  --output json

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

Ключевым сигналом является членство. Сравните узел, которому не удаётся подключиться (его идентификатор конфигурации IP-адреса сетевого интерфейса (NIC) или частный IP-адрес), со списком members. Если источник, на котором возникает сбой, находится во внутреннем пуле, а узел назначения, к которому он не может подключиться, является одним из VIP-адресов внешнего интерфейса, значит, вы столкнулись с ограничением hairpin-подключения.

Шаг 6

Проверьте, существуют ли несколько подсистем балансировки нагрузки в группе ресурсов и как они сложены. Каскадирование ограничено: внутренний Load Balancer (цен. категория "Стандартный") может находиться за общедоступным Load Balancer (цен. категория "Стандартный") (это поддерживаемая схема), но произвольные каскады, в которых общедоступный Load Balancer (цен. категория "Стандартный") расположен за общедоступным Load Balancer (цен. категория "Стандартный"), не поддерживаются.

Выполните следующие команды с 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

az network lb list \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, sku:sku.name, hasPublicFrontend:frontendIPConfigurations[?publicIPAddress!=null] | length(@), hasPrivateFrontend:frontendIPConfigurations[?privateIPAddress!=null] | length(@)}" \
  --output table

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

Сигнал — это SKU и тип внешнего интерфейса каждого балансировщика нагрузки в цепочке. hasPublicFrontend > 0означает, что Load Balancer является общедоступным и hasPrivateFrontend > 0 означает, что он имеет внутренний интерфейс.

Шаг 7

Проверьте, какие категории журналов диагностики поддерживает Балансировщик нагрузки. Балансировщик нагрузки 4-го уровня не формирует журналы HTTP-доступа или журналы запросов, а только метрики и события работоспособности или оповещения. На этом шаге подтверждается отсутствие категории журнала доступа, поэтому вы понимаете, что данные о потоках нужно собирать в другом месте.

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

Получите идентификатор ресурса Load Balancer, а затем укажите доступные категории диагностики:

# ── 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)

az monitor diagnostic-settings categories list \
  --resource "$LB_ID" \
  --query "value[].{name:name, type:categoryType}" \
  --output table

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

Сигнал — это набор возвращаемых имен категорий. Балансировщик нагрузки поддерживает категории метрик и категории журналов событий работоспособности, но не поддерживает категории для HTTP-запросов, журналов приложений или журналов доступа, поскольку он никогда не анализирует трафик уровня 7.

Шаг 8

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

Выполните следующие команды с 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, loadDistribution:loadDistribution, protocol:protocol}" \
  --output table

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

Значение loadDistribution — это сигнал, определяющий, насколько концентрированным становится трафик.

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

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

Разрешение A

Вам нужна функциональность уровня 7, например маршрутизация на основе пути или имени хоста, перезапись URL-адресов, терминация TLS или выбор бэкенда на основе SNI. Load Balancer работает только на уровне 4 (TCP и UDP), никогда не проверяет HTTP-запрос или ПРОТОКОЛ TLS SNI и не может принимать эти решения.

Выберите службу уровня 7, соответствующую вашей области:

• Шлюз приложений: региональный балансировщик нагрузки 7-го уровня с маршрутизацией по пути или имени хоста, терминацией TLS, SNI и WAF. Используйте его для одного региона.
• Front Door: глобальная точка входа уровня 7 с пограничной маршрутизацией, кэшированием или CDN и WAF. Используйте его для нескольких регионов или глобального трафика.
• Диспетчер трафика Azure: глобальная маршрутизация на основе DNS (она возвращает конечную точку DNS, а не прокси-трафик). Используйте это, когда вам требуется переключение при отказе на уровне DNS или геомаршрутизация, а не HTTP-прокси.

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

1. Проверьте, существует ли уже Application Gateway, через который можно направить трафик.

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

az network application-gateway list \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, tier:sku.tier, state:operationalState}" \
  --output table

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

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

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:     " RG
[ -z "$APPGW_NAME" ] && read -rp "New App Gateway Name: " APPGW_NAME
[ -z "$VNET_NAME" ] && read -rp "VNet Name:          " VNET_NAME
[ -z "$APPGW_SUBNET" ] && read -rp "App Gateway Subnet: " APPGW_SUBNET
[ -z "$APPGW_PUBLIC_IP" ] && read -rp "Public IP Name:     " APPGW_PUBLIC_IP

az network application-gateway create \
  --name "$APPGW_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --vnet-name "$VNET_NAME" \
  --subnet "$APPGW_SUBNET" \
  --public-ip-address "$APPGW_PUBLIC_IP" \
  --sku Standard_v2 \
  --priority 100 \
  --verbose

После подготовки шлюза настройте слушатели, правила маршрутизации на основе путей URL и серверные пулы, как описано в разделе Маршрутизация на основе путей URL в Application Gateway. Сохраняйте Load Balancer только для любого оставшегося трафика уровня 4 (не HTTP).

Разрешение B

Необходимо, чтобы клиент на протяжении всего сеанса оставался привязанным к одному и тому же бэкенду (настоящие sticky sessions). Балансировщик нагрузки поддерживает только хеш-привязку на основе сетевого кортежа (loadDistribution: Default, SourceIP и SourceIPProtocol). Он не поддерживает привязку на основе файлов cookie. Привязка по исходному IP-адресу перестаёт работать, как только несколько клиентов оказываются за одним NAT или прокси-сервером (все они попадают на один сервер) либо исходный IP-адрес клиента меняется (тогда он начинает попадать на другой сервер).

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

1. Если привязка к исходному IP-адресу приемлема для вашей рабочей нагрузки (клиенты имеют стабильные и различающиеся исходные IP-адреса), можно настроить в существующем правиле привязку по 2 или 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
[ -z "$RULE_NAME" ] && read -rp "Rule Name (from Step 4): " RULE_NAME

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

2. Если требуется истинная привязка на основе файлов cookie (независимо от IP-адреса источника клиента), переместите рабочую нагрузку HTTP в Шлюз приложений, которая поддерживает сходство сеансов на основе файлов cookie. Включите его в параметрах HTTP серверной части шлюза.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:     " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:      " RG
[ -z "$APPGW_NAME" ] && read -rp "App Gateway Name:    " APPGW_NAME
[ -z "$HTTP_SETTINGS_NAME" ] && read -rp "HTTP Settings Name:  " HTTP_SETTINGS_NAME

az network application-gateway http-settings update \
  --gateway-name "$APPGW_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --name "$HTTP_SETTINGS_NAME" \
  --cookie-based-affinity Enabled

Дополнительные сведения см. в разделе сходство на основе файлов cookie в шлюзе приложений.

Резолюция C

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

Выберите один из этих поддерживаемых редизайнов. Ни один из них не требует Load Balancer для прически:

• Подключитесь непосредственно к серверной части. С серверного экземпляра обращайтесь к парному экземпляру по его собственному частному IP-адресу или имени хоста вместо общего VIP-адреса.
• Используйте внутреннюю конечную точку, которая не является виртуальным IP-адресом Load Balancer. Поместите отдельное внутреннее имя или IP-адрес (например, запись Azure Частная зона DNS или выделенную внутреннюю службу) перед рабочей нагрузкой для вызовов внутри пула.
• Используйте Приватный канал Azure для доступа между службами. Откройте доступ к службе, стоящей за службой Приватный канал или закрытой конечной точкой, чтобы клиенты могли обращаться к ней без hairpin-маршрутизации через внешний интерфейс собственного балансировщика нагрузки.
• Перенаправьте HTTP-трафик через Application Gateway, который поддерживает запросы, исходящие от его собственных серверных экземпляров, для рабочих нагрузок уровня 7.

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

Разрешение D

Построенная вами топология с последовательным соединением балансировщиков нагрузки не является поддерживаемой конфигурацией. Балансировщик нагрузки поддерживает лишь ограниченный набор каскадных конфигураций, в частности внутренний балансировщик нагрузки уровня Standard за общедоступным балансировщиком нагрузки уровня Standard, но не поддерживает произвольные каскады с общедоступным балансировщиком нагрузки за общедоступным. Он также не поддерживает сочетание номеров SKU уровня "Базовый" и "Стандартный" в одном пути балансировки нагрузки.

Используйте поддерживаемый шаблон:

• Из общедоступного во внутренний (SKU «Стандартный»): Опубликуйте службу через общедоступный Load Balancer уровня «Стандартный», а затем разместите за ним внутренний Load Balancer уровня «Стандартный» для следующего уровня. Это поддерживаемый шаблон связывания.
• Обеспечьте единообразие SKU: Используйте SKU категории Standard на всех этапах. Не используйте балансировщик нагрузки уровня Basic вместе с балансировщиком нагрузки уровня Standard в рамках одного пути обработки трафика.
• Для распределения трафика на уровне 7 завершайте трафик на Application Gateway или Front Door и используйте Load Balancer только для уровня 4 за ними.

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

Убедитесь, что SKU каждого балансировщика нагрузки во всём пути передачи данных совпадает:

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

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

Если какой-либо балансировщик нагрузки в этой цепочке — Basic, запланируйте миграцию на SKU Standard, чтобы вся цепочка использовала один и тот же SKU. Дополнительные сведения см. в разделе "Обновление с уровня "Базовый" до Load Balancer (цен. категория "Стандартный").

Разрешение E

Вы ожидаете журналы доступа HTTP или журналы запросов от балансировщика нагрузки. Балансировщик нагрузки 4-го уровня никогда не анализирует полезную нагрузку приложения, поэтому он формирует только метрики и события состояния работоспособности, а категория журналов доступа отсутствует. Вместо этого собирайте данные о потоках на уровне подключений (5-кортежей) с помощью журналов потоков VNet и анализируйте их с помощью Наблюдатель за сетями или Traffic Analytics.

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

1. Убедитесь, что Наблюдатель за сетями существует в регионе Load Balancer:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID: " SUBSCRIPTION

az network watcher list \
  --subscription "$SUBSCRIPTION" \
  --query "[].{name:name, location:location, state:provisioningState}" \
  --output table

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

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:   " SUBSCRIPTION
[ -z "$RG" ] && read -rp "Resource Group:    " RG
[ -z "$FLOWLOG_NAME" ] && read -rp "Flow Log Name:     " FLOWLOG_NAME
[ -z "$VNET_NAME" ] && read -rp "VNet Name:         " VNET_NAME
[ -z "$STORAGE_ACCOUNT" ] && read -rp "Storage Account Name: " STORAGE_ACCOUNT
[ -z "$LOCATION" ] && read -rp "Region (e.g. eastus): " LOCATION

az network watcher flow-log create \
  --name "$FLOWLOG_NAME" \
  --resource-group "$RG" \
  --subscription "$SUBSCRIPTION" \
  --location "$LOCATION" \
  --vnet "$VNET_NAME" \
  --storage-account "$STORAGE_ACCOUNT" \
  --enabled true \
  --verbose

Значение --location должно соответствовать региону целевой виртуальной сети (региональный Наблюдатель за сетями выбирается по расположению). Используйте --subnet или --nic вместо --vnet, чтобы сузить область действия журнала потоков.

Для аналитики на уровне запроса просмотрите журналы потоков виртуальной сети в Аналитике трафика. Для журналов доступа уровня 7 рабочая нагрузка должна выполняться с помощью шлюза приложений или Front Door, в обоих из которых будут выдаваться журналы доступа.

Разрешение F

Распределение кажется неравномерным, потому что балансировщик нагрузки работает на основе хеширования, а не по алгоритму round-robin. При использовании режима Default (пятиэлементный кортеж) выполняется хэширование исходного IP-адреса, исходного порта, IP-адреса назначения, порта назначения и протокола, чтобы выбрать внутренний сервер для каждого потока. При использовании SourceIP или SourceIPProtocol каждый IP-адрес источника закрепляется за одним сервером. Небольшое число клиентов, долгоживущие соединения или общие внешние точки входа NAT либо прокси-серверов концентрируют потоки на части внутренних серверов, даже когда все эти серверы работоспособны.

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

1. Если задана привязка по 2- или 3-элементному кортежу и из-за этого трафик концентрируется, верните для правила хеширование по 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 (from Step 8): " RULE_NAME

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

2. Если вам требуется строгая балансировка отдельных запросов между бэкендами, а не для каждого потока, хэширование 4-го уровня не может её обеспечить. Переместите HTTP-нагрузку в Шлюз приложений, который выполняет балансировку для каждого запроса с помощью циклического алгоритма. Более подробный анализ энтропии источника и причин сохранения привязки, характерных для Load Balancer, см. в руководстве по устранению неполадок, связанных с неравномерным распределением, ссылка на которое приведена в разделе References.

References

• Обзор Azure Load Balancer
• режимы распределения Load Balancer (распределение на основе хэша)
• Балансировщик нагрузки: несколько внешних интерфейсов и ограничения
• Что такое Шлюз приложений Azure?
• Что такое Azure Front Door?
• Что такое диспетчер трафика?
• Журналы потоков VNet и Traffic Analytics
• Сравнение балансировщика нагрузки и шлюза приложений