Optimalizace propustnosti sítě pro virtuální počítače Azure

Azure virtuálních počítačů mají výchozí nastavení sítě, která je možné optimalizovat, aby se zlepšila propustnost a konzistence. Tento článek popisuje, jak optimalizovat výkon sítě pro virtuální počítače s Windows a Linuxem.

Important

Mnoho optimalizací popsaných v tomto článku (například řízení zahlcení, správa front, velikosti vyrovnávací paměti a ladění síťových adaptérů NIC) ovlivňuje tok síťového provozu mezi systémy.

Nejlepších výsledků dosáhnete tím, že tato nastavení konzistentně použijete u všech virtuálních počítačů, které se účastní úlohy, včetně těchto:

  • Klientské systémy
  • Serverové systémy

Použití těchto konfigurací pouze na podmnožinu virtuálních počítačů může vést k těmto potížím:

  • Nekonzistentní propustnost
  • Zvýšení přeposílání paketů
  • Suboptimální chování při zahlcení

Vždy ověřte změny v celé cestě k datům a otestujte celkový výkon.

Virtuální počítače s Windows

Pokud váš virtuální počítač s Windows podporuje akcelerované síťové služby, povolte tuto funkci pro zajištění optimální propustnosti. Další informace najdete v tématu Vytvoření virtuálního počítače s Windows s akcelerovanými síťovými službami.

U všech ostatních Windows virtuálních počítačů může škálování na straně příjmu (RSS) poskytovat vyšší maximální propustnost než virtuální počítač bez technologie RSS. Rss může být ve výchozím nastavení zakázané. Chcete-li zkontrolovat, zda je RSS povolené, a povolit ho, postupujte takto:

  1. Pomocí příkazu PowerShellu Get-NetAdapterRss zkontrolujte, jestli je pro síťový adaptér povolený rss. Výstup z Get-NetAdapterRss následujícího příkladu ukazuje, že rss není povolený.

    Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : False

  2. Pokud chcete povolit rss, zadejte následující příkaz:

    Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}

    Tento příkaz nemá žádný výstup. Změní nastavení síťové karty a způsobí dočasnou ztrátu připojení přibližně jednu minutu. Během ztráty připojení se zobrazí dialogové okno Opětovné připojení . Připojení se obvykle obnoví po třetím pokusu.

  3. Zadáním příkazu znovu potvrďte, že je na virtuálním Get-NetAdapterRss počítači povolená technologie RSS. V případě úspěchu se vrátí následující příklad výstupu:

    Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : True

Virtuální počítače s Linuxem

Technologie RSS je ve výchozím nastavení povolená na virtuálních počítačích s Linuxem v Azure. Linuxová jádra vydaná od října 2017 obsahují další možnosti optimalizace sítě, které pomáhají virtuálním počítačům s Linuxem dosáhnout vyšší propustnosti.

Povolení akcelerovaných síťových služeb Azure pro optimální propustnost

Azure akcelerované síťové služby můžou výrazně zlepšit propustnost a snížit latenci a zpoždění. V závislosti na velikosti virtuálního počítače a generování platformy Azure používá jednu ze dvou technologií: Mellanox, která je široce dostupná, a MANA, která je vyvinuta Microsoft.

vyladěná jádra Azure

Některé distribuce, jako je Ubuntu (Canonical) a SUSE, poskytují jádra optimalizovaná pro Azure.

Pomocí následujícího příkazu ověřte, že používáte jádro Azure, které obvykle obsahuje azure název jádra.

uname -r

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

Další linuxové distribuce

Většina moderních distribucí zahrnuje významná vylepšení sítí v novějších jádrech. Zkontrolujte verzi jádra a pokud je to možné, použijte verzi jádra 4.19 nebo novější. Novější jádra nabízejí lepší síťové chování a podporují moderní mechanismy řízení zahlcení, jako je BBR.

Dosažení konzistentní přenosové rychlosti na virtuálních počítačích s Linuxem v Azure

Virtuální počítače s Linuxem můžou zobrazovat nekonzistentní přenosové rychlosti, zejména při velkých regionálních přenosech (například 1 GB až 50 GB mezi západní Evropou a USA – západ). Mezi běžné příčiny patří starší jádra, výchozí velikosti vyrovnávací paměti a nevyladěná nastavení řízení zahlcení nebo správy front.

Chcete-li dosáhnout konzistentnější propustnosti, nejprve použijte následující základní vyladění a poté otestujte kombinace algoritmů řízení zahlcení a qdisc pro vaše pracovní zatížení.

Základní ladění sysctl (kopírovat/vložit)

Použijte následující základní nastavení 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

Řízení kongesce a testy qdisc (sysctl)

Různé úlohy se chovají odlišně. Otestujte tyto kombinace a zachovejte ten, který poskytuje nejlepší výsledky pro váš profil latence, propustnosti a opětovného přenosu.

  1. BBR + FQ (často silná výchozí hodnota pro přenosy s vysokou propustností a dlouhými přenosy) 
    sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq
  2. BBR + PFIFO_FAST (užitečné pro porovnání chování fronty při nárazovém nebo smíšeném provozu) 
    sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=pfifo_fast
  3. CUBIC + PFIFO_FAST (běžný starší základ pro kompatibilitu a srovnání) 
    sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.core.default_qdisc=pfifo_fast

Otestujte každou možnost na reprezentativním provozu a poté použijte nejlépe fungující kombinaci ve svém prostředí.

Note

pfifo_fast dostupnost se může lišit podle distribuce nebo jádra. Pokud není dostupná, použijte ve svém prostředí nejbližší podporovanou možnost qdisc a pokračujte v srovnávacím testování.

Pravidlo UDEV pro vyrovnávací paměti okruhu síťových adaptérů (TX/RX)

Vytvořte v /etc/udev/rules.d/99-azure-ring-buffer.rules pravidlo udev, které aplikuje nastavení kruhové vyrovnávací paměti na síťová rozhraní:

Použijte rx 4096 tx 4096 pro rozhraní akcelerované sítě (hv_pci) a ponechte rx 1024 tx 1024 pro syntetická hv_netvsc rozhraní.

Pokud dáváte přednost interaktivnímu způsobu ladění kruhového bufferu, můžete také použít tento pomocný nástroj: Nastavení síťového adaptéru Azure Linux (bash).

Note

Tento nástroj GitHub je volitelný pomocník a není součástí dokumentace k produktu Microsoft Learn. Před širokým zaváděním si projděte skripty a otestujte změny v neprodukčním prostředí.

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

Pravidlo UDEV pro délku vysílací fronty NIC

Vytvořte v /etc/udev/rules.d/99-azure-txqueue-len.rules následující pravidlo, které zvýší délku odesílací fronty:

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

Chování a vedlejší účinky duálního rozhraní SR-IOV

V linuxových sítích s vysokým výkonem Azure používá technologii SR-IOV (například s ovladači Mellanox, jako jsou mlx4 nebo mlx5). V tomto modelu uvidíte syntetické rozhraní i virtuální rozhraní (VF) pro stejnou síťovou cestu virtuálních počítačů. Další informace.

Tento návrh se očekává, ale při ladění a řešení potíží může dojít k nejasnostem, pokud se obě rozhraní považují za nezávislé datové cesty.

Mezi možné vedlejší účinky patří:

  • Nekonzistentní výsledky benchmarků, když se nastavení použije na jedno rozhraní, ale provoz používá druhé rozhraní.
  • Neočekávané špičky latence nebo retransmise během přepnutí při selhání mezi syntetickou cestou a cestou VF
  • Zavádějící diagnostické údaje, pokud jsou čítače a záznamy paketů získávány z nesprávného rozhraní.

Snížení rizika:

  • Před laděním ověřte, které rozhraní přenáší provoz vaší pracovní zátěže.
  • Udržujte nastavení udev a sysctl v souladu s vaší strategií pro rozhraní.
  • Znovu otestujte propustnost a latenci po restartování, aktualizacích ovladačů nebo akcelerovaných změnách stavu sítě.

Další poznámky

Správci systému mohou tato doporučení zavést úpravou konfiguračních souborů, jako jsou /etc/sysctl.d/, /etc/modules-load.d/ a /etc/udev/rules.d/. Pečlivě zkontrolujte aktualizace jádra a ovladačů, abyste se vyhnuli regresím.

Další informace o konkrétních konfiguracích a řešení potíží najdete v Azure dokumentaci k výkonu sítě.

Související obsah

  • Last updated on