Te doy la bienvenida a nuestro sitio web, en este lugar vas a encontrar la respuesta a lo que necesitas.
Solución:
Solución 1:
Lo que está buscando se denomina comúnmente “política de transmisión de hash” o “algoritmo de transmisión de hash”. Controla la selección de un puerto de un grupo de puertos agregados con los que transmitir una trama.
Conseguir el estándar 802.3ad ha resultado difícil porque no estoy dispuesto a gastar dinero en él. Habiendo dicho eso, 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 2007 Ottawa, ON, CA IEEE High Speed Study Group, el cumplimiento del estándar 802.3ad no exige algoritmos particulares para el “distribuidor de tramas”:
Este estándar no exige ningún algoritmo de distribución en particular; sin embargo, cualquier algoritmo de distribución debe asegurar que, cuando las tramas son recibidas por un recopilador de tramas como se especifica en 43.2.3, el algoritmo no causará a) Desorden de tramas que son parte de una conversación dada, ob) Duplicación de tramas . El requisito anterior de mantener el orden de las tramas se cumple asegurando que todas las tramas que componen una conversación determinada 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 en búfer o procesamiento por parte del recopilador de tramas correspondiente para reordenar las tramas.
Por lo tanto, cualquier algoritmo que utilice un controlador de conmutador / NIC para distribuir las tramas transmitidas debe cumplir con los requisitos establecidos en esa presentación (que, presumiblemente, estaba citando el estándar). No se especifica ningún algoritmo en particular, solo se define un comportamiento compatible.
Aunque no hay un algoritmo especificado, podemos mirar una implementación en 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 transmisión hash compatible con 802.3ad que aplica la función (consulte bonding.txt en el directorio Documentation networking de la fuente del kernel):
Destination Port = (( XOR ) AND 0xFFFF)
XOR ( XOR )) MOD
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 Ethernet lejos de su servidor a Internet, no está encapsulada en ninguna parte de dicha trama. El enrutador Dirección MAC está presente en el encabezado de dicho marco, 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 de transmisión de hash que tenga en cuenta tanto las direcciones IP de origen como 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án en una agregación más eficiente cuando se utilice una política de transmisión hash 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 en la situación. Si está enviando solicitudes de clientes a sus servidores, como habla Chris 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 desde la dirección IP del cliente de Internet, tendrá menos “flujos” posibles en una política hash de transmisión estrictamente basada en la capa 3.
Una política de transmisión de hash también podría tener en cuenta la información de la capa 4 (números de puerto TCP / UDP), siempre que cumpla con los requisitos del estándar 802.3ad. Tal algoritmo está en el kernel de Linux, como hace referencia en su pregunta. Tenga en cuenta que la documentación de ese algoritmo advierte que, debido a la fragmentación, es posible que el tráfico no fluya necesariamente por la misma ruta y, como tal, el algoritmo no es estrictamente compatible con 802.3ad.
Solucion 2:
muy sorprendentemente, hace unos días nuestras pruebas mostraron 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 corren xen con 1 puente que tiene el dispositivo de unión como miembro. Obviamente, el puente podría causar el problema, solo que no tiene ningún sentido considerando que se usaría hash basado en puerto ip +.
Sé que algunas personas se las arreglan para impulsar más de 180 MB a través de enlaces vinculados (es decir, usuarios de ceph), por lo que funciona en general. Posibles cosas a tener en cuenta: – Usamos el antiguo CentOS 5.4. – El ejemplo de OPs significaría que el segundo LACP “elimina” las conexiones. ¿Tiene sentido eso alguna vez?
Lo que me ha mostrado este hilo y la lectura de documentación, etc., etc.:
En general, todo el mundo sabe mucho sobre esto, es bueno recitar la teoría del método 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 fianza es de 2001 y no está 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 del kernel CentOS / RHEL5 es “SMP seguro” pero no “compatible con SMP” (consulte la charla de alto rendimiento de Facebook); NO escala por encima de una CPU, por lo que al vincular un reloj de cpu más alto> muchos núcleos
Si alguien termina con una buena configuración de enlace de alto rendimiento, o realmente sabe de lo que están hablando sería increíble si tomaran media hora para escribir un nuevo pequeño cómo que documente UN ejemplo de trabajo usando LACP, sin cosas extrañas y ancho de banda> uno Enlace
Solución 3:
Si su interruptor ve el true Destino L3, puede 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 nunca 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 dirección IP única 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 allí, porque entonces la IP “remota” siempre será la IP del equilibrador de carga o el servidor. Puede 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 realizar hash en 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.
Básicamente, siempre y cuando el cliente Puerto de origen (que normalmente cambia mucho) cambios, 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 que no tenga un equilibrador de carga en la mezcla.
Te mostramos las reseñas y valoraciones de los usuarios
Si conservas algún reparo o disposición de limar nuestro artículo puedes añadir una anotación y con mucho placer lo estudiaremos.
