Wie genau und speziell funktioniert das LACP-Zieladressen-Hashing auf Ebene 3?

Aufgrund einer früheren Frage vor über einem Jahr ( Multiplexed 1 Gbps Ethernet? ) Habe ich ein neues Rack mit einem neuen ISP mit LACP-Verbindungen überall eingerichtet. Dies ist erforderlich, da wir über einzelne Server (eine Anwendung, eine IP-Adresse) verfügen, die Tausende von Clientcomputern im gesamten Internet mit einer Gesamtgeschwindigkeit von über 1 Gbit / s bedienen.

Diese LACP-Idee soll es uns ermöglichen, die 1-Gbit / s-Grenze zu überschreiten, ohne ein Vermögen für 10GoE-Switches und NICs auszugeben. Leider habe ich Probleme mit der Verteilung des ausgehenden Datenverkehrs. (Dies trotz der Warnung von Kevin Kuphal in der oben verlinkten Frage.)

Der Router des Internetdienstanbieters ist eine Art Cisco. (Das habe ich aus der MAC-Adresse abgeleitet.) Mein Switch ist ein HP ProCurve 2510G-24. Und die Server sind HP DL 380 G5s, auf denen Debian Lenny läuft. Ein Server ist ein Hot-Standby-Server. Unsere Anwendung kann nicht geclustert werden. Hier ist ein vereinfachtes Netzwerkdiagramm, das alle relevanten Netzwerkknoten mit IPs, MACs und Schnittstellen enthält.

Obwohl es alle Details enthält, ist es etwas schwierig, mit meinem Problem umzugehen und es zu beschreiben. Der Einfachheit halber ist hier ein Netzwerkdiagramm dargestellt, das auf die Knoten und physischen Verbindungen beschränkt ist.

Also ging ich los und installierte mein Kit im neuen Rack und verband die Verkabelung meines ISP mit dessen Router. Beide Server haben eine LACP-Verbindung zu meinem Switch und der Switch hat eine LACP-Verbindung zum ISP-Router. Von Anfang an stellte ich fest, dass meine LACP-Konfiguration nicht korrekt war: Tests ergaben, dass der gesamte Datenverkehr zu und von jedem Server über eine physische GoE-Verbindung ausschließlich zwischen Server-zu-Switch und Switch-zu-Router übertragen wurde.

Mit einigen Google-Suchen und viel RTMF-Zeit in Bezug auf das Binden von Linux-Netzwerkkarten habe ich festgestellt, dass ich das Binden von Netzwerkkarten durch Ändern steuern kann /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 Datenverkehr, der meinen Server verlässt, wie erwartet über beide Netzwerkkarten übertragen. Der Datenverkehr wurde jedoch immer noch über nur eine physische Verbindung vom Switch zum Router geleitet .

Wir brauchen diesen Datenverkehr über beide physischen Verbindungen. Nach dem Lesen und erneuten Lesen des Verwaltungs- und Konfigurationshandbuchs für den 2510G-24 finde ich Folgendes :

[LACP verwendet] Quell-Ziel-Adresspaare (SA / DA) zum Verteilen des ausgehenden Datenverkehrs über Bündelverbindungen. SA / DA (Quelladresse / Zieladresse) bewirkt, dass der Switch den ausgehenden Verkehr auf der Grundlage von Quell- / Zieladressenpaaren auf die Verbindungen innerhalb der Trunk-Gruppe verteilt. Das heißt, der Switch sendet Verkehr von derselben Quelladresse zu derselben Zieladresse über dieselbe Bündelverbindung und Verkehr von derselben Quelladresse zu einer anderen Zieladresse über eine andere Verbindung, abhängig von der Rotation der Pfadzuweisungen zwischen den Links im Kofferraum.

Es sieht so aus, als ob eine geklebte Verbindung nur eine MAC-Adresse enthält, und daher wird mein Server-zu-Router-Pfad immer über einen Pfad von Switch zu Router verlaufen, da der Switch nur einen MAC sieht (und nicht zwei - einen von jeden Port) für beide LACP-Verbindungen.

Verstanden. Aber das ist was ich will:

Ein teurerer HP ProCurve Switch ist der 2910al, der Quell- und Zieladressen der Stufe 3 in seinem Hash verwendet. Im Abschnitt "Verteilung des ausgehenden Datenverkehrs über gebündelte Verbindungen" des ProCurve 2910al-Handbuchs für Verwaltung und Konfiguration :

Die tatsächliche Verteilung des Verkehrs durch eine Amtsleitung hängt von einer Berechnung ab, die Bits aus der Quelladresse und der Zieladresse verwendet. Wenn eine IP-Adresse verfügbar ist, werden die letzten fünf Bits der IP-Quelladresse und der IP-Zieladresse berechnet, andernfalls werden die MAC-Adressen verwendet.

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

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

Ich muss wissen, welche Zieladresse verwendet wird:

• die IP des Kunden , das Endziel?
• Oder die IP des Routers , das nächste Übertragungsziel der physischen Verbindung.

Wir haben noch keinen Ersatzschalter gekauft. Bitte helfen Sie mir, genau zu verstehen, ob der Layer-3-LACP-Zieladressenhashing das ist, was ich benötige oder nicht. Der Kauf eines weiteren unbrauchbaren Schalters ist keine Option.

Was Sie suchen, wird im Allgemeinen als "Hash-Übertragungsrichtlinie" oder "Hash-Übertragungsalgorithmus" bezeichnet. Es steuert die Auswahl eines Ports aus einer Gruppe von zusammengefassten Ports, mit denen ein Frame übertragen werden soll.

Es hat sich als schwierig erwiesen, den 802.3ad-Standard in den Griff zu bekommen, da ich nicht bereit bin, dafür Geld auszugeben. Trotzdem konnte ich einige Informationen von einer halboffiziellen Quelle abrufen, die etwas Licht auf das wirft, wonach Sie suchen. Gemäß dieser Präsentation der IEEE-Hochgeschwindigkeitsstudiengruppe von Ottawa, ON, CA (2007), die den 802.3ad-Standard erfüllt, werden keine bestimmten Algorithmen für den "Frame Distributor" vorgeschrieben:

Dieser Standard schreibt keine bestimmten Verteilungsalgorithmen vor. Jeder Verteilungsalgorithmus muss jedoch sicherstellen, dass der Algorithmus beim Empfang von Frames durch einen Frame Collector gemäß 43.2.3 nicht a) eine falsche Reihenfolge von Frames verursacht, die Teil einer bestimmten Konversation sind, oder b) eine Duplizierung von Frames . Die obige Anforderung zur Aufrechterhaltung der Frame-Reihenfolge wird erfüllt, indem sichergestellt wird, dass alle Frames, aus denen eine bestimmte Konversation besteht, auf einer einzigen Verbindung in der Reihenfolge übertragen werden, in der sie vom MAC-Client generiert wurden. Daher beinhaltet diese Anforderung weder das Hinzufügen (oder Ändern) von Informationen zum MAC-Frame noch das Puffern oder Verarbeiten seitens des entsprechenden Frame Collector, um Frames neu zu ordnen.

Unabhängig davon, welchen Algorithmus ein Switch / NIC-Treiber zum Verteilen übertragener Frames verwendet, müssen die in dieser Präsentation (die vermutlich aus dem Standard zitiert wurde) angegebenen Anforderungen eingehalten werden. 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 Linux-Kernel-Bonding-Treiber verfügt beispielsweise über eine 802.3ad-kompatible Übertragungs-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 bewirkt, dass sowohl die Quell- und Ziel-IP-Adressen als auch 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 Frame vorhanden ist. Nehmen Sie sich eine Sekunde Zeit, um darüber nachzudenken. Die IP-Adresse des Routers in einem Ethernet-Frame-Header, der von Ihrem Server zum Internet entfernt ist, ist in einem solchen Frame nirgendwo gekapselt. Die MAC-Adresse des Routers ist im Header eines solchen Frames enthalten, die IP-Adresse des Routers jedoch nicht. Die Ziel-IP-Adresse, die in der Nutzlast des Frames enthalten ist, ist die Adresse des Internet-Clients, der die Anfrage an Ihren Server sendet.

Eine Übertragungs-Hash-Richtlinie, die sowohl die Quell- als auch die Ziel-IP-Adresse berücksichtigt, vorausgesetzt, Sie verfügen über einen sehr unterschiedlichen Pool von Clients, sollte für Sie eine gute Leistung bringen. Im Allgemeinen führen unterschiedlichere Quell- und / oder Ziel-IP-Adressen im Verkehr, der über eine solche aggregierte Infrastruktur fließt, zu einer effizienteren Aggregation, wenn eine Layer-3-basierte Übertragungs-Hash-Richtlinie verwendet wird.

Ihre Diagramme zeigen Anforderungen, die direkt aus dem Internet an die Server gesendet werden. Es lohnt sich jedoch, darauf hinzuweisen, wie ein Proxy die Situation beeinflussen kann. Wenn Sie Client-Anfragen an Ihre Server weiterleiten, kann es zu Engpässen kommen, über die Chris in seiner Antwort spricht . Wenn dieser Proxy die Anforderung von seiner eigenen Quell-IP-Adresse anstelle der IP-Adresse des Internet-Clients ausführt, haben Sie weniger mögliche "Flows" in einer streng auf Layer 3 basierenden Übertragungs-Hash-Richtlinie.

Eine Übertragungs-Hash-Richtlinie könnte auch Layer-4-Informationen (TCP / UDP-Portnummern) berücksichtigen, sofern diese den Anforderungen des 802.3ad-Standards entsprechen. Ein solcher Algorithmus befindet sich im Linux-Kernel, wie Sie in Ihrer Frage verweisen. Beachten Sie, dass in der Dokumentation zu diesem Algorithmus darauf hingewiesen wird, dass der Datenverkehr aufgrund der Fragmentierung möglicherweise nicht auf demselben Pfad verläuft und der Algorithmus daher nicht strikt 802.3ad-konform ist.

sehr überraschend, vor ein paar tagen haben unsere tests gezeigt, dass xmit_hash_policy = layer3 + 4 zwischen zwei direkt verbundenen linuxservern keine auswirkung hat, der gesamte verkehr wird einen port benutzen. beide laufen xen mit 1 brücke, die die bindevorrichtung als glied hat. Am offensichtlichsten ist, dass die Bridge das Problem verursachen könnte, nur dass es überhaupt keinen Sinn ergibt, wenn man bedenkt, dass IP + Port-basiertes Hashing verwendet wird.

Ich weiß, dass es einige Leute tatsächlich schaffen, 180 MB + über gebundene Links (dh Ceph-Benutzer) zu pushen, so dass es im Allgemeinen funktioniert. Mögliche Dinge, die Sie sich ansehen sollten: - Wir haben das alte CentOS 5.4 verwendet - Das OP-Beispiel würde bedeuten, dass das zweite LACP die Verbindungen "enttäuscht" - macht das jemals Sinn?

Was dieser Thread und das Lesen der Dokumentation usw. usw. mir gezeigt hat:

• Im Allgemeinen weiß jeder viel darüber, kann die Theorie gut aus dem Bonding-Howto oder sogar den IEEE-Standards rezitieren, während die praktische Erfahrung bei weitem nicht vorhanden ist.
• Die RHEL-Dokumentation ist bestenfalls unvollständig.
• Die Bonddokumentation stammt aus dem Jahr 2001 und ist nicht aktuell genug
• Der Layer2 + 3-Modus ist anscheinend nicht in CentOS (er wird in Modinfo nicht angezeigt und hat in unserem Test den gesamten Datenverkehr gelöscht, wenn er aktiviert ist.)
• Es hilft nicht, dass SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) und RedHat (BONDING_OPTS) unterschiedliche Möglichkeiten haben, Einstellungen für den Bond-Modus festzulegen
• Das CentOS / RHEL5-Kernel-Modul ist "SMP-sicher", aber nicht "SMP-fähig" (siehe Facebook-Hochleistungsgespräch) - es skaliert NICHT über eine CPU, also bei Bindung höherer CPU-Taktraten> vieler Kerne

Wenn irgendjemand ein gutes Hochleistungs-Bonding-Setup hat oder wirklich weiß, wovon er spricht, wäre es fantastisch, wenn er eine halbe Stunde braucht, um ein neues kleines Howto zu schreiben, das EIN Arbeitsbeispiel mit LACP dokumentiert, keine merkwürdigen Dinge und Bandbreite > ein link

Wenn Ihr Switch das wahre L3-Ziel erkennt, kann er dies überprüfen. Grundsätzlich gilt, dass Link 1 für ungeradzahlige Ziele und Link 2 für geradzahlige Ziele gilt, wenn Sie 2 Links haben. Ich glaube nicht, dass sie jemals die Next-Hop-IP verwenden, es sei denn, sie sind dafür konfiguriert, aber das ist so ziemlich dasselbe wie die MAC-Adresse des Ziels.

Das Problem, auf das Sie stoßen werden, ist, dass abhängig von Ihrem Datenverkehr das Ziel immer die einzelne IP-Adresse des einzelnen Servers ist, sodass Sie diesen anderen Link niemals verwenden werden. Wenn das Ziel das ferne 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 über nur eine der verfügbaren Verbindungen.

Es wird noch schlimmer, wenn sich irgendwo ein Load Balancer befindet, denn dann ist die "entfernte" IP immer entweder die IP des Load Balancers oder der Server. Sie könnten das ein bisschen umgehen, indem Sie viele IP-Adressen auf dem Load Balancer und dem Server verwenden, aber das ist ein Hack.

Möglicherweise möchten Sie Ihren Anbieterhorizont ein wenig erweitern. Andere Anbieter, wie z. B. extreme Netzwerke, können Hashes für Folgendes ausführen:

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

Solange sich also der Quellport des Clients (der sich normalerweise stark ändert) ändert, wird der Datenverkehr gleichmäßig verteilt. Ich bin sicher, dass andere Anbieter ähnliche Funktionen haben.

Selbst das Speichern von Quell- und Ziel-IP-Adressen würde ausreichen, um Hotspots zu vermeiden, sofern Sie keinen Load Balancer in der Mischung haben.

Ich werde vermuten, dass es aus der Client-IP ist, nicht der Router. Die realen Quell- und Ziel-IPs haben einen festen Versatz im Paket, und das wird schnell erledigt sein. Das Hashing der Router-IP würde eine Suche basierend auf dem MAC erfordern, richtig?

Da ich gerade hier gelandet bin, habe ich ein paar Dinge gelernt: Um graues Haar zu vermeiden, brauchst du einen anständigen Switch, der eine Layer3 + 4-Richtlinie unterstützt, und dasselbe auch unter Linux.

In einigen Fällen könnte die standard-perverse Lötlampe mit der Bezeichnung ALB / SLB (Modus 6) besser funktionieren. Operativ ist es aber zum Kotzen.

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

Ich habe es auch mit OpenVSwitch versucht und hatte einmal eine Instanz, bei der der Datenverkehr unterbrochen wurde (jedes erste Paket ging verloren ... ich habe keine Ahnung)