Pregunta ¿Cómo funciona exactamente y específicamente el hash de dirección de destino LACP de capa 3?


Basado en una pregunta anterior hace más de un año (Ethernet multiplexado de 1 Gbps?), Salí y configuré un nuevo bastidor con un nuevo ISP con enlaces LACP por todas partes. Necesitamos esto porque tenemos servidores individuales (una aplicación, una IP) que sirven miles de computadoras cliente en todo el 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 los 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 anterior).

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

alt text

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

alt text

Así que fui e instalé mi kit en el nuevo rack y conecté los cables 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 demostraron que todo el tráfico hacia y desde cada servidor pasaba por un enlace físico de GoE exclusivamente entre el servidor al conmutador y el conmutador al enrutador.

alt text

Con algunas búsquedas en Google y un montón de 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 desde el conmutador al enrutador a través de un solo enlace físico, todavía.

alt text

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

[LACP usa] dirección de origen-destino   pares (SA / DA) para la distribución   Tráfico saliente a través de enlaces troncales.   SA / DA (dirección de origen / destino   dirección) hace que el cambio a   distribuir el tráfico saliente a la   enlaces dentro del grupo troncal en el   base de la dirección de origen / destino   pares Es decir, el interruptor envía   tráfico desde la misma dirección de origen   a la misma dirección de destino   a través del mismo enlace troncal, y   envía tráfico desde la misma fuente   dirección a un destino diferente   dirección a través de un enlace diferente,   Dependiendo de la rotación del camino.   tareas entre los enlaces en el   el maletero.

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

Lo tengo. Pero esto es lo que quiero:

alt text

Un conmutador HP ProCurve más caro 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 ProCurve 2910al Guía de gestión y configuración:

La distribución real del tráfico.   a través de un tronco depende de una   cálculo utilizando bits de la Fuente   Dirección y dirección de destino. Cuando   una dirección IP está disponible, la   el cálculo incluye los últimos cinco   bits de la dirección de origen IP y IP   dirección de destino, de lo contrario el MAC   Se utilizan direcciones.

DE ACUERDO. Por lo tanto, para que esto funcione de la manera que yo 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 LACP de capa 3?

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

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

No hemos salido y hemos comprado un interruptor de reemplazo todavía. Por favor, ayúdeme a entender exactamente si el hash de la dirección de destino LACP de la capa 3 es o no es lo que necesito. Comprar otro interruptor inútil no es una opción.


52
2017-08-17 10:33


origen


Excelente, pregunta bien investigada! Desafortunadamente, no sé la respuesta ... - Doug Luxem
¿Puede ver el costo del árbol de expansión de cada puente / troncal en ProCurve? - dbasnett
También el estado y la prioridad? Parece que cuando HP <---> Cisco puede que los troncales no tengan la misma prioridad y terminen bloqueados. ¿Un anuncio para no mezclar vendedores? - dbasnett
Esta es posiblemente la mejor pregunta formateada que he visto en Server Fault - sclarson
Espero que alguien pueda tener el mismo cuidado con la respuesta que prodigó la pregunta. - Neil Trodden


Respuestas:


Lo que buscas es comúnmente llamado "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 un marco.

Poner en mis manos el estándar 802.3ad ha resultado difícil porque no estoy dispuesto a gastar dinero en ello. Dicho esto, he podido obtener información de una fuente semioficial que arroja algo de luz sobre lo que estás buscando. Por esta presentación de la reunión del Grupo de estudio de alta velocidad IEEE CAE de Ottawa, ON, 2007 El estándar 802.3ad no exige algoritmos particulares para el "distribuidor de cuadros":

Este estándar no exige ningún algoritmo (s) de distribución en particular; sin embargo, cualquier algoritmo de distribución garantizará que, cuando las tramas sean recibidas por un Frame Collector como se especifica en 43.2.3, el algoritmo no cause a) un orden incorrecto de las tramas que forman parte de una conversación dada, o b) la duplicación de tramas . El requisito anterior para mantener el orden de las tramas se cumple asegurando que todas las tramas que componen una conversación dada se transmiten 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 en búfer o procesamiento en la parte del Recopilador de tramas correspondiente para reordenar las tramas.

Por lo tanto, cualquiera que sea el algoritmo que utilice un controlador de conmutador / NIC para distribuir las tramas transmitidas debe cumplir con los requisitos que se indican en esa presentación (que, presumiblemente, se citaba de la norma). No hay un algoritmo específico especificado, solo un comportamiento compatible definido.

Aunque no hay un algoritmo especificado, podemos ver una implementación particular para tener una idea de cómo podría funcionar ese 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 \ networking de la fuente 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 hash 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 de Ethernet que se encuentra lejos de su servidor e Internet, no está encapsulada en ningún lugar en ese marco. El enrutador Dirección MAC está presente en el encabezado de dicha trama, pero la dirección IP del enrutador no lo está. 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 hash de transmisión que tenga en cuenta las direcciones IP de origen y de destino, suponiendo que tenga un grupo de clientes muy variado, 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á en una agregación más eficiente cuando se usa una política de hash de transmisión basada en la capa 3.

Sus diagramas muestran las 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 va a enviar solicitudes de clientes a sus servidores, entonces, como Chris habla en su respuesta entonces 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 basada en la capa 3 estrictamente.

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 y cuando se cumpla con los requisitos del estándar 802.3ad. Tal algoritmo se encuentra en el kernel de Linux, como usted menciona en su pregunta. Tenga en cuenta que la documentación para ese algoritmo advierte que, debido a la fragmentación, el tráfico no necesariamente fluye por la misma ruta y, como tal, el algoritmo no es estrictamente compatible con 802.3ad.


13
2017-08-19 22:47



Sí, he resuelto el servidor de Linux "transmitir política hash". (Una experiencia muy educativa que hizo posible esta pregunta). Es el maldito cambio que me tiene en un aprieto. Gracias por la información sobre los marcos IP. Estoy un poco débil con los niveles más bajos de la red. En mi opinión, el marco estaba dirigido al enrutador, con el destino más profundo en la carga útil. :PAG - Stu Thompson


muy sorprendentemente, hace unos días, nuestras pruebas demostraron que xmit_hash_policy = layer3 + 4 no tendrá ningún efecto entre dos servidores Linux conectados directamente, todo el tráfico usará 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 hashing 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 cosas para mirar: - Utilizamos centos viejos 5.4. - El ejemplo de OP significa que el segundo LACP "deshace" las conexiones. ¿Tiene sentido, alguna vez?

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

  • En general, todo el mundo sabe mucho acerca de esto, es bueno para recitar la teoría del vínculo 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 unión es de 2001 y no es lo suficientemente actualizada.
  • Aparentemente, el modo layer2 + 3 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 del kernel CentOS / RHEL5 es "seguro para SMP" pero no "compatible con SMP" (vea facebook highperformance talk) - NO se escala por encima de una CPU, por lo que con la vinculación de un reloj cpu superior> muchos núcleos

Si nadie termina con una buena configuración de vinculación de alto rendimiento, o realmente sabe de lo que están hablando. Sería increíble si tomaran media hora para escribir un nuevo howto que documente UN ejemplo de trabajo usando LACP, sin cosas extrañas y ancho de banda> uno enlazar


5
2018-06-16 12:30



Se pone peor: ¡Las diferentes versiones de Debian tienen diferentes métodos para configurar la vinculación! De hecho, he documentado cómo configuro mi vinculación en una publicación de blog, que parece tener un tráfico decente. - Stu Thompson


Si su conmutador ve el verdadero destino L3, puede hacer un hash en eso. Básicamente, si tiene 2 enlaces, piense que el enlace 1 es para destinos con números impares, el enlace 2 es para destinos con números pares. No creo que alguna vez utilicen la IP del siguiente salto a menos que estén configurados para hacerlo, pero eso es casi 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 único servidor, 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 allí, porque entonces la IP "remota" siempre será la IP del equilibrador de carga o el servidor. Podría evitarlo un poco usando 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 hacer hash en cosas como:

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

Básicamente, mientras el puerto de origen del cliente (que generalmente cambia mucho) cambie, distribuirá el tráfico de manera uniforme. Estoy seguro de que otros proveedores tienen características similares.

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


2
2017-08-19 19:53



Gracias. Sin balanceo de carga. Y no me preocupa el tráfico entrante: tenemos una relación de tráfico de> 50: 1: en tráfico. (Es una aplicación de video web.) - Stu Thompson
Creo que en su caso, el hash en el destino no le proporcionará nada, ya que el conmutador verá el destino como su servidor. La ingeniería de tráfico L2 simplemente no es muy buena. Y 'hash' en este tipo de aplicación va a ser bastante primitivo: lo mejor que puedes hacer es sumar todos los bits en las direcciones que estén en uso y, si el resultado es 0, haz clic en un enlace o 1 sal del otro. - chris
Como lo entiendo de mi cita anterior de ProCurve 2910al, el hash está en los últimos cinco bits de la fuente y destino. Entonces, no importa si uno (mi servidor) está arreglado, el otro variará para casi todos los clientes en el Nivel 3. ¿Nivel 2? Ese es mi problema actual: solo hay una dirección de origen y una dirección de destino para el hash. - Stu Thompson


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


0
2017-08-19 16:47





Desde que acabé de regresar aquí, algunas cosas que aprendí a estas alturas: Para evitar las canas, necesita un interruptor decente que admita una política de layer3 + 4, y lo mismo también en Linux.

En unos cuantos casos, el soplete de pervertido de estándares llamado ALB / SLB (modo 6) podría funcionar mejor. Operacionalmente apesta sin embargo.

Trato de usar 3 + 4 siempre que sea posible, ya que a menudo quiero ese ancho de banda entre dos sistemas adyacentes.

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


-1
2018-03-26 18:24