Otimizar a taxa de transferência de rede para máquinas virtuais do Azure

Azure VMs (máquinas virtuais) têm configurações de rede padrão que podem ser otimizadas para melhorar a taxa de transferência e a consistência. Este artigo descreve como otimizar o desempenho da rede para VMs Windows e Linux.

Importante

Muitas das otimizações descritas neste artigo (por exemplo, controle de congestionamento, disciplina de fila, tamanhos de buffer e ajuste de NIC) afetam a forma como o tráfego flui entre os sistemas.

Para obter melhores resultados, aplique essas configurações consistentemente em todas as máquinas virtuais que participam da carga de trabalho, incluindo:

Sistemas cliente
Sistemas de servidor

Aplicar essas configurações a apenas um subconjunto de máquinas virtuais pode levar a:

Taxa de transferência inconsistente
Aumento nas retransmissões de pacotes
Comportamento de congestionamento abaixo do ideal

Sempre valide as alterações em todo o caminho de dados e teste o desempenho de ponta a ponta.

Máquinas virtuais do Windows

Se a máquina virtual do Windows der suporte à rede acelerada, habilite esse recurso para a taxa de transferência ideal. Para obter mais informações, confira Criar uma VM do Windows com rede acelerada.

Para todas as outras VMs Windows, o RSS (Dimensionamento lateral de recebimento) pode fornecer uma taxa de transferência máxima maior do que uma VM sem RSS. O RSS pode estar desabilitado por padrão. Para verificar se o RSS está habilitado e habilitá-lo, siga estas etapas:

Verifique se o RSS está habilitado para um adaptador de rede usando o comando Get-NetAdapterRss PowerShell. No exemplo a seguir, a saída de Get-NetAdapterRss mostra que o RSS não está habilitado.
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : False
```
Para habilitar o RSS, insira o seguinte comando:
```
Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}
```
Esse comando não tem saída. Ele altera as configurações de NIC (placa de interface de rede) e causa perda temporária de conectividade por cerca de um minuto. Aparece uma caixa de diálogo Reconectando durante a perda de conectividade. Normalmente, a conectividade for restaurada após a terceira tentativa.
Confirme se o RSS está habilitado na VM inserindo o Get-NetAdapterRss comando novamente. Se for bem-sucedido, será retornada a seguinte saída de exemplo:
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : True
```

Máquinas virtuais do Linux

O RSS é habilitado por padrão em VMs (máquinas virtuais) do Linux em Azure. Os kernels do Linux lançados desde outubro de 2017 incluem opções adicionais de otimização de rede que ajudam as VMs do Linux a obter uma taxa de transferência mais alta.

Habilitar a Rede Acelerada do Azure para uma taxa de transferência ideal

Azure Rede Acelerada pode melhorar significativamente a taxa de transferência e reduzir a latência e o tremulação. Dependendo do tamanho da VM e da geração da plataforma, Azure usa uma das duas tecnologias: Mellanox, que está amplamente disponível, e MANA, que é desenvolvida por Microsoft.

Kernels ajustados ao Azure

Algumas distribuições, como Ubuntu (Canonical) e SUSE, fornecem kernels otimizados para o Azure.

Use o comando a seguir para verificar se você está usando o kernel Azure, que geralmente inclui azure o nome do kernel.

uname -r

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

Outras distribuições do Linux

A maioria das distribuições modernas inclui grandes melhorias de rede em kernels mais recentes. Verifique sua versão do kernel e use 4.19 ou posterior, quando possível. Kernels mais recentes incluem melhor comportamento de rede e dão suporte a opções de controle de congestionamento modernas, como BBR.

Obtendo velocidades de transferência consistentes em VMs do Linux no Azure

As VMs do Linux podem mostrar velocidades de transferência inconsistentes, especialmente durante grandes transferências regionais (por exemplo, 1 GB a 50 GB entre a Europa Ocidental e o Oeste dos EUA). As causas comuns incluem kernels mais antigos, tamanhos de buffer padrão e configurações não ajustadas de controle de congestionamento ou de disciplina de fila.

Para obter uma taxa de transferência mais consistente, aplique o ajuste de linha de base a seguir e teste as combinações de congestionamento/qdisc para sua carga de trabalho.

Ajuste básico de sysctl (copiar e colar)

Aplique as seguintes configurações de sysctl de linha de base:

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 de congestionamento e testes de qdisc (sysctl)

Cargas de trabalho diferentes se comportam de forma diferente. Teste essas combinações e mantenha a que fornece os melhores resultados para seu perfil de latência, taxa de transferência e retransmissão.

BBR + FQ (geralmente uma opção padrão sólida para transferências de alta vazão e longa distância)
```
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq
```

BBR + PFIFO_FAST (útil para comparar o comportamento da fila em tráfego intermitido ou misto)

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

CUBIC + PFIFO_FAST (linha de base herdada comum para compatibilidade e comparação)

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

Meça cada opção com tráfego representativo e use a combinação de melhor desempenho para seu ambiente.

Note

pfifo_fast A disponibilidade pode variar de acordo com a distribuição/kernel. Se não estiver disponível, use a opção de qdisc compatível mais próxima no seu ambiente e continue com o benchmarking.

Regra UDEV para buffers de anel NIC (TX/RX)

Crie, em /etc/udev/rules.d/99-azure-ring-buffer.rules, uma regra do udev para aplicar configurações de buffer circular às interfaces de rede:

Use rx 4096 tx 4096 para interfaces de rede aceleradas (hv_pci) e mantenha rx 1024 tx 1024 para interfaces sintéticas hv_netvsc .

Se preferir uma abordagem interativa para o ajuste do buffer circular, você também pode usar esta ferramenta auxiliar: Configuração de NIC do Azure Linux (bash).

Note

Essa ferramenta GitHub é um auxiliar opcional e não faz parte da documentação do produto Microsoft Learn. Examine os scripts e teste as alterações em um ambiente de não produção antes da distribuição ampla.

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

Regra UDEV para qdisc em eventos de interface

Depois de concluir os testes de desempenho e selecionar o qdisc de sua preferência, crie uma regra do udev em /etc/udev/rules.d/99-azure-qdisc.rules para aplicar esse qdisc quando as interfaces de rede forem adicionadas ou alteradas.

Substitua <qdisc_choice> pelo qdisc selecionado durante o teste (por exemplo, fq ou 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>"

Regra UDEV para o tamanho da fila de transmissão da NIC

Crie a seguinte regra em /etc/udev/rules.d/99-azure-txqueue-len.rules para aumentar o tamanho da fila de transmissão:

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

Agendamento do IRQ (irqbalance)

Dependendo da sua carga de trabalho, talvez você queira impedir que o serviço irqbalance agende IRQs em nós específicos. Ao usar IRQBalance, atualize /etc/default/irqbalance para especificar quais CPUs não devem ter IRQs agendadas. Você precisará determinar a máscara que exclui essas CPUs.

Mais informações sobre como calcular a máscara estão disponíveis aqui.

Comportamento de dupla interface e efeitos colaterais do SR-IOV

Em redes de alto desempenho no Linux, a Azure usa SR-IOV (por exemplo, com drivers da Mellanox, como mlx4 ou mlx5). Neste modelo, você pode ver tanto uma interface sintética quanto uma interface de função virtual (VF) para o mesmo caminho de rede da VM. Saiba mais.

Esse design é esperado, mas pode criar confusão durante o ajuste e a solução de problemas se ambas as interfaces forem tratadas como caminhos de dados independentes.

Os possíveis efeitos colaterais incluem:

Resultados de benchmark inconsistentes quando as configurações são aplicadas a uma interface, mas o tráfego usa a outra interface.
Picos de latência inesperados ou retransmissões durante o failover entre caminhos sintéticos e VF.
Diagnósticos enganosos quando contadores e capturas de pacotes forem coletados da interface errada.

Para reduzir o risco:

Valide qual interface transporta o tráfego da sua carga de trabalho antes de fazer ajustes.
Mantenha os ajustes do udev e do sysctl consistentes com sua estratégia para interfaces.
Testar novamente a taxa de transferência e a latência após a reinicialização, atualizações de driver ou alterações aceleradas de estado de rede.

Observações adicionais

Os administradores do sistema podem implementar essas recomendações editando arquivos de configuração, como /etc/sysctl.d/, /etc/modules-load.d/e /etc/udev/rules.d/. Examine as atualizações do kernel e do driver com cuidado para evitar regressões.

Para obter mais informações sobre configurações específicas e solução de problemas, consulte Azure documentação sobre o desempenho da rede.

Implantar VMs próximas umas às outras para baixa latência com o grupo de posicionamento por proximidade.
Veja o resultado otimizado com o teste de Largura de Banda/Taxa de Transferência para o seu cenário.
Leia mais sobre como a largura de banda é alocada a máquinas virtuais.
Leia Rede Virtual do Azure perguntas frequentes.

Comentários

Esta página foi útil?

Last updated on 2026-06-20