Netwerkdoorvoer voor virtuele Azure-machines optimaliseren

Azure virtuele machines (VM's) beschikken over standaardnetwerkinstellingen die kunnen worden geoptimaliseerd om de doorvoer en consistentie te verbeteren. In dit artikel wordt beschreven hoe u netwerkprestaties optimaliseert voor Windows- en Linux-VM's.

Belangrijk

Veel van de optimalisaties die in dit artikel worden beschreven (bijvoorbeeld congestiebeheer, wachtrijdiscipline, buffergrootten en NIC-afstemming) beïnvloeden hoe verkeer tussen systemen stroomt.

Voor de beste resultaten past u deze instellingen consistent toe op alle virtuele machines die deelnemen aan de workload, waaronder:

  • Clientsystemen
  • Serversystemen

Het toepassen van deze configuraties op slechts een subset van virtuele machines kan leiden tot:

  • Inconsistente doorvoer
  • Toegenomen pakkethertransmissies
  • Niet-optimaal congestiegedrag

Valideer altijd wijzigingen in het hele gegevenspad en test de prestaties end-to-end.

Virtuele Windows-machines

Als uw Windows-VM versneld netwerken ondersteunt, schakelt u deze functie in voor optimale doorvoer. Zie Een Virtuele Windows-machine maken met versneld netwerken voor meer informatie.

Voor alle andere Windows VM’s kan RSS (Receive Side Scaling) een hogere maximale doorvoer bieden dan een VM zonder RSS. RSS is mogelijk standaard uitgeschakeld. Voer de volgende stappen uit om te controleren of RSS is ingeschakeld en in te schakelen:

  1. Controleer of RSS is ingeschakeld voor een netwerkadapter met behulp van de PowerShell-opdracht Get-NetAdapterRss . In het volgende voorbeeld laat de uitvoer van Get-NetAdapterRss zien dat RSS niet is ingeschakeld.

    Name                    : Ethernet
    InterfaceDescription    : Microsoft Hyper-V Network Adapter
    Enabled                 : False
    
  2. Voer de volgende opdracht in om RSS in te schakelen:

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

    Deze opdracht heeft geen uitvoer. Het wijzigt de NIC-instellingen (Network Interface Card) en veroorzaakt tijdelijk connectiviteitsverlies gedurende ongeveer één minuut. Er wordt een dialoogvenster voor opnieuw verbinden weergegeven tijdens het connectiviteitsverlies . De verbinding wordt meestal hersteld na de derde poging.

  3. Controleer of RSS is ingeschakeld op de virtuele machine door de Get-NetAdapterRss opdracht opnieuw in te voeren. Als dit lukt, wordt de volgende voorbeelduitvoer geretourneerd:

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

Virtuele Linux-machines

RSS is standaard ingeschakeld in virtuele Linux-machines (VM's) in Azure. Linux-kernels die sinds oktober 2017 zijn uitgebracht, bevatten extra netwerkoptimalisatieopties waarmee Linux-VM's een hogere doorvoer kunnen bereiken.

Versneld netwerken van Azure inschakelen voor optimale doorvoer

Azure Versneld netwerken kunnen de doorvoer aanzienlijk verbeteren en latentie en jitter verminderen. Afhankelijk van de VM-grootte en platformgeneratie gebruikt Azure een van de twee technologieën: Mellanox, die algemeen beschikbaar is en MANA, dat is ontwikkeld door Microsoft.

op Azure afgestemde kernels

Sommige distributies, zoals Ubuntu (Canonical) en SUSE, bieden Azure afgestemde kernels.

Gebruik de volgende opdracht om te controleren of u de Azure kernel gebruikt, die meestal deel uitmaakt azure van de kernelnaam.

uname -r

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

Andere Linux-distributies

De meeste moderne distributies bevatten belangrijke netwerkverbeteringen in nieuwere kernels. Controleer de kernelversie en gebruik indien mogelijk 4.19 of hoger. Nieuwere kernels bevatten beter netwerkgedrag en bieden ondersteuning voor moderne opties voor congestiebeheer, zoals BBR.

Consistente overdrachtssnelheden bereiken in Linux-VM's in Azure

Linux-VM's kunnen inconsistente overdrachtssnelheden weergeven, met name tijdens grote regionale overdrachten (bijvoorbeeld 1 GB tot 50 GB tussen Europa - west en VS - west). Veelvoorkomende oorzaken zijn oudere kernels, standaardbuffergrootten en niet-afgestemde instellingen voor congestiebeheer of wachtrijdiscipline.

Om een consistentere doorvoer te krijgen, past u eerst de volgende basisafstemming toe en test u vervolgens combinaties van congestie en qdisc voor uw werklast.

Sysctl-basislijn afstemmen (kopiëren/plakken)

Pas de volgende sysctl-instellingen voor de basislijn toe:

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

Controle van netwerkcongestie en qdisc-tests (sysctl)

Verschillende workloads gedragen zich anders. Test deze combinaties en behoud het resultaat dat de beste resultaten biedt voor uw profiel voor latentie, doorvoer en opnieuw verzenden.

  1. BBR + FQ (vaak een goede standaardkeuze voor hoge doorvoer en overdrachten over lange afstanden)
    sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
    sudo sysctl -w net.core.default_qdisc=fq
    
  2. BBR + PFIFO_FAST (handig om het gedrag van wachtrijen onder bursty of gemengd verkeer te vergelijken)
    sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
    sudo sysctl -w net.core.default_qdisc=pfifo_fast
    
  3. CUBIC + PFIFO_FAST (algemene verouderde basislijn voor compatibiliteit en vergelijking)
    sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
    sudo sysctl -w net.core.default_qdisc=pfifo_fast
    

Meet elke optie met representatieve verkeer en gebruik vervolgens de best presterende combinatie voor uw omgeving.

Note

pfifo_fast beschikbaarheid kan variëren per distributie/kernel. Als deze optie niet beschikbaar is, gebruikt u de dichtstbijzijnde ondersteunde qdisc-optie in uw omgeving en gaat u verder met benchmarken.

UDEV-regel voor NIC-ringbuffers (TX/RX)

Maak een udev-regel /etc/udev/rules.d/99-azure-ring-buffer.rules om ringbufferinstellingen toe te passen op netwerkinterfaces:

Gebruik rx 4096 tx 4096 voor Accelerated Networking-interfaces (hv_pci) en behoud rx 1024 tx 1024 voor synthetische hv_netvsc-interfaces.

Als u de voorkeur geeft aan een interactieve benadering voor het afstemmen van ringbuffers, kunt u dit hulpprogramma ook gebruiken: Azure Linux NIC setup (bash).

Note

Dit GitHub hulpprogramma is een optionele helper en maakt geen deel uit van Microsoft Learn-productdocumentatie. Controleer de scripts en test wijzigingen in een niet-productieomgeving vóór de brede implementatie.

# 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-regel voor de lengte van de NIC-verzendwachtrij

Maak de volgende regel in /etc/udev/rules.d/99-azure-txqueue-len.rules om de lengte van de transmissiewachtrij te verhogen:

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

Gedrag en bijwerkingen van SR-IOV met dubbele interface

In Linux high-performance netwerken gebruikt Azure SR-IOV (bijvoorbeeld met Mellanox-stuurprogramma's zoals mlx4 of mlx5). In dit model ziet u zowel een synthetische interface als een VF-interface (virtual function) voor hetzelfde VM-netwerkpad. Meer informatie.

Dit ontwerp wordt verwacht, maar het kan verwarring veroorzaken tijdens het afstemmen en oplossen van problemen als beide interfaces worden behandeld als onafhankelijke gegevenspaden.

Mogelijke bijwerkingen zijn:

  • Inconsistente benchmarkresultaten wanneer instellingen worden toegepast op de ene interface, maar het verkeer gebruikt de andere.
  • Onverwachte latentiepieken of hertransmissies tijdens failover tussen synthetische en VF-paden.
  • Misleidende diagnostische gegevens als tellers en pakketopnamen worden verzameld van de verkeerde interface.

Om het risico te verkleinen:

  • Controleer welke interface uw workloadverkeer draagt voordat u gaat afstemmen.
  • Houd de afstemming van udev en sysctl in lijn met uw interfacestrategie.
  • Voer en latentie opnieuw testen na opnieuw opstarten, updates van stuurprogramma's of versnelde netwerkstatuswijzigingen.

Aanvullende opmerkingen

Systeembeheerders kunnen deze aanbevelingen toepassen door configuratiebestanden zoals /etc/sysctl.d/, /etc/modules-load.d/, en /etc/udev/rules.d/ te bewerken. Controleer de updates van kernel en stuurprogramma zorgvuldig om regressies te voorkomen.

Zie Azure documentatie over netwerkprestaties voor meer informatie over specifieke configuraties en probleemoplossing.