der-phil
Goto Top

LACP vs Round-Robin-Bonding

Hallo!

Ich nutze bislang immer LACP als Bonding-Mode - sowohl zwischen Switchen, als auch bei der Anbindung von performancehungrigen Systemen.

Am Wochenende habe ich das in Frage gestellt. Bisher ging ich davon aus, dass der Bonding Modus "round-robin" nur bei Direktverbindungen zwischen Systemen möglich ist - nicht aber über Switche. Dann habe ich einige Seiten im Internet gefunden, die beschreiben, dass Round-Robin mit Switchunterstützung möglich ist.

Könnt ihr mir hier eine Denkhilfe geben?

Da LACP bei Single-Streams keinen Performancevorteil bringt, wäre dann nicht bei Servern, die häufig "schnelle 1:1 Verbindungen" nutzen es sinnvoller, als Round-Robin-Bond anzubinden?
Wie müssen hier dann die Switche konfiguriert werden? Einfach als statisches LAG?


Nutzt ihr Bonding-Mode-0 (Round-Robin)?

Danke und Grüße
Phil

Content-Key: 334729

Url: https://administrator.de/contentid/334729

Printed on: April 19, 2024 at 20:04 o'clock

Member: Anton28
Anton28 Apr 10, 2017 at 06:58:56 (UTC)
Goto Top
Guten Morgen Phil,

wäre es nicht besser, Bandbreitenhungrige System mit 10, 40 oder 100 Gigabit/s an die Switche anzubinden ?

Ich habe das Round-Robin erst bei einem System richtig funktionieren sehen und das waren IBM P Systeme.

Aber ich bin nicht der Nabel der Welt, und ich kenne nur immer einen kleinen Teil all dessen was so läuft.

Ich würde eher dazu tendieren, bandbreitengiereige System mit 10,40 oder 100 Gbit/s an die Switche anzubinden.

Gruß

Anton
Member: aqui
aqui Apr 10, 2017 at 07:54:58 (UTC)
Goto Top
Die Grundproblematik ist das Round Robin NICHT standardkonform ist sondern immer eine Hersteller proprietäre Lösung.
Der 802.3ad Standard schreibt ein Hashing Verfahren über die letzten 4 Bit der Mac- oder IP Adresse vor. Aus diesem Hash wird dann der physische Link berechnet.
Bessere Hersteller rechnen in den Hash noch den TCP oder UDP Port mit rein um mehr Entropie reinzubekommen.
Dazu kommt das die eine Seite natürlich nicht wissen kann welches hashing Verfahren die andere macht. Das wird NICHT abgestimmt zwischen beiden Enden. Es kann also gut sein das der Hinweg ein ganz anderer ist als der Rückweg.
LACP hat damit übrigens nichts zu tun, denn das negotiated rein nur Aggregation Ports beim gegenüber.

Man kann natürlich immer mit statischen LAGs arbeiten, die z.B. ein proprietäres Round Robin Verfahren machen das bedeutet dann aber nicht das auch die andere Seite das macht wenn dort normals 802.3ad konformes Hashing zum Einsatz kommt.
Keineswegs nutzen Switchhersteller dann andere Hashing Verfahren bei statischen LAGs. Dort passiert das gleiche wie mit LACP nur das eben kein LACP gemacht wird und man die LAG Ports manuell festlegen muss.
Man muss also beim LAG schon etwas genauer hinsehen wie der Traffic Flow ist und ob es mehr Sinn macht nach Macs oder IP Adressen zu hashen.
Dieser generelle Hashing Unterbau der nie homogen beidseitig ist sorgt aber immer dafür das es niemals eine homogene Auslastung von LAGs gibt. Auch nicht wenn man einseitig Round Robin macht was dann wieder proprietär ist.
Deswegen ist es oft besser dann eine sog. Fat Pipe zu nehemn also einen Link höherer Bandbreite als ein LAG Design.
In Umgebungen mit vielen Mac oder IP Adressen also großer Entropie können aber auch LAGs sinnvoll sein. Gerade wenn es um Switchkopplungen oder Server Anbindungen geht.
Das ist immer eine individuelle Designfrage. Die goldenen Daumenregel die überall passt gibt es nicht.
Mitglied: 108012
108012 Apr 10, 2017 at 08:19:07 (UTC)
Goto Top
Hallo,

LACP vs Round-Robin-Bonding
Lass uns doch einfach nur über LAG ("Link Aggregation Group") reden, denn dazu gibt es so viele unterschiedliche Begriffe, die dann
aber zum Teil wieder ganz was anderes bei anderen Herstellern bedeuten.
- Bonding - Linux allgemein
- Etherchannel - Cisco
- Trunk - führt oder transportiert im allgemeine noch VLANs darüber
- LAG dynamisch (LACP)
- LAG statisch (fest und manuell konfiguriert)

Ich nutze bislang immer LACP als Bonding-Mode - sowohl zwischen Switchen, als auch bei der Anbindung von performancehungrigen Systemen.
Man kann das benutzen für;
  • Switche - Router
  • Switche - Server
  • Switche - Switche
  • Router - Switche
  • Router - Server
  • Router - Router
  • Server - Server
  • Server - Switche
  • Server - Router

Am Wochenende habe ich das in Frage gestellt. Bisher ging ich davon aus, dass der Bonding Modus "round-robin" nur
bei Direktverbindungen zwischen Systemen möglich ist - nicht aber über Switche.
Also es gibt zwei Arten von LAGs, die einen sind dynamische und die anderen sind statische LAGs. Dynamische nimmt man
wenn man da noch öfters mal ran muss oder aber sich in der gesamten Netzwerk Struktur etwas (auch öfters) ändert.
Und statische LAGs setzt man in der Regel dort ein wo man nicht so oft ran muss oder sich dort nicht mehr so schnell
etwas ändert.

Versionen
Bei den dynamischen LAGs erledigt das mit der Konfiguration in der Regel das LACP vollautomatisch und bei den statischen LAGs
wird es vom Admin selber, also manuell, konfiguriert und von daher ist es dann immer besser wenn man Switche von ein und dem
selben Hersteller verwendet und auch Server hat die alle Merkmale eines statischen LAGs, also so wie es der Switch Hersteller anbietet,
verwenden bzw. konfigurieren kann.

Arten
Dann gibt es noch unterschiedliche Arten des Zustandes eines LAGs, also active/active und active/passiv, bei denen dann
je nach Anzahl der LAN Ports (min. 2 - max. 8) die in Benutzung sind, es gibt Konzepte die sich leider auch hierin unterscheiden
und das auch noch von Hersteller zu Hersteller unterschiedlich angeboten wird oder etwas ganz anderes bedeutet. Bei einigen
LAGs (statisch) ist es eben so das alle im LAG befindlichen Leitungen benutzt werden können und bei den dynamischen ist es
wiederum so dass dort erst eine Leitung voll sein muss bevor die nächste Leitung angefangen wird.

Balancing
Aber wenn nun schon ein statisches LAG benutzt wird, muss auch auf beiden Seiten völlig identisch eingestellt werden wie
die Leitungen (LAN Ports oder Kabel) denn nun "gefüllt oder benutzt" werden. Und dazu gibt es mehrere Verteilermethoden
wie zum Beispiel Round Robin, Weighted Round Robin und so weiter und so fort, und zusammen mit einer active/active
Einstellung werden dann alle Leitungen gleichzeitig benutzt und gleich voll in Beschlag genommen, also alle Leitungen
sind dann zu 40% gefüllt und werden benutzt und nicht wie bei LACP erst muss eine Leitung voll sein und dann wird
die nächste Leitung benutzt oder gar erst muss eine Leitung ausfallen bis die nächste Leitung benutzt wird.

Klar muss das auch dann so von allen Herstellern unterstützt und angeboten werden, also dem Router, dem Switch und
dem Server Hersteller bzw. dem Netzwerkadapter Hersteller (mittels Treibern).

Mal ein Beispiel
Dann habe ich einige Seiten im Internet gefunden, die beschreiben, dass Round-Robin mit Switchunterstützung möglich ist.
Also das ist in der Regel dann ein statisches LAG, mit active/active Unterstützung und Round Robin oder Weighted Round Robin
Algorithmus.

Könnt ihr mir hier eine Denkhilfe geben?
siehe weiter oben.

Da LACP bei Single-Streams keinen Performancevorteil bringt, wäre dann nicht bei Servern, die häufig "schnelle 1:1 Verbindungen"
nutzen es sinnvoller, als Round-Robin-Bond anzubinden?
Es kommt drauf an was wer wie und wofür benötigt und dann noch einmal wer was anbietet und wer dazu kompatibel ist!
Wenn der Server nur LAG (LACP) anbietet und der Switch auch nur, dann wird es nicht anders gehen, oder?
Bieten Switche und Server allerdings statisches LAG und auch beide RSTP und Round Robin im active/active Modus an
kann man das auch so einstellen bzw. konfigurieren. Will damit nur sagen, dass man mit Intel, Chelsio Netzwerkadaptern
und Switche oder Router nur eines Herstellers immer am besten fährt, bei solchen Sachen!!! Denn das bietet ein Höchstmaß
an Kompatibilität bei der Konfiguration an.

Wie müssen hier dann die Switche konfiguriert werden? Einfach als statisches LAG?
Alle Switch in einen Stapel im Ring packen und dann die Stapel an den Core anschließen ist hier wohl die aktuellste und
moderateste Methode zur Zeit. Allerdings kann man auch einen Switch Stapel mit sagen wir mal 4 Switchen machen
und jeder Switch hat dann 24 SFP+ Ports und dort "LAGged" man dann die Server, NAS und SAN Geräte dran mit min.
2 und max. 8 Leitungen an. Dann hat man 20, 40, 60 oder gar 80 GBit/s aggregiert an das Netzwerk angebunden. Klar
und das wurde ja auch schon von anderer Seite angesprochen wird das irgend wann zu teuer und man sollte dann evtl.
schon einmal über die Anbindung mittels 40/56 GBit/s oder gar 100/200 GBit/s mit schnellerer Hardware wie evtl. über
den Einsatz von Infiniband Leaf & Spine Switchen nachdenken um dort ein potentes SAN Netzwerk einzurichten was
man dann eben an das restliche und normale Netzwerk wieder anbindet. Allerdings ist man dann auch in einer ganz
anderen Preisklasse und Liga vertreten denn so ein Spine Switch (Mellanox SX1036) kostet eben gebraucht schon ca.
~12.000 Euro und ein Leaf Switch ist mit ca. ~5.000 Euro auch nicht billig und die Dual Port Karten (40/56 GBit/s)
kosten dann auch noch einmal ca. ~1.300 Euro pro Karte.

Nutzt ihr Bonding-Mode-0 (Round-Robin)?
Wir nutzen vereinzelt statische LAGs mit folgenden Einstellungen zusammen mit folgenden Netgear Switchen
- M7300 & M5300 Serie
- M7100 & M3300 Serie
- M4300 Serie

Statisch, active/active, Weighted Round Robin, RSTP damit auch alle Leitungen gleichzeitig benutzt werden.

Gruß
Dobby
Member: aqui
aqui Apr 10, 2017 updated at 08:39:08 (UTC)
Goto Top
aber zum Teil wieder ganz was anderes bei anderen Herstellern bedeuten.
Das ist nicht ganz richtig. Vom Verfahren her bedeuten sie alle das gleiche !
Man kann das benutzen für;
Eigentlich ALLES. Nicht nur diese speziellen Kombinationen. Alles was 802.3ad / LACP oder irgendwelche statischen Aggregation Verfahren supportet sei es in Treiber oder NIC direkt kann das face-wink
Dann gibt es noch unterschiedliche Arten des Zustandes eines LAGs, also active/active und active/passiv,
Das gibt es ausschliesslich nur bei LAGs die mit LACP arbeiten, den das ist rein LACP bezogen. Statische LAGs haben diese Zuordnung active/passive nicht.
und bei den dynamischen ist es
wiederum so dass dort erst eine Leitung voll sein muss bevor die nächste Leitung angefangen wird.
Sorry, Dobby aber das ist technisch FALSCH !
Alle Leitungen werden immer vom Hashing Verfahren benutzt. Es ist vollkommen unabhängig welchen Füllgrad der einzelne physische Link hat. Das kann das LAG Verfahren auch gar nicht wissen, denn soviel "Intelligenz" hat das gar nicht.
Der zugrundeliegende Hashing Algorythmus ist immer gleich bei dynamischen wie auch bei statischen LAGs. Klar, denn der ist immer IEEE Standard konform. Jedenfalls ist das bei Switches und Routern immer so. Bei Server OS Systemen ist es etwas anders, denn dort gibt es zusätzlich proprietäre Verfahren. Das bedingt aber auch wieder das auf der anderen Seite was Identisches sein muss. Hier hast du Recht.
also alle Leitungen sind dann zu 40% gefüllt und werden benutzt und nicht wie bei LACP erst muss eine Leitung voll sein und dann wird die nächste Leitung benutzt
Das ist technsich wieder komplett falsch. Sorry...
LACP negotiated ausschliesslich LAG fähige Ports. Es hat nichts mit dem Balancing Verfahren 802.3ad an sich zu tun. Deshalb ist es sachlich vollkommen falsch das Leitungen aufgefüllt werden usw. Siehe oben...
IP Balancing Verfahren machen sowas, niemals aber Balancing Verfahren auf dem Layer 2 wie es LAGs ja nun mal sind. Du darfst das keinesfalls mit L3 verwechseln...ganz andere Baustelle !
Das kannst du auch ganz schnell selber sehen wenn du dir die einzelnen physischen Layer 2 Link Auslastungen mal mit einem grafischen Tool ansiehst:
RX Dropped Pkts Problem
Vergiss das also bitte schnell wieder !
in der Regel dann ein statisches LAG, mit active/active Unterstützung
Gibt es wie gesagt nicht bei statischen LAGs, denn dazu ist LACP zwingend notwendig !

RSTP ist ein Spanning Tree Protokoll. Das hat übrigens mit Link Aggregation nicht das Geringste zu tun und beeinflusst das auch nicht.
Ein LAG Port wird aus Spanning Tree Sicht wie ein einzelner Port gesehen. Beeinflusst aber weder das Hashing Verfahren noch sonstwas. Ganz andere Baustelle.
Bitte Vorsichtig das du hier nicht alles im freien Fall durcheinanderbringst, denn es lesen auch Laien mit die solche falschen Fakten dann auch noch übernehmen.