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 correctamente 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 puede ayudar a estandarizar la forma de probar y establecer la línea base de su 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 recibirá 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 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 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 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 tráfico de la manera que cree que es. 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. Se recomienda usar 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.

• NSG de NIC - Puede haber grupos de seguridad de red (NSG) específicos aplicados a nivel de NIC. Asegúrese de que el conjunto de reglas de NSG sea 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.

• VNet Subnet: 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 la NIC, los NSG también se pueden aplicar en el 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 máquina virtual, primero se aplica el NSG de la NIC y luego se aplica el NSG de la subred.

• UDR de subred: las Rutas Definidas por el Usuario pueden dirigir el tráfico a un punto 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í, comprenda dónde va y qué hará el siguiente salto en 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 NSG y UDR. Asegúrese de saber si están allí y qué efectos tienen en el tráfico.

• Puerta de enlace de red virtual (ExpressRoute): una vez que el peering (ExpressRoute) o VPN está habilitado, no hay muchas configuraciones que puedan afectar la forma en que se enruta el tráfico o si se enruta. Si tiene una puerta de enlace de red virtual 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 ruta y determina la trayectoria que toma el tráfico.

• Filtro de ruta (no se muestra): se necesita 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 momento, se encuentra en la parte WAN del enlace. Este dominio de enrutamiento puede ser el proveedor de servicios, la WAN corporativa o Internet. Hay muchos saltos, dispositivos y empresas implicados en estos vínculos, lo que podría dificultar la solución 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 una red de campus o empresa.

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

La mayoría de los problemas de red se pueden analizar y aislar 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.

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

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 documento se centra en las pruebas de rendimiento, específicamente en los dos comandos link Performance de este módulo de PowerShell.

Estos son los tres pasos básicos para usar este kit de herramientas para pruebas de rendimiento:

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 3389 (RDP para Windows) o 22 (SSH para Linux) y permita el tráfico en 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.

   Una vez que la máquina remota esté lista, 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:

   Captura de pantalla de la salida de PowerShell de la prueba de rendimiento del enlace.

   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 .

Solución de problemas

Si los resultados de las pruebas 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íe 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. Consulte la sección Referencias para obtener más información sobre las suposiciones de rendimiento.

2. Comience 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 el proceso sin una investigación exhaustiva, ya que esto 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, y siga moviendo los puntos de prueba para aislar el componente infractor.

5. Tenga en cuenta todas las capas de OSI

   Aunque centrarse en la red y las capas 1-3 (capas físicas, de datos y de red) es común, 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.

Diagrama de varias redes virtuales conectadas a un circuito ExpressRoute.

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 se puede encontrar la solución. A veces llega a un punto en el que no puede seguir 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.

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 tus resultados basándose en el principio de "confianza, pero verifica".

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, configuramos un ExpressRoute en Seattle, Washington, EE. UU. En la tabla siguiente se 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 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 usaron 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 fue 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.

Diagrama del entorno de prueba en el que está instalado AzureCT.

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 sería de aproximadamente 160 ms, pero realmente 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