Dell Unity : Modification de l’algorithme d’équilibrage de charge de liaison ou de jonction LACP (corrigible par Dell)
Summary: Le trafic LACP (Link Aggregation Control Protocol) est équilibré pour les écritures sur les processeurs de stockage Unity via une liaison ou une liaison LACP, mais n’est pas équilibré uniformément lorsque des réponses sont envoyées à des demandes de lecture. ...
Symptoms
Dans certains environnements et conditions de mise en réseau, l’algorithme par défaut peut utiliser par défaut une interface unique.
Exemples:
Lorsque l’adresse MAC source est la même (c’est-à-dire lors de l’utilisation d’un routeur), l’adresse MAC sera toujours la même et le port utilisé pour les transmissions sera toujours le même.
En outre, dans des circonstances particulières, différentes adresses MAC peuvent générer la même valeur.
Par exemple, si les adresses MAC se terminent toujours par un nombre pair (0, 2, 4, 6, 8, A, C ou E) et qu’il existe deux ports dans la jonction ou la liaison LACP, le calcul du hachage dirigera le trafic via le même port à chaque fois.
Les liaisons ou jonctions LACP indiquent que le trafic n’est pas équilibré et utilisent une seule interface au lieu de toutes les interfaces de manière uniforme.
Cela peut être confirmé sur le réseau de production (par les administrateurs système du commutateur réseau) ou en examinant l’affichage graphique du réseau dans Unisphere sous Performances du système>.
netstat -i' dans le shell de service.
Cause
LACP sur Unity utilise la couche 2 comme « xmit_hash_policy » par défaut.
L’utilisation de la couche 2+3 comme « xmit_hash_policy » est destinée à fournir une distribution plus équilibrée du trafic que la couche 2 seule, en particulier dans les environnements où un périphérique de passerelle de couche 3 est nécessaire pour atteindre la plupart des destinations.
Référence : https://www.kernel.org/doc/Documentation/networking/bonding.txt
Layer2 utilise la fonction XOR des adresses MAC matérielles et du champ d’ID de type de paquet pour générer le hachage.
La formule est la suivante :
hash = source MAC XOR destination MAC XOR packet type ID slave number = hash modulo slave count.
Layer2+3 utilise une combinaison d’informations de protocole de couche 2 et couche 3 pour générer le hachage.
Le hachage est généré à l’aide d’une combinaison du XOR des adresses MAC matérielles et des adresses IP.
La formule est la suivante :
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.
Les couches 2 et 2 + 3 sont toutes deux conformes à la norme 802.3ad.
Resolution
Pour Unity OE Code 4.3 et versions ultérieures :
Modifiez le paramètre xmit_hash_policy avec l' svc_network_bond commander.
Famille Dell Unity™ Version 4.3 : Commandes de maintenance - Notes techniques - page 74.
Usage:
svc_network_bond [-h|--help] -d <device> {-s -o <option> -v <value>} {-g [-o <option>]}
La syntaxe est semblable à l’exemple ci-dessous :
service@(none) spb:~> svc_network_bond -s -d bond23 -o xmit_hash_policy -v 2
Les valeurs acceptables pour xmit_hash_policy are:
Paramètre
par défaut 0 ou couche 2 Ce paramètre utilise le XOR des adresses MAC matérielles pour générer le hachage.
1 ou layer3+4 Utilise les informations de protocole de la couche supérieure (lorsqu’elles sont disponibles) pour générer le hachage.
Cela permet au trafic vers un réseau homologue particulier de couvrir plusieurs esclaves, bien qu’une seule connexion ne couvre pas plusieurs esclaves.
2 ou layer2+3 Utilise une combinaison d’informations de protocole de couche 2 et couche 3 pour générer le hachage : l’algorithme Mode 2 ou Layer2+3 est conforme à la norme 802.3ad.
Pour Unity OE Code 4.2.3.9670635 et versions antérieures :
Contactez le service client Dell et mentionnez ce numéro de l’article de la base de connaissances.
Pour Unity OE Code 5.3.x ou version ultérieure
La modification ne nécessite pas le shell de service et aucun redémarrage n’est requis.
Voici un exemple de configuration de la baie Unity dans le xmit_hash_policy de notre laboratoire.
Cette baie Unity est configurée avec une jonction LACP appelée bond22.
Connectez-vous en SSH à la baie Unity à l’aide du compte de service.
Tout d’abord, vérifiez sur quoi son xmit_hash_policy est défini.
# 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 #
Définissez ensuite le xmit_hash_policy sur 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 et arp Nécessite l’activation du shell de service.
Exemple 'netstat -i' qui affiche les membres d’une liaison et peut être utilisée pour déterminer si le trafic est haché.
Dans cet exemple, « bond20 » (la liaison LACP) est composé des interfaces « eth20 » et « eth21 ».
Notez la différence dans la colonne TX-OK, qui représente le trafic sortant à partir 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
Exemple de sortie de « arp » sur Service Shell qui affiche les adresses MAC (HWaddress) pour chaque adresse IP.
Ceux-ci doivent être différents pour que le protocole LACP équilibre précisément la charge du trafic sur plusieurs ports physiques.
Plusieurs interfaces doivent être filtrées en fonction de l’interface que vous utilisez.
À utiliser
'ip addr' pour trouver le "Iface" qui est attribuée à l’adresse IP que vous souhaitez analyser.
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