Resolver problemas de rendimiento de la red

Resumen

Azure proporciona una manera estable y rápida de conectar la red local a Azure. Los clientes de todos los tamaños usan métodos como VPN de sitio a sitio y ExpressRoute para ejecutar sus negocios en Azure. ¿Pero qué ocurre cuando el rendimiento no satisface sus expectativas o experiencia anterior? Este artículo te ayuda a estandarizar la forma de realizar pruebas y de establecer una línea base para tu entorno específico.

Aprenderá a probar de forma sencilla y coherente la latencia de red y el ancho de banda entre dos hosts. También recibe consejos sobre las formas de examinar la red de Azure para ayudar a aislar los puntos de problemas. El script y las herramientas de PowerShell descritos requieren dos hosts en la red (en cada extremo del enlace que se está probando). Un host debe ser un Windows Server o escritorio, y el otro host puede ser Windows o Linux.

Componentes de red

Antes de profundizar en la solución de problemas, vamos a analizar algunos términos y componentes comunes. Esta reflexión garantiza que piense en cada componente de la cadena integral que habilita la conectividad en Azure.

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

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

Al examinar el diagrama de derecha a izquierda, se analizará brevemente cada componente:

• Máquina virtual : es posible que el servidor tenga varias NIC. Asegúrese de que las rutas estáticas, las rutas predeterminadas y la configuración del sistema operativo envían y reciben el tráfico de la manera esperada. 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 tráfico está limitado por el ancho de banda disponible para la NIC. Use DS5v2 para realizar pruebas para 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.

• NIC NSG - Puede haber NSG específicos aplicados a nivel de NIC. Asegúrese de que el conjunto de reglas de NSG es adecuado para el tráfico que intenta pasar. Por ejemplo, asegúrese de que los puertos 5201 para iPerf, 3389 para RDP o 22 para SSH están abiertos para permitir que se supere el tráfico de prueba.

• Subred de la red virtual - La NIC está asignada a una subred específica. Asegúrese de saber cuál y las reglas asociadas a esa subred.

• NSG de subred - Al igual que en la NIC, también se pueden aplicar grupos de seguridad de red a nivel de subred. Asegúrese de que el conjunto de reglas de NSG es adecuado para el tráfico que intenta pasar. Para el tráfico entrante a la NIC, primero se aplica el Grupo de Seguridad de Red (NSG) de subred y después el NSG de la NIC. Cuando el tráfico sale de la VM, el NSG de la NIC se aplica primero y, a continuación, el NSG de la subred.

• UDR de subred - Las rutas definidas por el usuario (UDR) pueden dirigir el tráfico a través de un salto intermedio, como un firewall o un equilibrador de carga. Asegúrese de saber si hay una UDR implementada para su tráfico. Si es así, entienda adónde se dirige y cómo afecta ese siguiente salto a su tráfico. Por ejemplo, un firewall podría pasar tráfico y denegar otro tráfico entre los mismos dos hosts.

• Subred de puerta de enlace / NSG / UDR - Al igual que la subred de la máquina virtual, la subred de puerta de enlace puede tener los NSG y las UDR. Asegúrese de saber si están allí y qué efectos tienen en el tráfico.

• Puerta de enlace de VNet (ExpressRoute) - Una vez habilitado el emparejamiento (ExpressRoute) o la VPN, no hay muchas opciones de configuración que puedan afectar a cómo se enruta el tráfico, o incluso si llega a enrutarse. Si tiene una puerta de enlace de red virtual conectada a varios circuitos ExpressRoute o túneles VPN, tenga en cuenta la configuración del peso de la conexión. El peso de la conexión afecta a la preferencia de ruta y determina la trayectoria que toma el tráfico.

• Filtro de rutas (No se muestra): se necesita un filtro de rutas cuando se usa Peering de Microsoft mediante ExpressRoute. Si no recibe ninguna ruta, compruebe si el filtro de ruta está configurado y aplicado correctamente al circuito.

En este momento, se encuentra en la parte WAN del enlace. Este dominio de enrutamiento puede ser el proveedor de servicios, la WAN corporativa o Internet. En estas conexiones intervienen muchos saltos, dispositivos y empresas, lo que puede dificultar el diagnóstico de problemas. Primero debe descartar tanto Azure como las redes corporativas para poder investigar los saltos entre ellos.

En el diagrama anterior, al extremo izquierdo está la red corporativa. Dependiendo del tamaño de su empresa, este dominio de enrutamiento puede ser algunos dispositivos de red entre usted y la WAN o varias capas de dispositivos en un campus o red empresarial.

Dada la complejidad de estos tres entornos de red de alto nivel diferentes, a menudo es óptimo empezar en los bordes e intentar mostrar dónde es bueno el rendimiento y dónde se degrada. Este enfoque puede ayudar a identificar cuál de los tres dominios de enrutamiento es problemático. A continuación, puede centrar la solución de problemas en ese entorno específico.

Herramientas

Puede analizar y aislar la mayoría de los problemas de red mediante herramientas básicas como ping y traceroute. Es raro que necesite profundizar en el análisis de paquetes mediante herramientas como Wireshark.

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

Puede usar un módulo de PowerShell (AzureCT) que encapsula estas herramientas y métodos.

AzureCT: el kit de herramientas de conectividad de Azure

El módulo de PowerShell de AzureCT incluye dos componentes: Availability Testing y Performance Testing. Este artículo se centra en las pruebas de rendimiento, específicamente en los dos comandos de rendimiento de vínculo de este módulo de PowerShell.

Para usar este kit de herramientas para pruebas de rendimiento, siga estos tres pasos básicos:

1. Instalación del módulo de PowerShell

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

   Este comando descarga e instala el módulo de PowerShell localmente.

2. Instalación de las aplicaciones auxiliares

   Install-LinkPerformance
   

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

3. Ejecución de la prueba de rendimiento

   En primer lugar, en el host remoto, instale y ejecute iPerf en modo de servidor. Asegúrese de que el host remoto esté escuchando en el puerto 3389 (RDP para Windows) o en el 22 (SSH para Linux), y de que permita tráfico por el puerto 5201 para iPerf. Si el host remoto está Windows, instale AzureCT y ejecute el comando Install-LinkPerformance para configurar iPerf y las reglas de firewall necesarias.

   Cuando esté 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 simultáneas de carga y latencia para calcular la capacidad de ancho de banda y la latencia del vínculo de red.

4. Revisar la salida de la prueba

   El formato de salida de PowerShell es similar al siguiente:

   

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

Solución de problemas de rendimiento

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 de manera secuencial es más efectivo que las pruebas aleatorias.

1. Desafío de 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 que el tráfico completo de 1 Gbps no sea realista debido a las características de rendimiento de TCP a través de vínculos de latencia alta. Para obtener más información sobre las suposiciones de rendimiento, consulte la sección Referencias.

2. Empiece en el perímetro de la red

   Comience en los bordes entre 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 investigarlo a fondo, ya que esa suposición puede retrasar la resolución.

3. Creación de un diagrama

   Dibuje un diagrama del área en cuestión para trabajar de forma metódica y aislar el problema. Planee puntos de prueba y actualice el mapa a medida que borre las áreas o profundice.

4. Dividir y conquistar

   Segmente la red y restrinja el problema. Identifique dónde funciona y dónde no. Siga moviendo los puntos de prueba para aislar el componente infractor.

5. Tenga en cuenta todas las capas de OSI

   Aunque es habitual centrarse en la red y las capas 1-3 (capas físicas, 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 de problemas avanzadas de ExpressRoute

Aislar Azure componentes puede ser difícil si no está seguro de dónde está el borde de la nube. Con ExpressRoute, el perímetro es un componente de red denominado Microsoft Enterprise Edge (MSEE). El MSEE es el primer punto de contacto en la red de Microsoft y el último salto al salir de él. Al crear una conexión entre la puerta de enlace de red virtual y el circuito ExpressRoute, se conecta al MSEE. Reconocer el MSEE como primer o último salto es fundamental para aislar un problema de red de Azure. Conocer la dirección del tráfico ayuda a determinar si el problema está en Azure o en una posterior bajada en la red WAN o corporativa.

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

Plan de pruebas

1. Ejecute la prueba de Get-LinkPerformance entre VM1 y VM2. Esta prueba proporciona información sobre si el problema es local. Si la prueba genera resultados aceptables de latencia y ancho de banda, puede marcar la red virtual local como buena.

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

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

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

Cuanto más aísle el problema, más rápido podrá encontrar una solución. A veces, llega a un punto en el que no puede seguir adelante con la solución de problemas. Por ejemplo, es posible que vea el enlace de su proveedor de servicios realizando saltos a través de Europa cuando usted espera que se mantenga en Asia. En este momento, póngase en contacto con alguien para obtener ayuda en función del dominio de enrutamiento al que aísle el problema. Reducirlo a un componente específico es aún mejor.

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

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

Para problemas de Azure, una vez que aísle el problema con tanto detalle como sea posible, revise la documentación de red de Azure y, si es necesario, abra una incidencia de soporte técnico.

Referencias

Expectativas de latencia y ancho de banda

Por ejemplo, configura un ExpressRoute en Seattle, Washington, EE. UU. En la tabla siguiente se muestran la latencia y el ancho de banda que observa al realizar pruebas en varias ubicaciones de Azure, junto con las distancias estimadas.

Configuración de prueba:

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

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

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

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

• Todas las pruebas usan el comando azureCT Get-LinkPerformance con una prueba de carga de 5 minutos para cada una de las seis ejecuciones de prueba. Por ejemplo:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• El flujo de datos de cada prueba procede del servidor local (cliente iPerf en Seattle) a la máquina virtual de Azure (servidor iPerf en la región de Azure indicada).

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

• La columna "Ancho de banda máximo" muestra los datos de la prueba de carga de flujo TCP de 16 con un tamaño de ventana de 1 MB.

Resultados de latencia y ancho de banda

* La latencia hacia Brasil es un ejemplo donde la trayectoria de la fibra óptica difiere significativamente de la distancia en línea recta. La latencia esperada es de aproximadamente 160 ms, pero en realidad es de 189 ms debido a la ruta de fibra más larga.

Pasos siguientes

• Descargue Azure Connectivity Toolkit
• Siga las instrucciones para prueba de rendimiento de enlaces