NIC Teaming / Multichannel / Switch independent

[Küstennebel 0]

Moin Forum,

 

wir sind gerade dabei unseren neuen Server 2016 Standard aufzusetzen, der nun endlich unseren alten Server 2003 ablösen soll. In unserer kleinen Firma ist der Server sowohl DC als auch File- und Druckserver (so wie der alte auch).

Der gekaufte Dell Rackserver bringt nun standardmäßig 4 NICs mit, die frei konfiguriert werden können. Beim alten Server hatten wir über den Broadcom Treiber schon damals NIC Taming für die 2 NICs aktiviert, allerdings ohne zu messen, ob das irgendwas an Durchsatzverbesserung gebracht hat. Zumindest lief es all die Jahre ohne Fehlermeldungen oder Komplikationen im LAN.

Nun arbeiten wir uns gerade in Server 2016 ein und lernten, dass das OS schon eine Teaming Funktion mitbringt, man also nicht mehr auf die Herstellertreiber angewiesen ist. Allerding gehen die Meinungen im Netz und auch hier im Forum hinsichtlich des Sinns in einfachen bzw. kleinen Umgebungen auseinander.

 

Hier mal unsere aktuellen Randbedingungen:

- Windows Server 2016 Standard mit 4 NICs (derzeit ist erst mal nur eine aktiv)

- ca. 20 Client Rechner mit aktuellem Windows 7 Professional (alle Rechner mit nur 1 NIC)

- unmanaged 48 Port Switch

 

1. Lohnt es sich, das Teaming am Server zu aktivieren, da ja mitunter mehrere User gleichzeitig auf den Server zugreifen?

2. Lohnt es sich, das Teaming erst zu aktivieren, wenn (in den nächsten Jahren) alle Clients auf W10 umgestellt worden sind?

3. Oder lohnt es sich, das Teaming zu aktivieren, wenn ein neuer Switch angeschafft wurde, der die entsprechende Funktionalität beherrscht (switch-dependent)?

 

Gruß

Jörg

[testperson 1.677]

Hi,

 

solange es keine Gründe für "Switch dependent" gibt würde ich immer "Switch independent" nutzen. Anstatt den einen Switch auszutauschen wäre ein zweiter Switch hilfreicher ;)

 

Gruß

Jan

[NorbertFe 2.035]

Dann müssten die Switches aber trotzdem lacp oder ein ähnliches Feature beherrschen, sonst hat er ja trotzdem nur 1gb. ;)

[lefg 276]

Moin

 

Ob es sich lohnt zu spekulieren? Ob es sich lohnt zu messen und den Verlauf aufzuzeichnen, als Graph darzustellen?

 

20 Clients, ob Wx oder W10, ob das wirklich eine wesentliche Rolle spielt? Wesentlich ist doch wohl, was und wie stark treiben es Server und Clients miteinander.

 

Ich ginge der Sache wohl mit PRTG auf den Grund, schon interessehalber.

 

Ein Netzwerk ohne PRTG? Ich mag nicht mehr ohne networken. :)

bearbeitet 3. Oktober 2017 von lefg

[NorbertFe 2.035]

Nein lohnt sich sicher nicht, in meinen Augen. ;)

[Küstennebel 0]

Ihr seid ja fleißig, sogar am Feiertag. :thumb1:

 

Ein Netzwerk ohne PRTG? Ich mag nicht mehr ohne networken. :)

Klingt erst mal interessant, insbesondere da die 100 Sensoren Version Freeware ist. Wir sind ja nur eine kleine Firma ohne IT Abteilung. Teure Netzwerküberwachung wird da nicht angeschafft. Mein Kollege und ich machen die IT quasi nebenbei mit (müssen wir jetzt an dieser Stelle nicht drüber diskutieren). Vielleicht testen wir das mal.

 

 

Dann müssten die Switches aber trotzdem lacp oder ein ähnliches Feature beherrschen, sonst hat er ja trotzdem nur 1gb. ;)

Wozu gibt es dann aber "switch independent", wenn es nichts bringt?

[magheinz 110]

wenn die bandbreite knapp wird würde ich den nächsten switch mit 10gbit kaufen. die kostenbdoch nicht mehr viel. lacp etc würde ich wegen Verdügbarkeit bauen, aber ob das hier lohnt?

[NorbertFe 2.035]

Dann hätte er aber auch einen Server mit 10G kaufen sollen. ;) Und bei 20 PCs ist das zwar nett, aber wahrscheinlich mit Kanonen auf Spatzen geschossen.

Wozu gibt es dann aber "switch independent", wenn es nichts bringt?

Hat ja niemand gesagt, dass Switch Independent "nichts bringt". Du solltest unterscheiden, zwischen Host zu Switch und Switch zu Switch Verbindung. Ich bezog mich dabei auf letzteres und da kenne ich zumindest keine Verbindungsart die "Switch Independent" funktioniert. Also bleibt dir entweder eine Verbindung auf LACP Basis oder der Switchhersteller bietet entsprechende Lösungen auf proprietärer Basis an.

 

Ich bleibe dabei, dass das Teaming in eurer Umgebung wahrscheinlich ziemlich überflüssig ist, aber wenn mans halt konfigurieren will dann eben Switch Independent. Ob man dazu dann 4 NICs teamt... Naja ich denke ihr merkt davon wohl kaum was am Ende. Probiers halt aus.

 

Bye

Norbert

[Doso 77]

NIC Teaming hat auch den angenehmen Effekt der erhöhten Ausfallsicherheit. Geht mal eine Netzwerkkarte kaputt oder zieht einer versehentlich am Server ein Kabel läuft es weiter. In der Praxis werdet ihr das aber kaum merken.

 

Wir haben es auf unseren Hyper-V Servern an da es hier teilweise positive Effekte hat wenn man einen Host per Live Migration leer macht, aber auch hier merkt man sonst kaum was davon.

 

Edit: Übrigens gibt es glaube ich keinen Upgrade Pfad direkt von Windows Server 2003 auf Windows Server 2016 bei Domänen Controllern. Da wird es einen Zwischenschritt brauchen.

bearbeitet 3. Oktober 2017 von Doso

[NilsK 2.934]

Moin,

 

die Frage ist, was ihr mit dem Teaming erreichen wollt. Wenn nur ein Switch dahintersteht, ist es weitgehend witzlos - dass eine Netzwerkkarte ausfällt, wäre eher exotisch (zumal bei einer 4-Port-Karte, was es ja wahrscheinlich ist). Ein Switch fällt eher mal aus, oder man will ihn neu starten (Firmware-Upgrade).

 

Eine Durchsatzverbesserung ist nur dann zu erwarten, wenn es mehrere "Streams" gibt, die parallel laufen können - es bleibt ja dabei, dass jede Karte nur 1 Gbit kann, das Teaming ändert daran nichts. Derselbe Datenstrom wird nicht auf zwei Karten aufgeteilt. Genau wie bei einer Bahnstrecke: Auf einem Gleis kann immer nur ein Zug mit seiner Maximalgeschwindigkeit fahren. Ein zweites Gleis erhöht nicht die Geschwindigkeit des einen Zugs, aber es kann ein zweiter gleichzeitig mit Maximalgeschwindigkeit fahren.

 

Bei dem Konstrukt würde ich über Virtualisierung nachdenken und die Dienste auf zwei VMs verteilen, das geht mit der einen Lizenz. Dann ergibt auch das Teaming ein wenig Sinn, weil dann - vereinfacht gesagt - jede VM eine NIC ausnutzen kann. Bei 20 Clients ist ein einzelner DC zu wenig, mit weniger als zwei sollte man nicht arbeiten. Da kämen dann weitere VMs (und damit weitere Lizenzen) ins Spiel.

 

Zusätzlich ist Dosos Hinweis relevant, allerdings etwas anders, als es dort steht. Um euer AD zu aktualisieren, muss der neue DC zunächst parallel zum alten laufen, um das AD übernehmen und aktualisieren zu können. Einen Zwischenschritt über eine ältere Version braucht es nicht, weil es ja kein Inplace-Upgrade ist.

 

Gruß, Nils

bearbeitet 4. Oktober 2017 von NilsK

[Küstennebel 0]

Moin,

 

 

... dass eine Netzwerkkarte ausfällt, wäre eher exotisch (zumal bei einer 4-Port-Karte, was es ja wahrscheinlich ist).

Da müssten 2 getrennte 2-Port Karten drinstecken oder auf dem Board verbaut sein. Zumindest, wenn man von der Position der RJ45 Buchsen ausgeht. Zwei befinden sich nebeneinander an der linken Seite und die zwei anderen in der Mitte der Serverrückseite.

Wir werden wohl mal zwei zu einem Team verbinden, um die Ausfallsicherheit zu erhöhen (auch wenn wir keinen zweiten Switch bekommen). Die anderen beiden deaktivieren wir dann.

In diesem Zusammenhang müssen wir nur noch herausfinden, was es mit der integrierten iDrac auf sich hat. In unserem alten Server hatten wir eine separate iDrac Karte, welche auch bei runtergefahrenem Server mit ihrer IP ansprechbar war. Darüber ließ sich dann der Server auch remote wieder hochfahren.

Bei der integrierten iDrac Funktionalität des neuen Servers konnten wir beim Setup einen NIC und eine IP für iDrac festlegen, die aber scheinbar nur im ausgeschalteten Zustand des Servers aktiv ist. Wenn der Server online ist, kann man alle 4 NICs unter Windows wieder frei konfigurieren. Na, da müssen wir mal noch ein wenig lesen und testen.

 

 

... Zusätzlich ist Dosos Hinweis relevant, allerdings etwas anders, als es dort steht. Um euer AD zu aktualisieren, muss der neue DC zunächst parallel zum alten laufen, um das AD übernehmen und aktualisieren zu können. Einen Zwischenschritt über eine ältere Version braucht es nicht, weil es ja kein Inplace-Upgrade ist.

 

Gruß, Nils

 

Hatte schon kurzzeitig rote Flecken im Gesicht bekommen, nachdem ich Doso's Hinweis gelesen hatte. :cry:  Aber nun bin ich wieder beruhigt. Der Server ist schonmal zum Mitgliedsserver gemacht worden. Demnächst wird er dann als zusätzlicher DC hochgestuft, um dann alle FSME Rollen übernehmen zu können. Aber immer Eins nach zwei Anderen.

 

Gruß

Jörg

[Otaku19 33]

netzwerkseitig is hier zu betrachtne um welche Art des teamings es sich handelt, anscheinend wird acitve/active angestrebt, das muss man schon wissen was genau da passiert, wie und wie viele MAC Adressen da ins Spiel kommen, sonst hat man sich da schnell in Aus optimiert :) auf einem unmanaged switch hat man halt keine Möglichkeiten was nachzuschauen oder per PRTG zu messen.

 

Ich würde hier auf Nummer sicher gehen, active/standby und gut ist

[Küstennebel 0]

Noch mal 'ne kurze Rückmeldung: 2 Netzwerkkarten sind jetzt zu einem Team mit Hilfe der Windows Server 2016 Bordmittel (Servermanager) zusammengefasst. Das Ganze switchunabhängig und mit dynamischem Lastenausgleich. Mehr zur Konfiguration kann ich nicht rauslesen.

 

Wir haben auch mal einen Durchsatztest mit einer 3 GB großen Datei gemacht. Auf dem alten 2003er Server mit Broadcom Teaming können wir durchschnittlich mit 96 MB/s schreiben und mit 44 MB/s lesen (warum Lesen so einbricht, weiß ich auch nicht).

Auf dem neuen 2016er Server mit Windows Teaming können wir mit ca. 114 MB/s lesen/schreiben. Das ist, meine ich, eine ganz gute Bruttorate.

Damit sollte unser Gb Netzwerk auch so ziemlich ausgereizt sein.

 

Gruß

Jörg

[NorbertFe 2.035]

Das liegt aber nicht am Team, denn das ist ziemlich genau 1gbit/s ;)

Da spielt wohl eher windows 2016 und die deutlich neuere Hardware eine Rolle.

[NilsK 2.934]

Moin,

 

kann ja auch nicht am Team liegen. Eine Datei kopieren ist ein einzelner Datenstrom. Für Multichannel-SMB dürfte es gerade kein Team sein. :D

 

Wie so oft, ist das Kopieren einer Datei als Benchmark auch hier wenig geeignet.

 

Gruß, Nils