Rendimiento máximo de agregación de enlace (LACP / 802.3ad)


10

Estoy viendo un comportamiento confuso con respecto a las interfaces unidas en Linux y me gustaría presentar la situación con la esperanza de que alguien pueda aclararme la situación.

Tengo dos servidores: el servidor 1 (S1) tiene 4 conexiones de Ethernet de 1 Gbit; El servidor 2 (S2) tiene 2x conexiones de Ethernet de 1 Gbit. Ambos servidores ejecutan Ubuntu 12.04, aunque con el kernel 3.11.0-15 (del paquete lts-saucy linux-generic).

Ambos servidores tienen todas sus interfaces de red respectivas agrupadas en una única interfaz bond0 con la siguiente configuración (en /etc/network/interfaces):

bond-mode 802.3ad
bond-miimon 100
bond-lacp-rate fast
bond-slaves eth0 eth1 [eth2 eth3]

Entre los servidores hay un par de conmutadores HP que (creo) están configurados correctamente para LACP en los puertos en cuestión.

Ahora, el enlace funciona: el tráfico de red fluye alegremente hacia y desde ambas máquinas. Y se están utilizando todas las interfaces respectivas, por lo que no es que la agregación esté fallando por completo. Sin embargo, necesito tanto ancho de banda como sea posible entre estos dos servidores, y no obtengo los ~ 2 Gbit / s que esperaría.

En mis pruebas, puedo observar que cada servidor parece asignar cada conexión TCP (por ejemplo, iperf, scp, nfs, lo que sea) a una única interfaz esclava. Esencialmente, todo parece limitado a un máximo de 1 gigabit.

Al configurar bond-xmit-hash-policy layer3+4, puedo usar iperf -c S1 -P2para enviar en dos interfaces esclavas, pero en el lado del servidor, la recepción todavía solo se produce en una interfaz esclava y, por lo tanto, el rendimiento total se limita a 1 Gbit / s, es decir, el cliente muestra ~ 40-50MB / s en dos interfaces esclavas, el servidor muestra ~ 100MB / s en una interfaz esclava. Sin configurar bond-xmit-hash-policyel envío también se limita a una interfaz esclava.

Tenía la impresión de que LACP debería permitir este tipo de agrupación de conexiones, permitiendo, por ejemplo, una sola transferencia scp para utilizar todas las interfaces disponibles entre los dos hosts.

¿Está mal mi comprensión de LACP? ¿O me he perdido algunas opciones de configuración en alguna parte? ¡Cualquier sugerencia o pista para la investigación sería muy apreciada!

Respuestas:


18

Una explicación rápida y sucia es que una sola línea de comunicación usando LACP no dividirá los paquetes en múltiples interfaces. Por ejemplo, si tiene una sola conexión TCP que transmite paquetes de HostA a HostB, no abarcará las interfaces para enviar esos paquetes. Últimamente he estado buscando mucho en LACP aquí para encontrar una solución en la que estamos trabajando y este es un error común de que 'vincular' o 'truncar' múltiples interfaces de red con LACP le brinda un "rendimiento" de las interfaces combinadas. Algunos proveedores han creado controladores propietarios que se enrutarán a través de múltiples interfaces, pero el estándar LACP no se desprende de lo que he leído. Aquí hay un enlace a un diagrama decente y una explicación que encontré en HP mientras buscaba problemas similares: http://www.hp.com/rnd/library/pdf/59692372.pdf


1
Todo eso tiene sentido. No tengo idea de por qué no había descubierto mi error antes; Debo haber estado bordeando los términos de búsqueda correctos y las páginas de documentación. Parece que, dependiendo del hardware de la red, podríamos cambiar el modo de hash src-dest y tener suerte con el rendimiento de múltiples interfaces, pero creo que en esta etapa estaré contento con lo que tenemos. Gracias por sus aclaraciones y el enlace muy útil.
Zetten el

Encantado de ayudar. He estado leyendo mucho sobre esto últimamente tratando de obtener una aclaración sobre la terminología relacionada con el enlace troncal y la vinculación que los diferentes proveedores usan de manera diferente. Descubrí que fuera de los estándares específicos, como los definidos por los proveedores de IEEE, tienden a usar algunos términos de manera intercambiable ...
Mike Naylor

66
El documento ya no está disponible en la URL original, pero aún se puede acceder a través de Internet Archive: web.archive.org/web/20030324105208/http://www.hp.com/rnd/…
smbear

3

bond-xmit-hash-policy layer3+4establece el equilibrio de carga de su servidor de origen al conmutador. No establece el algoritmo de equilibrio de carga de su conmutador al segundo servidor. Es casi seguro que todavía está equilibrado en la capa 2 o la capa 3, es decir, en absoluto.


2

Bueno, en primer lugar, cuando está usando un controlador de equipo, eso creará algunos gastos generales y reducirá el rendimiento máximo esperado, que es de ~ 940 MB / s en un adaptador de 1 GB, en ~ 10%.

No estoy seguro de qué tipo de adaptador tiene, pero si está utilizando controladores integrados, la configuración probablemente no sea ideal para un rendimiento máximo. podría considerar agregar colas, hasta 4, ya que una sola cola en el adaptador probablemente no puede alcanzar la velocidad de cable.

Otra consideración es que un subproceso de iperf probablemente no obtendrá las velocidades máximas. Para 1GB, 2-6 hilos probablemente sea más ideal, puede usar un script bash simple para lanzar múltiples hilos al mismo tiempo.

Para una NIC Intel, pero RSS y RSC de hardware pueden afectar el rendimiento, en Broadcom asegúrese de que TOE esté funcionando.

Sin embargo, el primer paso sería eliminar los LAG e intentar probar 1 puerto de tráfico en cada sistema para ver cuánto rendimiento obtiene, hacer esto con todos los puertos, luego probar 2. LACP es una bestia voluble para configurar bien, y nunca he intentado configurarlo en un conmutador HP, solo Force10 (anterior a Dell).

Además, ¿por qué hay un par de interruptores?


Como se describió en la otra respuesta, el problema subyacente era mi comprensión de LACP, pero solo para completar la imagen: las cajas de Linux están utilizando el controlador de enlace del núcleo. Cada interfaz individualmente puede impulsar un rendimiento de casi el máximo de gigabits (aparentemente alrededor de 110-117MB / s dependiendo de otro tráfico), así que realmente solo estaba buscando aumentar ese ancho de banda en lugar de ajustar las NIC individuales. En cuanto a los conmutadores, tenemos un sitio de varias oficinas y hay conmutadores de enlace troncal con fibra mux / demux y varios otros bits y bobs en el camino. Sin embargo, tenía ambos servidores en un conmutador HP 2920-48G para probar.
Zetten el

iperf tiene un --parallelparámetro que controla la cantidad de flujos de clientes paralelos a ejecutar
8.8.8.8
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.