3 formas de reducir la latencia de red en Azure

La latencia de red se considera uno de los factores para que el rendimiento de su aplicación tenga éxito, y en Azure existen muchas posibilidades para reducirla.

Latencia de Red

En resumen, la latencia es el tiempo de respuesta entre cuando realizas una acción y cuando ves su resultado

¿Cómo puedo medir la Latencia de Red?

Personalmente, prefiero usar PsPing, y Microsoft recomienda Latte. Para sistemas Linux, puedes usar SocketPerf.

En un escenario ideal, deberías tener acceso a los servidores que quieres probar, para poder jugar con la conectividad cliente-servidor

Configuración del servidor

Abra ya sea CMD o Powershell, navegue hasta la carpeta que haya extraído PsPing y use el siguiente comando

psping -s 192.168.0.4:5000

Conexión desde el cliente al servidor

Abra ya sea CMD o Powershell, navegue hasta la carpeta que haya extraído PsPing y use el siguiente comando

psping -l 8k -n 10000 -h 100 192.168.0.4:5000

Lado del cliente

Lado del servidor

Recursos de Azure

Azure proporciona algunos recursos para reducir la latencia de las máquinas virtuales como se enumera a continuación

• Redes Aceleradas
• Recepción en la Canalización de Lado de Recepción (Receive Side Scaling)
• Grupos de Ubicación de Proximidad

Red Acelerada (Accelerated Networking)

Usando Accelerated Networking la comunicación que se reenvía a la VM proviene directamente de la interfaz de red de la VM, y ya no pasa por el host ni por el conmutador virtual, reduciendo la cantidad de saltos para alcanzar su destino.

Escenarios compatibles

• Sistemas operativos

  • Windows Server 2019 Datacenter
  • Windows Server 2016 Datacenter
  • Windows Server 2012 R2 Datacenter
  • Ubuntu 14.04 con el kernel linux-azure
  • Ubuntu 16.04 o posterior
  • SLES12 SP3 o posterior
  • RHEL 7.4 o posterior
  • CentOS 7.4 o posterior
  • CoreOS Linux
  • Debian “Stretch” con kernel backports
  • Oracle Linux 7.4 y posteriores con Red Hat Compatible Kernel (RHCK)
  • Oracle Linux 7.5 y posteriores con UEK versión 5
  • FreeBSD 10.4, 11.1 y 12.0

• Tamaños de Máquina Virtual

  • Instancias de Propósito General y de Compute-optimizada con 2 o más vCPUs
    • D/DSv2
    • F/Fs
  • Instancias que admiten Hyperthreading con 4 o más vCPUs
    • D/Dsv3
    • D/Dsv4
    • E/Esv3
    • Ea/Easv4
    • Fsv2
    • Lsv2
    • Ms/Mms
    • Ms/Mmsv2

Habilitar Accelerated Networking

[trp_language language=”en_US”]

[/trp_language]
[trp_language language=”pt_BR”]

[/trp_language]

PowerShell para habilitar Accelerated Networking

$virtualMachine = "proximity-02"
$resourceGroup = "blog-vinicius-deschamps"
$nicName = "proximity-02521"

Stop-AzVM -ResourceGroup $resourceGroup -Name $virtualMachine

$nic = Get-AzNetworkInterface -ResourceGroup $resourceGroup -Name $nicName

$nic.EnableAcceleratedNetworking = $true

$nic | Set-AzNetworkInterface

Start-AzVM -ResourceGroup $resourceGroup -Name $virtualMachine

Recepción y escalado del lado de la red (Receive side scaling)

Si su Máquina Virtual no cumple con los Escenarios Compatibles para habilitar Accelerated Networking, puede habilitar Receive Side Scaling y alcanzar un mayor rendimiento máximo.

Aunque, el escenario óptimo sería tener estas dos características habilitadas.

Escenarios Compatibles

• Windows Server 2012 R2 o posterior
• Núcleos Linux lanzados desde octubre de 2017

Ver Receive Side Scaling en la Máquina Virtual

Receive side scaling puede estar deshabilitado por defecto en una VM de Windows en Azure, y siempre habilitado por defecto en una VM de Linux en Azure.

Para verificar en la VM de Windows, conéctese a ella y abra PowerShell y escriba

Get-NetAdapterRss

Como se puede ver, el RSS está configurado como False en el parámetro Enabled, así que para activarlo escribe el siguiente comando

IMPORTANTE: La Máquina Virtual perderá conectividad mientras se ejecuta el comando a continuación

Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name} # Habilita el RSS

Y este comando no imprime una salida, así que para verificar si funcionó o no, usa nuevamente Get-NetAdapterRss

Grupos de Ubicación de Proximidad (Proximity Placement Groups)

Cuando provisions una Máquina Virtual en Azure y eliges una región, la VM puede estar provisionada en cualquiera de los centros de datos de esa región y si necesitas baja latencia, podrías encontrarte con problemas.

Proximity Placement Group permite que las Máquinas Virtuales estén ubicadas físicamente entre sí mediante un agrupamiento lógico que ayuda a reducir la latencia.

Habilitar Proximity Placement Group

En el Azure Portal, usa la función de Búsqueda y escribe Proximity, luego haz clic en Proximity Placement Group

Ahora, haz clic en Add

Tienes que elegir Subscription, Resource Group, Region y Proximity Placement Group Name, finalmente pulsa Review + create

Revisa el Proximity Placement Group, y haz clic en Create

Una vez recibas Your deployment is complete, entonces ya estás listo para cambiar tu Máquina Virtual a la Proximity Placement Group

IMPORTANTE: Tu VM debe estar en un estado de Detenido Desasignado para poder cambiar la Proximity Placement Group

En tu Máquina Virtual, ve a Configuration, elige Proximity Placement Group y haz clic en Save

Escenario de prueba

Tengo 3 máquinas virtuales, y 2 de ellas cuentan con Accelerated Networking, Receive Side Scaling y forman parte del mismo Proximity Placement Group.

Máquina Virtual	Accelerated Networking	Receive Side Scaling	Proximity Placement Group
proximity-01	Enabled	Enabled	proximity-eastus-group
proximity-02	Enabled	Enabled	proximity-eastus-group
proximity-03	Disabled	Disabled	–

Tomé como referencia los pasos que mostré anteriormente en How can I measure Network Latency? para realizar estas pruebas y proximity-01 fue configurada para ser nuestro servidor y proximity-02 y proximity-03 los clientes

proximity-02 a proximity-01

proximity-03 a proximity-01

La diferencia de latencia fue de 0.04 ms pero tenga en cuenta que el paquete utilizado fue 8192 bytes, lo que significa que para un paquete más grande, tendrá una latencia mayor.

Si su aplicación tiene cargas de trabajo sensibles a la latencia, ciertamente debería considerar tener estas características habilitadas y aplicadas a sus VMs.

¡Y eso es todo!

Espero que les haya gustado, y nos vemos en mi próxima publicación.

Foto de Peter Mizsak en Unsplash