9
ZFS ISCSI auf NTFS Windows Server - ideale Blocksize?
Hallo zusammen
Ausgangslage: Geplant ist ein NAS4Free mit RAIDZ2 und iSCSI, eingebunden auf Windows Server 2012R2. Gibt es eine Empfehlung im Bezug auf die verwendete Blockgrösse beim ZFS Volume, so dass die Performance optimal ist?
Danke und Gruss, Dave
Ausgangslage: Geplant ist ein NAS4Free mit RAIDZ2 und iSCSI, eingebunden auf Windows Server 2012R2. Gibt es eine Empfehlung im Bezug auf die verwendete Blockgrösse beim ZFS Volume, so dass die Performance optimal ist?
Danke und Gruss, Dave
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: 285759
Url: https://administrator.de/contentid/285759
Printed on: April 25, 2024 at 20:04 o'clock
9 Comments
Latest comment
- "eingebunden auf Windows" - soll heißen unter HyperV als VM
- oder ein einzelnes Storage, dessen LUN einer Windows-Instanz zugewiesen wird?
bei iSCSI wäre jede Blockgröße über 1kByte ohne Jumbo-Frames schon schlecht - da fragmentiert - mit geht's evt. bis 8kByte (nach Switch dazwischen)
und generell Hardware mit TCP-Offload-Funkt. sinnvoll,
gibt's auf dem Ziel einen Hypervisor, dürfte dessen Caching größere Blockgrößen begünstigen?!
Das ist aber jetzt schon ein ziemlicher Rundumschlag, beschreibe doch die Umgebung etwas intensiver.
HG
Mark
- oder ein einzelnes Storage, dessen LUN einer Windows-Instanz zugewiesen wird?
bei iSCSI wäre jede Blockgröße über 1kByte ohne Jumbo-Frames schon schlecht - da fragmentiert - mit geht's evt. bis 8kByte (nach Switch dazwischen)
und generell Hardware mit TCP-Offload-Funkt. sinnvoll,
gibt's auf dem Ziel einen Hypervisor, dürfte dessen Caching größere Blockgrößen begünstigen?!
Das ist aber jetzt schon ein ziemlicher Rundumschlag, beschreibe doch die Umgebung etwas intensiver.
HG
Mark
1
Hallo Mark
Danke für das Feedback. Es handelt sich dabei um ein einzelnes Storage, das als iSCSI Storage auf einem Windows Server eingebunden werden soll, als Daten-Storage. Ziel-Dateisystem ist NTFS. Geplant habe ich vorerst, dass der Server und das SAN direkt via 10GB Ethernet als Teaming miteinander gekoppelt werden. Zu einem späteren Zeitpunkt soll dann ein 10GB Switch zwischengeschaltet werden. Der Datenverkehr zwischen Server und SAN sollen über separate Links auch künftig betrieben werden. Der Datenverkehr Server <-> LAN geht über eine separate Leitung (4fach Team).
Gruss Dave
Danke für das Feedback. Es handelt sich dabei um ein einzelnes Storage, das als iSCSI Storage auf einem Windows Server eingebunden werden soll, als Daten-Storage. Ziel-Dateisystem ist NTFS. Geplant habe ich vorerst, dass der Server und das SAN direkt via 10GB Ethernet als Teaming miteinander gekoppelt werden. Zu einem späteren Zeitpunkt soll dann ein 10GB Switch zwischengeschaltet werden. Der Datenverkehr zwischen Server und SAN sollen über separate Links auch künftig betrieben werden. Der Datenverkehr Server <-> LAN geht über eine separate Leitung (4fach Team).
Gruss Dave
dann damit (10GBit) größtmögliche Blockgrößen (z.B. 16kByte) - die Slices im RAID - um die Leitungsbandbreite auszunutzen, "ein kleines Paket braucht genauso lange, wie ein großes" -
(Teaming ist es bei 1x 10Gbit noch nicht, 10Gbit ohne Switch habe ich noch nie probiert)
HG
Mark
(Teaming ist es bei 1x 10Gbit noch nicht, 10Gbit ohne Switch habe ich noch nie probiert)
HG
Mark
Ja klar, ich habe oben vergessen zu sagen, dass die Adapter 2 x 10 GBE haben... Da werde ich ein Team bilden...
das wird aber nicht viel bringen, klar, SPOF vermieden, aber wenn nur eine LUN einem Server zur Verfügung gestellt wird, wird trotzdem nur 1x 10Gbit abgerufen...
Moin,
Teaming/LCAP würde ich bei iSCSI aber eher vermeiden wenn OS und SAN MPIO unterstützen ist das mE die bessere Lösung. Umschalten des Pfades (falls konfigurierbar) analog der Blockgröße
lg,
Slainte
Teaming/LCAP würde ich bei iSCSI aber eher vermeiden wenn OS und SAN MPIO unterstützen ist das mE die bessere Lösung. Umschalten des Pfades (falls konfigurierbar) analog der Blockgröße
lg,
Slainte
Hallo zusammen,
aufzusetzen und dann via "Round Robin" bzw. "weighted round robin" die Leitungen
gleichmäßig zu füllen und zwar alle beide zur gleichen Zeit?
Lass Dir das einmal "durch den Kopf gehen" und bedenke bitte das bei einem LAG (LACP)
erst eine Leitung voll sein muss damit die nächste mit benutzt wird! Und das ist bei einem
statischen LAG nicht der Fall!
Gruß
Dobby
Ja klar, ich habe oben vergessen zu sagen, dass die Adapter 2 x 10 GBE haben...
Da werde ich ein Team bilden...
Wäre es dann aber nicht besser kein LACP zu benutzen sondern ein statisches LAGDa werde ich ein Team bilden...
aufzusetzen und dann via "Round Robin" bzw. "weighted round robin" die Leitungen
gleichmäßig zu füllen und zwar alle beide zur gleichen Zeit?
Lass Dir das einmal "durch den Kopf gehen" und bedenke bitte das bei einem LAG (LACP)
erst eine Leitung voll sein muss damit die nächste mit benutzt wird! Und das ist bei einem
statischen LAG nicht der Fall!
Gruß
Dobby
... Auf der NAS4Free kann ich ein "Loadbalance" machen...
Balances outgoing traffic across the active ports based on
hashed protocol header information and accepts incoming
traffic from any active port. This is a static setup and
does not negotiate aggregation with the peer or exchange
frames to monitor the link. The hash includes the Ethernet
source and destination address, and, if available, the VLAN
tag, and the IP source and destination address.
Balances outgoing traffic across the active ports based on
hashed protocol header information and accepts incoming
traffic from any active port. This is a static setup and
does not negotiate aggregation with the peer or exchange
frames to monitor the link. The hash includes the Ethernet
source and destination address, and, if available, the VLAN
tag, and the IP source and destination address.
The hash includes the Ethernet
source and destination address, and, if available, the VLANtag, and the IP source and destination address.
- und das ist bei einem NAS, einer LUN, einem Target nunmal alles gleich
