Optimización del rendimiento de red en las máquinas virtuales de Azure

Las máquinas virtuales (VM) de Azure tienen una configuración de red predeterminada que se puede optimizar para mejorar el rendimiento y la estabilidad. En este artículo se describe cómo optimizar el rendimiento de red para máquinas virtuales Linux y Windows.

Máquinas virtuales Windows

Si la máquina virtual Windows admite red acelerada, habilite esa característica para lograr un rendimiento óptimo. Para más información, consulte Creación de una máquina virtual Windows con redes aceleradas.

Para todas las demás máquinas virtuales de Windows, el escalado del lado de recepción (RSS) puede proporcionar un rendimiento máximo mayor que una máquina virtual sin RSS. RSS puede deshabilitarse de forma predeterminada. Para comprobar si RSS está habilitado y habilitarlo, siga estos pasos:

1. Compruebe si RSS está habilitado para un adaptador de red mediante el comando Get-NetAdapterRss de PowerShell. En el ejemplo siguiente, la salida de Get-NetAdapterRss muestra que RSS no está habilitado.

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

2. Para habilitar RSS escriba el siguiente comando:

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

   Este comando no tiene salida. Cambia la configuración de la tarjeta de interfaz de red (NIC) y provoca una pérdida temporal de conectividad durante aproximadamente un minuto. Durante la pérdida de conectividad, aparece un cuadro de diálogo Reconectando. La conectividad se suele restaurar al tercer intento.

3. Confirme que RSS está habilitado en la máquina virtual, para lo que debe volver a escribir el comando Get-NetAdapterRss. Si se realiza correctamente, se devuelve la siguiente salida de ejemplo:

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

Máquinas virtuales Linux

RSS está habilitado de forma predeterminada en máquinas virtuales Linux en Azure. Los kernels de Linux publicados desde octubre de 2017 incluyen opciones de optimización de red adicionales que ayudan a las máquinas virtuales Linux a lograr un mayor rendimiento.

Habilitación de redes aceleradas de Azure para un rendimiento óptimo

Azure Accelerated Networking puede mejorar significativamente el rendimiento y reducir la latencia y la vibración. Según el tamaño de máquina virtual y la generación de plataformas, Azure usa una de las dos tecnologías: Mellanox, que está ampliamente disponible y MANA, que está desarrollada por Microsoft.

Kernels optimizados para Azure

Algunas distribuciones, como Ubuntu (Canonical) y SUSE, proporcionan núcleos optimizados para Azure.

Use el siguiente comando para comprobar que usa el kernel Azure, que normalmente incluye azure en el nombre del kernel.

uname -r

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

Otras distribuciones de Linux

La mayoría de las distribuciones modernas incluyen mejoras de red importantes en los kernels más recientes. Compruebe la versión del kernel y use la versión 4.19 o posterior cuando sea posible. Los kernels más recientes incluyen un mejor comportamiento de red y admiten opciones de control de congestión modernas, como BBR.

Lograr velocidades de transferencia coherentes en máquinas virtuales Linux en Azure

Las máquinas virtuales Linux pueden mostrar velocidades de transferencia incoherentes, especialmente durante las transferencias regionales grandes (por ejemplo, de 1 GB a 50 GB entre Oeste de Europa y Oeste de EE. UU.). Entre las causas comunes se incluyen las versiones antiguas del kernel, los tamaños de búfer predeterminados y la configuración no optimizada del control de congestión o de la disciplina de colas.

Para obtener un rendimiento más coherente, aplique el siguiente ajuste de línea base y, a continuación, pruebe las combinaciones de congestión y qdisc para su carga de trabajo.

Configuración básica de sysctl (copiar y pegar)

Aplique la siguiente configuración de sysctl de línea 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

Control de congestión y pruebas de qdisc (sysctl)

Las distintas cargas de trabajo se comportan de forma diferente. Pruebe estas combinaciones y mantenga la que proporciona los mejores resultados para la latencia, el rendimiento y el perfil de retransmisión.

1. BBR + FQ (a menudo un valor predeterminado seguro para transferencias de alto rendimiento y de larga distancia)

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

2. BBR + PFIFO_FAST (útil para comparar el comportamiento de la cola con tráfico en ráfagas o mixto)

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

3. CUBIC + PFIFO_FAST (línea base heredada común para compatibilidad y comparación)

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

Mida cada opción con tráfico representativo y, a continuación, use la combinación de mejor rendimiento para su entorno.

Regla UDEV para los búferes circulares de la NIC (TX/RX)

Cree una regla udev en /etc/udev/rules.d/99-azure-ring-buffer.rules para aplicar la configuración del búfer de anillo a las interfaces de red:

Use rx 4096 tx 4096 para las interfaces de redes aceleradas (hv_pci) y mantenga rx 1024 tx 1024 para las interfaces sintéticas hv_netvsc .

Si prefiere un enfoque interactivo para ajustar el ring buffer, también puede usar esta herramienta auxiliar: Configuración de la NIC de Azure Linux (bash).

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

Regla UDEV para qdisc en eventos de interfaz

Después de finalizar la prueba comparativa y seleccionar su qdisc preferido, cree una regla udev en /etc/udev/rules.d/99-azure-qdisc.rules para aplicar ese qdisc cuando se agreguen o cambien las interfaces de red.

Reemplace <qdisc_choice> por el qdisc que seleccionó durante las pruebas (por ejemplo, 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>"

Regla UDEV para la longitud de la cola de transmisión de NIC

Cree la siguiente regla en /etc/udev/rules.d/99-azure-txqueue-len.rules para aumentar la longitud de la cola de transmisión:

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

Programación de IRQ (irqbalance)

Según su carga de trabajo, es posible que quiera restringir el servicio irqbalance para que no programe IRQs en nodos específicos. Al usar IRQBalance, actualice /etc/default/irqbalance para especificar qué CPU no deben tener programadas IRQ. Deberá determinar la máscara que excluye esas CPU.

Aquí encontrará más información sobre cómo calcular la máscara.

Comportamiento y efectos secundarios de SR-IOV de doble interfaz

En las redes de alto rendimiento de Linux, Azure usa SR-IOV (por ejemplo, con controladores Mellanox como mlx4 o mlx5). En este modelo, se pueden ver tanto una interfaz sintética como una interfaz de función virtual (VF) en la misma ruta de acceso de red de la máquina virtual. Obtenga más información.

Este diseño se espera, pero puede crear confusión durante el ajuste y la solución de problemas si ambas interfaces se tratan como rutas de acceso de datos independientes.

Entre los posibles efectos secundarios se incluyen:

• Resultados de pruebas comparativas incoherentes cuando la configuración se aplica a una interfaz, pero el tráfico usa la otra.
• Picos de latencia inesperados o retransmisiones durante la conmutación por error entre rutas de acceso sintéticas y VF.
• Diagnósticos engañosos si los contadores y las capturas de paquetes se obtienen de la interfaz incorrecta.

Para reducir el riesgo:

• Compruebe qué interfaz transporta el tráfico de la carga de trabajo antes de ajustar.
• Mantenga la configuración de udev y sysctl coherente con su estrategia para las interfaces.
• Vuelva a probar el rendimiento y la latencia después del reinicio, las actualizaciones de controladores o los cambios de estado de red acelerados.

Notas adicionales

Los administradores del sistema pueden implementar estas recomendaciones editando archivos de configuración como /etc/sysctl.d/, /etc/modules-load.d/y /etc/udev/rules.d/. Revise cuidadosamente las actualizaciones del kernel y del controlador para evitar regresiones.

Para más información sobre configuraciones específicas y solución de problemas, consulte Azure documentación sobre el rendimiento de redes.

Contenido relacionado

• Implemente las máquinas virtuales cerca unas de otras para obtener una latencia baja con los grupos de colocación por proximidad.
• Vea el resultado optimizado con las pruebas de rendimiento de ancho de banda para su escenario.
• Aprenda cómo el ancho de banda se asigna a las máquinas virtuales.
• Lea Azure Virtual Network preguntas más frecuentes.