ASIC vs x86 enrutamiento / conmutación de propósito general


14

Los administradores de sistemas a menudo intentan convencerme de que los sistemas operativos x86 de propósito general pueden funcionar tan bien como los enrutadores con CPU de bajo MHz y silicio dedicado (es decir, ASIC) a velocidades de línea de 1 Gbps. Este pensamiento se está trasladando al ámbito SDN, como los conmutadores virtuales en VMWare.

Creo que entiendo intuitivamente las diferencias entre los beneficios de los ASIC frente a x86 en el manejo del tráfico, particularmente con respecto a los microbursts. ¿Es correcto suponer que los ASIC para las interfaces de enrutador o conmutador superarán el uso de una CPU x86 para todo el procesamiento de paquetes que sufrirá en gran medida las interrupciones de la CPU? Sé que el sistema operativo (Windows, Linux o especializado) contribuye en gran medida al rendimiento del hardware para enrutar o cambiar también. Y sé que las velocidades de bus x86 imponen máximos teóricos al ancho de banda de conmutación, especialmente una vez que las velocidades superan los 1 Gbps.

  1. ¿Cómo se compara la velocidad de conmutación Catalyst 6500 Sup2T ASIC, por ejemplo, con las velocidades de conmutación x86 realistas que se encuentran en sistemas operativos generales o SDN?

  2. ¿Cómo se compara la velocidad de conmutación Cisco 7200VXR-NPE-G2, por ejemplo, con la misma ...

  3. ¿Cómo se comparan las latencias típicas de enrutadores o conmutadores con sistemas operativos generales que realizan la misma función?

NOTA: No quiero escuchar los méritos de la ubicación del conmutador virtual o su función dentro de una red virtual y física. Tampoco quiero debatir los méritos de SDN para el tiempo de implementación de la aplicación.

Respuestas:


19

¿Es correcto suponer que los ASIC para las interfaces de enrutador o conmutador superarán el uso de una CPU x86 para todo el procesamiento de paquetes que sufrirá en gran medida las interrupciones de la CPU?

Es difícil decir específicamente si las interrupciones son una limitación, ya que no estamos nombrando modelos específicos de CPU, sistema operativo o enrutador en esta parte de su pregunta. En general, es una generalización segura que las CPU de uso general no pueden afectar el rendimiento de conmutación de paquetes de un ASIC bien diseñado. Cuando digo rendimiento, me refiero a las métricas de RFC 2544 , como la tasa de reenvío de paquetes por segundo (NDR), el rendimiento y la latencia sin caída.

Eso no quiere decir que no haya lugar para un enrutador basado en CPU; solo que nuestras experiencias de vida nos dicen que una CPU no puede cambiar paquetes tan rápido como un ASIC o FPGA. Mi conclusión acerca de que los ASIC / FPGA son más rápidos que una CPU multinúcleo parece verse reforzada por este Q&A en Electronics.SE .

Rendimiento del bus PCI

Sé que las velocidades de bus x86 imponen máximos teóricos para el ancho de banda de conmutación, especialmente una vez que las velocidades superan los 1 Gbps.

No estoy seguro de a qué restricciones de autobús se refiere aquí, pero la información que tiene podría estar algo desactualizada. El bus PCI Express utilizado en la mayoría de los sistemas escala mucho más de 10 Gbps en estos días.

PCIe 2.0 utiliza un esquema de codificación 8b / 10b que lo penaliza aproximadamente un 20% por la sobrecarga de codificación del carril PCI; antes de esa penalización de codificación, PCIe 2.0 ofrece 4 Gbps de ancho de banda sin procesar por carril. Sin embargo, incluso con el 20% de penalización 8b / 10b, PCIe 2.0 x8 (8 carriles PCIe) exprime más de 25 Gbps; por lo tanto, puede ejecutar fácilmente un solo adaptador 10GE a velocidad de línea bidireccional en una tarjeta PCIe 2.0 x8.

PCIe 3.0 (utilizado en los conjuntos de chips Intel Ivy Bridge) utiliza una codificación de 128b / 130b, lo que mejora en gran medida la eficiencia del bus PCI y duplica el ancho de banda por carril. Por lo tanto, una tarjeta PCIe 3.0 x8 podría entregar 63Gbps (8.0 * 8 * 128/132). Esto no es nada para estornudar; puede empacar de manera segura dos 10GE de velocidad de línea en un solo elevador con esas tasas de rendimiento.

Rendimiento de Cisco vs Vyatta

Advertencia: estoy usando material de marketing proporcionado por el proveedor para todas las comparaciones ...

  1. ¿Cómo se compara la velocidad de conmutación Catalyst 6500 Sup2T ASIC, por ejemplo, con las velocidades de conmutación x86 realistas que se encuentran en sistemas operativos generales o SDN?

Esto es un poco desafiante porque vamos a comparar un sistema de conmutación completamente distribuido (Sup2T) con un sistema de conmutación centralizado (Vyatta), así que tenga cuidado al interpretar los resultados.

  • Sup2T puede reenviar a una velocidad de hasta 60Mpps sin caída con funciones habilitadas . Referencia: Libro Blanco sobre la arquitectura Catalyst 6500 Sup2T . Tenga en cuenta que este es solo un sistema Sup2T sin tarjetas de reenvío distribuido (DFC). Nota 1
  • He encontrado los resultados de la prueba RFC 2544 para el reenvío de Vyatta 5600 a una velocidad de no caída de hasta 20.58Mpps y 70Mpps si puede aceptar algunas caídas. El rendimiento de NDR fue de 72 Gbps. Referencia: Vyatta 5600 vRouter Performance Test (SDN Central) . Es necesario registrarse en SDN Central para ver el informe completo.
  1. ¿Cómo se compara la velocidad de conmutación Cisco 7200VXR-NPE-G2, por ejemplo, con la misma ...

El Vyatta sopla un NPE-G2 fuera del agua, en cuanto al rendimiento; el NPE-G2 puede hacer hasta 2Mpps según la hoja de datos de Cisco NPE-G2 . Sin embargo, esa no es una comparación justa dada la antigüedad del NPE-G2, frente a un nuevo sistema Intel 10-Core repleto de tarjetas 10GE.

¿Cómo se comparan las latencias típicas de enrutadores o conmutadores con sistemas operativos generales que realizan la misma función?

Esa es una pregunta fantástica. Este documento indica que Vyatta tiene latencias más altas, pero me gustaría ver este tipo de pruebas realizadas con las CPU de la serie Intel E5.

Resumen

Resumen de una comparación lado a lado de Sup2T vs Brocade Vyatta 5600:

  • Sup2T: 60Mpps NDR IPv4 con características (como ACL)
  • Vyatta e Intel E5: hasta 20Mpps IPv4 NDR sin características , o 70Mpps si puede aceptar pequeñas cantidades de gotas.

El Sup2T sigue ganando en mi opinión, particularmente cuando miras lo que obtienes con el Sup2T (escala distribuida a 720Mpps, MPLS, innumerables MIB, conmutación Layer2 y Layer3, etc.).

Si lo único que le importa es el rendimiento de conmutación sin formato, puede obtener números de rendimiento respetables de una CPU x86. Sin embargo, en redes reales, a menudo no se trata solo de quién tiene los mejores números de carreras de resistencia; la mayoría de las personas deben preocuparse por las funciones (consulte: ¿ Cuándo debería centrarme en cada valor para la evaluación del cambio? ). Un factor importante a considerar es la cantidad de funciones disponibles y cómo se integran con el resto de su red.

También vale la pena ver la viabilidad operativa del uso de sistemas basados ​​en x86 en su empresa. No he usado Brocade + Vyatta yo mismo, pero podrían hacer un trabajo decente creando buenos comandos de show y ganchos de soporte en la caja. Si realmente admiten suficientes funciones y su sistema se escala bien en redes reales , entonces, si eso es lo que desea, hágalo.

Sin embargo, si alguien sale barato y solo construye una caja de Linux + bird/ quagga+ ACLs + qos, no me gustaría ser el tipo que respalde esa solución. Siempre he sostenido que la comunidad de código abierto hace un gran trabajo innovando, pero la capacidad de soporte de sus sistemas palidece en comparación con los proveedores de red convencionales (Arista / Cisco / Force10 / Juniper). Solo hay que mirar iptablesy tcver cuán complicado puede hacer una CLI. De vez en cuando respondo preguntas de personas que miran la salida de ip link showo ifconfigy se sorprenden porque los contadores de paquetes no son correctos; Por lo general, los principales proveedores de red realizan un trabajo mucho mejor probando sus contadores, en comparación con lo que veo en los controladores NIC de Linux.


Notas finales :

Nota 1 Nadie a quien le importe el rendimiento compraría un Sup2T y no podría llenar el chasis con DFC. El Sup2T puede cambiar a 60Mpps, pero un chasis cargado con DFC escala a 720Mpps.

Nota 2 La prueba de Vyatta se ejecutó en Intel E5-2670v2 de 10 núcleos y doble procesador a 2.5Ghz por núcleo; si contamos un solo núcleo como dos núcleos virtuales (es decir, hiperprocesamiento), eso es un total de 40 núcleos para la conmutación de paquetes. El Vyatta se configuró con NIC Intel x520-DA2 y utilizó Brocade Vyatta versión 3.2.


1
¿Sabes cuáles eran los tamaños de los cuadros en esas figuras? El resumen ejecutivo de Vyatta dijo que alcanzaron 70Mpps con marcos de 64B; Cuál es el mismo tamaño de cuadro utilizado en las pruebas Sup2T?
Ryan Foley

0

La serie 7200 está en desuso en favor de la serie ASR porque no pueden manejar la conmutación multigigabit de velocidad de línea. Los catalizadores y los conmutadores Nexus tienen una ventaja de reenvío sobre un procesador de propósito general SI la conmutación de paquetes permanece en silicio. Si el tráfico debe cambiarse por proceso (es decir, debe evaluarse en la CPU en lugar de en el ASIC / FPGA), su rendimiento se desploma y la latencia aumenta. Por esta razón, si necesita una conmutación de alto rendimiento, separe el plano de reenvío del plano de enrutamiento y optimice para mantener la mayor cantidad posible de su conmutación en silicio.

En algunos casos, verá un silicio de conmutación de propósito especial unido a un procesador de propósito general (como los interruptores de caja blanca destinados a usar Big Switch u otro SDN para la parte superior del rack, distribución o superposición), y en estos casos, puede ver lo mejor de todos los mundos (alto rendimiento, conmutación de baja latencia; procesamiento de alta potencia para la determinación de rutas y políticas; integración con marcos de gestión como Puppet o Chef).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.