52 votos

Cómo exactamente y específicamente hace de capa 3 LACP dirección de destino de hash de trabajo?

Basado en una pregunta anterior hace más de un año (Multiplexado Ethernet de 1 Gbps?), Yo me fui y la configuración de un nuevo bastidor con un nuevo proveedor de internet con LACP enlaces por todo el lugar. Necesitamos porque contamos con servidores individuales (una aplicación, una sola IP) que ofrece miles de los equipos cliente en todo el Internet en exceso de 1 gbps acumulativa.

Este LACP idea se supone que vamos a romper el 1Gbps barrera sin gastar una fortuna en 10GoE interruptores y Nic. Por desgracia, me he encontrado con algunos problemas en relación con el tráfico saliente de distribución. (Esto a pesar de que Kevin Kuphal de advertencia en la anterior relacionado pregunta.)

El ISP router es un Cisco de algún tipo. (Deduje que a partir de la dirección MAC.) Mi cambio es una HP ProCurve 2510G-24. Y los servidores HP DL 380 G5s ejecutando Debian Lenny. Un servidor es un hot standby. Nuestra aplicación no puede ser agrupado. Aquí está simplificada del diagrama de red que incluye a todos relevancia los nodos de la red con una ip, Mac y las interfaces.

alt text

Si bien tiene todo el detalle de que es un poco difícil de trabajar y describir mi problema. Así que, para simplificar, aquí es un diagrama de red reducida a los nodos y enlaces físicos.

alt text

Así que me fui y se instala mi kit en el nuevo bastidor y conectado mi ISP del cableado de su router. Ambos servidores tienen un LACP enlace a mi interruptor y el interruptor se tiene un LACP enlace al enrutador del ISP. Desde el principio me di cuenta de que mi LACP configuración no es correcta: pruebas mostraron todo el tráfico hacia y desde cada servidor que estaba pasando más de un físico GoE enlace exclusivamente entre ambos servidor-a-switch y el switch a router.

alt text

Con algunas búsquedas en google y un montón de RTMF tiempo sobre linux NIC vinculación, descubrí que yo podía controlar la NIC vinculación modifiying /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 tiene el tráfico que sale de mi servidor a través de ambas Nic como se esperaba. Pero el tráfico estaba moviendo desde el switch a router por sólo un enlace físico, todavía.

alt text

Necesitamos que el tráfico que va encima de los dos enlaces físicos. Después de leer y releer el 2510G-24 de la Gestión y la Guía de Configuración, me parece:

[LACP usa] fuente-dirección de destino pares (SA/DA) para la distribución de el tráfico saliente sobre enlaces troncalizados. SA/DA (dirección de origen/destino dirección) hace que el modificador distribuir el tráfico saliente a la los enlaces dentro del grupo de troncales en la base de la fuente/ dirección de destino los pares. Es decir, el conmutador envía el tráfico procedente de la misma dirección de origen a la misma dirección de destino a través de la misma troncalizados enlace, y envía el tráfico de la misma fuente dirección a un destino diferente dirección a través de un enlace distinto, dependiendo del giro de la ruta las asignaciones entre los enlaces en las el tronco.

Parece que una servidumbre de enlace presenta sólo una dirección MAC, y por lo tanto mi servidor-a-router camino siempre va a ser más de una ruta de acceso desde el switch a router porque el interruptor ve pero un MAC (y no dos: uno de cada puerto), tanto para la LACP había enlaces.

Lo consiguió. Pero esto es lo que quiero:

alt text

Más caro, HP ProCurve switch es la 2910al utiliza el nivel 3 de origen y las direcciones de destino en lo del hash. Desde el Saliente "la Distribución del Tráfico a Través de Enlaces Troncalizados" de la sección de la ProCurve 2910al la Gestión y Guía de Configuración:

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

OK. Así que, para que esto funcione de la manera que yo quiero, la dirección de destino es la clave desde mi dirección de origen es fijo. Esto lleva a mi pregunta:

Cómo exactamente y específicamente hace de capa 3 LACP hash trabajo?

Necesito saber a que dirección de destino se utiliza:

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

No hemos ido y se compró un reemplazo de interruptor todavía. Por favor, que me ayude a entender exactamente si la capa 3 LACP dirección de destino de hash es o no es lo que necesito. La compra de otro inútil cambiar no es una opción.

13voto

Evan Anderson Puntos 118832

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

Llegar a mis manos la 802.3 ad estándar ha sido difícil porque no estoy dispuesta a gastar dinero en él. Habiendo dicho eso, he sido capaz de recoger algo de información de un semi-fuente oficial, que arroja un poco de luz sobre lo que usted está buscando. Por esta presentación desde el 2007 Ottawa, ON, CA IEEE de Alta Velocidad de Grupo de Estudio de la reunión de la 802.3 ad norma no mandato particular de los algoritmos para el "frame " distribuidor":

Esta norma no obliga a una distribución particular del algoritmo(s); sin embargo, cualquier algoritmo de distribución deberá asegurarse de que, cuando los marcos son recibidos por un Marco de Colector como se especifica en 43.2.3, el algoritmo no deberá provocar una) Mis pedidos de los marcos que son parte de cualquier conversación, o b) la Duplicación de tramas. El requisito anterior para mantener el marco de pedido es recibido por garantizar que todos los fotogramas que componen una determinada conversación se transmiten en un solo enlace en el orden en que son generados por la MAC del Cliente; por lo tanto, este requisito no implica la adición (o modificación) de cualquier tipo de información a la MAC de marco, ni el almacenamiento en búfer o de procesamiento en la parte de la Trama correspondiente Colector con el fin de re-orden de marcos.

Así, cualquiera que sea el algoritmo de un conmutador / controlador de la NIC utiliza para distribuir tramas transmitidas deben cumplir con los requisitos como se indicó en la presentación (que, presumiblemente, fue una cita de la norma). No hay ningún algoritmo especificado, sólo compatible con un comportamiento definido.

Aunque no hay ningún algoritmo especificado, podemos mirar una implementación en particular para tener una idea de la forma en que un algoritmo puede trabajar. El kernel de Linux "bonding" conductor, por ejemplo, tiene un 802.3 ad-compatible con hash de transmisión de la política que se aplica la función (ver bonding.txt en la Documentación\redes directorio de los fuentes del núcleo):

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

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

La dirección IP de destino se utiliza en este tipo de hash sería la dirección que está presente en la trama. Tome un segundo para pensar en eso. La dirección IP del router, en un marco de Ethernet cabecera lejos de su servidor de Internet, no está encapsulado en cualquier lugar en tal marco. El router, la dirección MAC está presente en el encabezado de una trama, pero la dirección IP del router no es. La dirección IP de destino encapsulado en la trama de la carga útil será la dirección de Internet del cliente que hace la petición a su servidor.

Un hash de transmisión de la política que toma en cuenta tanto de origen y de destino direcciones IP, asumiendo que usted tiene una amplia gama de piscina de clientes, debe hacer bastante bien para usted. En general, más ampliamente, de variado origen y/o direcciones IP de destino en el tráfico que fluye a través de un agregado de infraestructura dará como resultado más eficaz agregación cuando una capa de 3 basado en hash de transmisión de la política se utiliza.

Los diagramas muestran las solicitudes que vienen directamente de los servidores de Internet, pero vale la pena señalar lo que es un proxy puede hacer a la situación. Si eres cliente de proxy de peticiones a los servidores de entonces, como chris habla en su respuesta a continuación, usted puede causar cuellos de botella. Si el proxy está haciendo la solicitud a partir de su propia dirección IP de origen, en lugar de desde la Internet dirección IP del cliente, vamos a tener menos posible "flujos" en un sentido estrictamente capa 3 basado en hash de transmisión de la política.

Un hash de transmisión de la política también podría tomar la capa 4 de la información (TCP / UDP números de puerto) en cuenta, también, así que siempre que mantienen con los requisitos establecidos en el 802.3 ad estándar. Este algoritmo está en el kernel de Linux, como se hace referencia en su pregunta. Tenga en cuenta que la documentación para que el algoritmo advierte que, debido a la fragmentación, el tráfico no necesariamente puede fluir a lo largo de la misma ruta y, como tal, el algoritmo no es estrictamente 802.3 ad-compatible.

5voto

darkfader Puntos 39

muy sorprendentemente baratos, hace un par de días nuestras pruebas mostraron que xmit_hash_policy=layer3+4 no tendrá ningún efecto entre dos directamente conectado a los servidores de linux, todo el tráfico que se va a utilizar un puerto. de tanto correr xen con 1 puente que tiene la unión dispositivo como un miembro. más Obviamente, el puente podría causar el problema, sólo que no tiene sentido teniendo EN cuenta que la ip+puerto basado en hash se utiliza.

Conozco a algunas personas que realmente logran empujar 180 MB+ a lo largo de la servidumbre de los enlaces (es decir, ceph los usuarios), por lo que hace al trabajo en general. Cosas a tener en cuenta: - Hemos utilizado viejo CentOS 5.4 - La OPs ejemplo sería el segundo LACP "unhashes" las conexiones - ¿que sentido, alguna vez?

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

  • En general todo el mundo sabe mucho acerca de esto, es bueno recitar la teoría de la unión howto o incluso las normas de la IEEE, mientras que la experiencia práctica es cerca a ninguno.
  • La RHEL la documentación está incompleta en el mejor.
  • La unión de la documentación es de 2001 y no lo suficientemente actual
  • nivel 2+3 modo al parecer no está en CentOS (que no se muestran en modinfo, y en nuestra prueba se cayó todo el tráfico cuando está activado)
  • No ayuda el hecho de que SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) y RedHat (BONDING_OPTS) todos tienen diferentes maneras de especificar por los bonos del modo de configuración
  • El CentOS/RHEL5 módulo de kernel es "SMP seguro", pero no "SMP capaz" (véase el facebook de alto rendimiento hablar) - NO se escala por encima de una CPU, por lo que la vinculación con los mayores de reloj de cpu > muchos núcleos

Si alguien termina una buena de alto rendimiento de la vinculación de la instalación, o realmente sabe lo que están hablando acerca de que sería increíble si se tuvo una media hora para escribir un nuevo pequeño howto que los documentos de UN ejemplo de trabajo utilizando LACP, no extraño a las cosas, y el ancho de banda > un enlace

2voto

Erowlin Puntos 121

Si el interruptor ve la verdadera L3 destino, puede hash en que. Básicamente, si tienes 2 enlaces, creo que el enlace 1 es impar destinos, enlace 2 es para numeradas destinos. No creo que nunca uso el next-hop IP a menos que se configure para hacerlo, pero eso es casi lo mismo que usar la dirección MAC de destino.

El problema que vas a chocar es que, dependiendo del tráfico, el destino siempre será el único servidor de una única dirección IP, por lo que nunca vamos a usar que otro enlace. Si el destino es el sistema remoto en el internet, usted conseguirá una distribución uniforme, pero si es algo como un servidor web, donde el sistema es la dirección de destino, el cambio siempre va a enviar el tráfico a través de sólo uno de los enlaces disponibles.

Vas a estar en peor forma que si hay un equilibrador de carga en algún lugar de allí, porque entonces la "remota" IP siempre será el equilibrador de carga de la IP o el servidor. Usted podría conseguir de todo un poco por el uso de gran cantidad de direcciones IP en el equilibrador de carga y el servidor, pero eso es un hack.

Es posible que desee ampliar su horizonte de los vendedores un poco. Otros proveedores, tales como la extrema redes, puede hash en cosas como:

L3_L4 algoritmo de Capa 3 y Capa 4, la combinación de la fuente y las direcciones IP de destino y de origen y de destino TCP y UDP número de puerto. Disponible en SummitStack y de la Cumbre de X250e, X450a, X450e, y X650 los conmutadores de la serie.

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

Incluso hashing por IP de origen y destino sería suficiente para evitar las manchas, siempre y cuando usted no tiene un equilibrador de carga en la mezcla.

0voto

Bill Weiss Puntos 6677

Voy a suponer que está fuera de la IP del cliente, no el router. El verdadero origen y de destino IPs será en una compensación fija en el paquete, y que va a ser rápido para hacer hash. Hash de la IP del router requeriría una búsqueda basada en el MAC, ¿verdad?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: