15
NAS über ISCSI an Windows Server 2016 Performanceverlust? LACP Einsatz sinnvoll?
Hallo zusammen,
ich habe momentan eine recht performante NAS. Diese hat per smb Share Daten freigegeben. Das lief auch super. Problem des Ganzen war nur, dass meine Backupsoftware die NAS nicht sichern konnte. (VEEAM Backup and Replication). Die kann nämlich nur VM's und deren Platten sichern.
Naja ich habe nun die NAS mittels ISCSI in meinem Windows Server 2016 Host eingebunden. Dort wiederum eine .vhdx für meinen virtualisierten FileServer erstellt.
soweit sogut...
Ich merke jetzt allerdings einen Performanceverlust und kann nicht ganz nachvollziehen warum und weshalb, weiß einer von Rat?
Habe mir vor dem Umzug eine Datei gemerkt, die ich auf meinem Windows10 Client kopiert habe: vorher 61 MB/s nachher 45 MB/s...
warum? der virtualisierte Fileserver shared wiederum an meinen Windows10 Client.
Habe sogar ein NIC Teaming über 3 erstellt... (momentan ohne LACP)
Zudem hätte ich eine Frage zu LACP oder Multipathing.
die NAS hat eine 10GBit Karte eingebaut. ich habe ein 10GBit Switch (managed)
Mein Windows 10 Client hat ebenfalls eine 10Gbit Karte eingebaut.
Mein Server (hier ist die NAS per ISCSI angebunden) hat allerdings nur 1Gbit NICS. Nun hatte ich die Idee für zusätzliche Performance LACP zu nutzen.
wurst,
dieser win10 client ist der 3D Zeichner / Render PC... wie kriege ich hier die höchste Bandbreite drauf?
Den Flaschenhals Server kann ich versuchen mit 3x 1GBit mittels Link Aggregation (LACP) flotter zu bekommen.
WÜRDE DAS ÜBERHAUPT FUNKTIONIEREN? Ich meine gelesen zu haben, dass LACP nur dann funktioniert, wenn die Gegenseite auch die selbe Konstellation aufweist. (Müsste meine Nas dann auch 3x 1GBit Interfaces haben? oder reicht der EINE 10GBit Port der NAS)
Vielen Vielen Dank im Voraus
ich habe momentan eine recht performante NAS. Diese hat per smb Share Daten freigegeben. Das lief auch super. Problem des Ganzen war nur, dass meine Backupsoftware die NAS nicht sichern konnte. (VEEAM Backup and Replication). Die kann nämlich nur VM's und deren Platten sichern.
Naja ich habe nun die NAS mittels ISCSI in meinem Windows Server 2016 Host eingebunden. Dort wiederum eine .vhdx für meinen virtualisierten FileServer erstellt.
soweit sogut...
Ich merke jetzt allerdings einen Performanceverlust und kann nicht ganz nachvollziehen warum und weshalb, weiß einer von Rat?
Habe mir vor dem Umzug eine Datei gemerkt, die ich auf meinem Windows10 Client kopiert habe: vorher 61 MB/s nachher 45 MB/s...
warum? der virtualisierte Fileserver shared wiederum an meinen Windows10 Client.
Habe sogar ein NIC Teaming über 3 erstellt... (momentan ohne LACP)
Zudem hätte ich eine Frage zu LACP oder Multipathing.
die NAS hat eine 10GBit Karte eingebaut. ich habe ein 10GBit Switch (managed)
Mein Windows 10 Client hat ebenfalls eine 10Gbit Karte eingebaut.
Mein Server (hier ist die NAS per ISCSI angebunden) hat allerdings nur 1Gbit NICS. Nun hatte ich die Idee für zusätzliche Performance LACP zu nutzen.
- Frage 1: Kann sich jemand erklären, warum ich nach dem ISCSI Umzug weniger Bandbreite habe?
- Frage 2: es geht mir hauptsächlich um die Bandbreite für meinen EINEN windows 10 client. Load balancing ist mir
wurst,
dieser win10 client ist der 3D Zeichner / Render PC... wie kriege ich hier die höchste Bandbreite drauf?
- Frage 3: NAS 1x 10GBit -> 10GBit Switch -> 1GBitServer(ISCSI) -> 10GBit Switch -> 10GBit Windows10 Client
Den Flaschenhals Server kann ich versuchen mit 3x 1GBit mittels Link Aggregation (LACP) flotter zu bekommen.
WÜRDE DAS ÜBERHAUPT FUNKTIONIEREN? Ich meine gelesen zu haben, dass LACP nur dann funktioniert, wenn die Gegenseite auch die selbe Konstellation aufweist. (Müsste meine Nas dann auch 3x 1GBit Interfaces haben? oder reicht der EINE 10GBit Port der NAS)
Vielen Vielen Dank im Voraus
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 427266
Url: https://administrator.de/contentid/427266
Printed on: April 20, 2024 at 01:04 o'clock
15 Comments
Latest comment
Moin.
Ich erreiche mit nur einer einzige Gbit-NIC ohne jegliches Trunking ~90MB/s beim Kopieren vom Client auf's NAS; umgekehrt sind es >100MB/s - dein Performanceproblem liegt sicher nicht am Netzwerk, ich tippe eher auf Platten, Konfiguration etc.
Details wären hilfreich:
- welches NAS, wie sind die Platten konfiguriert
- Läuft der Client mit HDD oder SSD
Cheers,
jsysde
Ich erreiche mit nur einer einzige Gbit-NIC ohne jegliches Trunking ~90MB/s beim Kopieren vom Client auf's NAS; umgekehrt sind es >100MB/s - dein Performanceproblem liegt sicher nicht am Netzwerk, ich tippe eher auf Platten, Konfiguration etc.
Details wären hilfreich:
- welches NAS, wie sind die Platten konfiguriert
- Läuft der Client mit HDD oder SSD
Cheers,
jsysde
Moin Jsysde,
NAS: TS-1237u-rp SAS Platten. RAID 10 (habe 100% von meinem möglichem Speicher dem ISCSI LUN zugewiesen)
Client läuft mit 1TB S-ATA SSD (Samsung 860 pro)
NAS: TS-1237u-rp SAS Platten. RAID 10 (habe 100% von meinem möglichem Speicher dem ISCSI LUN zugewiesen)
Client läuft mit 1TB S-ATA SSD (Samsung 860 pro)
Hallo
zwei Fragen/Hinweise:
- liegt die system-vhdx auf dem ISCSI?
- hast du das ISCSI über ein separates Kabel 1:1 mit dem NAS verbunden
Bei 1:1 Verbindungen bringt LACP keine Vorteile - von der Redundanz der Kabel mal abgesehen.
Grüße
lcer
zwei Fragen/Hinweise:
- liegt die system-vhdx auf dem ISCSI?
- hast du das ISCSI über ein separates Kabel 1:1 mit dem NAS verbunden
Bei 1:1 Verbindungen bringt LACP keine Vorteile - von der Redundanz der Kabel mal abgesehen.
Grüße
lcer
Moin Icer,
zu 1) System Vhdx liegt nicht auf dem ISCSI. da liegen wirklich nur zum Großteil CAD/ZeichenZeug für den windows 10 Render/Zeichner Pc drauf...
zu 2) hm würde mir das mehr performance bringen?
momentan sieht es so aus:
NAS 10GBit Interface -> 10GBit Switch -> (NIC-Team über 3x 1GBit, switch unabhängig) Server
ich könnte NAS direkt auf einem freien NIC am Server anstecken, ergo: NAS 10GBit Interface -> 1Gbit Server
zu 1) System Vhdx liegt nicht auf dem ISCSI. da liegen wirklich nur zum Großteil CAD/ZeichenZeug für den windows 10 Render/Zeichner Pc drauf...
zu 2) hm würde mir das mehr performance bringen?
momentan sieht es so aus:
NAS 10GBit Interface -> 10GBit Switch -> (NIC-Team über 3x 1GBit, switch unabhängig) Server
ich könnte NAS direkt auf einem freien NIC am Server anstecken, ergo: NAS 10GBit Interface -> 1Gbit Server
Moin.
Ok, also schnelle Platten im NAS und SSD im Client - das liest sich erstmal gut.
Wenn du aber bei direktem Zugriff vom Client aufs NAS via 10G-NIC nur 61MB/s hast (womit haste das überhaupt gemessen), ist irgendwas ziemlich faul. Da könnten z.B. falsche Kabel im Einsatz sein, der Switch könnte die Ursache sein etc. Das aus der Ferne zu troubleshooten könnte etwas verzwickt werden... Welche Kabel hast du verwendet?
Kannst du mal den Client direkt (ohne Switch dazwischen) mit dem NAS verbinden und mal ganz blöd den Durchsatz messen?
Da müssten Werte deutlich oberhalb der 100MB/s.-Marke rumkommen. Wenn das mal sauber funktioniert, den Switch dazwischen und erneut messen - hier müssen die Werten beinah identisch gut sein.
Zum ISCSI-Setup, wie ich es normalerweise baue:
Hardware ist mit 10G-NIC mit Switch verbunden, in den VMs dann mehrere virtuelle Adapter in unterschiedlichen VLANs (Client, ISCSI, etc.); Jumbo Frames aktivieren auf den ISCSI-NICs, auf dem Switch und auf dem NAS. MPIO konfigurieren auf dem Server und auf dem NAS und ISCSI-LUN(s) entsprechend anbinden.
Cheers,
jsysde
Ok, also schnelle Platten im NAS und SSD im Client - das liest sich erstmal gut.
Wenn du aber bei direktem Zugriff vom Client aufs NAS via 10G-NIC nur 61MB/s hast (womit haste das überhaupt gemessen), ist irgendwas ziemlich faul. Da könnten z.B. falsche Kabel im Einsatz sein, der Switch könnte die Ursache sein etc. Das aus der Ferne zu troubleshooten könnte etwas verzwickt werden... Welche Kabel hast du verwendet?
Kannst du mal den Client direkt (ohne Switch dazwischen) mit dem NAS verbinden und mal ganz blöd den Durchsatz messen?
Da müssten Werte deutlich oberhalb der 100MB/s.-Marke rumkommen. Wenn das mal sauber funktioniert, den Switch dazwischen und erneut messen - hier müssen die Werten beinah identisch gut sein.
Zum ISCSI-Setup, wie ich es normalerweise baue:
Hardware ist mit 10G-NIC mit Switch verbunden, in den VMs dann mehrere virtuelle Adapter in unterschiedlichen VLANs (Client, ISCSI, etc.); Jumbo Frames aktivieren auf den ISCSI-NICs, auf dem Switch und auf dem NAS. MPIO konfigurieren auf dem Server und auf dem NAS und ISCSI-LUN(s) entsprechend anbinden.
Cheers,
jsysde
Frage 1: Kann sich jemand erklären, warum ich nach dem ISCSI Umzug weniger Bandbreite habe?
Weil du jetzt mehr Overhead als vorher hast. Davor lief lediglich SMB zum NAS und jetzt hast du zwischen Client und Server SMB und vom Server zum NAS iSCSI.
Verstehe nicht ganz, warum alle bis auf dem Server 10GBit NICs haben.
Ein NIC-Team mit 3x 1GBit NICs erhöht nicht die Performance, sondern ermöglicht lediglich, dass mehrere Verbindungen gleichzeitig statt finden können ohne Performance-Einbüße. Dennoch bleibt es bei 1GBit/s.
LACP ist die falsche Baustelle, dass ist lediglich für automatische Link Aggregation.
Du solltest dich mit SMB3 und Multipath I/O beschäftigen.
Was ist das Ziel von dem ganzen wenn der Client eh eine 1TB SSD hat?
@jsysde
die 61MB/s habe ich gemessen, als ich ich das 1GBit NIC des Windows 10 Clients genutzt habe . 1GBit Windows 10 -> 1GBit Server. (Mein Desktop hat 1x 1GBit NIC Und 1x10GBit NIC)
ich wollte einen Vorher/Nachher Vergleich (Vor dem Umzug / Nach dem Umzug).
Habe mir halt eine größere Datei gemerkt und diese vor dem Umzug auf meinen Client kopiert und eben nach dem Umzug.
Denke nicht dass es an den Kabeln liegt, zu 100% kann ich das erst am Montag sagen. Ich bestell und nutze allerdings nur MINDESTENS Cat6+
Als ich 10GBit NAS NIC mit 10Gbit Client NIC Verbunden hatte, hatte ich 440MB/s beim kopieren...... denke also somit, dass es nicht an der Verkabelung liegt.
Wie soll das funktionieren, wenn ich Windows10 Client und Switch direkt messen will? Soll ich das NAS und windows 10 Client direkt verbinden und die nas als ISCSI Target in meinen Windows 10 Client hängen??
Zum ISCSI Setup:
Jumbo Frames aktivieren auf den ISCSI-NICs, auf dem Switch und auf dem NAS
wo würde ich das am Server in meinem Fall aktivieren? im NIC Team? am Switch mache ich das an den ISCSI / Server NICS oder grundsätzlich für alle?
habe ich noch nie konfiguriert, wäre diese Anleitung ratsam?:
https://www.windowspro.de/wolfgang-sommergut/multipath-io-mpio-fuer-iscs ...
kannst du kurz näher auf "entsprechend einbinden am NAS und ISCSI LUNs" eingehen?
Grüße
die 61MB/s habe ich gemessen, als ich ich das 1GBit NIC des Windows 10 Clients genutzt habe . 1GBit Windows 10 -> 1GBit Server. (Mein Desktop hat 1x 1GBit NIC Und 1x10GBit NIC)
ich wollte einen Vorher/Nachher Vergleich (Vor dem Umzug / Nach dem Umzug).
Habe mir halt eine größere Datei gemerkt und diese vor dem Umzug auf meinen Client kopiert und eben nach dem Umzug.
Denke nicht dass es an den Kabeln liegt, zu 100% kann ich das erst am Montag sagen. Ich bestell und nutze allerdings nur MINDESTENS Cat6+
Als ich 10GBit NAS NIC mit 10Gbit Client NIC Verbunden hatte, hatte ich 440MB/s beim kopieren...... denke also somit, dass es nicht an der Verkabelung liegt.
Wie soll das funktionieren, wenn ich Windows10 Client und Switch direkt messen will? Soll ich das NAS und windows 10 Client direkt verbinden und die nas als ISCSI Target in meinen Windows 10 Client hängen??
Zum ISCSI Setup:
Jumbo Frames aktivieren auf den ISCSI-NICs, auf dem Switch und auf dem NAS
- Jumbo Frames müsste noch auf der NAS aktiviert sein, am Server und Switch habe ich das ehrlich gesagt noch nicht gemacht, werde ich gleich testen.
wo würde ich das am Server in meinem Fall aktivieren? im NIC Team? am Switch mache ich das an den ISCSI / Server NICS oder grundsätzlich für alle?
- MPIO konfigurieren auf dem Server und auf dem NAS und ISCSI-LUN(s) entsprechend anbinden.
habe ich noch nie konfiguriert, wäre diese Anleitung ratsam?:
https://www.windowspro.de/wolfgang-sommergut/multipath-io-mpio-fuer-iscs ...
kannst du kurz näher auf "entsprechend einbinden am NAS und ISCSI LUNs" eingehen?
Grüße
@vBurak
Servus Burak,
Verstehe nicht ganz, warum alle bis auf dem Server 10GBit NICs haben.
Du solltest dich mit SMB3 und Multipath I/O beschäftigen.
MultiPath I/O nach Anleitung :
https://www.windowspro.de/wolfgang-sommergut/multipath-io-mpio-fuer-iscs ...
sinnvoll?
Was ist das Ziel von dem ganzen wenn der Client eh eine 1TB SSD hat?
Viele Grüße
Servus Burak,
Verstehe nicht ganz, warum alle bis auf dem Server 10GBit NICs haben.
- weil der Server erst neulich dazu kam! vorher gab es NUR die NAS. kleine Firma sehr schnell groß geworden.
Du solltest dich mit SMB3 und Multipath I/O beschäftigen.
- hast du mir nen Tipp ? SMB3 ist aufjedenfall aktiviert und wird genutzt :d Jumbo Frames werde ich noch aktivieren (oder kontrollieren ob die nicht sowieso schon aktiviert sind... )
MultiPath I/O nach Anleitung :
https://www.windowspro.de/wolfgang-sommergut/multipath-io-mpio-fuer-iscs ...
sinnvoll?
Was ist das Ziel von dem ganzen wenn der Client eh eine 1TB SSD hat?
- Die ist nicht groß genug
. 3D Rendering ist wahnsinnig Speicherintensiv.
Viele Grüße
mal die TCP Offloading-Properties der Netzwerkkarte durchprobieren. Windows 2016 vertut sich da gelegentlich mal und das kostet dann erstmal Performance. Und im Übrigen ist die Maximalperformance von 65 MB/Sec bei einer Raid 10 Konfiguration schon sehr langsam. Vermutlich war schon vorher irgendwas schief.
Jumbo Frames bringt nur was wenn das auch in allen Switchen aktiviert ist, aber mit Jumbo Frames im LAN beseitigt man normalerweise keine Performanceprobleme... kann man sogar mit dem Ping nachprüfen, Ping hat einen -L Parameter, wo man die Paketgröße angeben kann. Wenn also ein 64 KB Ping Paket genauso schnell am Ziel ankommt wie eins mit 64 byte dann wird man mit dem Jumbo frame ganz gewiß nichts reißen können.
Jumbo Frames bringt nur was wenn das auch in allen Switchen aktiviert ist, aber mit Jumbo Frames im LAN beseitigt man normalerweise keine Performanceprobleme... kann man sogar mit dem Ping nachprüfen, Ping hat einen -L Parameter, wo man die Paketgröße angeben kann. Wenn also ein 64 KB Ping Paket genauso schnell am Ziel ankommt wie eins mit 64 byte dann wird man mit dem Jumbo frame ganz gewiß nichts reißen können.
Hast du auf allen Komponenten Jumbo Framing aktiviert ?? Das ist in jedem Fall dringend anzuraten bei 10G ! Man beseitigt damit in der Tat keine Probleme, das ist richtig aber es bewirkt das man das Maximum rausholen kann über den gesamten Pfad wenn die Komponenten das supporten, was sie in der Regel aber tun.
SMB/CIFS ist zudem eine sehr schlechte Messlatte, da sie viele sehr kleine Pakete für den Datentransfer nutzen was ungemein ineffizent ist. Besonders mit wenig performanten Billigswitches bei kleinen Paketen darf man da keine Wunder erwarten.
Letztlich ist es schon ein gravierender Unterschied ob man ein Paket in einem 9k Byte Block einzeln überträgt oder zerhackt in n-mal 64Byte Paketen. Gut bei Premium Switches kein Thema aber der TO wird sicher Billigprodukte ala NetGear oder D-Link einsetzen und da sieht es eben anderes aus !
Deshalb wäre es sehr sinnvoll du würdest mal gänzlich unabhängig von der Sharing Protokoll Infrastruktur deine wirkliche Netz Performance messen um mal verlässliche und Aussage sichere Werte zu bekommen.
Z. B. mit NetIO oder IPerf3
https://web.ars.de/netio/
http://www.nwlab.net/art/netio/netio.html
Grundsätzlich ist aber auch dein Design suboptimal, denn im Frontend hast du 10G und im Backend dann mit einmal nur 1G.
Sinnvoll wäre es natürlich andersrum oder wenigstens es homogen hinzubekommen.
Wenn du bei ISCSI dann auch noch TCP Encapsulation nutzt dann ist das Fatal weil du ein Sliding Windows Problem und damit dann sog. Buffer Bloating bekommst durch den Speed Unterschied.
https://www.heinlein-support.de/sites/default/files/iscsi-optimization.p ...
https://blogs.cisco.com/datacenter/the-napkin-dialogues-lossless-iscsi
usw.
Besser man nutzt dann NFS mit UDP aber das geht eben nicht immer wenn man ISCSI basiert ist.
LACP LAGs wird dir nur wenig nützen, denn 802.3ad LAGs nutzen ein Hashing Verfahren über die Mac- oder IP Adressen um Sessions dann doch immer auf physische Links zu binden. Da du mit einer Punkt zu Punkt Verbindung zw. Server und NAS eben nur sehr wenig bis gar keine Entropie zw. den Macs was dann die Granularität in der Auswahl auf die LAG Member gegen Null gehen lässt.
Hier hilft dir auch nur eine "Fat Pipe".
SMB/CIFS ist zudem eine sehr schlechte Messlatte, da sie viele sehr kleine Pakete für den Datentransfer nutzen was ungemein ineffizent ist. Besonders mit wenig performanten Billigswitches bei kleinen Paketen darf man da keine Wunder erwarten.
Wenn also ein 64 KB Ping Paket genauso schnell am Ziel ankommt wie eins mit 64 byte dann wird man mit dem Jumbo frame ganz gewiß nichts reißen können.
Das ist auch nicht die Frage und hat mit Performance nichts zu tun. Entscheident ist hier die Anzahl der kleinen 64Byte Pakete pro Zeiteinheit. Da trennt sich dann ganz schnell die Spreu vom Weizen bei den Switches. Mit einem einzelnen Ping pro Sekunde ist sowas natürlich sinnfrei zu testen.Letztlich ist es schon ein gravierender Unterschied ob man ein Paket in einem 9k Byte Block einzeln überträgt oder zerhackt in n-mal 64Byte Paketen. Gut bei Premium Switches kein Thema aber der TO wird sicher Billigprodukte ala NetGear oder D-Link einsetzen und da sieht es eben anderes aus !
Deshalb wäre es sehr sinnvoll du würdest mal gänzlich unabhängig von der Sharing Protokoll Infrastruktur deine wirkliche Netz Performance messen um mal verlässliche und Aussage sichere Werte zu bekommen.
Z. B. mit NetIO oder IPerf3
https://web.ars.de/netio/
http://www.nwlab.net/art/netio/netio.html
Grundsätzlich ist aber auch dein Design suboptimal, denn im Frontend hast du 10G und im Backend dann mit einmal nur 1G.
Sinnvoll wäre es natürlich andersrum oder wenigstens es homogen hinzubekommen.
Wenn du bei ISCSI dann auch noch TCP Encapsulation nutzt dann ist das Fatal weil du ein Sliding Windows Problem und damit dann sog. Buffer Bloating bekommst durch den Speed Unterschied.
https://www.heinlein-support.de/sites/default/files/iscsi-optimization.p ...
https://blogs.cisco.com/datacenter/the-napkin-dialogues-lossless-iscsi
usw.
Besser man nutzt dann NFS mit UDP aber das geht eben nicht immer wenn man ISCSI basiert ist.
LACP LAGs wird dir nur wenig nützen, denn 802.3ad LAGs nutzen ein Hashing Verfahren über die Mac- oder IP Adressen um Sessions dann doch immer auf physische Links zu binden. Da du mit einer Punkt zu Punkt Verbindung zw. Server und NAS eben nur sehr wenig bis gar keine Entropie zw. den Macs was dann die Granularität in der Auswahl auf die LAG Member gegen Null gehen lässt.
Hier hilft dir auch nur eine "Fat Pipe".
Mal ganz ab von der ganzen Problematik,
Kann veeam nicht seit der neuesten Version USB Platten und smb shares mit sichern?
Kann veeam nicht seit der neuesten Version USB Platten und smb shares mit sichern?
Zitat von @manchmalfunktionierts:
Problem des Ganzen war nur, dass meine Backupsoftware die NAS nicht sichern konnte. (VEEAM Backup and Replication). Die kann nämlich nur VM's und deren Platten sichern.
Problem des Ganzen war nur, dass meine Backupsoftware die NAS nicht sichern konnte. (VEEAM Backup and Replication). Die kann nämlich nur VM's und deren Platten sichern.
Das ist so nicht richtig. Veaam B&R kann auf jedem Fall SMB-Freigaben sichern.
Wenn Die zu sichernden Daten in einer Freigabe liegen, kann Veeam B&R die Daten auch sichern (Tape). Und das mindestens schon seit Version 7.
Hallo Monstermania, und wie sicher bist du dir da? hier die Antwort vom Veeam Support
Siehe Anhang von meinem Post darüber.... Laut Veeam Support nicht.
PS: Ich kauf ne 10gbit für den server.... zuviel aufwand...
PS: Ich kauf ne 10gbit für den server.... zuviel aufwand...
Moin,
100%ig sicher.
Wir sichern mit Veeam B&R die Freigaben eines QNAP Nas auf eine Tape-Library.
Gruß
Dirk
PS: Es mag sein, dass Veeam kein Share auf Disk sichern kann (Copy2File).
100%ig sicher.
Wir sichern mit Veeam B&R die Freigaben eines QNAP Nas auf eine Tape-Library.
Gruß
Dirk
PS: Es mag sein, dass Veeam kein Share auf Disk sichern kann (Copy2File).
