Comment fonctionne exactement et spécifiquement le hachage d'adresse de destination LACP de couche 3?
Sur la base d'une question précédente il y a plus d'un an ( Ethernet multiplexé 1 Gbit/s? ), je suis parti et j'ai installé un nouveau rack avec un nouveau FAI avec des liaisons LACP partout. Nous en avons besoin car nous avons des serveurs individuels (une application, une IP) qui desservent des milliers d'ordinateurs clients sur Internet au-delà de 1 Gbit/s cumulés.
Cette idée LACP est censée nous permettre de franchir la barrière des 1 Gbit/s sans dépenser une fortune en commutateurs et cartes réseau 10 GoE. Malheureusement, j'ai rencontré quelques problèmes concernant la distribution du trafic sortant. (Ceci malgré l'avertissement de Kevin Kuphal dans la question liée ci-dessus.)
Le routeur du FAI est une sorte de Cisco. (J'ai déduit cela de l'adresse MAC.) Mon commutateur est un HP ProCurve 2510G-24. Et les serveurs sont HP DL 380 G5 exécutant Debian Lenny. Un serveur est une redondance d'UC. Notre application ne peut pas être mise en cluster. Voici un schéma de réseau simplifié qui inclut tous les nœuds de réseau pertinents avec IP, MAC et interfaces.
Bien qu'il ait tous les détails, il est un peu difficile de travailler avec et de décrire mon problème. Donc, par souci de simplicité, voici un schéma de réseau réduit aux nœuds et aux liaisons physiques.
Je suis donc parti et installé mon kit sur le nouveau rack et connecté le câblage de mon FAI à partir de leur routeur. Les deux serveurs ont un lien LACP vers mon commutateur, et le commutateur a un lien LACP vers le routeur ISP. Dès le début, j'ai réalisé que ma configuration LACP n'était pas correcte: les tests ont montré que tout le trafic vers et depuis chaque serveur passait par une liaison GoE physique exclusivement entre le serveur à commutateur et le commutateur à routeur.
Avec quelques recherches sur Google et beaucoup de temps RTMF concernant la liaison Linux NIC, j'ai découvert que je pouvais contrôler la liaison NIC en modifiant la liaison /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
Cela a eu le trafic quittant mon serveur sur les deux cartes réseau comme prévu. Mais le trafic se déplaçait du commutateur au routeur sur une seule liaison physique, encore.
Nous avons besoin que ce trafic passe par les deux liaisons physiques. Après avoir lu et relu les 2510G-24 Guide de gestion et de configuration , je trouve:
[LACP utilise] des paires d'adresses source-destination (SA/DA) pour distribuer le trafic sortant sur les liaisons à ressources partagées. SA/DA (adresse source/adresse de destination) oblige le commutateur à distribuer le trafic sortant vers les liaisons au sein du groupe de lignes sur la base de paires d'adresses source/destination. En d'autres termes, le commutateur envoie le trafic de la même adresse source vers la même adresse de destination via la même liaison agrégée, et envoie le trafic de la même adresse source vers une adresse de destination différente via un lien différent, en fonction de la rotation des affectations de chemin parmi les liens dans le coffre.
Il semble qu'un lien lié ne présente qu'une seule adresse MAC, et donc mon chemin de serveur à routeur sera toujours sur un chemin de commutateur à routeur car le commutateur ne voit qu'un MAC (et non deux - un de chaque port) pour les deux liaisons LACP.
Je l'ai. Mais c'est ce que je veux:
Un commutateur HP ProCurve plus cher est le 2910al utilise les adresses de source et de destination de niveau 3 dans son hachage. De la section "Distribution du trafic sortant sur les liaisons partagées" du ProCurve 2910al's Guide de gestion et de configuration :
La distribution réelle du trafic à travers une jonction dépend d'un calcul utilisant des bits provenant de l'adresse source et de l'adresse de destination. Lorsqu'une adresse IP est disponible, le calcul inclut les cinq derniers bits de l'adresse source IP et de l'adresse IP de destination, sinon les adresses MAC sont utilisées.
D'ACCORD. Donc, pour que cela fonctionne comme je le souhaite, l'adresse de destination est la clé puisque mon adresse source est fixe. Cela m'amène à ma question:
Comment fonctionne exactement et spécifiquement le hachage LACP de la couche 3?
J'ai besoin de savoir quelle adresse de destination est utilisée:
- l'IP du client , la destination finale?
- Ou l'adresse IP du routeur , la prochaine destination de transmission de liaison physique.
Nous ne sommes pas encore partis et avons acheté un interrupteur de remplacement. Aidez-moi à comprendre exactement si le hachage d'adresse de destination LACP de couche 3 est ou n'est pas ce dont j'ai besoin. Acheter un autre interrupteur inutile n'est pas une option.
Ce que vous recherchez est communément appelé "politique de hachage de transmission" ou "algorithme de hachage de transmission". Il contrôle la sélection d'un port dans un groupe de ports agrégés avec lesquels transmettre une trame.
Il est difficile de mettre la main sur la norme 802.3ad car je ne suis pas prêt à dépenser de l'argent pour cela. Cela dit, j'ai pu glaner des informations auprès d'une source semi-officielle qui éclaire ce que vous recherchez. Par cette présentation de la réunion du groupe d'étude à grande vitesse IEEE 2007 d'Ottawa, ON, CA la norme 802.3ad ne requiert pas d'algorithmes particuliers pour le "répartiteur de trames":
Cette norme ne prescrit aucun algorithme de distribution particulier; cependant, tout algorithme de distribution doit garantir que, lorsque des trames sont reçues par un collecteur de trames comme spécifié en 43.2.3, l'algorithme ne doit pas provoquer a) un mauvais ordre des trames faisant partie d'une conversation donnée, ou b) la duplication des trames . L'exigence ci-dessus de maintenir l'ordre des trames est satisfaite en s'assurant que toutes les trames qui composent une conversation donnée sont transmises sur une seule liaison dans l'ordre où elles sont générées par le client MAC; par conséquent, cette exigence n'implique pas l'ajout (ou la modification) d'informations à la trame MAC, ni la mise en mémoire tampon ou le traitement de la part du collecteur de trames correspondant afin de réorganiser les trames.
Donc, quel que soit l'algorithme utilisé par un commutateur/NIC pilote pour distribuer les trames transmises doit respecter les exigences énoncées dans cette présentation (qui, vraisemblablement, citait la norme). Aucun algorithme particulier n'est spécifié, seul un comportement conforme est défini.
Même si aucun algorithme n'est spécifié, nous pouvons examiner une implémentation particulière pour avoir une idée de la façon dont un tel algorithme pourrait fonctionner. Le pilote de "liaison" du noyau Linux, par exemple, a une politique de hachage de transmission compatible 802.3ad qui applique la fonction (voir bonding.txt dans le répertoire Documentation\networking de la source du noyau):
Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF)
XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>
Cela provoque à la fois les adresses IP source et de destination, ainsi que les adresses MAC source et de destination, pour influencer la sélection du port.
L'adresse IP de destination utilisée dans ce type de hachage serait l'adresse présente dans la trame. Prenez une seconde pour y penser. L'adresse IP du routeur, dans un en-tête de trame Ethernet loin de votre serveur vers Internet, n'est encapsulée nulle part dans une telle trame. Le routeur adresse MAC est présent dans l'en-tête d'une telle trame, mais pas l'adresse IP du routeur. L'adresse IP de destination encapsulée dans la charge utile de la trame sera l'adresse du client Internet qui fait la demande à votre serveur.
Une stratégie de hachage de transmission qui prend en compte à la fois les adresses IP source et de destination, en supposant que vous disposez d'un pool de clients très varié, devrait faire assez bien pour vous. En général, des adresses IP source et/ou de destination plus variées dans le trafic circulant à travers une telle infrastructure agrégée se traduiront par une agrégation plus efficace lorsqu'une politique de hachage de transmission basée sur la couche 3 est utilisée.
Vos diagrammes montrent les demandes provenant directement d'Internet depuis les serveurs, mais il convient de souligner ce qu'un proxy peut faire dans la situation. Si vous procurez des requêtes de clients à vos serveurs par procuration, comme chris en parle dans sa réponse alors vous pouvez provoquer des goulots d'étranglement. Si ce proxy fait la demande à partir de sa propre adresse IP source, au lieu de l'adresse IP du client Internet, vous aurez moins de "flux" possibles dans une politique de hachage de transmission strictement basée sur la couche 3.
Une politique de hachage de transmission peut également prendre en compte les informations de couche 4 (numéros de port TCP/UDP), tant qu'elle respecte les exigences de la norme 802.3ad. Un tel algorithme est dans le noyau Linux, comme vous le mentionnez dans votre question. Sachez que la documentation de cet algorithme avertit qu'en raison de la fragmentation, le trafic peut ne pas nécessairement circuler sur le même chemin et, en tant que tel, l'algorithme n'est pas strictement compatible 802.3ad.
de manière très surprenante, il y a quelques jours, nos tests ont montré que xmit_hash_policy = layer3 + 4 n'aura aucun effet entre deux serveurs linux directement connectés, tout le trafic utilisera un port. les deux exécutent xen avec 1 pont qui a le dispositif de liaison comme membre. le plus Évidemment, le pont pourrait causer le problème, juste qu'il n'a pas de sens AT ALL considérant que le hachage basé sur le port ip + serait utilisé.
Je sais que certaines personnes parviennent à pousser 180 Mo + sur des liens liés (c'est-à-dire des utilisateurs de ceph), donc cela fonctionne en général. Choses possibles à examiner: - Nous avons utilisé l'ancien CentOS 5.4 - L'exemple des OP signifierait que le deuxième LACP "détache" les connexions - est-ce que cela a du sens, jamais?
Ce que ce fil et la documentation lisant etc etc m'ont montré:
- En général, tout le monde en sait beaucoup à ce sujet, est bon à réciter la théorie du liage howto ou même les normes IEEE, alors que l'expérience pratique est presque nulle.
- La documentation RHEL est au mieux incomplète.
- La documentation de cautionnement date de 2001 et n'est pas suffisamment à jour
- le mode layer2 + 3 n'est apparemment pas dans CentOS (il ne s'affiche pas dans modinfo, et dans notre test, il a supprimé tout le trafic lorsqu'il est activé)
- Cela n'aide pas que SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) et RedHat (BONDING_OPTS) aient tous des façons différentes de spécifier les paramètres du mode par liaison
- Le module du noyau CentOS/RHEL5 est "SMP safe" mais pas "SMP capable" (voir la conversation facebook haute performance) - il ne s'étend PAS au-dessus d'un CPU, donc avec une horloge CPU plus élevée de liaison> de nombreux cœurs
Si n'importe qui finit par une bonne configuration de liaison haute performance, ou sait vraiment de quoi ils parlent, ce serait génial s'ils prenaient une demi-heure pour écrire un nouveau petit guide qui documente UN exemple de travail en utilisant LACP, pas de trucs bizarres et de bande passante> un lien
Si votre commutateur voit la véritable destination L3, il peut y hacher. Fondamentalement, si vous avez 2 liens, pensez que le lien 1 est pour les destinations impaires, le lien 2 est pour les destinations paires. Je ne pense pas qu'ils utilisent jamais l'IP du prochain bond, sauf s'ils sont configurés pour le faire, mais c'est à peu près la même chose que l'utilisation de l'adresse MAC de la cible.
Le problème que vous allez rencontrer est que, selon votre trafic, la destination sera toujours l'adresse IP unique du serveur unique, vous n'utiliserez donc jamais cet autre lien. Si la destination est le système distant sur Internet, vous obtiendrez une distribution uniforme, mais s'il s'agit d'un serveur Web, où votre système est l'adresse de destination, le commutateur enverra toujours du trafic sur un seul des liens disponibles.
Vous serez encore plus mal en point s'il y a un équilibreur de charge quelque part, car l'IP "distante" sera toujours soit l'IP de l'équilibreur de charge, soit le serveur. Vous pouvez contourner cela un peu en utilisant beaucoup d'adresses IP sur l'équilibreur de charge et le serveur, mais c'est un hack.
Vous voudrez peut-être élargir un peu votre horizon de fournisseurs. D'autres fournisseurs, tels que les réseaux extrêmes, peuvent hacher des choses comme:
Algorithme L3_L4: couches 3 et 4, adresses IP source et destination combinées et source et destination TCP et numéros de port UDP. Disponible sur les commutateurs des séries SummitStack et Summit X250e, X450a, X450e et X650 .
Donc, fondamentalement, tant que le port source du client (qui change généralement beaucoup) change, vous répartirez uniformément le trafic. Je suis sûr que d'autres fournisseurs ont des fonctionnalités similaires.
Même le hachage sur l'IP source et de destination serait suffisant pour éviter les points chauds, tant que vous n'avez pas d'équilibreur de charge dans le mix.
Je suppose que c'est hors de l'IP du client, pas du routeur. Les adresses IP réelles de source et de destination seront à un décalage fixe dans le paquet, et cela va être rapide pour le hachage. Le hachage de l'IP du routeur nécessiterait une recherche basée sur le MAC, non?