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)
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.
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.
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?
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.
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.
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 :)
