Trunking / Link Aggregation Problem
Artur Kawa
ich habe zwei Rechner mit Intel PT 1000 Dual Port NICs
ausgestattet. Die Rechner haben das BS Win Server 2008 und
im Intel NIC Treiber ist Statische Link Aggregation konfiguriert.
Beide Intel NIC Adapter sind zu einer Gruppe zusammengefasst.
Die beiden PCs habe ich mit jeweils zwei Cat6 Kabeln an einen
Netgear GS108T angeschlossen. Das ist ein Smart Managed Gigabit
Switch. Dort habe ich statische Link Aggregation aktiviert und jeweils
zwei Ports zusammengefasst, an welche die PCs angeschlossen sind.
In den Windows Kisten werden 2 GBit/s als Geschwindigkeit der
Netzwerkumgebung angezeigt. Eine Pr�fung der tats�chlichen
Datentransferrate ergibt jedoch, das 1 GBit nicht �berschritten werden!
Das Benchmark-Tool netio zeigt Werte um die max. 110000 KBit/s.
Kopieren von Dateien �berschreiten keine 100 MB/s. Obwohl die
verbaute Hardware zu dem 3-5fachen f�hig ist.
Was mache ich falsch. Bin echt am verzweifeln. Habe verschiedenes
ausprobiert: Die statische Link Aggregation, die dynamische Link
Aggregation. Eingestellt am Switch und den NICs. Auch habe ich
einen anderen Switch probiert, n�mlich den Netgear GS724Tv2,
welcher aber nur zu statischem Trunking f�hig ist. Trotzdem, das
Ergebnis blieb gleich.
Zum Schlu� habe ich jeweils ein Netzwerkkabel abgezogen und
die NICs als Single-Port konfiguriert. Die Anzeige in der
Netzwerkumgebung von Windows zeigte dann logischerweise 1
GBit/s an. Die Tests mit netio und Datei �ber Netz kopieren,
ergab exakt die gleichen Werte wie oben bei aktiviertem Trunking.
Was mache ich falsch? Ein VLAN habe ich nicht konfiguriert,
da ich keine ben�tige. Das hat ja auch mit Trunking nichts zu tun, oder?
Ich verstehe das nicht, weshalb die Datenrate bei aktiviertem
Trunking nicht doppelt so hoch war, wie bei Single-Port-Betrieb.
Werden von mir weitere Informationen ben�tigt, um zu entscheiden,
was ich falsch gemacht habe?
Danke f�r Eure Hilfe.
Gruss
Artur
P.S.
habe in mehrere Newsgroups gepostet:
de.comp.hardware.netzwerke.misc
de.comp.os.ms-windows.netzwerke
microsoft.public.de.windows.vista.netzwerk
Bastian Lutz
X-Post ohne F'up2 ist boese, F'up2dchnm.
Artur Kawa schrieb:
> ich habe zwei Rechner mit Intel PT 1000 Dual Port NICs
> ausgestattet. Die Rechner haben das BS Win Server 2008 und
> im Intel NIC Treiber ist Statische Link Aggregation konfiguriert.
> Beide Intel NIC Adapter sind zu einer Gruppe zusammengefasst.
>
> Die beiden PCs habe ich mit jeweils zwei Cat6 Kabeln an einen
> Netgear GS108T angeschlossen. Das ist ein Smart Managed Gigabit
> Switch. Dort habe ich statische Link Aggregation aktiviert und jeweils
> zwei Ports zusammengefasst, an welche die PCs angeschlossen sind.
>
> In den Windows Kisten werden 2 GBit/s als Geschwindigkeit der
> Netzwerkumgebung angezeigt. Eine Pr�fung der tats�chlichen
> Datentransferrate ergibt jedoch, das 1 GBit nicht �berschritten werden!
>
> Das Benchmark-Tool netio zeigt Werte um die max. 110000 KBit/s.
Welche Paketgroesse? Evtl. zu klein gewaehlt?
> Kopieren von Dateien �berschreiten keine 100 MB/s.
Welches Protokoll bzw. wie gemessen? SMB hat einen ziemlichen Overhead,
mit FTP waerst du da viel genauer.
> Obwohl die
> verbaute Hardware zu dem 3-5fachen f�hig ist.
Was sagt ein HD-Benchmark?
> Was mache ich falsch. Bin echt am verzweifeln. Habe verschiedenes
> ausprobiert: Die statische Link Aggregation, die dynamische Link
> Aggregation. Eingestellt am Switch und den NICs. Auch habe ich
> einen anderen Switch probiert, n�mlich den Netgear GS724Tv2,
> welcher aber nur zu statischem Trunking f�hig ist. Trotzdem, das
> Ergebnis blieb gleich.
1. Der Switch beherscht offenbar QOS -> Switch richtig konfiguriert,
Firmware-Update verfuegbar, dass das Problem behebt oder reicht evtl.
die Backplane nicht?
2. Kann man bzgl. QOS was im OS einstellen?
3. Hab bei Intel was gefunden:
"Intel� I/O Acceleration Technology (Intel� I/OAT) Drivers and System
Check Utility
Provides device drivers and checks your Windows* system for hardware and
software components necessary to run Intel� I/O Acceleration Technology."
Ich kenne mich damit zwar nicht aus, aber mir scheint es so, als ob es
dir bei der Analyse des Problems behilflich sein koennte.
Bastian Lutz
--
Wenn jemand irgendwas von Anonymitaet faselt, wenn er oder jemand
anderes (meist Newbies) darauf hingewiesen wurde, dass er einen Realname
verwenden sollte, hat er den Hinweis nicht richtig gelesen.
Christian Dürrhauer
> Ich verstehe das nicht, weshalb die Datenrate bei aktiviertem
> Trunking nicht doppelt so hoch war, wie bei Single-Port-Betrieb.
>
> Werden von mir weitere Informationen ben�tigt, um zu entscheiden,
> was ich falsch gemacht habe?
Bastian hat ja schon ein paar allgemeine zu beachtende Tips gegeben.
Konkret auf den ersten Blick sehe ich in Deiner Beschreibung nichts, wo ich
sagen w�rde "Das ist es!".
Aber folgenden Vorschlag h�tte ich noch:
-beide Maschinen mit statischem Trunking konfigurieren
-man sollte "round robin" einstellen k�nnen (zumindest bei den �lteren
Treiberversionen bei 1000MT Dual bis 13.xx wird mir das so angezeigt, dann
wird abwechselnd die eine, dann die andere Karte angesprochen). Getestet
habe ich selbst jedoch nur den FastEthernet Trunk.
-Switch ebenso statisch
-richtig verkabeln
-beide Maschinen! (sonst ist der Testcase ung�ltig - kann nur eine Seite
1GB/s liefern oder empfangen, wird die andere Seite entsprechend
ausgebremst ;-) )
Ein VLAN brauchst Du nicht zwangsweise.
Zwar ist es spekulativ, aber es ist auch m�glich, dass Deine
Switch-Hardware irgendwo limitiert ist. Bei mir wird Netgear eher nicht so
eingesetzt ;-)
HTH
--
mit freundlichen Gr��en/with kind regards
Christian D�rrhauer
I want to die peacefully, in my sleep, like my grandfather. Not screaming,
terrified, like his passengers.
Artur Kawa
und danke f�r die Hinweise.
Ich habe auch in Foren gefragt. Dort habe ich teilweise die Antwort
bekommen, dass mein Problem keines ist, sondern es so richtig ist,
wenn es so funktioniert.
Ich bekam die Aussage, dass wenn ich: PC1 und PC2 habe und beide
mit Duall Link Gigabit NICs ausgestattet habe. Dann beide Rechnern
mit jeweils zwei Netzwerkkabeln an einen Static Link Aggregation
f�higen Switch angeschlossen habe.
Also konkret, PC1 habe ich an die Ports 1 und 2 des Switches
angeschlossen.
PC2 habe ich an die Ports 7 und 8 angeschlossen.
Am Switch habe ich statisches Trunking (statisches Link Aggregation)
aktiviert und zwar so, dass der erste Trunk die Ports 1 und 2 umfasst
und der zweite Trunk die Ports 7 und 8.
Nun habe ich auf den Windows Server 2008 Kisten (PC1 und PC2)
in der Intel NIC Konfiguration beide Ports der NIC geb�ndelt und
dort im Treiber statische Link Aggregation eingestellt.
Beide Rechner zeigen 2 GBit als Verbindung an und k�nnen gegenseitig
angepingt werden.
Datendurchsatztest mit netio zeigt leider 110.000 KBit/s an.
Man hat mir in den anderen Foren gesagt, dass dies so der Normalzustand
w�re.
W�rde ich mit zwei PCs auf den mit Dual-NIC ausgestatteten Server
zugreifen, h�tte ich die 2 GBit. Von einem Rechner auf den anderen
zuzugreifen, wird jedoch immer nur 1 GBit erreicht, da der Datentransfers
von MAC zu MAC erfolgt.
Gruss
Artur
Christian Dürrhauer
zwar habe ich nicht mit Gigabitlinks getestet, sondern dasselbe nur mit
FastEthernetlinks, doch dort multipliziert sich die verf�gbare Bandbreite
mit der Anzanl der Ports. Man kann den Testcase nat�rlich nur dann nicht
nachstellen, wenn der Host, der die Messung macht, den Server k�nstlich
limitiert, z.B. weil er ein langsameres Interface hat.
Aber so schlau sollte jeder selbst sein ;-)
Artur Kawa
> zwar habe ich nicht mit Gigabitlinks getestet, sondern dasselbe nur mit
> FastEthernetlinks, doch dort multipliziert sich die verf�gbare Bandbreite
> mit der Anzanl der Ports. Man kann den Testcase nat�rlich nur dann nicht
> nachstellen, wenn der Host, der die Messung macht, den Server k�nstlich
> limitiert, z.B. weil er ein langsameres Interface hat.
Nein, der Server limitiert sicher nicht. netio wurde ja verwendet. Auch das
Raid kann 300 MB/s liefern.
Eigenartig, dass er bei Dir der Durchsatz mit Anzahl der Ports im Trunk
multipliziert und bei mir nicht. An Gigabit vs. Fast-Ethernet d�rfte es
nicht
liegen.
Die Backplane des Switches schafft ja auch ein vielfaches dessen.
Es ist zum Verzweifeln...
Gruss
Artur
Artur Kawa
> zwar habe ich nicht mit Gigabitlinks getestet, sondern dasselbe nur mit
> FastEthernetlinks, doch dort multipliziert sich die verf�gbare Bandbreite
> mit der Anzanl der Ports. Man kann den Testcase nat�rlich nur dann nicht
> nachstellen, wenn der Host, der die Messung macht, den Server k�nstlich
> limitiert, z.B. weil er ein langsameres Interface hat.
Nochmals zur Verdeutlichung, dass ich nichts missverstanden habe:
Du hast quasi zwei PCs �ber Trunking mit jeweils zwei Ports verbunden
gehabt (Fast - Ethernet) und erreichtest mit den Ports somit einen
Datendurchsatz zwischen beiden PCs von 200 MBit, also ca. 22-24 MB/s?
Gruss
Artur
Christian Dürrhauer
Wenn ich es noch richtig zusammenbekomme: bis auf die Datenrate:ja. Es
ergaben sich eher so 20MB/s. Getestet mit einem Corebuilder 3500,
Superstack 3300 und - puh - ich glaube, einer HP PCI64
Dual-FastEthernet-Karte (intel-basierend) und einer PCI-X 1000MT Dualport
Gigabit. Switchseitig waren die Links statisch getrunkt und irgendwo habe
ich RoundRobin eingestellt (ich denke, das war in dem intel-Treiber, diese
Einstellung ist wichtig - es darf kein Failover-Modus aktiv sein). Ich
musste crossover-Kabel verwenden. Bestimmt war es netio 1.19 oder 1.23
damals.
Hm. Bevor Du jetzt Panik schiebst: es k�nnte sein, dass ich was
durcheinander gebracht habe. M�glicherweise erhielt ich die 20MB/s nur
serverseitig, daf�r aber an jedem der per single-link FastEthernet
konnektierten Clients volle FastEthernet-Geschwindigkeit. Wof�r ja immer
noch die Chance besteht, dass dies das ist, was Du eigentlich willst.
Tut mir leid, ich bekomme es nicht mehr richtig zusammen und mag jetzt
eigentlich nicht umkonfigurieren ;-)
HTH
Jan Heichler
<cdu...@duerrhauer.de> wrote:
Hi!
>Wenn ich es noch richtig zusammenbekomme: bis auf die Datenrate:ja. Es
>ergaben sich eher so 20MB/s. Getestet mit einem Corebuilder 3500,
>Superstack 3300 und - puh - ich glaube, einer HP PCI64
>Dual-FastEthernet-Karte (intel-basierend) und einer PCI-X 1000MT Dualport
>Gigabit. Switchseitig waren die Links statisch getrunkt und irgendwo habe
>ich RoundRobin eingestellt (ich denke, das war in dem intel-Treiber, diese
>Einstellung ist wichtig - es darf kein Failover-Modus aktiv sein). Ich
>musste crossover-Kabel verwenden. Bestimmt war es netio 1.19 oder 1.23
>damals.
Und du hast Windows als OS verwendet?
>
>Hm. Bevor Du jetzt Panik schiebst: es k�nnte sein, dass ich was
>durcheinander gebracht habe. M�glicherweise erhielt ich die 20MB/s nur
>serverseitig, daf�r aber an jedem der per single-link FastEthernet
>konnektierten Clients volle FastEthernet-Geschwindigkeit. Wof�r ja immer
>noch die Chance besteht, dass dies das ist, was Du eigentlich willst.
Ohne der gro�e Netzwerkexperte zu sein ist mein Kenntnisstand
folgendes:
Eine TCP/IP Verbindung kann immer nur einen Link "belegen". Damit ist
eine einzelne Verbindung auch immer auf den Speed eines einzelnen
Links begrenzt. Das sieht der Standard so vor.
Es gibt verschiedene Methoden wie man entscheiden kann welchen Link
eine Verbindung nutzt.
Eventuell kann der OP mal zwei netios zwischen den Servern parallel
laufen lassen?
"RoundRobin" kenn ich eigentlich nur als "mode 0" beim Linux-Kernel
Treiber f�r trunking - damit kann man auch wirklich mit zwei
Gigabit-Links 1.5 bis 1.8 mal so schnell werden. Allerdings ist das
Nutzungsfeld sehr eingeschr�nkt, da diese Performance nur mit ziemlich
gro�en Paketen erreicht wird.
Gru�
Jan
Jan Heichler
wrote:
>> zwar habe ich nicht mit Gigabitlinks getestet, sondern dasselbe nur mit
>> FastEthernetlinks, doch dort multipliziert sich die verf�gbare Bandbreite
>> mit der Anzanl der Ports. Man kann den Testcase nat�rlich nur dann nicht
>> nachstellen, wenn der Host, der die Messung macht, den Server k�nstlich
>> limitiert, z.B. weil er ein langsameres Interface hat.
>
>Nein, der Server limitiert sicher nicht. netio wurde ja verwendet. Auch das
>Raid kann 300 MB/s liefern.
Was genau hast du eigentlich vor? Kannst du das kurz umreissen?
>Die Backplane des Switches schafft ja auch ein vielfaches dessen.
Ich denke mit 4 popeligen GigE-Links kommt selbst ein Netgear zurecht
;-P
(sorry, aber wenn man etwas mehr mit Netzwerken zu tun hat, dann ist
Netgear, D-Link, Longshine, $whatever meist ein "no-go" und man geht
eher eine Kategorie h�her - HP, Nortel, Cisco ... und ich mag den Dell
62xx noch... das bezeichnen "richtige Netzwerker" auch schon als
Schrott ...)
>Es ist zum Verzweifeln...
Es w�re interessant zu wissen warum du zwischen deinen beiden Rechnern
nun unbedingt "2GE" haben willst - eventuell kann man dann zu einer
L�sung raten die zumindest deine Anspr�che erf�llt.
Jan
Christian Dürrhauer
> Eine TCP/IP Verbindung kann immer nur einen Link "belegen". Damit ist
> eine einzelne Verbindung auch immer auf den Speed eines einzelnen
> Links begrenzt. Das sieht der Standard so vor.
jaja - der Witz am Trunk ist aber gerade, dass es EIN Link ist.
> Es gibt verschiedene Methoden wie man entscheiden kann welchen Link
> eine Verbindung nutzt.
hm, dar�ber kann man philosophieren. Ich w�rde mich jetzt auf den
Standpunkt stellen: Nur eine einzige. N�mlich durch die Vergabe von IPs an
physische Links in Verbindung mit der Routingtabelle. Was dar�ber kommt
(Metriken, Routing Protokolle) kochen auch nur mit Wasser^WTCP/IP. (Hoffe,
habe jetzt nix vergessen ;-) ) Ausnahmen vielleicht Routerprotokolle,
Failover - aber die machen im Prinzip nichts anderes als einen
Kommunikationspfad zwischen Ger�ten aufzubauen, wo die Assoziation einer IP
pro physischer Link ge�ndert wird. Also nicht wirklich passend.
> Eventuell kann der OP mal zwei netios zwischen den Servern parallel
> laufen lassen?
hm, damit testet er nur den Duplex. Da der bei Gigabit eh obligatorisch
ist, spielt der Test (fast) keine Rolle.
> "RoundRobin" kenn ich eigentlich nur als "mode 0" beim Linux-Kernel
> Treiber f�r trunking - damit kann man auch wirklich mit zwei
> Gigabit-Links 1.5 bis 1.8 mal so schnell werden. Allerdings ist das
> Nutzungsfeld sehr eingeschr�nkt, da diese Performance nur mit ziemlich
> gro�en Paketen erreicht wird.
kommt drauf an, wie das IO- und Verarbeitungsratio zu der
�bertragungsgeschwindigkeit ist, also auf gut Deutsch, die
Leistungsf�higkeit der Netzwerkkomponente. Du kannst auch mit 1500bytes
gro�en Paketen eine Gigabitleitung (fast) mit Gigabit saturieren - Du
brauchst nur ausreichend schnelle Hardware. Gigabit ist zu Core2Quad-Zeiten
fast 08/15 (extrem schlechte HW au�en vor). Was der OP vorhat sollte
problemlos m�glich sein.
Jan Heichler
<cdu...@duerrhauer.de> wrote:
>> Eine TCP/IP Verbindung kann immer nur einen Link "belegen". Damit ist
>> eine einzelne Verbindung auch immer auf den Speed eines einzelnen
>> Links begrenzt. Das sieht der Standard so vor.
>
>jaja - der Witz am Trunk ist aber gerade, dass es EIN Link ist.
*grummel* ... wenn man will kann man alles falsch verstehen.
Wenn man einen Trunk als B�ndelung mehrerer Links sieht besteht er
eben aus mehr als einem Link.
>
>> Es gibt verschiedene Methoden wie man entscheiden kann welchen Link
>> eine Verbindung nutzt.
>
>hm, dar�ber kann man philosophieren. Ich w�rde mich jetzt auf den
>Standpunkt stellen: Nur eine einzige. N�mlich durch die Vergabe von IPs an
>physische Links in Verbindung mit der Routingtabelle.
Moment. Trunks sind Layer 2. Da ist noch nix mit IP.
>Was dar�ber kommt
>(Metriken, Routing Protokolle) kochen auch nur mit Wasser^WTCP/IP. (Hoffe,
>habe jetzt nix vergessen ;-) ) Ausnahmen vielleicht Routerprotokolle,
>Failover - aber die machen im Prinzip nichts anderes als einen
>Kommunikationspfad zwischen Ger�ten aufzubauen, wo die Assoziation einer IP
>pro physischer Link ge�ndert wird. Also nicht wirklich passend.
Das Problem mit "round robin" (also dem versenden von
Ethernernet-Frames abwechselnd �ber je einen der beiden Links eines
Trunks) ist ads es auf "der anderen Seite" f�r jede Menge Overhead
sorgt. Man muss n�mlich mehr umsortieren, da Pakete die vorher quasi
sequentiell eintrafen pl�tzlich in verschiedenen Gruppen sind.
Wenn man sich z.B. die Implementierung von tlb und alb im
Linux-Treiber anschaut: das basiert auf einem Hash �ber MAC-Adressen.
Bei alb (IIRC) wird zus�tzlich noch geschaut wie die Auslastung der
einzelnen Links ist. Anhand dieser Informationen wird dann ein
Datenstrom auf einen Link gelegt.
>
>> Eventuell kann der OP mal zwei netios zwischen den Servern parallel
>> laufen lassen?
>
>hm, damit testet er nur den Duplex. Da der bei Gigabit eh obligatorisch
>ist, spielt der Test (fast) keine Rolle.
Nein. Das meinte ich nicht
Man startet einfach zwei Instanzen von netio. Dazu muss man
gegebenenfalls die Portnummern manipulieren (hoffe das geht - kenne
netio nicht so)... So das immer 2 x senden und 2 x empfangen l�uft.
Das wird nicht absolut synchron sein, doch sollte es eine Idee geben
ob es wenigstens dann > 1 GBit/s ist.
>
>> "RoundRobin" kenn ich eigentlich nur als "mode 0" beim Linux-Kernel
>> Treiber f�r trunking - damit kann man auch wirklich mit zwei
>> Gigabit-Links 1.5 bis 1.8 mal so schnell werden. Allerdings ist das
>> Nutzungsfeld sehr eingeschr�nkt, da diese Performance nur mit ziemlich
>> gro�en Paketen erreicht wird.
>
>kommt drauf an, wie das IO- und Verarbeitungsratio zu der
>�bertragungsgeschwindigkeit ist, also auf gut Deutsch, die
>Leistungsf�higkeit der Netzwerkkomponente.
Da es immer auf irgendwas ankommt ... ;-)
Wir haben damals 2 x GigE pro Server gehabt - intel-Chips.
Out-of-the-box kann wohl kein Switch vern�nftig mit dem Round-Robin
Prinzip von Linux umgehen (die L�sung war einfach zwei switche zu
nehmen - einer f�r Link0 und einer f�r Link1 pro server).
Das hat dann dazu gef�hrt das wir ca. 1.1 GBit/s Datenrate hatten.
Erst nachdem man dem Kerneltreiber des Intel-Chips einige Parameter
mitgegeben hat (coalescing off... und so zeug) ging es bis auf 1.8...
allerdings nur f�r sehr gro�e Pakete.
Und das ist keine Konfiguration die ich in einem Server wirklich
fahren m�chte - damals ging es um einen Compute Cluster und war eine
akzeptable L�sung.
>Du kannst auch mit 1500bytes
>gro�en Paketen eine Gigabitleitung (fast) mit Gigabit saturieren - Du
>brauchst nur ausreichend schnelle Hardware.
Ja. Und?
>Gigabit ist zu Core2Quad-Zeiten
>fast 08/15 (extrem schlechte HW au�en vor). Was der OP vorhat sollte
>problemlos m�glich sein.
Ich zweifle nicht daran die Pakete schnell genug liefern/verarbeiten
kann - aber was der OP beschreibt deckt sich exakt mit dem was ich als
"spezifiziertes Verhalten" kenne.
Es w�re interessant zu wissen was eigentlich erreicht werden soll -
dann k�nnte man vielleicht L�sungen aufzeigen die das Problem
erschlagen...
Jan
Christian Dürrhauer
> On Tue, 29 Sep 2009 10:39:13 +0200, Christian D�rrhauer
> <cdu...@duerrhauer.de> wrote:
>
>>> Eine TCP/IP Verbindung kann immer nur einen Link "belegen". Damit ist
>>> eine einzelne Verbindung auch immer auf den Speed eines einzelnen
>>> Links begrenzt. Das sieht der Standard so vor.
>>
>> jaja - der Witz am Trunk ist aber gerade, dass es EIN Link ist.
>
> *grummel* ... wenn man will kann man alles falsch verstehen.
:-)
Ich schrieb das nur, weil ich glaubte, Du w�rdest einen Trunk als mehrere
logische Links sehen, denn nur dann w�re Deine Argumentation bzgl. HW-Link
und TCP/IP stichhaltig. Aber ich dachte, das h�tte ich klarmachen k�nnen?
> Wenn man einen Trunk als B�ndelung mehrerer Links sieht besteht er
> eben aus mehr als einem Link.
einigen wir uns darauf, dass es einen Unterschied zwischen physischem und
logischem Link gibt.
>>> Es gibt verschiedene Methoden wie man entscheiden kann welchen Link
>>> eine Verbindung nutzt.
>>
>> hm, dar�ber kann man philosophieren. Ich w�rde mich jetzt auf den
>> Standpunkt stellen: Nur eine einzige. N�mlich durch die Vergabe von IPs an
>> physische Links in Verbindung mit der Routingtabelle.
>
> Moment. Trunks sind Layer 2. Da ist noch nix mit IP.
von Trunks schrieb ich jetzt zwar nichts, aber ja, Du hast recht. Aber
nichts anderes habe ich behauptet. Ich ging auf Deine Aussage "Es gibt
verschiedene Methoden wie man entscheiden kann welchen Link
eine Verbindung nutzt." ein und habe unterstellt, dass Du mit Verbindung
die TCP-Session meinst. Wenn Du noch auf Layer2 bezogen warst, dann mea
culpa.
>> Was dar�ber kommt
>> (Metriken, Routing Protokolle) kochen auch nur mit Wasser^WTCP/IP. (Hoffe,
>> habe jetzt nix vergessen ;-) ) Ausnahmen vielleicht Routerprotokolle,
>> Failover - aber die machen im Prinzip nichts anderes als einen
>> Kommunikationspfad zwischen Ger�ten aufzubauen, wo die Assoziation einer IP
>> pro physischer Link ge�ndert wird. Also nicht wirklich passend.
>
> Das Problem mit "round robin" (also dem versenden von
> Ethernernet-Frames abwechselnd �ber je einen der beiden Links eines
> Trunks) ist ads es auf "der anderen Seite" f�r jede Menge Overhead
> sorgt. Man muss n�mlich mehr umsortieren, da Pakete die vorher quasi
> sequentiell eintrafen pl�tzlich in verschiedenen Gruppen sind.
ok
> Wenn man sich z.B. die Implementierung von tlb und alb im
> Linux-Treiber anschaut: das basiert auf einem Hash �ber MAC-Adressen.
> Bei alb (IIRC) wird zus�tzlich noch geschaut wie die Auslastung der
> einzelnen Links ist. Anhand dieser Informationen wird dann ein
> Datenstrom auf einen Link gelegt.
ich kenne diese Varianten jetzt nicht konkret, aber dachte eigentlich, dass
die MAC-Adressen nach au�en identisch sind. So ist es bis jetzt jedenfalls
bei den Etherchannel AIX-Kisten und den Wintel-Servern mit getrunkten
Links, die ich kenne. Oder bezieht sich das nur auf die internen MACs?
>>> Eventuell kann der OP mal zwei netios zwischen den Servern parallel
>>> laufen lassen?
>>
>> hm, damit testet er nur den Duplex. Da der bei Gigabit eh obligatorisch
>> ist, spielt der Test (fast) keine Rolle.
>
> Nein. Das meinte ich nicht
>
> Man startet einfach zwei Instanzen von netio. Dazu muss man
> gegebenenfalls die Portnummern manipulieren (hoffe das geht - kenne
> netio nicht so)... So das immer 2 x senden und 2 x empfangen l�uft.
> Das wird nicht absolut synchron sein, doch sollte es eine Idee geben
> ob es wenigstens dann > 1 GBit/s ist.
das schrieb ich auch schon. Einfach zwei Clients dran, gut ist.
>>> "RoundRobin" kenn ich eigentlich nur als "mode 0" beim Linux-Kernel
>>> Treiber f�r trunking - damit kann man auch wirklich mit zwei
>>> Gigabit-Links 1.5 bis 1.8 mal so schnell werden. Allerdings ist das
>>> Nutzungsfeld sehr eingeschr�nkt, da diese Performance nur mit ziemlich
>>> gro�en Paketen erreicht wird.
>>
>> kommt drauf an, wie das IO- und Verarbeitungsratio zu der
>> �bertragungsgeschwindigkeit ist, also auf gut Deutsch, die
>> Leistungsf�higkeit der Netzwerkkomponente.
>
> Da es immer auf irgendwas ankommt ... ;-)
>
> Wir haben damals 2 x GigE pro Server gehabt - intel-Chips.
> Out-of-the-box kann wohl kein Switch vern�nftig mit dem Round-Robin
> Prinzip von Linux umgehen (die L�sung war einfach zwei switche zu
> nehmen - einer f�r Link0 und einer f�r Link1 pro server).
nagut, out-of-the-box kann eigentlich keine Hardware irgendwas, ohne dass
man Software aufspielt oder es zumindest konfiguriert ;-)
Es gibt mehrere M�glichkeiten, Trunks zu definieren, darunter IEEE802.3ad
mit LACP. Mein CoreBuilder 3500 hat bei dem Test eine statische,
propriet�re Aggregation bekommen.
> Das hat dann dazu gef�hrt das wir ca. 1.1 GBit/s Datenrate hatten.
> Erst nachdem man dem Kerneltreiber des Intel-Chips einige Parameter
> mitgegeben hat (coalescing off... und so zeug) ging es bis auf 1.8...
> allerdings nur f�r sehr gro�e Pakete.
>
> Und das ist keine Konfiguration die ich in einem Server wirklich
> fahren m�chte - damals ging es um einen Compute Cluster und war eine
> akzeptable L�sung.
>
>> Du kannst auch mit 1500bytes
>> gro�en Paketen eine Gigabitleitung (fast) mit Gigabit saturieren - Du
>> brauchst nur ausreichend schnelle Hardware.
>
> Ja. Und?
ich wollte damit nur sagen, dass Eure Hardware bei Euren Tests
offensichtlich nicht leistungsf�hig genug war ;-)
>> Gigabit ist zu Core2Quad-Zeiten
>> fast 08/15 (extrem schlechte HW au�en vor). Was der OP vorhat sollte
>> problemlos m�glich sein.
>
> Ich zweifle nicht daran die Pakete schnell genug liefern/verarbeiten
> kann - aber was der OP beschreibt deckt sich exakt mit dem was ich als
> "spezifiziertes Verhalten" kenne.
>
> Es w�re interessant zu wissen was eigentlich erreicht werden soll -
> dann k�nnte man vielleicht L�sungen aufzeigen die das Problem
> erschlagen...
das auf jeden Fall! :-)
Christian Dürrhauer
> Ich schrieb das nur, weil ich glaubte, Du w�rdest einen Trunk als mehrere
> logische Links sehen
streiche "logische".
Jan Heichler
<cdu...@duerrhauer.de> wrote:
>> *grummel* ... wenn man will kann man alles falsch verstehen.
>
>:-)
>Ich schrieb das nur, weil ich glaubte, Du w�rdest einen Trunk als mehrere
>logische Links sehen, denn nur dann w�re Deine Argumentation bzgl. HW-Link
>und TCP/IP stichhaltig. Aber ich dachte, das h�tte ich klarmachen k�nnen?
War mir nicht klar.
>
>> Wenn man einen Trunk als B�ndelung mehrerer Links sieht besteht er
>> eben aus mehr als einem Link.
>
>einigen wir uns darauf, dass es einen Unterschied zwischen physischem und
>logischem Link gibt.
Okay.
Physischer Link = "Das Kabel zwischen zwei Ports an zwei Switchen"
Logischer Link = der Trunk/Etherchannel/LAG-PORT oder wie auch immer
der Hersteller es gerade nennen will...
>> Wenn man sich z.B. die Implementierung von tlb und alb im
>> Linux-Treiber anschaut: das basiert auf einem Hash �ber MAC-Adressen.
>> Bei alb (IIRC) wird zus�tzlich noch geschaut wie die Auslastung der
>> einzelnen Links ist. Anhand dieser Informationen wird dann ein
>> Datenstrom auf einen Link gelegt.
>
>ich kenne diese Varianten jetzt nicht konkret, aber dachte eigentlich, dass
>die MAC-Adressen nach au�en identisch sind. So ist es bis jetzt jedenfalls
>bei den Etherchannel AIX-Kisten und den Wintel-Servern mit getrunkten
>Links, die ich kenne. Oder bezieht sich das nur auf die internen MACs?
Der Trunk hat nach au�en eine MAC (IIRC). Es geht nach der MAC des
Absenders. Der Server der zwei oder mehr physische Links in einem
Trunk hat kann ja nicht bestimmen auf welchem Port er Daten empf�ngt -
aber er kann entscheiden wo er Daten sendet. Und das passiert dann
halt mit einem Algorithmus wie "Hashwert der Absenderadresse" oder
Eben "Hashwert" + "Auslastung der physischen Links". Ich gehe davon
aus das auch 802.3ad das nicht anders macht.
>> Man startet einfach zwei Instanzen von netio. Dazu muss man
>> gegebenenfalls die Portnummern manipulieren (hoffe das geht - kenne
>> netio nicht so)... So das immer 2 x senden und 2 x empfangen l�uft.
>> Das wird nicht absolut synchron sein, doch sollte es eine Idee geben
>> ob es wenigstens dann > 1 GBit/s ist.
>
>das schrieb ich auch schon. Einfach zwei Clients dran, gut ist.
Okay - stimmt.
>> Da es immer auf irgendwas ankommt ... ;-)
>>
>> Wir haben damals 2 x GigE pro Server gehabt - intel-Chips.
>> Out-of-the-box kann wohl kein Switch vern�nftig mit dem Round-Robin
>> Prinzip von Linux umgehen (die L�sung war einfach zwei switche zu
>> nehmen - einer f�r Link0 und einer f�r Link1 pro server).
>
>nagut, out-of-the-box kann eigentlich keine Hardware irgendwas, ohne dass
>man Software aufspielt oder es zumindest konfiguriert ;-)
�hm... es kann einfach kein Switch - denn das was Linux macht n�mlich
die Frames immer auf nem anderen physischen Link rausjagen ist wohl
nicht spezifiziert und wird nicht unterst�tzt. Aber das ist vielleicht
auch altes wissen....
>Es gibt mehrere M�glichkeiten, Trunks zu definieren, darunter IEEE802.3ad
>mit LACP. Mein CoreBuilder 3500 hat bei dem Test eine statische,
>propriet�re Aggregation bekommen.
Was ist ein "CoreBuilder"? ;-)
>>> Du kannst auch mit 1500bytes
>>> gro�en Paketen eine Gigabitleitung (fast) mit Gigabit saturieren - Du
>>> brauchst nur ausreichend schnelle Hardware.
>>
>> Ja. Und?
>
>ich wollte damit nur sagen, dass Eure Hardware bei Euren Tests
>offensichtlich nicht leistungsf�hig genug war ;-)
Definitiv nicht.
Das waren Xeon-Server mit 4 Cores/2CPUs @3.0 Ghz. Viel schneller
konnte man damals in der x86 Welt nicht sein. Mit einem einzelnen
GigE-Link kam man auf ziemlich genau 115 MB/s. Mit zwei Links und
einem eigenen Softwareprotokoll zur Verteilung der Daten
(TCP/IP-Ebene) gingen 220 MB/s (aus dem Ged�chtnis). Nur mit Trunks
ging es eben nicht hoch...wobei... 1.8 Gbit/s waren mit dem
propriet�ren trunking von Linux dann ja doch drin.
Und zur Leistungsf�higkeit: 2 x DualCore @3 GHz reicht aus um mit
1500er MTU auf nem 10GE Link immerhin 4.5 GBit/s zu erreichen. F�r
volle Geschwindigkeit muss man dann aber auf Jumbo-Frames gehen.
>> Es w�re interessant zu wissen was eigentlich erreicht werden soll -
>> dann k�nnte man vielleicht L�sungen aufzeigen die das Problem
>> erschlagen...
>
>das auf jeden Fall! :-)
Aber der OP hat sich scheinbar verkr�melt ;-)
Jan
Artur Kawa
> Es w�re interessant zu wissen warum du zwischen deinen beiden Rechnern
> nun unbedingt "2GE" haben willst - eventuell kann man dann zu einer
> L�sung raten die zumindest deine Anspr�che erf�llt.
Ja, gerne.
Eigentlich ganz einfach. M�chte von der Workstation einen Zugriff auf
das Raid auf dem Server mit deutlich mehr als 100 MB/sec haben. Denn
diese Geschwindigkeit limitiert bereits meine Arbeit.
Dachte auf diese Weise 200 MB/s erreichen zu k�nnen, was leider nicht
geht.
Das Raid auf dem Server kann knappe 400 MB/s liefern. Soeben getestet.
Gruss
Artur
Artur Kawa
> Aber der OP hat sich scheinbar verkr�melt ;-)
Nein, bin wieder da und habe oben geantwortet ;-)
Jan Heichler
wrote:
>> Es w�re interessant zu wissen warum du zwischen deinen beiden Rechnern
>> nun unbedingt "2GE" haben willst - eventuell kann man dann zu einer
>> L�sung raten die zumindest deine Anspr�che erf�llt.
>
>Ja, gerne.
>
>Eigentlich ganz einfach. M�chte von der Workstation einen Zugriff auf
>das Raid auf dem Server mit deutlich mehr als 100 MB/sec haben. Denn
>diese Geschwindigkeit limitiert bereits meine Arbeit.
>
>Dachte auf diese Weise 200 MB/s erreichen zu k�nnen, was leider nicht
>geht.
Da ergeben sich mehrere Fragen ;-)
1) Wieviele Leute greifen auf die Daten zu die auf diesem Server
liegen?
2) private oder berufliche Umgebung?
3) welche Applikation und warum sind 100 MB/s zu wenig? ;-)
4) Warum ist das RAID nicht lokal in deiner Workstation?
5) Wie gro� ist die Entfernung zwischen Server und Workstation? Und
was liegen da f�r Kabel.
>
>Das Raid auf dem Server kann knappe 400 MB/s liefern. Soeben getestet.
6) Wie getestet? - Zwischen Server und Workstation soll CIFS zum
Einsatz kommen, richtig?
Gru�
Jan