¿Cómo funciona exactamente y específicamente el hashing de direcciones de destino de capa 3 LACP?

Basado en una pregunta anterior hace más de un año (¿ Multiplexed 1 Gbps Ethernet? ), Salí y configuré un nuevo rack con un nuevo ISP con enlaces LACP por todo el lugar. Necesitamos esto porque tenemos servidores individuales (una aplicación, una IP) que sirven a miles de computadoras cliente en todo Internet por encima de 1 Gbps acumulativo.

Se supone que esta idea de LACP nos permite romper la barrera de 1 Gbps sin gastar una fortuna en conmutadores 10GoE y NIC. Desafortunadamente, me he encontrado con algunos problemas relacionados con la distribución del tráfico saliente. (Esto a pesar de la advertencia de Kevin Kuphal en la pregunta vinculada anterior).

El enrutador del ISP es un Cisco de algún tipo. (Lo deduje de la dirección MAC). Mi switch es un HP ProCurve 2510G-24. Y los servidores son HP DL 380 G5 con Debian Lenny. Un servidor es un hot standby. Nuestra aplicación no se puede agrupar. Aquí hay un diagrama de red simplificado que incluye todos los nodos de red relevantes con IP, MAC e interfaces.

Si bien tiene todos los detalles, es un poco difícil trabajar y describir mi problema. Entonces, por simplicidad, aquí hay un diagrama de red reducido a los nodos y enlaces físicos.

Así que me fui e instalé mi kit en el nuevo bastidor y conecté el cableado de mi ISP desde su enrutador. Ambos servidores tienen un enlace LACP a mi conmutador, y el conmutador tiene un enlace LACP al enrutador ISP. Desde el principio me di cuenta de que mi configuración de LACP no era correcta: las pruebas mostraron que todo el tráfico hacia y desde cada servidor estaba yendo a través de un enlace GoE físico exclusivamente entre el servidor para cambiar y el interruptor para enrutador.

Con algunas búsquedas en Google y mucho tiempo RTMF con respecto a la vinculación NIC de Linux, descubrí que podía controlar la vinculación NIC modificando /etc/modules

# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1

loop

Esto hizo que el tráfico saliera de mi servidor a través de ambas NIC como se esperaba. Pero el tráfico se movía del conmutador al enrutador a través de un solo enlace físico, aún .

Necesitamos que el tráfico pase por ambos enlaces físicos. Después de leer y releer la Guía de administración y configuración del 2510G-24 , encuentro:

[LACP usa] pares de direcciones de origen-destino (SA / DA) para distribuir el tráfico saliente a través de enlaces troncalizados. SA / DA (dirección de origen / dirección de destino) hace que el conmutador distribuya el tráfico saliente a los enlaces dentro del grupo troncal en función de los pares de direcciones de origen / destino. Es decir, el conmutador envía tráfico desde la misma dirección de origen a la misma dirección de destino a través del mismo enlace troncalizado, y envía tráfico desde la misma dirección de origen a una dirección de destino diferente a través de un enlace diferente, dependiendo de la rotación de las asignaciones de ruta entre Enlaces en el maletero.

Parece que un enlace enlazado presenta solo una dirección MAC y, por lo tanto, mi ruta de servidor a enrutador siempre va a estar sobre una ruta de conmutador a enrutador porque el conmutador ve solo una MAC (y no dos, una de cada puerto) para ambos enlaces LACP'd.

Entendido. Pero esto es lo que quiero:

Un conmutador HP ProCurve más costoso es el 2910al que utiliza direcciones de origen y destino de nivel 3 en su hash. De la sección "Distribución de tráfico saliente a través de enlaces troncales" de la Guía de administración y configuración de ProCurve 2910al :

La distribución real del tráfico a través de una troncal depende de un cálculo que utiliza bits de la dirección de origen y la dirección de destino. Cuando hay una dirección IP disponible, el cálculo incluye los últimos cinco bits de la dirección IP de origen y la dirección IP de destino; de lo contrario, se usan las direcciones MAC.

OKAY. Entonces, para que esto funcione de la manera que quiero, la dirección de destino es la clave, ya que mi dirección de origen es fija. Esto lleva a mi pregunta:

¿Cómo funciona exactamente y específicamente el hashing de capa 3 LACP?

Necesito saber qué dirección de destino se utiliza:

• la IP del cliente , ¿el destino final?
• O la IP del enrutador , el próximo destino de transmisión del enlace físico.

No nos hemos apagado y comprado un interruptor de reemplazo todavía. Ayúdame a comprender exactamente si el hashing de la dirección de destino de LACP de capa 3 es o no lo que necesito. Comprar otro interruptor inútil no es una opción.

Lo que está buscando se denomina comúnmente "política de hash de transmisión" o "algoritmo de hash de transmisión". Controla la selección de un puerto de un grupo de puertos agregados con los que transmitir una trama.

Tener en mis manos el estándar 802.3ad ha resultado difícil porque no estoy dispuesto a gastar dinero en él. Dicho esto, he podido obtener información de una fuente semioficial que arroja algo de luz sobre lo que está buscando. Según esta presentación del Grupo de Estudio de Alta Velocidad 2007 IEEE de Ottawa, ON, CA que cumple con el estándar 802.3ad no exige algoritmos particulares para el "distribuidor de trama":

Este estándar no exige ningún algoritmo de distribución particular; sin embargo, cualquier algoritmo de distribución debe garantizar que, cuando un Frame Collector recibe los marcos como se especifica en 43.2.3, el algoritmo no debe causar a) Ordenamiento incorrecto de los marcos que forman parte de una conversación dada, o b) Duplicación de marcos . El requisito anterior para mantener el orden de trama se cumple asegurando que todas las tramas que componen una conversación dada se transmitan en un solo enlace en el orden en que son generadas por el Cliente MAC; por lo tanto, este requisito no implica la adición (o modificación) de ninguna información a la trama MAC, ni ningún almacenamiento intermedio o procesamiento por parte del recopilador de tramas correspondiente para reordenar las tramas.

Por lo tanto, cualquier algoritmo que use un interruptor / controlador NIC para distribuir tramas transmitidas debe cumplir con los requisitos establecidos en esa presentación (que, presumiblemente, estaba citando el estándar). No se especifica un algoritmo particular, solo se define un comportamiento conforme.

Aunque no hay un algoritmo especificado, podemos ver una implementación particular para tener una idea de cómo podría funcionar dicho algoritmo. El controlador de "vinculación" del kernel de Linux, por ejemplo, tiene una política de hash de transmisión compatible con 802.3ad que aplica la función (consulte bonding.txt en el directorio Documentation \ network del origen del kernel):

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

Esto hace que las direcciones IP de origen y destino, así como las direcciones MAC de origen y destino, influyan en la selección del puerto.

La dirección IP de destino utilizada en este tipo de hashing sería la dirección que está presente en el marco. Tómate un segundo para pensar en eso. La dirección IP del enrutador, en un encabezado de trama Ethernet lejos de su servidor a Internet, no está encapsulada en ningún lugar de dicha trama. La dirección MAC del enrutador está presente en el encabezado de dicho marco, pero la dirección IP del enrutador no. La dirección IP de destino encapsulada en la carga útil del marco será la dirección del cliente de Internet que realiza la solicitud a su servidor.

Una política de hash de transmisión que tenga en cuenta las direcciones IP de origen y de destino, suponiendo que tenga un grupo muy variado de clientes, debería funcionar bastante bien para usted. En general, las direcciones IP de origen y / o destino más variadas en el tráfico que fluye a través de dicha infraestructura agregada resultarán en una agregación más eficiente cuando se utiliza una política de hash de transmisión basada en la capa 3.

Sus diagramas muestran solicitudes que llegan directamente a los servidores desde Internet, pero vale la pena señalar qué podría hacer un proxy ante la situación. Si está enviando solicitudes de clientes a sus servidores, entonces, como Chris habla en su respuesta , puede causar cuellos de botella. Si ese proxy realiza la solicitud desde su propia dirección IP de origen, en lugar de hacerlo desde la dirección IP del cliente de Internet, tendrá menos "flujos" posibles en una política de hash de transmisión basada estrictamente en la capa 3.

Una política de hash de transmisión también podría tener en cuenta la información de la capa 4 (números de puerto TCP / UDP), siempre que se mantenga con los requisitos del estándar 802.3ad. Tal algoritmo está en el kernel de Linux, como se menciona en su pregunta. Tenga en cuenta que la documentación de ese algoritmo advierte que, debido a la fragmentación, el tráfico puede no necesariamente fluir a lo largo de la misma ruta y, como tal, el algoritmo no es estrictamente compatible con 802.3ad.

Sorprendentemente, hace unos días nuestras pruebas mostraron que xmit_hash_policy = layer3 + 4 no tendrá ningún efecto entre dos servidores Linux directamente conectados, todo el tráfico utilizará un puerto. ambos ejecutan xen con 1 puente que tiene el dispositivo de enlace como miembro. Obviamente, el puente podría causar el problema, solo que no tiene sentido en absoluto considerando que se usaría el hash basado en el puerto ip +.

Sé que algunas personas realmente logran empujar 180MB + sobre enlaces enlazados (es decir, usuarios de ceph), por lo que funciona en general. Posibles aspectos a tener en cuenta: - Utilizamos CentOS 5.4 antiguo. - El ejemplo de OP significaría que el segundo LACP "desenreda" las conexiones. ¿Tiene sentido eso alguna vez?

Lo que este hilo y la lectura de documentación, etc., etc. me han mostrado:

• En general, todo el mundo sabe mucho sobre esto, es bueno para recitar la teoría de la guía de vinculación o incluso los estándares IEEE, mientras que la experiencia práctica es casi nula.
• La documentación de RHEL está incompleta en el mejor de los casos.
• La documentación de la vinculación es de 2001 y no es lo suficientemente actualizada.
• El modo layer2 + 3 aparentemente no está en CentOS (no se muestra en modinfo y, en nuestra prueba, eliminó todo el tráfico cuando estaba habilitado)
• No ayuda que SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) y RedHat (BONDING_OPTS) tengan diferentes formas de especificar la configuración del modo por enlace
• El módulo de kernel CentOS / RHEL5 es "seguro para SMP" pero no "compatible con SMP" (vea la charla de alto rendimiento de Facebook): NO escala por encima de una CPU, por lo que al vincular un reloj de CPU superior> muchos núcleos

Si alguien termina con una buena configuración de enlace de alto rendimiento, o realmente sabe de lo que está hablando, sería increíble si se tomara media hora para escribir un nuevo pequeño tutorial que documente UN ejemplo de trabajo usando LACP, sin cosas extrañas y ancho de banda > un enlace

Si su conmutador ve el verdadero destino L3, puede tener problemas con eso. Básicamente, si tiene 2 enlaces, piense que el enlace 1 es para destinos impares, el enlace 2 es para destinos pares. No creo que alguna vez usen la IP del siguiente salto a menos que estén configurados para hacerlo, pero eso es más o menos lo mismo que usar la dirección MAC del objetivo.

El problema con el que se encontrará es que, dependiendo de su tráfico, el destino siempre será la única dirección IP del servidor único, por lo que nunca usará ese otro enlace. Si el destino es el sistema remoto en Internet, obtendrá una distribución uniforme, pero si es algo así como un servidor web, donde su sistema es la dirección de destino, el conmutador siempre enviará tráfico a través de solo uno de los enlaces disponibles.

Estará en peor forma si hay un equilibrador de carga en algún lugar, porque la IP "remota" siempre será la IP del equilibrador de carga o el servidor. Podría evitarlo un poco utilizando muchas direcciones IP en el equilibrador de carga y el servidor, pero eso es un truco.

Es posible que desee ampliar un poco su horizonte de proveedores. Otros proveedores, como las redes extremas, pueden analizar cosas como:

Algoritmo L3_L4: Capa 3 y Capa 4, las direcciones IP de origen y destino combinadas y los números de puerto TCP y UDP de origen y destino. Disponible en los conmutadores de las series SummitStack y Summit X250e, X450a, X450e y X650.

Entonces, básicamente, siempre que cambie el puerto de origen del cliente (que generalmente cambia mucho), distribuirá uniformemente el tráfico. Estoy seguro de que otros proveedores tienen características similares.

Incluso el hash en la IP de origen y destino sería suficiente para evitar puntos calientes, siempre y cuando no tenga un equilibrador de carga en la mezcla.

Supongo que está fuera de la IP del cliente, no del enrutador. Las IP de origen y destino reales estarán en un desplazamiento fijo en el paquete, y será rápido hacer hashing. Hashing la dirección IP del enrutador requeriría una búsqueda basada en el MAC, ¿verdad?

Como acabo de terminar aquí, algunas cosas que aprendí ahora: para evitar las canas, necesitas un interruptor decente que admita una política de capa 3 + 4, y lo mismo también en Linux.

En algunos casos, el soplete de perversión de estándares llamado ALB / SLB (modo 6) podría funcionar mejor. Operativamente apesta sin embargo.

Yo mismo trato de usar 3 + 4 cuando sea posible, ya que a menudo quiero ese ancho de banda entre dos sistemas adyacentes.

También probé con OpenVSwitch y tuve una vez una instancia en la que el flujo de tráfico interrumpió (cada primer paquete perdido ... no tengo idea)