Ottimizzare la velocità effettiva di rete per le macchine virtuali di Azure

Azure macchine virtuali (VM) hanno impostazioni di rete predefinite che possono essere ottimizzate per migliorare la velocità effettiva e la coerenza. Questo articolo descrive come ottimizzare le prestazioni di rete per le macchine virtuali Windows e Linux.

Importante

Molte delle ottimizzazioni descritte in questo articolo (ad esempio, il controllo della congestione, la disciplina della coda, le dimensioni del buffer e l'ottimizzazione della scheda di interfaccia di rete) influiscono sul flusso del traffico tra i sistemi.

Per ottenere risultati ottimali, applicare queste impostazioni in modo coerente in tutte le macchine virtuali che partecipano al carico di lavoro, tra cui:

Sistemi client
Sistemi server

L'applicazione di queste configurazioni a un solo subset di macchine virtuali può comportare:

Velocità di trasmissione non costante
Ritrasmissione dei pacchetti aumentata
Comportamento della congestione non ottimale

Convalidare sempre le modifiche nell'intero percorso dati e testare le prestazioni end-to-end.

macchine virtuali Windows

Se la macchina virtuale Windows supporta la rete accelerata, abilitare tale funzionalità per una velocità effettiva ottimale. Per altre informazioni, vedere Creare una macchina virtuale Windows con rete accelerata.

Per tutte le altre macchine virtuali Windows, receive side scaling (RSS) può offrire una velocità effettiva massima più elevata rispetto a una macchina virtuale senza RSS. Rss potrebbe essere disabilitato per impostazione predefinita. Per verificare se RSS è abilitato e abilitarlo, seguire questa procedura:

Controllare se RSS è abilitato per una scheda di rete usando il comando PowerShell Get-NetAdapterRss . Nell'esempio seguente, l'output di Get-NetAdapterRss mostra che RSS non è abilitato.
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : False
```
Per abilitare RSS, immettere il comando seguente:
```
Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}
```
Questo comando non produce alcun output. Modifica le impostazioni della scheda di interfaccia di rete (NIC) e causa una perdita di connettività temporanea per circa un minuto. Viene visualizzata una finestra di dialogo Riconnessione durante la perdita di connettività. La connettività viene in genere ripristinata dopo il terzo tentativo.
Verificare che RSS sia abilitato nella macchina virtuale immettendo di nuovo il Get-NetAdapterRss comando . In caso di esito positivo, viene restituito l'output di esempio seguente:
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : True
```

Macchine virtuali Linux

RSS è abilitato per impostazione predefinita nelle macchine virtuali Linux in Azure. I kernel Linux rilasciati a partire da ottobre 2017 includono opzioni di ottimizzazione di rete aggiuntive che consentono alle macchine virtuali Linux di ottenere una velocità effettiva maggiore.

Abilitare la rete accelerata di Azure per una velocità effettiva ottimale

Azure rete accelerata può migliorare significativamente la velocità effettiva e ridurre la latenza e il jitter. A seconda delle dimensioni della macchina virtuale e della generazione della piattaforma, Azure usa una delle due tecnologie: Mellanox, ampiamente disponibile, e MANA, sviluppato da Microsoft.

Kernel ottimizzati per Azure

Alcune distribuzioni, ad esempio Ubuntu (Canonical) e SUSE, forniscono kernel ottimizzati per Azure.

Usare il comando seguente per verificare che si stia usando il kernel Azure, che in genere include azure nel nome del kernel.

uname -r

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

Altre distribuzioni Linux

La maggior parte delle distribuzioni moderne include importanti miglioramenti di rete nei kernel più recenti. Controllare la versione del kernel e usare la versione 4.19 o successiva, quando possibile. I kernel più recenti includono un comportamento di rete migliore e supportano opzioni di controllo della congestione moderne, ad esempio BBR.

Raggiungimento di velocità di trasferimento coerenti nelle macchine virtuali Linux in Azure

Le macchine virtuali Linux possono mostrare velocità di trasferimento incoerenti, soprattutto durante trasferimenti regionali di grandi dimensioni, ad esempio da 1 GB a 50 GB tra Europa occidentale e Stati Uniti occidentali. Le cause comuni includono kernel obsoleti, dimensioni predefinite dei buffer e impostazioni non ottimizzate del controllo della congestione o della disciplina di accodamento.

Per ottenere una velocità effettiva più uniforme, applicare le seguenti ottimizzazioni di base e poi testare le combinazioni di congestione/qdisc per il carico di lavoro.

Configurazione di base di sysctl (copia/incolla)

Applicare le impostazioni sysctl di base seguenti:

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

Controllo della congestione e test qdisc (sysctl)

I diversi carichi di lavoro si comportano in modo diverso. Testare queste combinazioni e mantenere quella che offre i risultati migliori per il profilo di latenza, velocità effettiva e ritrasmissione.

BBR + FQ (spesso un'impostazione predefinita avanzata per i trasferimenti a velocità effettiva elevata e a lungo raggio)
```
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq
```
BBR + PFIFO_FAST (utile per confrontare il comportamento della coda in condizioni di traffico a raffiche o misto)
```
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=pfifo_fast
```

CUBIC + PFIFO_FAST (baseline legacy comune per compatibilità e confronto)

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.core.default_qdisc=pfifo_fast

Misurare ogni opzione con il traffico rappresentativo, quindi usare la combinazione di prestazioni migliore per l'ambiente in uso.

Annotazioni

pfifo_fast la disponibilità può variare in base alla distribuzione o al kernel. Se non è disponibile, usare l'opzione qdisc più vicina supportata nell'ambiente e continuare il benchmarking.

Regola UDEV per buffer ad anello NIC (TX/RX)

Creare una regola udev in /etc/udev/rules.d/99-azure-ring-buffer.rules per applicare le impostazioni del buffer circolare alle interfacce di rete:

Usare rx 4096 tx 4096 per le interfacce di rete accelerata (hv_pci) e mantenere rx 1024 tx 1024 per le interfacce sintetiche hv_netvsc .

Se preferisci un approccio interattivo per l'ottimizzazione del buffer circolare, puoi anche usare questo strumento di supporto: configurazione della NIC di Azure Linux (bash).

Annotazioni

Questo strumento GitHub è uno strumento di supporto facoltativo e non fa parte della documentazione del prodotto Microsoft Learn. Esaminare gli script e testare le modifiche in un ambiente non di produzione prima dell'implementazione generale.

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

Regola UDEV per qdisc sugli eventi dell'interfaccia

Dopo aver completato il benchmarking e selezionato il qdisc preferito, crea una regola udev in /etc/udev/rules.d/99-azure-qdisc.rules per applicare tale qdisc quando le interfacce di rete vengono aggiunte o modificate.

Sostituire <qdisc_choice> con l'opzione qdisc selezionata durante il test (ad esempio, fq o 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>"

Regola UDEV per la lunghezza della coda di trasmissione della scheda di rete

Creare la regola seguente in /etc/udev/rules.d/99-azure-txqueue-len.rules per aumentare la lunghezza della coda di trasmissione:

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

Pianificazione degli IRQ (irqbalance)

A seconda del carico di lavoro, potrebbe essere opportuno impedire al servizio irqbalance di pianificare gli IRQ su nodi specifici. Quando si usa IRQBalance, aggiornare /etc/default/irqbalance per specificare su quali CPU non devono essere pianificati gli IRQ. È necessario determinare la maschera che esclude tali CPU.

Altre informazioni su come calcolare la maschera sono disponibili qui.

SR-IOV comportamento della doppia interfaccia ed effetti collaterali

Nella rete Linux ad alte prestazioni Azure usa SR-IOV (ad esempio, con driver Mellanox come mlx4 o mlx5). In questo modello è possibile visualizzare sia un'interfaccia sintetica che un'interfaccia VF (Virtual Function) per lo stesso percorso di rete della macchina virtuale. Scopri di più.

Questa progettazione è prevista, ma può creare confusione durante l'ottimizzazione e la risoluzione dei problemi se entrambe le interfacce vengono considerate come percorsi di dati indipendenti.

I possibili effetti collaterali includono:

Risultati di benchmark incoerenti quando le impostazioni vengono applicate a un'interfaccia, ma il traffico usa l'altro.
Picchi improvvisi di latenza o ritrasmissioni durante il failover tra percorsi sintetici e VF.
Diagnostica fuorviante se i contatori e le acquisizioni di pacchetti vengono raccolti dall'interfaccia errata.

Per ridurre i rischi:

Verificare quale interfaccia gestisce il traffico del carico di lavoro prima di eseguire l'ottimizzazione.
Mantieni la configurazione di udev e sysctl coerente con la strategia relativa alle interfacce.
Ripetere il test della velocità effettiva e della latenza dopo il riavvio, gli aggiornamenti del driver o le modifiche dello stato di rete accelerato.

Note aggiuntive

Gli amministratori di sistema possono implementare queste raccomandazioni modificando i file di configurazione, ad /etc/sysctl.d/esempio , /etc/modules-load.d/e /etc/udev/rules.d/. Esaminare attentamente gli aggiornamenti del kernel e dei driver per evitare regressioni.

Per altre informazioni su configurazioni e risoluzione dei problemi specifici, vedere Azure documentazione sulle prestazioni di rete.

Distribuire le macchine virtuali vicine tra loro per una bassa latenza con gruppi di posizionamento di prossimità.
Vedere il risultato ottimizzato con test della larghezza di banda/velocità effettiva per lo scenario in uso.
Informazioni su come allocare la larghezza di banda alle macchine virtuali.
Leggi le domande frequenti su Rete virtuale di Azure.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-06-20