Link Aggregation

[HorstCH]

Hallo Zusammen

Ich nutze zu Hause Debian auf dem Desktop (9.5) und FreeNAS (11.1-U6) als NAS-System. Beide hängen am selben Switch, weil im selben Raum, und der hängt am Router. Ich tausche öfter grosse Dateien (~50GB) zwischen den Systemen aus. Kann ich NAS und PC direkt verbinden (ich hab noch zwei Quadport GBit Karten) und mit Link Aggregation den Datendurchsatz somit erhöhen? Wenn ja wie?
Beide Rechner sollen mit dem Switch verbunden bleiben, der Datentransfer zwischen diesen beiden sollte möglichst nur über die direkte Leitung fliessen (falls möglich).
PS: Der Debian Rechner läuft auf einer SSD, und das NAS würde ich gegebenenfalls mit einer SSD beschleunigen, somit wären die Festplatten kein Flaschenhals.

[r4pt0r]

Kann ich NAS und PC direkt verbinden (ich hab noch zwei Quadport GBit Karten)

Ja

und mit Link Aggregation den Datendurchsatz somit erhöhen?

nein.

Ein Stream kann immer nur über einen Link laufen; somit ist z.b. für einen Dateitransfer nach wie vor die Bandbreite eines einzelnen (physischen) Links ausschlaggebend.

Wenn mehrere Transfers parallel laufen, können diese ggf auf die vorhandenen Links verteilt werden, hierzu sollte dann balance-rr oder balance-alb als mode gewählt werden um die last (einigermaßen) gleichmäßig zu verteilen. Je nach Treiber kann es auch nötig sein weitere flags zu setzen, da evtl die MAC oder IP ausschlaggebend für die Zuordnung des Streams ist, somit kann je IP/MAC nur 1 Link genutzt werden.

Hier eine ausführliche Erklärung des bonding unter Linux:
https://wiki.linuxfoundation.org/networking/bonding

[dufty2]

und mit Link Aggregation den Datendurchsatz somit erhöhen?

nein.

ja.

balance-rr kann das tatsächlich.
Hattu Deinen link nicht gelesen bis "MT Bonding Mode Selection for Single Switch Topology"?

Der switch wird evtl. LACP nicht können und ich weiss nicht, wie das korrekte Verkabeln bei einer p2p-Verbindung wäre.

Vermutlich wäre 10Gig-Interfaces einfacher (und brächte mehr Durchsatz),
da aber die Quad-1Gig-Karten schon vorhanden sind:
Probieren geht über Studieren!

[bluestar]

balance-rr kann das tatsächlich.

Wenn man sich die Information zu Retransmissions / TCP Reordering durchliest, dann willst du das nicht wirklich produktiv nutzen.

[dufty2]

balance-rr kann das tatsächlich.

Wenn man sich die Information zu Retransmissions / TCP Reordering durchliest, dann willst du das nicht wirklich produktiv nutzen.

Sprichst Du aus eigener Erfahrung und hast Du "nur" Text des Links gelesen?

Wenn bei mir 1,2 Gbit/s rauskäme, wäre mir das (die 4fach-Verkabelung) es nicht wert,
bei 2,5 bis 3 Gbit/s hingegen trotz TCP Reordering: Mmmh, warum nicht?
Ich schrieb' ja: Probieren geht über studieren

[catdog2]

Wenn man sich die Information zu Retransmissions / TCP Reordering durchliest, dann willst du das nicht wirklich produktiv nutzen.

Oder man probierts mal mit Multipath TCP https://en.wikipedia.org/wiki/Multipath_TCP

[BenutzerGa4gooPh]

Man nimmt am besten Standards (zumal dann, wenn es die schon seit 2014 gibt )
https://standards.ieee.org/standard/802_1AX-2014.html
(Dann klappt es nicht nur proprietär, manchmal auch mit Geräten mehrer Hersteller untereinander und "zukunftsfähig". Alte Standards werden oft bei Weiterentwicklungen berücksichtigt.)

M. W. wird die Abkürzung LACP heutzutage von verschiedenen Herstellern benutzt.
https://en.wikipedia.org/wiki/Link_Aggr ... l_Protocol
Wenn das für die Absicht des TE (Durchsatzerhöhung für mehrere Streams, gleichzeitige Clients, Redundanz) nicht angemessen ist, siehe dufty2: 10 GBE.

Im Heimnetz funktioniert (auch proprietäres) Probieren über Studieren meist schneller/billiger - zumal wenn entsprechende Netzwerkadapter vorhanden sind und man nicht über einen Switch eines andereren Herstellers verbinden muss, eine (zusätzliche) Direktverbindung zwischen zwei gleichen Adaptern nutzen kann - und wohl besser sollte, wenn der Switch von anderem Hersteller ist und vmtl. eh zu wenig Ports für LAG/LACP hat. M. E. beabsichtigt der TE auch eine zusätzliche Direktverbindung zwischen 2 Netzwerkadaptern. Hoffentlich des gleichen professionellen Herstellers für erfolgreiche proprietäre Basteleien.

Jedenfalls wären Links auf Datenblätter von Netzwerkadaptern und Switch interessant gewesen. Vielleicht kommt ja noch ein zweiter Beitrag von Horst.

[r4pt0r]

und mit Link Aggregation den Datendurchsatz somit erhöhen?

nein.

ja.

balance-rr kann das tatsächlich.
Hattu Deinen link nicht gelesen bis "MT Bonding Mode Selection for Single Switch Topology"?

Der switch wird evtl. LACP nicht können und ich weiss nicht, wie das korrekte Verkabeln bei einer p2p-Verbindung wäre.

Vermutlich wäre 10Gig-Interfaces einfacher (und brächte mehr Durchsatz),
da aber die Quad-1Gig-Karten schon vorhanden sind:
Probieren geht über Studieren!

Das letzte mal als ich balance-rr getestet habe brach der link unter starker last regelmäßig ein (retransmissions) - Auch bei direkter Verbindung mit identisch langen kabeln. Ursache dürften wohl die queues sein.... Dazu kommt, dass balance-rr wohl eine linux-spezifische implementierung (oder zumindest mit einigen Eigenheiten) ist - interoperabilität zu anderen Platformen also nahe 0. Die links fielen an cisco catalyst auch regelmäßig auf einen link zurück.
Habe das damals nicht weiter verfolgt und einfach 10GbE verbaut - schneller, einfacher, stabiler und problemlos auch bei geswitchten verbindungen....

Ansonsten: bei LAG über/zwischen verschiedenen (hw)platformen sollte man möglichst beim standardisierten 802.3ad Modus bleiben - das erspart Ausfälle und Kopfschmerzen und hat auch zwischen verschiedenen Switchherstellern i.d.r. die kürzesten Zeiten beim Verbindungsaufbau. Andere modi können u.U. mehrere Sekunden zum aushandeln und aktivieren eines links benötigen; manche switches crashen auch gerne bei unbekanntem LACP Modus (Netgear "small business" Schrott... )

Die einzigen Protokolle bei denen m.E. das zusammenfassen der gesamten verfügbaren Bandbreite tatsächlich problemlos funktioniert sind PAgP oder MC-LAG/VPC für Port-/Etherchannel über verschiedene pfade/switches/chassis. Das sind aber alles cisco-spezifische protokolle, also nur für switch-uplinks geeignet, nicht für client-uplinks.


Die "Reihenfolge" der Kabel wird BTW durch LACP (oder ggf proprietäres Protokoll) erkannt - da gibt es also kein korrekt oder falsch. Die Reihenfolge im LAG/Etherchannel ist i.d.r. völlig unabhängig von der physischen Anordnung und ändert sich auch regelmäßig beim reboot des clients oder trennen einer/mehrerer links.