Dell Unity: Cómo cambiar el algoritmo de balanceo de carga de enlace o troncal de LACP (corregible por Dell)
Summary: El tráfico del protocolo de control de agregación de enlaces (LACP) se balancea para las escrituras en los SP de Unity mediante un enlace troncal o un enlace LACP, pero no se balancea uniformemente cuando se envían respuestas a solicitudes de lectura. ...
Symptoms
En determinadas condiciones y entornos de red, es posible que el algoritmo predeterminado utilice de manera predeterminada una sola interfaz.
Ejemplos:
Cuando la dirección MAC de origen es la misma (es decir, cuando se usa un enrutador), la MAC siempre será la misma y el puerto que se utiliza para las transmisiones siempre será el mismo.
Además, en circunstancias especiales, diferentes MAC también pueden dar como resultado el mismo valor.
Por ejemplo, si los MAC siempre terminan en un número par (0, 2, 4, 6, 8, A, C o E) y hay dos puertos en el enlace troncal o la vinculación LACP, el cálculo del hash también dirigirá el tráfico a través del mismo puerto cada vez.
Las vinculaciones o troncales de LACP muestran que el tráfico no está equilibrado, ya que utiliza una sola interfaz en lugar de todas las interfaces de manera uniforme.
Esto se puede confirmar en la red de producción (mediante los administradores del sistema de switches de red) o mirando la pantalla gráfica de red en Unisphere en SYSTEM >Performance.
netstat -i' en el shell de servicio.
Cause
LACP en Unity utiliza la capa 2 como su "xmit_hash_policy" predeterminado.
El uso de Capa 2 + 3 como "xmit_hash_policy" está diseñado para proporcionar una distribución de tráfico más equilibrada que la capa 2 por sí sola, especialmente en entornos donde se requiere un dispositivo de puerta de enlace de capa 3 para llegar a la mayoría de los destinos.
Referencia: https://www.kernel.org/doc/Documentation/networking/bonding.txt
capa 2 utiliza XOR de direcciones MAC de hardware y el campo de ID de tipo de paquete para generar el hash.
La fórmula es
hash = source MAC XOR destination MAC XOR packet type ID slave number = hash modulo slave count.
Layer2+3 utiliza una combinación de información de protocolo de capa 2 y capa 3 para generar el hash.
El hash se genera mediante una combinación de XOR de las direcciones MAC de hardware y las direcciones IP.
La fórmula es
hash = source MAC XOR destination MAC XOR packet type ID hash = hash XOR source IP XOR destination IP hash = hash XOR (hash RSHIFT 16) hash = hash XOR (hash RSHIFT 8) And then hash is reduced modulo slave count.
Tanto Layer2 como Layer2+3 cumplen con 802.3ad.
Resolution
Para Unity OE Code 4.3 y versiones posteriores:
Cambie la opción xmit_hash_policy Con el svc_network_bond mandar.
Familia Dell Unity™ versión 4.3: Notas técnicas de los comandos de servicio , página 74.
Uso:
svc_network_bond [-h|--help] -d <device> {-s -o <option> -v <value>} {-g [-o <option>]}
La sintaxis sería similar al siguiente ejemplo:
service@(none) spb:~> svc_network_bond -s -d bond23 -o xmit_hash_policy -v 2
Los valores aceptables para xmit_hash_policy son:
0 o capa 2 Configuración
predeterminada Este parámetro utiliza el XOR de las direcciones MAC de hardware para generar el hash.
1 o capa3+4 Utiliza la información del protocolo de capa superior (cuando está disponible) para generar el hash.
Esto permite que el tráfico a un par de red en particular abarque varios esclavos, aunque una sola conexión no abarcará varios esclavos.
2 o capa2+3 utiliza una combinación de información de protocolo de capa2 y capa3 para generar el hash: el algoritmo de modo 2 o capa 2+3 cumple con 802.3ad.
Para el código 4.2.3.9670635 y versiones anteriores
de Unity OE: Comuníquese con el servicio al cliente de Dell y mencione el número de este KBA.
Para el código Unity OE 5.3.x o superior
Para realizar el cambio no se requiere el shell de servicio y no es necesario reiniciar.
Este es un ejemplo de la configuración del arreglo Unity en el xmit_hash_policy de nuestro laboratorio.
Este arreglo Unity está configurado con un tronco LACP conocido como bond22.
Acceda mediante SSH al arreglo de Unity con la cuenta de servicio.
En primer lugar, compruebe la configuración de su xmit_hash_policy.
# svc_network_bond --get --device bond22 -o xmit_hash_policy INFO: Selected device: bond22 INFO: Option to show: xmit_hash_policy INFO: Execution code: 0 xmit_hash_policy=0 #
A continuación, establezca el xmit_hash_policy en 2
# svc_network_bond --set --device bond22 -o xmit_hash_policy -v 2 INFO: Selected device: bond22 INFO: Option to modify: xmit_hash_policy INFO: Requested value: 2 WARNING: Do you want to proceed? [yes/no]: yes <<<<<< sometimes y works and sometimes it fails on the first attempts. Retry then. INFO: Execution code: 0 INFO: Option 'xmit_hash_policy' has been successfully changed. #
# svc_network_bond --get --device bond22 -o xmit_hash_policy INFO: Selected device: bond22 INFO: Option to show: xmit_hash_policy INFO: Execution code: 0 xmit_hash_policy=2 #
Additional Information
netstat y arp Requerir que el shell de servicio esté habilitado.
Ejemplo 'netstat -i' Salida, que muestra los miembros de un enlace y se puede utilizar para determinar si el tráfico se está cifrando.
En este ejemplo, 'bond20' (la vinculación LACP) se compone de las interfaces 'eth20' y 'eth21'.
Tenga en cuenta la diferencia en la columna TX-OK, que representa el tráfico saliente de Unity.
21:12:03 service@(none) spb:~> netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg bond20 9000 0 101724658 0 11 0 126087418 0 0 0 BMmRU cmin0 9000 0 14341258 0 0 0 11301712 0 0 0 BMRU eth2 1500 0 0 0 0 0 0 0 0 0 BMU eth3 1500 0 0 0 0 0 0 0 0 0 BMU eth10 1500 0 0 0 0 0 0 0 0 0 BMU eth11 1500 0 0 0 0 0 0 0 0 0 BMU eth12 1500 0 0 0 0 0 0 0 0 0 BMU eth13 1500 0 0 0 0 0 0 0 0 0 BMU eth20 9000 0 52249885 0 1 0 38317 0 0 0 BMsRU eth21 9000 0 49474773 0 10 0 126049101 0 0 0 BMsRU eth22 1500 0 0 0 0 0 0 0 0 0 BMU eth23 1500 0 0 0 0 0 0 0 0 0 BMU eth_int 9000 0 14341055 0 0 0 11301598 0 0 0 BMRU eve_br0 1500 0 16 0 0 0 3656 0 0 0 BMRU lo 65536 0 963282566 0 0 0 963282566 0 0 0 LRU mgmt 1500 0 1405994 0 64 0 360538 0 0 0 BMRU mgmt_vdev 1500 0 356150 0 64 0 326216 0 0 0 BMRU srm 1500 0 135650 0 64 0 5 0 0 0 BMRU vetheve1 1500 0 16 0 0 0 3647 0 0 0 BMRU
Ejemplo de salida de "arp" en el shell de servicio que muestra las direcciones MAC (HWaddress) para cada dirección IP.
Estos deben ser diferentes para que LACP balancee con precisión la carga del tráfico en varios puertos físicos.
Hay varias interfaces que deben filtrarse por la interfaz que está utilizando.
Uso
'ip addr' Para encontrar el archivo "Iface" que se asigna a la dirección IP que desea investigar.
19:23:33 service@(none) spa:~> arp Address HWtype HWaddress Flags Mask Iface 10.98.25.61 ether 00:25:b5:02:01:fc C bond20 10.98.25.60 ether 00:25:b5:02:00:1c C bond20 10.98.25.70 ether 00:25:b5:02:00:dc C bond20 10.98.25.63 ether 00:25:b5:02:01:8c C bond20 10.98.25.65 ether 00:25:b5:02:01:6c C bond20 10.98.25.62 ether 00:25:b5:02:01:dc C bond20 10.98.25.64 ether 00:25:b5:02:01:9c C bond20 10.98.25.67 ether 00:25:b5:02:01:0c C bond20 10.98.25.66 ether 00:25:b5:02:01:7c C bond20 10.98.25.59 ether 00:25:b5:02:00:0c C bond20 peer ether 8e:92:80:4d:2d:02 C eth_int 10.98.25.69 ether 00:25:b5:02:00:fc C bond20 10.98.25.1 ether 00:08:e3:ff:fd:90 C bond20 10.98.25.68 ether 00:25:b5:02:01:1c C bond20