Probar latencia de switch con Ethernet 10 Gigabit: Qué debemos buscar
Probar la latencia de switch con Ethernet de 10 gigabits requiere elegir adecuados switches y herramientas de prueba y recrear correctamente el flujo.
Con los precios decididamente bajando desde la estratosfera, los switches de Ethernet de 10 Gigabit (GbE) se están volviendo viables para implementaciones más extensas en las empresas. El ancho de banda bruto disponible no tiene precedentes: un solo puerto ofrece una capacidad bruta de 1.000 enlaces originales de Ethernet de 10 Mbps. Pero a medida que las empresas consideran la implementación, notarán que será fundamental no sólo probar el rendimiento, sino también la latencia de los switches de 10 GbE. No importa qué potencia tenga el switch; una latencia alta puede matar toda su utilidad.
¿Qué es la latencia de switch de Ethernet de 10 Gigabits?
Latencia es simplemente otra forma de decir demora. Con relación a los switches, nos preocupa esencialmente cuánto tiempo permanecerá un paquete de datos en el switch desde su entrada hasta su salida. Naturalmente, esta demora se agrega a la que ocurre en puntos de la red entre el usuario final y la aplicación destino.
| Para el usuario final, la latencia se traduce en un mayor tiempo de espera. Dada la capacidad inherente de los switches de 10 GbE, un switch determinado probablemente estará dando servicio a un número bastante grande de usuarios. Por tal razón, un solo switch tiene el potencial de volverse un gran cuello de botella para su organización. |
¿Qué causa la latencia en los switches de Ethernet de 10 Gigabit?
La latencia de un switch de red puede ser causada por una diversidad de factores generalmente asociados, directa o indirectamente, con la arquitectura interna del switch. En algún punto, un recurso queda limitado y los paquetes de datos se detienen esperando en búferes para acceder a ese recurso. El reloj sigue avanzado, y su resultado es la latencia.
Los switches de gama alta suelen realizar mucho más que simplemente conmutar los paquetes en la capa 2. Muchos switches de 10 GbE ofrecen conmutación en capas de la 4 a la 7, lo que requiere una inspección más profunda del contenido del paquete. En muchos casos, esto es acompañado por descarga SSL.
La carga criptográfica del procesamiento SSL puede drenar la potencia de procesamiento de un switch y aumentar su latencia. Por esta razón, algunos proveedores llevan a cabo una descarga de las funcionalidades SSL de su hardware, buscando así mejorar el rendimiento general. Los proveedores también pueden implementar una arquitectura distribuida dentro del switch para evitar los cuellos de botella que incrementan la latencia.
Modos de conmutación: Cortar vs. Almacenar-y-enviar
Los switches están diseñados para procesar el tráfico de acuerdo a las normas, pero no existe un estándar para el diseño del switch. Incluso con el mismo proveedor, los switches pueden variar en diseño porque no es raro que un vendedor fabrique sus propios switches de alta gama pero también le ponga su marca a un switch de otro proveedor para venderlo como un producto de gama inferior, por ejemplo.
Si usted estaba implementando LANs conmutadas a comienzos de los 90, seguro recordará la llamada "guerra de arquitectura" que estalló con respecto a si la mejor arquitectura para los switches era "cortar" o "almacenar y enviar". Los switches que cortan empiezan desviando el paquete hacia la ruta de salida en cuanto tienen suficiente información para identificar ese camino, lo que normalmente sucederá antes de que los datos de todo el paquete hayan terminado de llegar al puerto de entrada. En contrapartida, los switches que almacenan y reenvían, esperan hasta que llegue el paquete de datos completo antes de comenzar la transferencia hacia la ruta correspondiente.
Pese a que durante mucho tiempo no vi más alusiones a estas arquitecturas (“almacenar y enviar” se convirtió en el método estándar), algunos proveedores, en los últimos años, han estado defendiendo las ventajas del corte de datos. El más notorio de ellos fue Cisco, cuyo switch de centro de datos Nexus 5000 está identificado como uno que utiliza una arquitectura de corte.
Teóricamente, la arquitectura de corte puede reducir la latencia, especialmente para los paquetes más grandes, porque (suponiendo que el switch no necesitara hacer una inspección profunda de los datos) logra que el viaje de salida de los datos arranque antes de lo que lo haría en un escenario de almacenar-y-enviar. Pero hay que ser cautos: el beneficio puede ser sólo académico si la mejora va a ser de sólo de unos pocos microsegundos.
Simulación de carga de tráfico para probar la latencia del switch de Ethernet de 10 Gigabit
La latencia puede ser medida rápidamente y con precisión mediante herramientas comerciales de prueba de switches, tales como las ofrecidas por Ixia y Spirent Communications. Entonces, por fortuna las pruebas básicas no resultan un problema. No obstante, el desafío está en que la obtención de una medición válida y útil de latencia deberá realizarse cuando el switch se halle bajo carga.
Y más importante aún: la carga utilizada para la prueba deberá ser representativa del perfil de tráfico y carga que se espera tener una vez que el switch esté funcionando. Por ejemplo, los resultados de pruebas de latencia cuando el switch está reenviando tráfico no cifrado de capa 7 podrán indicarle muy poco acerca de la latencia del switch cuando tenga que manejar transacciones SSL.
Por fortuna, en la actualidad los generadores de tráfico son muy sofisticados y usted puede configurar fácilmente su arnés de prueba para generar flujos de tráfico multiprotocolo que reflejen su entorno real. Las estadísticas de los actuales engranajes de red, o incluso el monitoreo la red existente con un humilde analizador de red como Wireshark, pueden proporcionarle la información que necesita para entender las características del protocolo y la carga, sirviendo como punto de partida en su evaluación comparativa.
El tamaño más allá del tipo de tráfico para evaluar un switch
El tipo de tráfico no es la única variable crítica cuando se realiza una evaluación comparativa de latencia. Lo más importante es el tamaño del objeto. Una porción de datos de 64 bytes seguramente irá más rápido a través de un dispositivo y por lo tanto con menor latencia que la de una porción de 8 Kbytes. Por lo tanto, el tamaño del objeto siempre debe ser conocido. Una vez más, las estadísticas de la red existente le proporcionarán la información sobre los tamaños más comunes de los objetos en la red. Y no es de sorprender que los proveedores que quieren demostrar la menor latencia posible ejecuten invariablemente la prueba con objetos de datos de 64 bytes.
Pruebas con conexiones simultáneas
Por último, debe medirse la latencia cuando un sistema está ejecutando una cantidad de conexiones simultáneas y las tasas de activación/desactivación de las sesiones sean las relevantes para su entorno. Todos estos diversos factores de carga afectarán la latencia y con ello la calidad de la experiencia que tendrán los usuarios finales.
En los próximos artículos analizaré cómo lidiar con situaciones en las que la potencia de su herramienta de prueba no sea suficiente para llevar al máximo a su switch central. Y echaré un vistazo a los elementos claves para evaluar los switches de periferia donde el ancho de banda y el rendimiento se convierten en problemas muy diferentes al de los switches centrales.
Sobre el autor: Kevin Tolly es presidente y CEO del grupo Tolly, un laboratorio independiente de pruebas y una empresa de investigación que publica una serie de estrategias de pruebas de redes llamada Tolly Common Test Plan. Puede obtener más información sobre los informes de The Tolly Group en Tolly Common Test Plan.
