melters
Goto Top

Windows Fileserver Performance Optimierung - zweite Netzwerkkarte - zweite IP Adresse

Hallo zusammen,

um einen Windows 2016 Fileserver etwas performanter zu gestalten hatte ich mal versucht
den Server einfach mit einer zweiten gbit Netzwerkkarte und zweiter IP Adresse im gleichen Subnetz
zu konfigurieren. Soweit hat auch alles geklappt, die zweite Netzwerkkarte bekommt nur kein Gateway eingetragen.

Die Idee war das von einem Client "A" über die IP Adresse / Netzwerkkarte "I" des Servers
das Netzlaufwerk verbunden wird und von einem Client "B" das gleiche Netzlaufwerk über die IP Adresse / Netzwerkkarte "II"
des Servers eingebunden wird. Bei der Datenübertragung dann also theoretisch 2x1 gbit unabhängig möglich sein sollte.
Beim Testen war es aber so das der Datendurchsatz nicht schneller war als bei einer IP Adresse / Netzwerkkarte
und Zugriffs von beiden Clients am Server.

Bei Ansicht des Ressourcenmonitors am Server fällt auf das der Netzwerktraffik
sich auch immer auf die zweite Netzwerkkarte zu ca. 50% verlagert, selbst wenn nur ein Client "A"
das Netzlaufwerk über IP Adresse / Netzwerkkarte "I" verbunden hat und Daten kopiert, hat auch IP Adresse / Netzwerkkarte "II" davon 50% Traffik.

Macht es überhaupt Sinn auf die Art und Weise etwas mehr Peformance heraus zu holen
und wie kommt es das der Traffic sich trotz unterschiedlicher IP Einbindung des Netzlaufwerkes
trotz auf beidem Karten verteilt und nicht die doppelte Performance möglich ist?

Bin gespannt face-smile

Content-Key: 383308

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

Ausgedruckt am: 19.03.2024 um 09:03 Uhr

Mitglied: Vision2015
Lösung Vision2015 14.08.2018 um 16:56:11 Uhr
Goto Top
Moin...
Zitat von @melters:

Hallo zusammen,

um einen Windows 2016 Fileserver etwas performanter zu gestalten hatte ich mal versucht
den Server einfach mit einer zweiten gbit Netzwerkkarte und zweiter IP Adresse im gleichen Subnetz
zu konfigurieren. Soweit hat auch alles geklappt, die zweite Netzwerkkarte bekommt nur kein Gateway eingetragen.
Netter versuch...nun das wird so nix... wenn überhaubt mit einem 10 Gbit Netzwerk... oder bei 1 Gbit, wenn die hardware mitmacht, port trunking....
Trunking
was hast du für einen switch?

Die Idee war das von einem Client "A" über die IP Adresse / Netzwerkkarte "I" des Servers
das Netzlaufwerk verbunden wird und von einem Client "B" das gleiche Netzlaufwerk über die IP Adresse / Netzwerkkarte "II"
des Servers eingebunden wird. Bei der Datenübertragung dann also theoretisch 2x1 gbit unabhängig möglich sein sollte.
Beim Testen war es aber so das der Datendurchsatz nicht schneller war als bei einer IP Adresse / Netzwerkkarte
und Zugriffs von beiden Clients am Server.
nee... so wird das ja auch nix....
wie hast du den gemessen?
wenn überhaubt mit iPerf3

Bei Ansicht des Ressourcenmonitors am Server fällt auf das der Netzwerktraffik
sich auch immer auf die zweite Netzwerkkarte zu ca. 50% verlagert, selbst wenn nur ein Client "A"
das Netzlaufwerk über IP Adresse / Netzwerkkarte "I" verbunden hat und Daten kopiert, hat auch IP Adresse / Netzwerkkarte "II" davon 50% Traffik.
über was für einen Server reden wir eigentlich?
SSD Raid.... Sata / SAS 5200er spindeln... etc...
was für dateien, viele große.. oder kleine dateien...
SMB1/ SMB2/SMB3 ?

Macht es überhaupt Sinn auf die Art und Weise etwas mehr Peformance heraus zu holen
hm....
und wie kommt es das der Traffic sich trotz unterschiedlicher IP Einbindung des Netzlaufwerkes
trotz auf beidem Karten verteilt und nicht die doppelte Performance möglich ist?
weil jede verbindung nur nur max1 Gbit kann...

Bin gespannt face-smile
Frank
Mitglied: Penny.Cilin
Lösung Penny.Cilin 14.08.2018 um 17:14:56 Uhr
Goto Top
Hallo,

entschuldige, kann es sein, daß Du von der Materie noch nicht soviel Kenntnisse hast?
Nun, schreibst Du zwar daß Du einen Windows Server 2016 als Fileserver einsetzt, aber wie dieser angebunden ist, wissen wir nicht.
Das ist nun mal eine der essentiellen Informationen, die fehlen.

Und wie Frank aka Vision2015 schon geschrieben hat, müßtest Du Trunking bzw. LACP einsetzen. Und dazu muss auch der zugehörige Switch konfiguriert werden.

P.S. Wie Du eine Frage richtig stellst. Wenn Du diese Tipps beherzigst, dann können wir besser helfen.

Gruss Penny
Mitglied: melters
melters 14.08.2018 aktualisiert um 20:17:53 Uhr
Goto Top
Hallo zusammen,

sorry da fehlen tatsächlich ein paar Infos um es besser nachvollziehen zu können,
ich habe mal eine kurze Skizze gemacht die es hoffentlich eindeutiger zeigt als man es geschrieben erklären kann...


Zitat von @Vision2015:

Moin...
Zitat von @melters:
was hast du für einen switch?
Einen managed HP Switch der die genannten Features auch unterstützt

Beim Testen war es aber so das der Datendurchsatz nicht schneller war als bei einer IP Adresse / Netzwerkkarte
und Zugriffs von beiden Clients am Server.
wie hast du den gemessen?
wenn überhaubt mit iPerf3
Danke werde ich damit mal künftig testen, gemessen war erstmal anhand von Zeit / ungefähre Übertragungsrate,
recht ungenau damit, aber doch deutlich sichtbar das die Performance nicht besser wurde
Übertragen zum testen wurden große Daten, 5 GB isos, sowie massig .jpgs abwechselnd.

über was für einen Server reden wir eigentlich?
SSD Raid.... Sata / SAS 5200er spindeln... etc...
was für dateien, viele große.. oder kleine dateien...
SMB1/ SMB2/SMB3 ?
Die Kiste ist recht performant, 250 GB SDD auf der auch Freigabe "test" liegt, Xeon E5 CPU, 32 GB RAM, Intel Netzwerkkarten, vermutlich verwendet Windows smb3 bei 2016 sofern der Client ( Windows 10) es unterstützt.
Die Clients sind mit 8 GB Ram, i5 CPU und auch 250GB SSDs sowie Windows 10 ausgestattet.

und wie kommt es das der Traffic sich trotz unterschiedlicher IP Einbindung des Netzlaufwerkes
trotz auf beidem Karten verteilt und nicht die doppelte Performance möglich ist?
weil jede verbindung nur nur max1 Gbit kann...
Aber dann sollte doch theoretisch je Client 1 Gbit bei gleichzeitigem Zugriff möglich sein?

Hoffe die Angaben geben jetzt ein runderes Bild ab face-smile
aufbau_test2
Mitglied: emeriks
Lösung emeriks 15.08.2018 um 08:40:43 Uhr
Goto Top
Hi,
das geht nur und macht nur Sinn unter bestimmten Bedingungen.

Dass man an der 2. NIC kein extra GW eintragen kann, ist logisch, wenn an diese NIC eine Adresse aus dem selben Netz wie bei der anderen NIC gebunden ist. Du könntest hier höchstens ein 2. Subnetz erstellen, aber das würde ich mir sehr gut überlegen! Da kann alles nur noch schlimmer werden.

Wenn beide NIC Adressen im selben Netz haben und der Server sich mit beiden Adressen im DNS registriert hat, dann werden die Clients den Namen des Servers theoretisch nach Round-Robin auflösen, so dass es sein kann, dass die Clients "gleichmäßig verteilt" jeweils eine andere Adresse des Servers bekommen. Die Clients sprechen den Server dann also über verschiedene NIC an. Der Server wird aber immer über die am höchsten gebundene NIC dieser beiden antworten. D.h. alle Antworten in dieses Netz gehen über nur eine der beiden NIC raus. Damit bist Du wieder auf die Bandbreite dieser einen NIC limitiert und der erhoffte Effekt ist dahin.

Wenn, dann macht das also wie oben erwähnt nur Sinn, wenn die Clients aus verschiedenen Netzen kommen und der Server mit je einer NIC in einem dieser Netze ist oder der Traffic durch Routing an die NIC verteilt wird und der Server durch entsprechende Routing-Einträge weiß, an welches Netz er wie kommt. Allerdings musst Du hier aufpassen, dass die Clients dann immer die richtige (passende) IP-Adresse aus dem DNS aufgelöst bekommen.

E.
Mitglied: melters
melters 15.08.2018 um 09:43:42 Uhr
Goto Top
Hallo Emeriks,

vielen Dank für deine hilfreiche Rückmeldung!

Zitat von @emeriks:

Wenn beide NIC Adressen im selben Netz haben und der Server sich mit beiden Adressen im DNS registriert hat, dann werden die Clients den Namen des Servers theoretisch nach Round-Robin auflösen, so dass es sein kann, dass die Clients "gleichmäßig verteilt" jeweils eine andere Adresse des Servers bekommen. Die Clients sprechen den Server dann also über verschiedene NIC an. Der Server wird aber immer über die am höchsten gebundene NIC dieser beiden antworten. D.h. alle Antworten in dieses Netz gehen über nur eine der beiden NIC raus. Damit bist Du wieder auf die Bandbreite dieser einen NIC limitiert und der erhoffte Effekt ist dahin.

D.h. die am "höchsten gebundene NIC" ist statisch eingetragen und wechselst nicht aufgrund von hoher Auslastung auf die zweite NIC?
In der Tat sind beide IPs dem DNS Namen des Servers zugeordnet, da scheint dann Reverse Lookup zu greifen.
Was würde denn passieren wenn eine IP ohne DNS Eintrag verwendet würde, müsste dann nicht explizit dieser per IP angesprochen NIC genutzt werden? (Klar, ist eine nicht ganz saubere Lösung)

Wenn, dann macht das also wie oben erwähnt nur Sinn, wenn die Clients aus verschiedenen Netzen kommen und der Server mit je einer NIC in einem dieser Netze ist oder der Traffic durch Routing an die NIC verteilt wird und der Server durch entsprechende Routing-Einträge weiß, an welches Netz er wie kommt. Allerdings musst Du hier aufpassen, dass die Clients dann immer die richtige (passende) IP-Adresse aus dem DNS aufgelöst bekommen.

Wäre eine Option, hatte ich auch mal überlegt ist aber wie du schon schreibst eher umständlich, je nach weiterem Netzaufbau.
Es bestätigt sich aber insgesamt warum extra Storagesysteme mit lun und MPIO Anbindung mit Lastverteilung seine daseinsberechtigung haben face-wink
Mitglied: emeriks
emeriks 15.08.2018 um 10:36:18 Uhr
Goto Top
D.h. die am "höchsten gebundene NIC" ist statisch eingetragen und wechselst nicht aufgrund von hoher Auslastung auf die zweite NIC?
In der Tat sind beide IPs dem DNS Namen des Servers zugeordnet, da scheint dann Reverse Lookup zu greifen.
Was hat hier Reverse Lookup damit zu tun? Benutzen die Clients den Servernamen oder die IP-Adresse beim Zugriff auf den Server?
Was würde denn passieren wenn eine IP ohne DNS Eintrag verwendet würde, müsste dann nicht explizit dieser per IP angesprochen NIC genutzt werden? (Klar, ist eine nicht ganz saubere Lösung)
Wenn der Client nicht den Namen anspricht sondern die IP-Adresse, dann ja. Aber auch nur eingehend. Ausgehend sollte das dann wieder über die "höchste" NIC gehen.

Es bestätigt sich aber insgesamt warum extra Storagesysteme mit lun und MPIO Anbindung mit Lastverteilung seine daseinsberechtigung haben face-wink
Jetzt verwechselst Du Äppel mit Bürnen.
Selbst wenn Du jetzt am Server ein Storage über FC oder iSCSI angebunden hättest, egal ob über einen Pfad oder mehrere mit MPIO, so würde das doch nichts daran ändern, dass die Clients weiterhin über dieselbe Netzwerkanbindung mit dem Server sprechen müssen, wie vorher.
Mitglied: melters
melters 15.08.2018 um 11:28:44 Uhr
Goto Top
Zitat von @emeriks:

D.h. die am "höchsten gebundene NIC" ist statisch eingetragen und wechselst nicht aufgrund von hoher Auslastung auf die zweite NIC?
In der Tat sind beide IPs dem DNS Namen des Servers zugeordnet, da scheint dann Reverse Lookup zu greifen.
Was hat hier Reverse Lookup damit zu tun? Benutzen die Clients den Servernamen oder die IP-Adresse beim Zugriff auf den Server?
Wie geschrieben wurde beim Test von den Clients die Netzlaufwerkeinbindung über die IP Adresse nicht DNS Namen des Server verbunden, da trotzdem die Daten über den NIC mit einer anderen IP am Server eingegangen sind deutet doch darauf das die IP Adresse zum DNS aufgelöst wurde?

Was würde denn passieren wenn eine IP ohne DNS Eintrag verwendet würde, müsste dann nicht explizit dieser per IP angesprochen NIC genutzt werden? (Klar, ist eine nicht ganz saubere Lösung)
Wenn der Client nicht den Namen anspricht sondern die IP-Adresse, dann ja. Aber auch nur eingehend. Ausgehend sollte das dann wieder über die "höchste" NIC gehen.
Genau das scheint nicht zu klappen zumindest wenn die IP auch dem DNS Namen mit zugeordnet ist und aufgelöst werden kann, werde ich nochmal testen bei einer IP ohne DNS Anmeldung.

Es bestätigt sich aber insgesamt warum extra Storagesysteme mit lun und MPIO Anbindung mit Lastverteilung seine daseinsberechtigung haben face-wink
Jetzt verwechselst Du Äppel mit Bürnen.
Selbst wenn Du jetzt am Server ein Storage über FC oder iSCSI angebunden hättest, egal ob über einen Pfad oder mehrere mit MPIO, so würde das doch nichts daran ändern, dass die Clients weiterhin über dieselbe Netzwerkanbindung mit dem Server sprechen müssen, wie vorher.
Stimmt, aber beim eingebundenen ISCSI Storage sollte sich damit schon etwas mehr Performance rausbringen lassen als nur LACP Verbindungen zu nutzen? Oder andersherum gefragt, was wäre eine empfehlenswerte Alternative neben einer Erneuerung auf 10Gbit im Netzbereich?
Mitglied: Vision2015
Vision2015 15.08.2018 um 11:43:42 Uhr
Goto Top
Moin...

was sagt den iperf3 ?
poste doch mal bitte die ergebnisse!

>was hast du für einen switch?
Einen managed HP Switch der die genannten Features auch unterstützt
und was genau für ein HP Switch? wie wurde den LACP, eingerichtet?
pste mal bitte ein
show lacp
von der switch console!
normalerweise würden alle Nic´s in einem Trunk zusammengefasst, also hätte dein server eigentlich nur eine IP!
was für eine NIC ist in deinem server verbaut?

Frank
Mitglied: emeriks
emeriks 15.08.2018 um 12:02:04 Uhr
Goto Top
Also nochmal. Storageanbindung hat erstmal nichts mit der LAN-Performance zwischen Client und Server zu tun. Wenn der Storage über iSCSI schneller ist als der lokale Storage, dann und nur dann könnte das eine positive Auswirkung für die Clients haben. Auch auch nur dann, wenn das iSCSI dann über eigene NICs geht, weil es sonst den Verbindungen zu den Clients die Bandbreite wegnimmt.
Mitglied: melters
melters 15.08.2018 um 12:04:44 Uhr
Goto Top
Moinmoin

Zitat von @Vision2015:

Moin...

was sagt den iperf3 ?
poste doch mal bitte die ergebnisse!
Muss ich noch durchführen, poste ich sobald möglich

und was genau für ein HP Switch? wie wurde den LACP, eingerichtet?
HP 2530-24G Switch (J9776A)

pste mal bitte ein
show lacp
von der switch console!
LACP Trunk Port LACP Admin Oper
Port Enabled Group Status Partner Status Key Key
---- ------- ------- ------- ------- ------- ------ ------
15 Active Trk12 Up Yes Success 0 65
16 Active Trk12 Up Yes Success 0 65
19 Active Trk14 Up Yes Success 0 67
20 Active Trk14 Up Yes Success 0 67

normalerweise würden alle Nic´s in einem Trunk zusammengefasst, also hätte dein server eigentlich nur eine IP!
was für eine NIC ist in deinem server verbaut?
Ist eine I340-T4, normalerweise alle zusammen, zum testen aber in diesem Aufbau 2x2 zusammengefasst face-wink
Mitglied: melters
melters 15.08.2018 um 12:45:44 Uhr
Goto Top
Zitat von @emeriks:

Also nochmal. Storageanbindung hat erstmal nichts mit der LAN-Performance zwischen Client und Server zu tun. Wenn der Storage über iSCSI schneller ist als der lokale Storage, dann und nur dann könnte das eine positive Auswirkung für die Clients haben. Auch auch nur dann, wenn das iSCSI dann über eigene NICs geht, weil es sonst den Verbindungen zu den Clients die Bandbreite wegnimmt.

Ok, also ist die angedachte Lösung unbrauchbar :D

Wäre die Frage was Alternativ möglich ist um die Performance zu verbessern.
Vielleicht das per ISCSi anzubindende Storage anteilig an zwei verschiedene phys./virt. Server
einbinden und dann quasi zwei getrennt Speicherbereiche bereit stellen?
Dann quasi statt Server X 1x20TB dann Server X 1x10TB und Server Y 1x10TB?
Mitglied: emeriks
emeriks 15.08.2018 um 13:22:18 Uhr
Goto Top
Die Gesamtmenge an Daten ist für die Performance eines Server i.A. irrelevant. Interessant ist nur, wieviel Daten bewegt werden.
Insofern könnte auch eine Aufteilung in 20 TB : 1 GB Nutzen bringen, wenn 3 Benutzer mit diesen 1 GB mehr Stress produzieren, als 100 andere mit den verbleibenden 20 TB.
Es kan auch schon Sinn genug ergeben, wenn man die Daten innerhalb des Servers auf mehrere HDD's verteilt. Entweder in einem großen RAID oder in mehreren kleinen. Aber darüber nachzudenken macht wiederrum nur Sinn, wenn man dort den Flaschenhalks vermutet. Wenn das Problem in der Verbindung zu vermuten ist, dann könnte eine Aufteilung über mehrere Server Sinn ergeben.

Hast Du überthaupt schon einmal gemessen, wo genau bei Euch der Flaschenhals ist? Das könnten ja auch die auf 100 Mbit/s eingestellten NICs am Client sein. Oder eine falsch konfigurierte/programmierte Datenbank, welche zuviele IOpS produziert?
Mitglied: melters
melters 16.08.2018 um 16:44:24 Uhr
Goto Top
Zitat von @emeriks:
Hast Du überthaupt schon einmal gemessen, wo genau bei Euch der Flaschenhals ist? Das könnten ja auch die auf 100 Mbit/s eingestellten NICs am Client sein. Oder eine falsch konfigurierte/programmierte Datenbank, welche zuviele IOpS produziert?

Die NICs an den Clients laufen alle mit Gbit, scheint wirklich der Engpass an der Anbindung des Servers zu sein sobald viele Zugriff erfolgen.
Ich denke als kurzfristige Lösung wird es helfen den Zugriff / Datenablage Storage auf zwei Server aufzuteilen,
also getrennte ISCSI eingebundene Bereiche, mittelfristig scheint mir aber nur eine Investition in 10Gbit bei
der künftig geplanten Masse an Daten sinnvoll zu sein. Mittlerweile ist die Technik ja auch bezahlbarer geworden.
Mitglied: Vision2015
Vision2015 16.08.2018 um 17:00:01 Uhr
Goto Top
Moin...
Zitat von @melters:

Zitat von @emeriks:
Hast Du überthaupt schon einmal gemessen, wo genau bei Euch der Flaschenhals ist? Das könnten ja auch die auf 100 Mbit/s eingestellten NICs am Client sein. Oder eine falsch konfigurierte/programmierte Datenbank, welche zuviele IOpS produziert?

Die NICs an den Clients laufen alle mit Gbit, scheint wirklich der Engpass an der Anbindung des Servers zu sein sobald viele Zugriff erfolgen.
nur weil alle NIC´s Gigabit anzeigen, müssen die nicht unbedingt auch GBit übertragen!
hast du die IPerf Messung gemacht?
wenn ja, wie war das ergebnis?
Ich denke als kurzfristige Lösung wird es helfen den Zugriff / Datenablage Storage auf zwei Server aufzuteilen,
also getrennte ISCSI eingebundene Bereiche, mittelfristig scheint mir aber nur eine Investition in 10Gbit bei
der künftig geplanten Masse an Daten sinnvoll zu sein. Mittlerweile ist die Technik ja auch bezahlbarer geworden.
ja... nur auch bei 10 GBit gibbet einiges zu beachten! wenn es geht kauf nix über Kupfer, sondern SFP+
und auch da... mit iperf messen... in der regel gibbet viele konfigurations fehler... diese vermute ich auch bei dir!

Frank