Hallo zusammen, die Frage, auf die ich keine Antwort zu finden weiß: Wie intelligent erfolgt die Lastverteilung durch das lokale Netzwerk? Heißt am klaren Beispiel: Ich habe zu einem PC ein Ethernetkabel vom 1Gbps-Switch verlegt. Dann habe ich ja faktisch, falls auch die Netzwerkkarte unterstützt, eine 1Gbps-Verbindung ins Netzwerk (oder zumindest zum Switch). Wenn ich ein zweites Kabel zum selben PC (selbe Netzwerkkarte), zum selben Switch verlege - dann hätte ich (zumindest vom Gedankengang her) eine 2Gbps-Verbindung. Nun... die habe ich nicht. Per Traffic Analyzer habe ich zwar vereinzelt Daten auf der zweiten Anbindung, jedoch ganz sicher keine erwarteten 50%. Kann mir da einer vielleicht erklären, was da los ist? Unterstützt das Protokoll kein Clustering? (bin ein ziemlicher Anfänger, schlage mich gerade durch die Domänen im lokalen Netzwerk durch)
:
Verschoben durch User
Note schrieb: > Wenn ich ein zweites Kabel zum selben PC (selbe Netzwerkkarte), zum > selben Switch verlege - dann hätte ich (zumindest vom Gedankengang her) > eine 2Gbps-Verbindung. Nein, hast du nicht. Wir haben beispielsweise bei einigen unserer Red Hat -Maschinen von 2-fach auf 4-fach Bonding umgestellt. Das heisst jedoch nicht, das der Durchsatz sich dadurch verdoppelt. Der Grund liegt daran, dass sich die Netzwerkpakete beim Bonding-Mode 802.3ad (LACP) nicht gleichmaessig ueber alle Verbindungen zum Switch verteilen. Beim Linux-Maschinen sollte man noch die Hash-Policy "layer2+3" einstellen, um die Bonding-Verteilung ueber alle Interfaces zu verbessern. Am Switch gibt es aehnliche Moeglichkeiten.
Eventuell musst du diese erst im Switch und am rechner aktivieren. Dann gibt es verschiedene Profile wie diese vorgenommen wird (round Robin, hash über l2,...) wie gut das ganze ist hängt dann natürlich auch davon mit ab
Note schrieb: > Wenn ich ein zweites Kabel zum selben PC (selbe Netzwerkkarte), zum > selben Switch verlege - dann hätte ich (zumindest vom Gedankengang her) > eine 2Gbps-Verbindung. Ich lese nix von der Konfiguration des Switches selbst. Mit "dummen" Switches geht das nicht, die müssten wenigstens "Smart" (konfigurierbar) sein.
Angehängte Dateien:
-
intel_lagg.png
44 KB
Unter Windows ist das bissle blöd. Man braucht die richtigen
Netzwerkkarten. Besser gesagt die richtigen Treiber. Mit Intel und
Broadcom Multiport Server Karten hab ich bislang gute Erfahrungen. Bei
den Windows-Intel-Treibern kann man "hinterher" auch noch andere fremde
Karten "hinzufügen" (z.B. die Onboard-Realtek NetzwerkKarte für 3 Gbps)
Zumindest kenne ich keine Windows-Boardmittel um das "Universell" zu
lösen, und greif da immer zu Intel Karten. Unter Linux ist das alles
nicht so dramatisch.
Und das andere Ende bzw. der Managed-Switch muss das auch können.
Stichworte sind z.B. "statische" und "dynamische" Link-Aggregation-Group
(LAGG) oder die "Billig-Variante" Adaptiver Lastenausgleich (ALB). Das
kann Herstellerübergreifend immer mal leicht anders beschriftet sein.
I.d.R:
> 802.3ad LACP
Alle Ports müssen die selben Geschwindigkeiten und Duplex-Einstellungen
haben.
Beispiel Bild:
Aus den beiden physischen Verbindungen "LAN-Verbindung 2" und
"LAN-Verbindung 3" wird hinterher die virtuelle LAGG "LAN-Verbindung 4"
geschaffen, und nur noch in dieser werden die IP-Einstellungen
vorgenommen.
:
Bearbeitet durch User
Vielen lieben Dank an euch, anscheinend habe ich außer mir selbst auch noch einen ganz "dummen" Switch :)
Note schrieb: > Nun... die habe ich nicht. Per Traffic Analyzer habe ich zwar vereinzelt > Daten auf der zweiten Anbindung, jedoch ganz sicher keine erwarteten > 50%. > > Kann mir da einer vielleicht erklären, was da los ist? Bonding/Trunking/Teaming (oder wie man es nun immer nennt) funktioniert so, dass anhand gewisser Kriterien die Pakete entweder über die eine oder die andere Strippe geleitet werden. Maximal kann man Layer3 zur Gewinnung der Kriterien heranziehen, d.h.: die IP-Adressen der beteiligten Rechner. D.h.: zwischen zwei konkreten Rechnern bleibt es immer bei der Bandbreite einer Strippe. Die höhere Bandbreite erreicht man nur, wenn mehrere Rechner beteiligt sind. Wenn z.B. zwei Clients gleichzeitig von einem Server saugen, dann kann im Idealfall die Bandbreite verdoppelt werden, die der Server liefert. Die Wahrscheinlichkeit, dass dieser günstige Fall eintritt, liegt aber bei dem beschriebenen Szenario und nur zwei Strippen halt nur bei 50%. Oder anders ausgedrückt: Das ganze macht nur Sinn, wenn es darum geht, eine vielfach genutzte Resource (AKA: Server) besser anzubinden. Oder auch zwischen kaskadierten Switchen, an denen jeweils viele Rechner hängen, die kreuz und quer miteinander kommunizieren.
c-hater schrieb: > Maximal kann man Layer3 zur Gewinnung der Kriterien heranziehen, d.h.: > die IP-Adressen der beteiligten Rechner. D.h.: zwischen zwei konkreten > Rechnern bleibt es immer bei der Bandbreite einer Strippe. Die höhere Habs nie probiert, aber mit 'round Robin' verteilt der Sender doch die Packete von einem TCP-Stream auf die Strippen, oder?
Ja das ist RRPP "Round-Robing Per Paket", das was c-hater beschreibt ist RRPD "Round Robing Per Destination".
Wobei round robin überhaupt erst einmal unterstützt sein will. Was man auf beiden Seiten einer L2-Verbindung der Fall sein sollte, also sowohl im PC/Server als auch im Switch in dem er steckt. Das ist mitnichten selbstverständlich. Ob eine voll auf Lastverteilung auch einer einzelnen L3-Verbindung konfigurierte Strecke in der Praxis dann auch wirklich schneller ist, sollte man dann ernsthaft kontrollieren. Wenn Pakete einer solchen Verbindung öfter in verdrehter Reihenfolge beim Empfänger eintreffen, kann das je nach Implementierung auch mal zu Einbrüchen kommen.
:
Bearbeitet durch User
Bei der Modellierung solcher Verbindungen sollte man auf der Rechnung haben, dass Ethernet-Adapter gegenüber dem Betriebssystem heute oft mit 64k-Frames arbeiten, die erst im sendenden Adapter in 1500er Frames aufgedröselt werden. Der empfangende Adapter sammelt die wieder ein und macht 64k-Frames draus. Das reduziert die Last für das Betriebssystem beträchtlich und ist auch in 08/15 PC-Adaptern verbreitet. Will man in einem solchen Szenario mit Lastverteilung einer einzelnen Verbindung arbeiten, also Frames einer TCP-Verbindung round robin auf die Ports verteilen, stellen sich recht interessante Fragen nach dem "wie", also durch wen und mit welchen Folgen für das System. Auch unter der Berücksichtigung der Window-Size der TCP-Verbindung. NB: Jumbo-Frames sind auch deshalb längst aus der Mode gekommen. Sie sparen zwar ein paar Prozent Frame-Overhead ein, verändern aber die Frame/Interrupt-Last im System nicht mehr.
:
Bearbeitet durch User
Draco schrieb: > Ja das ist RRPP "Round-Robing Per Paket", das was c-hater beschreibt ist > RRPD "Round Robing Per Destination". Was letzlich das einzig funktionierende ist, weil so gut wie kein normaler Client mit etwas anderem klarkommt... RRPP erfordert Anwendungen, die damit klarkommen. Die sind de facto als als Notlösungen zu betrachten. Workarounds, um aus einer bestehenden Infrastruktur noch ein wenig mehr Performance herauszuquetschen. Bis irgendwann selbst dem meist völlig inkompetenten, aber nichtsdestotrotz enscheidungsgewaltigem BWLer klar wird, dass eine Investition doch unumgänglich ist...
Wäre es denkbar/sinnvoll, die Verbindung zwischen Switch und Rechner einfach auf 10G zu heben? Setzt natürlich neuen Switch und neue Netzwerkkarte voraus, erspart aber die ganzen Konfig-Probleme.
Reinhard S. schrieb: > Wäre es denkbar/sinnvoll, die Verbindung zwischen Switch und Rechner > einfach auf 10G zu heben? Setzt natürlich neuen Switch und neue > Netzwerkkarte voraus, erspart aber die ganzen Konfig-Probleme. Natürlich ist das machbar. Ob es sinnvoll ist, hängt wie immer von den Umständen ab. Frage Nummer 1: Kann der Server, bemessen an seinem tatsächlichen Anwendungsfall, überhaupt so viel Output liefern?
@Reinhard S. Sicher geht das. Aber wäre halt leichter beim bereits vorhandenen PC und bereits vorhandenem Switch ein weiteres Netzwerkkabel zu verlegen, anstatt 3 Geräte (PC, Server, Switch) 10Gbit-fähig zu machen :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.