Solución de problemas de rendimiento de red

Información general

Azure ofrece una manera estable y rápida para conectarse desde la red local a Azure. Clientes de todos los tamaños utilizan con éxito métodos como VPN de sitio a sitio y ExpressRoute para gestionar sus negocios en Azure. Pero, ¿qué ocurre cuando el rendimiento no satisface sus expectativas o la experiencia anterior? Este artículo puede ayudar a normalizar la forma de probar su entorno específico y de crear una base de referencia para este.

Obtendrá información sobre cómo puede probar la latencia de red y el ancho de banda de forma fácil y coherente entre dos hosts. También recibirá algunos consejos para examinar la red de Azure y ayudar a aislar puntos problemáticos. Las herramientas y el script de PowerShell descritos requieren dos hots en la red (en cualquiera de los extremos del vínculo que se va a probar). Un host debe ejecutar el Escritorio de Windows o Windows Server; el otro puede ejecutar Windows o Linux.

Componentes de red

Antes de adentrarnos en la solución de problemas, veamos algunos componentes y términos comunes. Esta explicación garantiza que estamos pensando en cada componente de la cadena de un extremo a otro que permite la conectividad en Azure.

En el nivel más alto, hay tres dominios de enrutamiento de red principales:

• La red de Azure (nube azul)
• Internet o WAN (nube verde)
• La red corporativa (nube naranja)

Vamos a analizar brevemente cada componente fijándonos en el diagrama de derecha a izquierda:

• Máquina virtual: el servidor puede tener varias NIC. Asegúrese de que todas las rutas estáticas, las rutas predeterminadas y la configuración del sistema operativo envían y reciben tráfico según lo previsto. Además, cada SKU de máquina virtual tiene una restricción de ancho de banda. Si usa una SKU de máquina virtual más pequeña, el ancho de banda disponible para la NIC limita el tráfico. Se recomienda usar DS5v2 para realizar pruebas a fin de garantizar el ancho de banda adecuado en la máquina virtual.

• NIC: asegúrese de que conoce la dirección IP privada asignada a la NIC en cuestión.

• NSG de NIC: puede haber grupos de seguridad de red específicos aplicados en el nivel de NIC. Asegúrese de que el conjunto de reglas de NSG es apropiado para el tráfico que intenta transmitir. Por ejemplo, asegúrese de que los puertos 5201 para iPerf, 3389 para RDP o 22 para SSH están abiertos para permitir la transferencia del tráfico de prueba.

• Subred de red virtual: la NIC se asigna a una subred específica. Asegúrese de saber cuál es y las reglas asociadas a esa subred.

• NSG de subred: al igual que la NIC, los NSG también pueden aplicarse a la subred. Asegúrese de que el conjunto de reglas de NSG es apropiado para el tráfico que intenta transmitir. Para el tráfico entrante a la NIC, el NSG de la subred se aplica primero y luego el NSG de la NIC. Cuando el tráfico sale de la VM, el NSG de la NIC se aplica primero y luego el NSG de la subred.

• UDR de subred: las rutas definidas por el usuario pueden dirigir el tráfico a un salto intermedio (como un firewall o un equilibrador de carga). Asegúrese de que sabe si hay un UDR implementado para el tráfico. Si es así, comprenda cuál es su destino y cómo afectará el próximo salto al tráfico. (Por ejemplo, un firewall puede pasar algún tráfico y denegar otro entre los mismos dos hosts).

• Gateway subnet / NSG / UDR: de la misma manera que la subred de máquina virtual, la subred de puerta de enlace puede tener NSG y UDR. Asegúrese de que existen y de qué efectos tienen en el tráfico.

• VNet Gateway (ExpressRoute) : una vez habilitado el emparejamiento (ExpressRoute) o VPN, existen muchas configuraciones que pueden afectar a que el tráfico se redirija o no y a cómo se lleva. Si tiene una instancia de Gateway conectada a varios circuitos ExpressRoute o túneles VPN, debe tener en cuenta la configuración del peso de la conexión. El peso de la conexión afecta a la preferencia de conexión y determina la ruta de acceso que toma el tráfico.

• Filtro de ruta (no se muestra): es necesario un filtro de ruta al usar el emparejamiento de Microsoft a través de ExpressRoute. Si no recibe ninguna ruta, compruebe si el filtro de ruta está configurado y aplicado correctamente al circuito.

En este punto, está en la parte WAN del vínculo. Este dominio de enrutamiento puede ser el proveedor de servicios, la WAN corporativa o Internet. Existen muchos saltos, tecnologías y empresas relacionados con estos vínculos, lo que puede dificultar la solución de problemas. En primer lugar, debe descartar tanto Azure como las redes corporativas para poder investigar los saltos intermedios.

En el diagrama anterior, en el extremo izquierdo, se muestra la red corporativa. Según el tamaño de su empresa, este dominio de enrutamiento puede corresponderse con unos cuantos dispositivos de red entre usted y la WAN o con varias capas de dispositivos de una red empresarial o de campus.

Dada la complejidad que plantean estos tres entornos de red de alto nivel distintos, suele ser una opción óptima empezar por los bordes y tratar de mostrar dónde el rendimiento es bueno y dónde se reduce. Este enfoque puede ayudar a identificar el dominio de enrutamiento del problema de los tres. Después, puede centrar la solución de problemas en ese entorno específico.

Herramientas

La mayoría de los problemas de red se pueden analizar y aislar con herramientas básicas como ping y traceroute. Es raro que necesite indagar tanto como un análisis de paquetes con herramientas como Wireshark.

Para facilitar la solución de problemas, se desarrolló Azure Connectivity Toolkit (AzureCT) para incluir algunas de estas herramientas en un paquete sencillo. Para las pruebas de rendimiento, las herramientas como iPerf y PSPing pueden proporcionarle información sobre la red. iPerf es una herramienta que se usa habitualmente para pruebas de rendimiento básicas y resulta bastante fácil de usar. PSPing es una herramienta Ping desarrollada por SysInternals. PSPing puede hacer ping de ICMP y TCP para llegar a un host remoto. Ambas herramientas son ligeras y se "instalan" solo con copiar los archivos en un directorio del host.

Estas herramientas y estos métodos se encapsulan en un módulo de PowerShell (AzureCT) que puede instalar y usar.

AzureCT (Azure Connectivity Toolkit)

El módulo AzureCT de PowerShell tiene dos componentes: pruebas de disponibilidad y pruebas de rendimiento. Este documento se centra en las pruebas de rendimiento, concretamente en los dos comandos de rendimiento de vínculos en este módulo de PowerShell.

Hay tres pasos básicos para usar este kit de herramientas para pruebas de rendimiento:

1. Instale el módulo de PowerShell

   (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
   

   Este comando descarga el módulo de PowerShell y lo instala de forma local.

2. Instale las aplicaciones auxiliares

   Install-LinkPerformance
   

   Este comando de AzureCT instala iPerf y PSPing C:\ACTTools en un directorio nuevo y abre los puertos del Firewall de Windows para permitir el tráfico ICMP y del puerto 5201 (iPerf).

3. Ejecute la prueba de rendimiento

   En primer lugar, instale y ejecute iPerf en modo de servidor en el host remoto. Asegúrese de que el host remoto escucha en los puertos 3389 (RDP para Windows) o 22 (SSH para Linux) y que se permite el tráfico a través del puerto 5201 para iPerf. Si el host remoto es Windows, instale AzureCT y ejecute el comando Install-LinkPerformance para configurar iPerf y las reglas de firewall necesarias.

   Una vez preparada la máquina remota, abra PowerShell en la máquina local e inicie la prueba:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Este comando ejecuta una serie de pruebas de carga y latencia simultáneas para estimar la capacidad y latencia de ancho de banda del vínculo de red.

4. Revise la salida de la prueba

   El formato del resultado de PowerShell tiene un aspecto similar al siguiente:

   

   Los resultados detallados de todas las pruebas iPerf y PSPing se guardan en archivos de texto individuales en el directorio de herramientas de AzureCT en C:\ACTTools.

Solución de problemas

Si los resultados de la prueba de rendimiento no son los esperados, siga un enfoque sistemático para identificar el problema. Dado el número de componentes en la ruta, un proceso paso a paso es más eficaz que las pruebas aleatorias.

Nota:

El escenario que se presenta aquí representa un problema de rendimiento, no de conectividad. Para aislar los problemas de conectividad a la red de Azure, siga el artículo Verificación de la conectividad de ExpressRoute.

1. Cuestione sus suposiciones

   Asegúrese de que sus expectativas sean razonables. Por ejemplo, con un circuito ExpressRoute de 1 Gbps y 100 ms de latencia, esperar el tráfico completo de 1 Gbps no es realista debido a las características de rendimiento de TCP en enlaces de alta latencia. Consulte la sección Referencias para más información sobre las hipótesis de rendimiento.

2. Comience en el perímetro de la red

   Comience por los límites entre los dominios de enrutamiento e intente aislar el problema en un único dominio de enrutamiento principal. Evite culpar a la 'caja negra' en la ruta sin una investigación exhaustiva, ya que esto puede retrasar la resolución.

3. Cree un diagrama

   Dibuje un diagrama del área en cuestión para trabajar metódicamente y aislar el problema. Planifique puntos de prueba y actualice el mapa a medida que despeje zonas o profundice en ellas.

4. Divida y vencerá

   Segmente la red y acote el problema. Identifique dónde funciona y dónde no, y siga moviendo sus puntos de prueba para aislar el componente defectuoso.

5. Tenga en cuenta todas las capas de OSI

   Aunque es habitual centrarse en la red y en las capas 1-3 (capas física, de datos y de red), recuerde que los problemas también pueden producirse en la capa 7 (capa de aplicación). Mantenga una mente abierta y verifique todas las suposiciones.

Solución avanzada de problemas de ExpressRoute

Aislar los componentes de Azure puede ser un reto si no está seguro de dónde está el límite de la nube. Con ExpressRoute, el perímetro es un componente de red llamado Microsoft Enterprise Edge (MSEE). MSEE es el primer punto de contacto en la red de Microsoft y el último salto al salir de ella. Cuando crea una conexión entre su puerta de enlace de red virtual y el circuito de ExpressRoute, se conecta a MSEE. El reconocimiento de MSEE como primer o último salto es fundamental para aislar un problema de redes de Azure. Conocer la dirección del tráfico ayuda a determinar si el problema está en Azure o más abajo en la WAN o en la red corporativa.

Nota:

MSEE no está en la nube de Azure. ExpressRoute se encuentra en el perímetro de la red de Microsoft, y no en Azure. Una vez conectado con ExpressRoute a MSEE, estará conectado a la red de Microsoft, lo que le permitirá acceder a servicios en la nube como Microsoft 365 (con emparejamiento de Microsoft) o Azure (con emparejamiento privado y/o de Microsoft).

Si dos redes virtuales están conectadas al mismo circuito de ExpressRoute, puede realizar pruebas para aislar el problema en Azure.

Plan de pruebas

1. Ejecute la prueba Get-LinkPerformance entre VM1 y VM2. Esta prueba le permitirá saber si el problema es local. Si la prueba genera resultados de latencia y ancho de banda aceptables, puede marcar la red virtual local como correcta.

2. Suponiendo que el tráfico de la red virtual local es correcto, ejecute la prueba Get-LinkPerformance entre VM1 y VM3. Esta prueba establece la conexión a través de la red de Microsoft en orden descendente hasta llegar a MSEE y vuelve a Azure. Si la prueba genera resultados de latencia y ancho de banda aceptables, puede marcar la red de Azure como correcta.

3. Si se descarta Azure, realice pruebas similares en su red corporativa. Si esas pruebas también son buenas, trabaje con su proveedor de servicios o ISP para diagnosticar su conexión WAN. Por ejemplo, realice pruebas entre dos sucursales o entre su escritorio y un servidor de centro de datos. Encuentre puntos de conexión como servidores y ordenadores cliente que puedan recorrer la ruta que está probando.

Importante

Para cada prueba, marque la hora del día y registre los resultados en un lugar común. Cada ejecución de prueba debe tener un resultado idéntico para una comparación de datos coherente. La coherencia entre múltiples pruebas es la razón principal para utilizar AzureCT para la resolución de problemas. La clave es obtener pruebas y datos coherentes en todo momento. Registrar la hora y tener datos coherentes es especialmente útil si el problema es esporádico. Sea meticuloso con la recopilación de datos desde el principio para evitar tener que volver a probar las mismas situaciones durante horas.

El problema ya está aislado, ¿ahora qué?

Cuanto más aísle el problema, más rápido podrá encontrar la solución. A veces llega un punto en el que no puede seguir con la resolución de problemas. Por ejemplo, es posible que vea el vínculo a través de su proveedor de servicios saltando por Europa cuando espera que permanezca en Asia. En este punto, pida ayuda a alguien en función del dominio de enrutamiento al que haya aislado el problema. Reducirlo a un componente específico es aún mejor.

En el caso de problemas de la red corporativa, el proveedor de servicios o el departamento de TI interno pueden ayudar con la configuración del dispositivo o la reparación de hardware.

Para problemas de WAN, comparta los resultados de las pruebas con su proveedor de servicios o ISP para ayudarles con su trabajo y evitar tareas redundantes. Es posible que quieran verificar sus resultados basándose en el principio de confiar pero verificar.

Para problemas de Azure, una vez que haya aislado el problema con el mayor detalle posible, revise la Documentación de red de Azure y, si es necesario, abra un vale de soporte.

Referencias

Expectativas de ancho de banda y latencia

Sugerencia

La distancia geográfica entre los puntos de conexión es el factor más importante en la latencia. Si bien la latencia del equipo (componentes físicos y virtuales, número de saltos, etc.) también juega un rol, la distancia del recorrido de la fibra, no la distancia en línea recta, es el colaborador principal. Esta distancia es difícil de medir con precisión, por lo que a menudo usamos una calculadora de distancias de ciudades para hacer una estimación aproximada.

Por ejemplo, configuramos una ExpressRoute en Seattle, Washington, EE. UU. La siguiente tabla muestra la latencia y el ancho de banda observados al realizar pruebas en varias ubicaciones de Azure, junto con las distancias estimadas.

Configuración de la prueba:

• Un servidor físico que ejecuta Windows Server 2016 con una NIC de 10 Gbps, conectado a un circuito ExpressRoute.

• Un circuito de ExpressRoute Premium de 10 Gbps con emparejamiento privado habilitado.

• Una red virtual de Azure con una puerta de enlace UltraPerformance en la región especificada.

• Una máquina virtual DS5v2 con Windows Server 2016 en la red virtual, usando la imagen predeterminada de Azure con AzureCT instalado.

• Todas las pruebas usaron el comando Get-LinkPerformance de AzureCT con una prueba de carga de 5 minutos para cada una de las seis series de pruebas. Por ejemplo:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• El flujo de datos para cada prueba fue desde el servidor local (cliente iPerf en Seattle) a la máquina virtual de Azure (servidor iPerf en las regiones de Azure descritas).

• Los datos de la columna "Latencia" muestra datos de la prueba sin carga (una prueba de latencia TCP sin iPerf en ejecución).

• Los datos de la columna "Ancho de banda máx." muestra datos de la prueba de carga del flujo de TCP 16 con un tamaño de ventana de 1 Mb.

Resultados de latencia y ancho de banda

Importante

Estas cifras solo sirven como referencia general. Muchos factores afectan a la latencia y, aunque estos valores son generalmente consistentes a lo largo del tiempo, las condiciones dentro de Azure o de la red del proveedor de servicios pueden cambiar, afectando a la latencia y al ancho de banda. Por norma general, estos cambios no generan diferencias importantes.

Ubicación de ExpressRoute	Región de Azure	Distancia estimada (km)	Latencia	Ancho de banda de 1 sesión	Bandwidth máximo
Seattle	Oeste de EE. UU. 2	191 km	5 ms	262,0 Mbits/s	3,74 Gbits/s
Seattle	Oeste de EE. UU.	1094 km	18 ms	82,3 Mbits/s	3,70 Gbits/s
Seattle	Centro de EE. UU.	2357 km	40 ms	38,8 Mbits/s	2,55 Gbits/s
Seattle	Centro-sur de EE. UU.	2877 km	51 ms	30,6 Mbits/s	2,49 Gbits/s
Seattle	Centro-Norte de EE. UU	2792 km	55 ms	27,7 Mbits/s	2,19 Gbits/s
Seattle	Este de EE. UU. 2	3769 km	73 ms	21,3 Mbits/s	1,79 Gbits/s
Seattle	Este de EE. UU.	3699 km	74 ms	21,1 Mbits/s	1,78 Gbits/s
Seattle	Japón Oriental	7705 km	106 ms	14,6 Mbits/s	1,22 Gbits/s
Seattle	Sur de Reino Unido 2	7708 km	146 ms	10,6 Mbits/s	896 Mbits/s
Seattle	Oeste de Europa	7834 km	153 ms	10,2 Mbits/s	761 Mbits/s
Seattle	Este de Australia	12 484 km	165 ms	9,4 Mbits/s	794 Mbits/s
Seattle	Sudeste de Asia	12 989 km	170 ms	9,2 Mbits/s	756 Mbits/s
Seattle	Sur de Brasil *	10 930 km	189 ms	8,2 Mbits/s	699 Mbits/s
Seattle	Sur de la India	12 918 km	202 ms	7,7 Mbits/s	634 Mbits/s

* La latencia a Brasil es un ejemplo en el que la distancia de recorrido de la fibra difiere significativamente de la distancia en línea recta. La latencia esperada sería de unos 160 ms, pero en realidad es de 189 ms debido a la ruta de fibra más larga.

Nota:

Estos números se probaron con AzureCT basado en iPerf en Windows a través de PowerShell. iPerf no respeta las opciones TCP predeterminadas de Windows para el factor de escalado y utiliza un recuento de turnos menor para el tamaño de la ventana TCP. Al ajustar los comandos de iPerf con el conmutador -w y un tamaño de ventana TCP mayor, se puede lograr un mejor rendimiento. Ejecutar iPerf en modo multiproceso desde varias máquinas también puede ayudar a alcanzar el máximo rendimiento del vínculo. Para obtener los mejores resultados de iPerf en Windows, use "Set-NetTCPSetting -AutoTuningLevelLocal Experimental". Compruebe las directivas de la organización antes de realizar cambios.

Pasos siguientes

• Descargue Azure Connectivity Toolkit.
• Siga las instrucciones para las pruebas de rendimiento de los vínculos