Frage Wie genau und speziell funktioniert das Hashing der Layer 3 LACP-Zieladressen?


Basierend auf einer früheren Frage vor über einem Jahr (Multiplex-1-Gbit / s-Ethernet?), Ging ich los und richtete ein neues Rack mit einem neuen ISP mit LACP-Links überall ein. Wir brauchen das, weil wir einzelne Server (eine Anwendung, eine IP) haben, die Tausende von Clientcomputern im gesamten Internet versorgen, die kumulativ über 1 GBit / s sind.

Diese LACP-Idee soll uns die 1Gbps-Grenze überwinden lassen, ohne ein Vermögen für 10GoE-Switches und NICs auszugeben. Leider habe ich Probleme mit der Verteilung des ausgehenden Datenverkehrs bekommen. (Dies trotz Kevin Kuphals Warnung in der oben verlinkten Frage.)

Der Router des ISP ist ein Cisco von irgendeiner Art. (Ich habe das aus der MAC-Adresse abgeleitet.) Mein Switch ist ein HP ProCurve 2510G-24. Und die Server sind HP DL 380 G5 mit Debian Lenny. Ein Server ist ein Hot Standby. Unsere Anwendung kann nicht gruppiert werden. Hier ist ein vereinfachtes Netzwerkdiagramm, das alle relevanten Netzwerkknoten mit IPs, MACs und Schnittstellen enthält.

alt text

Während es alle Details hat, ist es ein bisschen schwierig zu arbeiten und mein Problem zu beschreiben. Der Einfachheit halber ist hier ein Netzwerkdiagramm, das auf die Knoten und physischen Verbindungen reduziert ist.

alt text

Also ging ich los und installierte mein Kit am neuen Rack und verband die Kabel meines ISPs von ihrem Router. Beide Server haben eine LACP-Verbindung zu meinem Switch und der Switch hat eine LACP-Verbindung zum ISP-Router. Von Anfang an wurde mir klar, dass meine LACP-Konfiguration nicht korrekt war: Testen zeigte, dass der gesamte Verkehr zu und von jedem Server über eine physische GoE-Verbindung ausschließlich zwischen Server-zu-Switch und Switch-zu-Router lief.

alt text

Mit einigen Google-Suchen und viel RTMF-Zeit in Bezug auf Linux-NIC-Verbindungen entdeckte ich, dass ich die NIC-Bindung durch Modifizieren kontrollieren konnte /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

Dadurch wurde der Verkehr wie erwartet über beide NICs von meinem Server geleitet. Aber der Verkehr bewegte sich vom Switch zum Router über nur eine physische Verbindung, immer noch.

alt text

Wir brauchen diesen Verkehr über beide physikalischen Verbindungen. Nach dem Lesen und erneuten Lesen der 2510G-24 Verwaltungs- und Konfigurationshandbuch, Ich finde:

[LACP verwendet] Quelle-Zieladresse   Paare (SA / DA) zum Verteilen   ausgehender Verkehr über Bündelverbindungen.   SA / DA (Quelladresse / Ziel   Adresse) bewirkt den Wechsel zu   Verteilen Sie ausgehenden Datenverkehr an die   Links innerhalb der Trunk - Gruppe auf der   Basis der Quell- / Zieladresse   Paare. Das heißt, der Switch sendet   Verkehr von der gleichen Quelladresse   zur selben Zieladresse   durch die gleiche Bündelverbindung, und   sendet Datenverkehr von derselben Quelle   Adresse zu einem anderen Ziel   Adresse über einen anderen Link,   abhängig von der Rotation des Pfades   Zuordnungen zwischen den Links in der   Kofferraum.

Es scheint, dass eine verbundene Verbindung nur eine MAC-Adresse darstellt, und daher ist mein Server-zu-Router-Pfad immer über einen Pfad von Switch zu Router, da der Switch nur einen MAC (und nicht zwei - eins von) sieht jeden Port) für beide LACP-Links.

Ich habs. Aber das ist was ich will:

alt text

Ein teurerer HP ProCurve-Switch ist der 2910al, der in seinem Hash die Quell- und Zieladressen der Ebene 3 verwendet. Aus dem Abschnitt "Ausgehende Verkehrsverteilung über Trunk-Verbindungen" der ProCurve 2910al Verwaltungs- und Konfigurationshandbuch:

Die tatsächliche Verteilung des Verkehrs   durch einen Stamm hängt von a ab   Berechnung mit Bits aus der Quelle   Adresse und Zieladresse Wann   eine IP-Adresse ist verfügbar, die   Berechnung beinhaltet die letzten fünf   Bits der IP-Quelladresse und IP   Zieladresse, sonst der MAC   Adressen werden verwendet.

OK. Damit dies so funktioniert, wie ich es möchte, ist die Zieladresse der Schlüssel, da meine Quelladresse fest ist. Dies führt zu meiner Frage:

Wie genau und speziell funktioniert Layer-3-LACP-Hashing?

Ich muss wissen, welche Zieladresse verwendet wird:

  • die IP des Kunden, das Endziel?
  • Oder die IP des Routersdas nächste Übertragungsziel für die physikalische Verbindung.

Wir sind noch nicht gegangen und haben noch einen Ersatzschalter gekauft. Bitte helfen Sie mir, genau zu verstehen, ob das Layer 3 LACP-Zieladressen-Hashing ist oder nicht, was ich brauche. Der Kauf eines anderen nutzlosen Schalters ist keine Option.


52
2017-08-17 10:33


Ursprung


Ausgezeichnete, gut recherchierte Frage! Leider kenne ich die Antwort nicht ... - Doug Luxem
Können Sie sich die Spanning-Tree-Kosten für jede Bridge / Trunk auf der ProCurve anschauen? - dbasnett
Auch der Staat und die Priorität? Es scheint, dass wenn HP <---> Cisco, dass die Amtsleitungen möglicherweise nicht die gleiche Priorität haben und am Ende blockiert werden. Eine Werbung für das Mischen von Verkäufern ???? - dbasnett
Dies ist möglicherweise die beste formatierte Frage, die ich bei Serverfehler gesehen habe - sclarson
Ich hoffe, dass jemand die gleiche Menge an Sorgfalt für die Antwort verwenden kann, wie für die Frage verschwendet wurde. - Neil Trodden


Antworten:


Was Sie suchen, wird häufig als "Sende-Hash-Richtlinie" oder "Sende-Hash-Algorithmus" bezeichnet. Er steuert die Auswahl eines Ports aus einer Gruppe von Aggregatports, mit denen ein Frame übertragen werden soll.

Es hat sich als schwierig herausgestellt, den 802.3ad-Standard zu nutzen, weil ich nicht bereit bin, dafür Geld auszugeben. Nachdem ich das gesagt habe, konnte ich einige Informationen aus einer halboffiziellen Quelle finden, die etwas Licht in das bringt, wonach Sie suchen. Pro diese Präsentation von der 2007 Ottawa, ON, CA IEEE High Speed ​​Study Group Sitzung Der 802.3ad-Standard schreibt keine speziellen Algorithmen für den "Frame-Distributor" vor:

Dieser Standard schreibt keinen bestimmten Verteilungsalgorithmus vor. jeder Verteilungsalgorithmus muss jedoch sicherstellen, dass der Algorithmus beim Empfang von Frames durch einen Frame Collector, wie in 43.2.3 spezifiziert, a) eine Fehlordnung von Frames, die Teil einer bestimmten Konversation sind, oder b) die Duplizierung von Frames nicht verursacht . Die obige Anforderung zur Aufrechterhaltung der Rahmenordnung wird erfüllt, indem sichergestellt wird, dass alle Rahmen, die eine bestimmte Konversation bilden, auf einer einzelnen Verbindung in der Reihenfolge übertragen werden, in der sie vom MAC-Client erzeugt werden; daher beinhaltet diese Anforderung nicht das Hinzufügen (oder Modifizieren) irgendeiner Information zu dem MAC-Rahmen, noch irgendeine Pufferung oder Verarbeitung seitens des entsprechenden Rahmenkollektors, um Rahmen neu zu ordnen.

Also, welcher Algorithmus ein Switch / NIC-Treiber verwendet, um übertragene Frames zu verteilen, muss den Anforderungen entsprechen, die in dieser Präsentation angegeben sind (die vermutlich aus dem Standard zitiert wurde). Es ist kein bestimmter Algorithmus angegeben, sondern nur ein konformes Verhalten definiert.

Obwohl kein Algorithmus angegeben ist, können wir uns eine bestimmte Implementierung ansehen, um ein Gefühl dafür zu bekommen, wie ein solcher Algorithmus funktionieren könnte. Der Bonding-Treiber des Linux-Kernels verfügt beispielsweise über eine 802.3ad-konforme Sende-Hash-Richtlinie, die die Funktion anwendet (siehe bonding.txt im Verzeichnis Documentation \ networking der Kernel-Quelle):

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

Dies hat zur Folge, dass sowohl die Quell- als auch die Ziel-IP-Adresse sowie die Quell- und Ziel-MAC-Adressen die Portauswahl beeinflussen.

Die Ziel-IP-Adresse, die bei dieser Art von Hashing verwendet wird, ist die Adresse, die im Rahmen vorhanden ist. Nimm dir eine Sekunde Zeit, darüber nachzudenken. Die IP-Adresse des Routers ist in einem Ethernet-Frame-Header, der sich von Ihrem Server zum Internet befindet, nicht in einem solchen Frame eingeschlossen. Der Router ist MAC-Adresse ist im Header eines solchen Rahmens vorhanden, aber die IP-Adresse des Routers nicht. Die Ziel-IP-Adresse, die in den Payload des Frames eingekapselt ist, ist die Adresse des Internet-Clients, der die Anfrage an Ihren Server stellt.

Eine Sende-Hash-Richtlinie, die sowohl die Quell- als auch die Ziel-IP-Adresse berücksichtigt, vorausgesetzt, Sie haben einen sehr unterschiedlichen Pool an Clients, sollte Ihnen recht gut tun. Im Allgemeinen führen unterschiedlichere Quell- und / oder Ziel-IP-Adressen in dem über eine solche aggregierte Infrastruktur fließenden Verkehr zu einer effizienteren Aggregation, wenn eine Schicht-3-basierte Sende-Hash-Richtlinie verwendet wird.

In Ihren Diagrammen werden Anfragen angezeigt, die direkt vom Internet an die Server gesendet werden. Es sollte jedoch darauf hingewiesen werden, was ein Proxy für die Situation bedeuten könnte. Wenn Sie Clientanforderungen an Ihre Server dann Proxy, wie Chris spricht in seiner Antwort darüber dann können Sie Engpässe verursachen. Wenn dieser Proxy die Anforderung von seiner eigenen Quell-IP-Adresse anstatt von der IP-Adresse des Internet-Clients aus ausführt, haben Sie weniger mögliche "Flüsse" in einer streng auf Schicht 3 basierenden Sende-Hash-Richtlinie.

Eine Hash-Übertragungsrichtlinie könnte auch Schicht-4-Informationen (TCP / UDP-Port-Nummern) berücksichtigen, solange sie die Anforderungen des 802.3ad-Standards erfüllen. Ein solcher Algorithmus ist im Linux-Kernel, wie Sie in Ihrer Frage verweisen. Beachten Sie, dass die Dokumentation für diesen Algorithmus warnt, dass der Datenverkehr aufgrund der Fragmentierung nicht unbedingt auf dem gleichen Pfad verläuft und der Algorithmus daher nicht streng 802.3ad-konform ist.


13
2017-08-19 22:47



Ja, ich habe den Linux-Server aussortiert "Hash-Richtlinie übertragen". (Eine sehr lehrreiche Erfahrung, die diese Frage möglich gemacht hat.) Es ist der verdammte Schalter, der mich in eine Gurke steckt. Danke für die Info über IP-Frames - ich bin ein bisschen schwach mit wie die unteren Ebenen des Netzwerks stapeln. In meinen Augen war der Rahmen an den Router adressiert, mit einem Ziel tiefer in der Nutzlast. : P - Stu Thompson


Sehr überraschend, vor ein paar Tagen haben unsere Tests gezeigt, dass xmit_hash_policy = layer3 + 4 keinen Effekt zwischen zwei direkt verbundenen Linux-Servern hat, der gesamte Verkehr wird einen Port benutzen. beide laufen xen mit 1 bridge, die die bonding-einrichtung als member hat. Am offensichtlichsten könnte die Brücke das Problem verursachen, nur dass es überhaupt keinen Sinn ergibt, wenn man bedenkt, dass ip + port basiertes Hashing verwendet wird.

Ich weiß, dass es einigen Leuten tatsächlich gelingt, 180 MB + über verbundene Links (d. H. Ceph-Benutzer) zu schieben, so dass es im Allgemeinen funktioniert. Mögliche Dinge zu sehen: - Wir haben altes CentOS 5.4 verwendet - Das OPs-Beispiel würde bedeuten, dass die zweite LACP die Verbindungen "aufschneidet" - macht das überhaupt Sinn?

Was dieser Thread und Dokumentation lesen usw. hat mir gezeigt:

  • Im Allgemeinen weiß jeder viel darüber, ist gut im Rezitieren von Theorie aus dem Bonding-Howto oder sogar den IEEE-Standards, während praktische Erfahrung fast keine ist.
  • Die RHEL-Dokumentation ist bestenfalls unvollständig.
  • Die Bonding-Dokumentation stammt aus dem Jahr 2001 und ist nicht aktuell genug
  • layer2 + 3-Modus ist anscheinend nicht in CentOS (es zeigt nicht in modinfo, und in unserem Test ließ es den gesamten Verkehr fallen, wenn aktiviert)
  • Es hilft nicht, dass SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) und RedHat (BONDING_OPTS) unterschiedliche Möglichkeiten haben, die Einstellungen für jeden Bindungsmodus festzulegen
  • Das CentOS / RHEL5 Kernelmodul ist "SMP-sicher", aber nicht "SMP-fähig" (siehe facebook high-performance talk) - es skaliert NICHT über einer CPU, also mit einer höheren CPU-Taktrate> viele Kerne

Ob jemand endet mit einem guten Hochleistungs-Bonding-Setup oder weiß wirklich, worüber sie reden, wäre es toll, wenn sie eine halbe Stunde brauchten, um ein neues kleines Howto zu schreiben, das ein Arbeitsbeispiel mit LACP, keine komischen Sachen und Bandbreite> eins dokumentiert Verknüpfung


5
2018-06-16 12:30



Es wird schlimmer: Verschiedene Versionen von Debian haben unterschiedliche Methoden, um die Verbindung zu konfigurieren! Ich habe tatsächlich dokumentiert, wie ich meine Bindung in einem Blogpost eingerichtet habe, der anständigen Traffic zu bekommen scheint. - Stu Thompson


Wenn Ihr Switch das wahre L3-Ziel sieht, kann er darauf hashen. Grundsätzlich, wenn Sie 2 Links haben, denken Sie, Link 1 ist für ungerade Ziele, Link 2 ist für geradzahlige Ziele. Ich glaube nicht, dass sie jemals die Next-Hop-IP verwenden, wenn sie nicht dafür konfiguriert sind, aber das ist ziemlich genau so wie die Verwendung der MAC-Adresse des Ziels.

Das Problem, mit dem Sie konfrontiert werden, besteht darin, dass das Ziel je nach Datenverkehr immer die einzelne IP-Adresse des einzelnen Servers ist, sodass Sie diesen anderen Link niemals verwenden werden. Wenn das Ziel das Remote-System im Internet ist, erhalten Sie eine gleichmäßige Verteilung. Wenn es sich jedoch um einen Webserver handelt, bei dem Ihr System die Zieladresse ist, sendet der Switch den Datenverkehr immer nur über einen der verfügbaren Links.

Sie befinden sich in einer noch schlechteren Form, wenn sich irgendwo ein Load-Balancer befindet, denn dann ist die "Remote" -IP immer entweder die IP des Load-Balancers oder der Server. Sie könnten das umgehen, indem Sie viele IP-Adressen auf dem Load-Balancer und dem Server verwenden, aber das ist ein Hack.

Vielleicht möchten Sie Ihren Lieferantenhorizont etwas erweitern. Andere Anbieter, wie zum Beispiel extreme Netzwerke, können Hashes für Dinge wie:

L3_L4 Algorithmus-Layer 3 und Layer 4, die kombinierten Quell- und Ziel-IP-Adressen und   Quell- und Ziel-TCP- und UDP-Portnummern. Verfügbar auf SummitStack und Summit   Switches der Serien X250e, X450a, X450e und X650.

So lange sich der Quellport des Clients (der sich in der Regel stark ändert) ändert, verteilen Sie den Datenverkehr gleichmäßig. Ich bin sicher, dass andere Anbieter ähnliche Funktionen haben.

Selbst Hashing auf Quell- und Ziel-IP würde ausreichen, um Hotspots zu vermeiden, solange Sie keinen Load Balancer im Mix haben.


2
2017-08-19 19:53



Vielen Dank. Kein Lastausgleich. Und ich bin nicht besorgt über eingehenden Verkehr - wir haben ein> 50: 1 out: im Verkehrsverhältnis. (Es ist eine Web-Video-Anwendung.) - Stu Thompson
Ich denke, in deinem Fall wird dir der Hash auf dem Ziel nichts bringen, da der Switch das Ziel als deinen Server sehen wird. L2 Traffic Engineering ist einfach nicht sehr gut. Und "Hash" in dieser Art von Anwendung wird ziemlich primitiv sein - Stellen Sie das Beste, was Sie tun können, ist addieren Sie alle Bits in welche Adresse (n) verwendet werden und wenn das Ergebnis 0 ist, gehen Sie einen Link oder 1 geh den anderen aus. - chris
Wie ich es von meinem obigen ProCurve 2910al Zitat verstehe, ist der Hash auf den letzten fünf Bits der Quelle und Ziel. Also, egal ob einer (mein Server) fest ist, der andere wird für fast jeden Kunden auf Stufe 3 variieren. Level 2? Das ist mein aktuelles Problem - es gibt nur eine Quelle und eine Zieladresse, gegen die gerastert werden kann. - Stu Thompson


Ich nehme an, dass es von der Client-IP, nicht vom Router ist. Die realen Quell- und Ziel-IPs liegen im Paket in einem festen Offset, und das wird schnell geschehen. Hashing der Router-IP würde eine Suche auf der Grundlage der MAC, nicht wahr?


0
2017-08-19 16:47





Da ich gerade hier gelandet bin, habe ich jetzt ein paar Dinge gelernt: Um graue Haare zu vermeiden, benötigen Sie einen anständigen Switch, der eine Layer3 + 4-Richtlinie unterstützt, und das auch unter Linux.

In einigen wenigen Fällen könnte die ALB / SLB (mode6), die pervertierende Lötlampe, besser funktionieren. Operativ ist es aber nervig.

Ich selbst versuche, wenn möglich, 3 + 4 zu verwenden, da ich diese Bandbreite oft zwischen zwei benachbarten Systemen haben möchte.

Ich habe auch mit OpenVSwitch versucht und hatte einmal Instanz, wo dieser Verkehr gestört wird (jedes erste Paket verloren ... ich habe keine Ahnung)


-1
2018-03-26 18:24