Comment exactement et spécifiquement le hachage d'adresse de destination LACP de couche 3 fonctionne-t-il?

Basé sur une question posée il y a plus d'un an ( Ethernet 1 Gbps multiplexé? ), Je me suis mis à installer un nouveau rack avec un nouveau fournisseur d'accès à Internet avec des liaisons LACP partout. Nous en avons besoin parce que nous avons des serveurs individuels (une application, une IP) servant des milliers d’ordinateurs clients sur Internet dépassant 1 Gbps cumulatif.

Cette idée de LACP est supposée nous permettre de casser la barrière des 1 Gbps sans dépenser une fortune en commutateurs 10GoE et NIC. Malheureusement, j'ai eu quelques problèmes avec la distribution du trafic sortant. (Ceci malgré l'avertissement de Kevin Kuphal dans la question liée ci-dessus.)

Le routeur du FAI est un type de Cisco. (J'ai déduit cela de l'adresse MAC.) Mon commutateur est un HP ProCurve 2510G-24. Et les serveurs sont des HP DL 380 G5 exécutant Debian Lenny. Un serveur est un serveur en attente. Notre application ne peut pas être groupée. Voici un schéma de réseau simplifié comprenant tous les nœuds de réseau concernés avec adresses IP, adresses MAC et interfaces.

Bien qu’il ait tous les détails, c’est un peu difficile de travailler et de décrire mon problème. Donc, pour simplifier, voici un schéma de réseau réduit aux nœuds et aux liens physiques.

Je suis donc parti installer mon kit sur le nouveau rack et connecter le câblage de mon FAI à partir de leur routeur. Les deux serveurs ont une liaison LACP vers mon commutateur, et le commutateur possède une liaison 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 à destination et en provenance de chaque serveur passait par un lien physique GoE exclusivement entre le serveur à commutateur et le commutateur à routeur.

Après quelques recherches sur google et beaucoup de temps RTMF concernant la liaison de cartes réseau linux, j'ai découvert que je pouvais contrôler la liaison de cartes réseau en modifiant /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 passait du commutateur au routeur sur une seule liaison physique, encore .

Nous avons besoin de ce trafic passant par les deux liens physiques. Après avoir lu et relu le Guide de gestion et de configuration du 2510G-24 , je trouve:

[LACP utilise] des paires d'adresses source-destination (SA / DA) pour la distribution du trafic sortant sur des liaisons partagées. SA / DA (adresse source / adresse de destination) oblige le commutateur à répartir le trafic sortant vers les liaisons du groupe de lignes sur la base de paires d'adresses source / destination. Autrement dit, le commutateur envoie le trafic de la même adresse source à la même adresse de destination via le même lien partagé, et le trafic de la même adresse source à une adresse de destination différente via un lien différent, en fonction de la rotation des assignations de liens dans le coffre.

Il semble qu’une liaison liée ne présente qu’une seule adresse MAC. Par conséquent, mon chemin de serveur à routeur sera toujours sur un chemin de commutateur à routeur, car le commutateur ne voit qu’un seul MAC (et non deux - un de chaque port) pour les deux liaisons LACP.

Je l'ai. Mais voici ce que je veux:

Un commutateur HP ProCurve plus coûteux est le 2910al qui utilise des adresses source et de destination de niveau 3 dans son hachage. Dans la section "Distribution du trafic sortant sur plusieurs liaisons" du Guide de gestion et de configuration du ProCurve 2910al :

La répartition réelle du trafic sur une ligne de réseau 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 de destination IP, 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é car mon adresse source est fixe. Cela m'amène à ma question:

Comment exactement et spécifiquement le hachage LACP de couche 3 fonctionne-t-il?

J'ai besoin de savoir quelle adresse de destination est utilisée:

• l'adresse IP du client , la destination finale?
• Ou l'adresse IP du routeur , la prochaine destination de transmission du lien physique.

Nous n'avons pas encore acheté un commutateur de remplacement. S'il vous plaît, 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. L'achat d'un autre commutateur inutile n'est pas une option.

Ce que vous recherchez est généralement appelé "stratégie de transmission du hachage" ou "algorithme de transmission du hachage". Il contrôle la sélection d'un port parmi un groupe de ports agrégés permettant de transmettre une trame.

Mettre la main sur la norme 802.3ad s’est avéré difficile, car je ne suis pas disposé à dépenser de l’argent pour la réaliser. Cela dit, j’ai pu recueillir des informations auprès d’une source officieuse qui jettent la lumière sur ce que vous recherchez. Selon cette présentation du groupe d’étude haute vitesse CA IEEE 2007 de Ottawa, ON, respectant la norme 802.3ad, ne nécessite pas d’algorithmes particuliers pour le "distributeur de trames":

Cette norme ne requiert aucun algorithme de distribution particulier; toutefois, tout algorithme de distribution doit garantir que, lorsque des trames sont reçues par un collecteur de trames, comme spécifié au 43.2.3, l'algorithme ne doit pas causer: a) un ordre incorrect des trames faisant partie d'une conversation donnée, ou b) une duplication des trames . L'obligation ci-dessus de maintenir l'ordre des trames est satisfaite en s'assurant que toutes les trames composant une conversation donnée sont transmises sur une seule liaison dans l'ordre dans lequel elles sont générées par le client MAC; par conséquent, cette exigence n'implique ni l'ajout (ni la modification) d'informations dans la trame MAC, ni la mise en mémoire tampon ou le traitement de la part du collecteur de trames correspondant afin de réordonner les trames.

Ainsi, quel que soit l'algorithme utilisé par un commutateur / pilote de carte réseau pour répartir les trames transmises, il 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 du fonctionnement d'un tel algorithme. Le pilote "collage" du noyau Linux, par exemple, a une stratégie de hachage de transmission conforme à 802.3ad qui applique la fonction (voir le fichier bonding.txt dans le répertoire Documentation \ networking du source du noyau):

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

Ainsi, les adresses IP source et de destination, ainsi que les adresses MAC source et de destination, influencent 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 réfléchir à cela. L'adresse IP du routeur, dans un en-tête de trame Ethernet éloigné de votre serveur vers Internet, n'est encapsulée nulle part dans une telle trame. L' adresse MAC du routeur est présente 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 du cadre sera l'adresse du client Internet qui envoie la demande à votre serveur.

Une stratégie de hachage de transmission prenant en compte les adresses IP source et de destination, en supposant que vous disposiez d'un pool de clients très varié, devrait vous convenir. En général, des adresses IP source et / ou de destination plus variées dans le trafic traversant une telle infrastructure agrégée se traduiront par une agrégation plus efficace lorsqu'une stratégie de hachage de transmission basée sur la couche 3 est utilisée.

Vos diagrammes montrent les demandes provenant directement d’Internet directement sur les serveurs, mais il est utile de préciser les conséquences éventuelles d’un proxy sur la situation. Si vous envoyez des requêtes de clients à vos serveurs, comme le dit chris dans sa réponse, vous risquez de provoquer des goulots d'étranglement. Si ce proxy effectue la demande à partir de sa propre adresse IP source, et non de l'adresse IP du client Internet, vous aurez moins de "flux" possibles dans une stratégie de hachage de transmission strictement de couche 3.

Une stratégie de hachage de transmission peut également prendre en compte les informations de couche 4 (numéros de port TCP / UDP), pour autant qu'elles soient conformes aux exigences de la norme 802.3ad. Un tel algorithme se trouve dans le noyau Linux, comme vous l'avez mentionné dans votre question. Attention, la documentation de cet algorithme avertit qu'en raison de la fragmentation, le trafic ne suit pas nécessairement le même chemin et que, par conséquent, l'algorithme n'est pas strictement conforme à la norme 802.3ad.

De manière très surprenante, nos tests ont montré il y a quelques jours que xmit_hash_policy = layer3 + 4 n'aura aucun effet entre deux serveurs linux directement connectés, tout le trafic utilisera un seul port. les deux fonctionnent xen avec 1 pont ayant le dispositif de liaison en tant que membre. le plus évidemment, le pont pourrait être à l'origine du problème, simplement que cela n'a aucun sens, étant donné que le hachage basé sur ip + port serait utilisé.

Je sais que certaines personnes parviennent effectivement à appliquer plus de 180 Mo de données sur les liens (utilisateurs de ceph), donc cela fonctionne en général. Points possibles à examiner: - Nous utilisions l’ancien CentOS 5.4 - L’exemple des PO signifierait que le deuxième LACP "brise les liens" - cela at-il un sens, jamais?

Ce que ce fil et la documentation en lisant, etc., etc. m'a montré:

• En général, tout le monde en sait long sur la question, sait bien réciter la théorie tirée de la procédure de création de liens ou même les normes IEEE, alors que l’expérience pratique est pratiquement 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 lors de notre test, il a perdu tout le trafic lorsqu'il est activé)
• Cela n'aide en rien que SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) et RedHat (BONDING_OPTS) disposent toutes de manières différentes de spécifier des paramètres de mode par liaison.
• Le module de noyau CentOS / RHEL5 est "SMP Safe" mais pas "SMP capable" (voir la discussion facebook à haut rendement) - il ne fait pas la mise à l'échelle au-dessus d'un processeur, donc avec une liaison d'horloge plus élevée cpu> de nombreux cœurs

Si quelqu'un finit par avoir une bonne configuration de liaison haute performance, ou s'il sait vraiment de quoi il parle, il serait génial s'il leur fallait une demi-heure pour écrire un nouveau petit howto qui documente UN exemple de travail utilisant LACP, sans trucs étranges ni bande passante > un lien

Si votre commutateur voit la vraie destination L3, il peut y avoir un hachage. Fondamentalement, si vous avez 2 liens, pensez que le lien 1 concerne les destinations impaires, le lien 2 les destinations paires. Je ne pense pas qu'ils utilisent jamais l'IP du prochain saut à moins d'être configuré pour le faire, mais c'est à peu près la même chose que d'utiliser l'adresse MAC de la cible.

Le problème que vous allez rencontrer est que, en fonction de votre trafic, la destination sera toujours l'adresse IP unique du serveur unique afin que vous n'utilisiez jamais cet autre lien. Si la destination est le système distant sur Internet, la distribution est uniforme, mais si cela ressemble à un serveur Web, où votre système correspond à l'adresse de destination, le commutateur enverra toujours du trafic sur un seul des liens disponibles.

La situation sera encore pire si un équilibreur de charge se trouve quelque part là-dedans, car alors l'adresse IP "distante" sera toujours l'adresse IP de l'équilibreur de charge ou le serveur. Vous pouvez éviter cela en utilisant de nombreuses adresses IP sur l'équilibreur de charge et le serveur, mais c'est un bidouillage.

Vous voudrez peut-être élargir un peu votre horizon de fournisseurs. D'autres fournisseurs, tels que les réseaux extrêmes, peuvent utiliser des éléments tels que:

Algorithme L3_L4: couches 3 et 4, adresses IP source et de destination combinées et numéros de port TCP et UDP de source et de destination. Disponible sur les commutateurs 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épartissez également le trafic. Je suis sûr que d'autres fournisseurs ont des fonctionnalités similaires.

Même un hachage sur les adresses IP source et de destination suffirait à éviter les points chauds, tant que vous n'avez pas d'équilibreur de charge dans le mixage.

Je devinerai que c'est hors de l'IP du client, pas du routeur. Les adresses IP de source et de destination réelles auront un décalage fixe dans le paquet, et le hachage sera rapide. Hacher le routeur IP nécessiterait une recherche basée sur le MAC, non?

Depuis que je viens de me retrouver ici, voici quelques informations que j'ai apprises: Pour éviter les cheveux gris, vous avez besoin d'un commutateur digne qui prend en charge une stratégie layer3 + 4, et la même chose sous Linux.

Dans de nombreux cas, le chalumeau standard appelé ALB / SLB (mode 6) pourrait mieux fonctionner. Opérationnellement, ça craint.

J'essaie d'utiliser 3 + 4 dans la mesure du possible, car je souhaite souvent cette bande passante entre deux systèmes adjacents.

J'ai également essayé avec OpenVSwitch et ai eu une fois où cela a perturbé les flux de trafic (chaque premier paquet perdu ... je n'en ai aucune idée)