Оптимизируйте пропускную способность сети для виртуальных машин Azure

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

Important

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

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

Клиентские системы
Серверные системы

Применение этих конфигураций только к подмножествам виртуальных машин может привести к следующим:

Несогласованная пропускная способность
Увеличение повторной передачи пакетов
Неоптимальное поведение при перегрузке

Всегда проверяйте изменения во всем пути к данным и тестируйте сквозную производительность.

Виртуальные машины Windows

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

Для всех остальных виртуальных машин Windows масштабирование на стороне приема (RSS) может обеспечить более высокую максимальную пропускную способность, чем у виртуальной машины без RSS. RSS может быть отключен по умолчанию. Чтобы проверить, включен ли RSS и включить его, выполните следующие действия.

Проверьте, включен ли RSS для сетевого адаптера с помощью команды Get-NetAdapterRss PowerShell. В следующем примере выходные данные Get-NetAdapterRss показывают, что RSS не включен.
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : False
```
Чтобы включить RSS, введите следующую команду:
```
Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}
```
Эта команда не имеет выходных данных. Он изменяет параметры сетевой карты (сетевой адаптер) и приводит к временной потере подключения около одной минуты. Во время потери подключения появится диалоговое окно повторного подключения . Подключение обычно восстанавливается после третьей попытки.
Убедитесь, что RSS включена на виртуальной Get-NetAdapterRss машине, снова введя команду. При успешном выполнении возвращается следующий пример выходных данных:
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : True
```

Виртуальные машины Linux

RSS включен по умолчанию в виртуальных машинах Linux в Azure. Ядра Linux, выпущенные с октября 2017 года, включают дополнительные параметры оптимизации сети, которые помогают виртуальным машинам Linux достичь более высокой пропускной способности.

Включение ускоренной сети Azure для оптимальной пропускной способности

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

Оптимизированные ядра Azure

Некоторые дистрибутивы, такие как Ubuntu (Canonical) и SUSE, поставляют ядра, оптимизированные для Azure.

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

uname -r

# Sample output for an Azure kernel on an Ubuntu Linux VM
6.8.0-1017-azure

Другие дистрибутивы Linux

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

Обеспечение согласованной скорости передачи на виртуальных машинах Linux в Azure

Виртуальные машины Linux могут отображать несогласованные скорости передачи, особенно во время больших региональных передач (например, 1 ГБ до 50 ГБ между Западной Европой и Западной Частью США). К распространённым причинам относятся устаревшие версии ядра, размеры буферов по умолчанию, а также ненастроенные параметры управления перегрузкой или дисциплины очередей.

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

Базовая настройка sysctl (скопировать и вставить)

Примените следующие базовые параметры sysctl:

sudo tee /etc/sysctl.d/99-azure-network-tuning.conf > /dev/null <<'EOF'
# Buffer and memory tuning
# Overall TCP memory pressure thresholds (min, pressure, max pages)
net.ipv4.tcp_mem = 4096 87380 67108864
# Overall UDP memory pressure thresholds (min, pressure, max pages)
net.ipv4.udp_mem = 4096 87380 33554432
# Per-socket TCP read buffer limits (min, default, max bytes)
net.ipv4.tcp_rmem = 4096 87380 67108864
# Per-socket TCP write buffer limits (min, default, max bytes)
net.ipv4.tcp_wmem = 4096 65536 67108864
# Default socket receive buffer size in bytes
net.core.rmem_default = 33554432
# Default socket send buffer size in bytes
net.core.wmem_default = 33554432
# Minimum UDP send buffer per socket in bytes
net.ipv4.udp_wmem_min = 16384
# Minimum UDP receive buffer per socket in bytes
net.ipv4.udp_rmem_min = 16384
# Maximum socket send buffer size in bytes
net.core.wmem_max = 134217728
# Maximum socket receive buffer size in bytes
net.core.rmem_max = 134217728
# Busy polling time in microseconds for low-latency packet receive
net.core.busy_poll = 50
# Busy read time in microseconds when polling sockets
net.core.busy_read = 50

# Extra TCP and networking settings
# Enable TCP timestamps for RTT measurement and PAWS protection
net.ipv4.tcp_timestamps = 1
# Allow safer TIME-WAIT socket reuse for outbound connections
net.ipv4.tcp_tw_reuse = 1
# Expand available ephemeral source port range
net.ipv4.ip_local_port_range = 1024 65535
# Increase packets processed per NAPI polling cycle
net.core.netdev_budget = 1000
# Increase per-socket ancillary/option memory limit in bytes
net.core.optmem_max = 65535
# Disable F-RTO (typically unnecessary on stable wired paths)
net.ipv4.tcp_frto = 0
# Increase maximum listen backlog for pending connections
net.core.somaxconn = 32768
# Increase ingress packet backlog queue length
net.core.netdev_max_backlog = 32768
# Increase per-CPU packet processing quota per softirq cycle
net.core.dev_weight = 64
EOF

sudo sysctl --system

Управление перегрузкой и тесты qdisc (sysctl)

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

BBR + FQ (часто удачный выбор по умолчанию для высокопроизводительных передач на большие расстояния)
```
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq
```
BBR + PFIFO_FAST (полезно сравнить поведение очереди в условиях всплеска или смешанного трафика)
```
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=pfifo_fast
```
CUBIC + PFIFO_FAST (общие устаревшие базовые показатели совместимости и сравнения)
```
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.core.default_qdisc=pfifo_fast
```

Измеряйте каждый вариант с репрезентативным трафиком, а затем используйте оптимальное сочетание для вашей среды.

Note

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

Правило UDEV для буферов кругов сетевого адаптера (TX/RX)

Создайте в /etc/udev/rules.d/99-azure-ring-buffer.rules правило udev, чтобы применить параметры кольцевого буфера к сетевым интерфейсам:

Используйте rx 4096 tx 4096 для интерфейсов Accelerated Networking (hv_pci), а rx 1024 tx 1024 оставьте для синтетических интерфейсов hv_netvsc.

Если вы предпочитаете интерактивный подход к настройке кольцевого буфера, вы также можете использовать этот вспомогательный инструмент: Настройка сетевого адаптера Azure Linux (bash).

Note

Это средство GitHub является необязательным вспомогательным и не является частью документации по продуктам Microsoft Learn. Просмотрите скрипты и проверьте изменения в нерабокой среде перед широким развертыванием.

# Setup Accelerated Interface ring buffers (Mellanox / Mana) 
SUBSYSTEM=="net", DRIVERS=="hv_pci", ACTION=="add",  RUN+="/usr/sbin/ethtool -G $env{INTERFACE} rx 4096 tx 4096"

# Setup Synthetic interface ring buffers (hv_netvsc)
SUBSYSTEM=="net", DRIVERS=="hv_netvsc*", ACTION=="add",  RUN+="/usr/sbin/ethtool -G $env{INTERFACE} rx 1024 tx 1024"

Правило UDEV для qdisc при событиях интерфейса

После завершения тестирования и выбора предпочтительного варианта qdisc создайте правило udev в /etc/udev/rules.d/99-azure-qdisc.rules для применения этого qdisc при добавлении или изменении сетевых интерфейсов.

Замените <qdisc_choice> на qdisc, выбранный во время тестирования (например, fq или pfifo_fast):

ACTION=="add|change", SUBSYSTEM=="net", KERNEL=="enp*", PROGRAM="/sbin/tc qdisc replace dev \$env{INTERFACE} root noqueue"
ACTION=="add|change", SUBSYSTEM=="net", KERNEL=="eth*", PROGRAM="/sbin/tc qdisc replace dev \$env{INTERFACE} root <qdisc_choice>"

Правило UDEV для длины очереди передачи сетевого интерфейса

Создайте следующее правило в /etc/udev/rules.d/99-azure-txqueue-len.rules, чтобы увеличить длину очереди передачи:

SUBSYSTEM=="net", ACTION=="add|change", KERNEL=="eth*", ATTR{tx_queue_len}="10000"

Планирование IRQ (irqbalance)

В зависимости от характера нагрузки может потребоваться запретить службе irqbalance распределять IRQ на определённых узлах. При использовании IRQBalance обновите /etc/default/irqbalance, указав, каким процессорам не следует назначать IRQ. Необходимо определить маску , которая исключает эти ЦП.

Дополнительные сведения о том, как вычислить маску, см. здесь.

Двухинтерфейсное поведение SR-IOV и побочные эффекты

В высокопроизводительной сети Linux Azure использует SR-IOV (например, с драйверами Mellanox, такими как mlx4 илиmlx5). В этой модели можно увидеть как искусственный интерфейс, так и интерфейс виртуальной функции (VF) для одного сетевого пути виртуальной машины. Подробнее.

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

Возможные побочные эффекты:

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

Чтобы уменьшить риск, выполните приведенные действия.

Проверьте, какой интерфейс несет трафик рабочей нагрузки перед настройкой.
Следите за настройкой udev и sysctl в соответствии со стратегией интерфейса.
Повторное тестирование пропускной способности и задержки после перезагрузки, обновлений драйверов или ускорения изменений состояния сети.

Дополнительные примечания

Системные администраторы могут реализовать эти рекомендации, изменив такие файлы конфигурации, как /etc/sysctl.d/, /etc/modules-load.d/и /etc/udev/rules.d/. Внимательно просмотрите обновления ядра и драйвера, чтобы избежать регрессии.

Дополнительные сведения о конкретных конфигурациях и устранении неполадок см. в Azure документации по производительности сети.

Разверните виртуальные машины близко друг к другу для низкой задержки с группами размещения в непосредственной близости.
Ознакомьтесь с оптимизированным результатом тестирования пропускной способности и производительности для вашего сценария.
Узнайте, как пропускная способность выделяется виртуальным машинам.
Ознакомьтесь с часто задаваемыми вопросами Azure Virtual Network.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-06-20