Portbündelung aka Trunking aka LACP

[Skysnake]

Hi Leute,

ich habe jetzt schon mehrfach hier im Forum, als auch in den Tests von Computerbase zu den Synology/QNAP etc NAS gelesen, das bei mehreren Ports zwar Portbündelung möglich sei, dies aber erst bei mehreren Clients etwas bringen würde. Ich kann diese Aussage bisher absolut nicht nachvollziehen, daher nachfolgend mal ein paar Ausführungen. Vielleicht könnt ihr ja was dazu sagen. Das geht auch explizit @Frank wegen dem Teil aus dem DS1621+ Test

Die Synology DS1621+ setzt ohne Erweiterungskarte ab Werk auf vier 1-Gigabit-Anschlüsse, die per Link Aggregation gebündelt werden können, um den parallelen Zugriff mehrerer Clients zu beschleunigen oder eine erhöhte Ausfallsicherheit zu bieten.

Also ich verwende Portbündelung in Form von LACP häufig um Server redundant ans externe Nent anschließen zu können, damit Fehlertollerant gegenüber einem Ausfall im Netz sind. Da sehe ich auch immer, dass die Bandbreite zwischen den Servern mit LACP ansteigt, aber auch externe Server, die z.B. mit 10G angebunden sind den link auslasten können. Also zumindest unter CentOS7 und 8 wird bei nem Trunk wohl dynamisches trunking mit unseren Switchen verwendet. Mich würde es jetzt sehr wundern, wenn das bei den NAS anders wäre.

Wäre schön, wenn sich jemand mit fundierten Kenntnissen, oder am Besten halt @Frank mal dazu äußern könnte. Ich kann die Aussage nämlich wie gesagt nicht nachvollziehen, oder ist das jetzt so ein Windows Ding, wobei hier einfach mal stillschweigend davon ausgegangen wurde, dass die Leute Windows benutzen?

Danke schon mal im Voraus.

 

[Donnidonis]

Ein Trunk kann auf verschiedene Weise erstellt werden, genauer gesagt das Balancing zwischen den Ports eingestellt werden. Es gibt Active-Backup verfahren, balanced-rr (RoundRobin), balanced-xor, LACP (müsste 802.3ad sein) und vielleicht noch ein bisschen mehr. Dort kannst du dann noch verschiedene Methoden einstellen, nach welchem Kriterium die verschiedenen Trunk-Member genutzt werden sollen. Entweder basierend auf Layer2 (MAC Ebene) oder Layer3 (IP Ebene).

Wenn du mehr Speed als die 1G zwischen Client und NAS willst, solltest du SMB Multichannel aktivieren und Windows 10 nutzen.

 

[Skysnake]

Ja, das mit den Modi ist mir klar, wobei zumindest bei uns am Ende das Dynamic Trunking raus kommt, wenn wir das Aufsetzen. Was anderes macht in meinen Augen auch nicht wirklich Sinn, wenn es die Hardware unterstützt. Daher ja auch meine Frage, wie es zu obiger Aussage in den Tests kommen kann.

 

[dauerbrutzler]

Naja, das Teil (ich hab den Test nur kurz überflogen) sieht jetzt nicht nach Enterprise Hardware aus.. Da dürfte also zum einen ein simples Tx-Loadbalancing per TCP Stream sein, mit mehreren Tx Adaptern und einem der Rx macht - Oder bei LACP ein Tx/Rx pro TCP Stream auf einem Adapter. Wenn du eine Datei überträgst, hast du in dem Fall auch nur einmal die Bandbreite des Adapters.

 

[commandobot]

Das Thema ist nicht neu.
computerbase.de/forum/threads/link-aggregation-schnellere-verbindung-nas-zu-pc-moeglich.1957753/
computerbase.de/forum/threads/synology-nas-link-aggregation-mit-2-switches.1907669/
computerbase.de/forum/threads/windows-10-nas-link-aggregation.1706745/
computerbase.de/forum/threads/nas-im-heimnetzwerk-link-aggregation.1587123/
computerbase.de/forum/threads/link-aggregation-bei-nas-switch-und-desktop.1221290/
computerbase.de/forum/threads/link-aggregation-beim-nas-und-switch-richtig-einrichten.1218069/

 

[Skysnake]

Ähm, das ist doch völlig unabhängig vom NIC, sondern hängt davon ab, was das OS macht und halt was der Switch kann. Also zumindest ist das mein Stand.

Ergänzung (28. Dezember 2020)

@commandobot danke für die links, aber da steht zu 90% bullshit drin...

Ein nützlicher links war dann aber doch in den links drin auf die Synology doku. Man kann also IEEE 802.3ad Dynamic Link Aggregation konfigurieren. Alles andere hätte mich auch gewundert. Es wird auch auf MLAG verwiesen. Btw. das hatte ich vorher natürlich versehentlich unterschlagen. Unsere Switche können das natürlich... Deswegen geht auch nen SCP mit 200MB/s ohne Probleme etcp.

Damit sollten dann eigentlich auch alle Argumente bezüglich fehlendem Multistream von SAMBA etc doch wegfallen unter Windows oder? Man sieht als Client ja nicht mehr, das es mehrere Streams sind. Spätestens dann nicht, wenn die Windows clients 5/10G nics drin haben.... Oder?

 

[Skysnake]

Ping

Ich würde noch immer gerne wissen, warum in den Artikeln von CB geschrieben wird, das mehrere Links mit einem Rechner nichts bringen.

 

[Donnidonis]

Weil dein PC nunmal Daten auf einer Netzwerk Schnittstelle sendet. Du kannst LACP zwar auf Layer2 Hashing stellen, aber woher soll der PC wissen, dass er ein Paket über NIC1, das andere über NIC2 senden soll? Wenn du es schaffst zwei Übertragungen über die unterschiedlichen NICs zu machen könnte es funktionieren. Aber das ist alles andere als Standard und dafür ist LACP nunmal nicht gedacht. LACP ist dafür gedacht, das mehrere Clients mit voller Geschwindigkeit arbeiten können.

Einzig Lösung von einem PC mehr Übertragungsrate zu bekommen: SAMBA3 mit Multichannel, dort ist direkt implementiert Channel aufzubauen, Daten zu splitten und wieder zusammenzuführen etc. Und diese Funktion ist bei den NAS Herstellern eben nur inoffiziell, per Anpassung der config möglich. Deshalb hat CB in ihrer Aussage auch Recht.

 

[Skysnake]

Also ich habe heute mal nochmal getestet.

2x Server mit SSD mdraid1
5GB file
MLAG, sollte aber auf das Gleiche raus kommen wie LACP auf einem Switch
Scp mit 10G IP ~700MB/s
Scp mit bond IP ~200MB/s

Und da scp sowas von seriell ist kann ich wie gesagt kein Stück nachvollziehen, warum mit LACP nicht die Bandbreite nahezu verdoppeln soll...

Settings laut cat /proc/net/bonding/bond0
Bonding Mode: IEEE 802.3ad Dynamic Link Aggregation
Transmitter Hash Policy: Player2+3 (2)

802.3ad Info
LACP rate: slow
Min links: 0
Aggregatoren selection policy (ad_select): stable

Also wie gesagt, die Technik kann das also selbst bei seriellen Verbindungen verdoppeln. Und scp ist garantiert ein einzelner Stream. Sonst würde es auch nichts bringen mehrere SCPs parallel laufen zu lassen wenn man 10G+ hat und nicht nur große files transferieren will.

Ergänzung (19. Januar 2021)

Vielleicht sorgt der Artikel hier zur Erhellung. https://de.qaz.wiki/wiki/Link_aggregation

Dort wird vom Linux bond Treiber gesprochen der halt auch Round Robin kann. Das ist aber schon sehr alt.

Ich denke man kann daher davon ausgehen, dass das jedes moderne System kann. Synology gibt z.b. das auf ihrer Supportseite auch an. Ich hatte das mal rausgesucht.

Die Frage ist halt ob es eventuell Windows nicht kann. Dann ist es aber ein Problem von Windows und kein generelles Problem...

 

[Skysnake]

Ping

 

[Skysnake]

Pong

 

[dzorg]

Laut meinem Kenntnisstand implementieren Switches den IEEE 802.3ad Standard (heute unter IEEE 802.1AX-2008 geführt). "Dynamic Link Aggregation" bedeutet in dem Zusammenhang aber lediglich, dass LACP für die Aushandlung der LAG genutzt wird, anstatt es "statisch" ohne Kontrollprotokoll zu fahren. Das hat noch nichts mit dynamischer Aufteilung eines Datenstroms auf alle verfügbaren Leitungen der LAG zu tun.

Bei Switches ist mir nur die Betriebsart mit Hash-Bildung bekannt, um für ein Datenpaket den ausgehenden Port innerhalb einer LAG auszuwählen. Solange also nur ein Datenstrom läuft, dessen Quell- und Zieladressen (L2, L3, L4, je nach Einstelllunge des Switches) sich nicht ändern, wird der Datenstrom immer die gleiche Leitung nehmen und ist daher auf dessen Portspeed begrenzt. Liegen zwei Datenströme an (oder ein Filetransfer wird auf mehrere Streams aufgeteilt), kann sogar der ungünstige Fall eintreten, dass sie beide die gleiche Leitung nehmen und die restlichen ungenutzt sind.

Wie gesagt: Das obige gilt nur für den Datenverkehr, der den Switch verlässt. Die andere Datenrichtung wird vom Endgerät bestimmt. Wenn dieses beispielsweise round-robin nutzt, ist das für den Switch irrelevant. Allerdings frage ich mich hier, wieso das Quell-System bereits das nächste Paket über Leitung 2 schicken sollte, bevor das vorherige auf Leitung 1 abgearbeitet ist. Da hätte ich starke Bedenken hinsichtlich Out-of-Order-Packets am Zielsystem. Das Paket auf Leitung 1 ist ja weiterhin auf deren Speed begrenzt und verlässt nicht plötzlich doppelt so schnell den Port, nur weil noch eine weitere Leitung im LAG ist. Der begrenzende Faktor sollte hier demnach weiterhin der Speed einer Einzelleitung sein, auch bei round-robin-Betrieb.

Natürlich gibt es gerade im Enterprise-Umfeld heutzutage noch weitaus ausgefeiltere Methoden. Nimmt man beispielsweise Ethernet Fabrics (Brocade / Extreme Networks VDX Serie), so werden dort alle Inter-Switch-Links gleichermaßen belastet, solange die Pfadlänge/Metric zwischen zwei Hops identisch ist. Selbst wenn nur ein Datenstrom läuft. Hier wird tatsächlich per-packet-loadbalancing gemacht. Diese Implementierung hat allerdings nichts mehr mit dem oben angesprochenen Standard zu tun; hier kommt TRILL zum Einsatz.