Hallo liebe Gemeinde,
da dies mein erster Beitrag in diesem Forum ist, möchte ich mich kurz vorstellen:
Ich bin 44 Jahre alt und Administrator in einem mittelständischen Unternehmen mit 560 Clients.
Bis jetzt habe ich nur lesen an diesem Forum teilgenommen. Nun ist es aber an der Zeit mal unser Problem zu schildern...
Unsere Hardwareumgebung (in zwei getrennten Brandschutzabschnitten) sieht folgendermaßen aus:
Pro Abschnitt:
Zwei ESXi-Hosts (Fujitsu PRIMERGY RX300 S6, 2x Xeon 5650, 96GB RAM, Emulex 12002LPe 2x8Gb/s FC )
Zwei FC-Switche Brocade 300
Eine Dx90(S1/erstes Model, 24x300GB/15K/SAS, 12x600GB/15K/SAS)
Globale Infos:
VMWare vsphere 5.1 (Ent.Plus), Vcenter auf eigenem Blech.
Eine DX90 ist der Master, die andere Slave (Remote Advanced Copy, sync).
Des Weiteren eine DX80 (24x 1TB NL-SAS) und eine Tapelibrary für Backup "Disk to Disk to Tape".
Alle Komponenten sind per 8Gb-FC an den Brocade-Switchen angeschlossen (bis auf die TL; die kann nur 4GB).
Alle Ports sind fest auf 8GB eingestellt(außer der Port für die TL).
Fillwords auf den Switchports auf Mode3.
VAAI auf den Hosts deaktiviert; "Disk.ScheNumReqOustandig" auf 128 und "lun_queue_depth" auf 8 (wir haben insgesamt nur 4 Lun's).
FC-Strecken sind redundant und auf zwei unterschiedlichen Wegen verlegt.
Eine Zone besteht aus jeweils einem Switch pro Brandschutzabschnitt (Full-Fabric).
VMWare und Fujitsu haben diese Konfiguration abgesegnet.......
Also eigentlich ideale Voraussetzungen für eine schnelle Umgebung.........
Nun zu Problem:
Von Anfang an hatten wir eine bescheidene Schreibgeschwindigkeit auf dem Storage.
Z.B.: auf einer Raidgruppe mit 8 Platten im RAID5 und einer LUN mit der Gesamtgröße der kompletten Raidgruppe
haben wir folgende Schreibwerte (SEQ-schreiben von 15GB großen Dateien, Log-Daten aus der DX90 ausgelesen):
Windows Server 2008, REC execute, 73,5 Mb/s (Sync-Spiegel aktiv) (NTFS, 4096Bytes)
Windows Server 2008, REC suspend, 180 Mb/s (Sync-Spiegel inaktiv) (NTFS, 4096Bytes)
Suse Linux, REC execute, 245 Mb/s (Sync-Spiegel aktiv) (ext3)
Suse Linux, REC suspend, 311 Mb/s (Sync-Spiegel inaktiv) (ext3)
VMDK-Erstellung (40GB, Eager-zero), REC execute, 193 Mb/s (Sync-Spiegel aktiv) (vmfs 5.58)
VMDK-Erstellung (40GB, Eager-zero), REC suspend, 275 Mb/s (Sync-Spiegel inaktiv)(vmfs 5.58)
Wie man anhand der Werte ersehen kann, gibt es natürlich eine Einbuße beim aktiven Sync-Spiegel. Dessen sind wir uns natürlich auch bewusst.
Und Fujitsu sagt auch, das der Spiegel ca.30% der Leistung frisst.
Aber warum zum Teufel haben wir eine ziemlich große Diskrepanz zwischen den Linux- und Windowsbasierenden Systemen?
Was macht Linux hier besser und wie könnten wir die Windows-Server pushen. Gerade unsere DEKO-und Werbeabteilung haben Probleme beim Speichern großer Grafiken.
Die Fujitsu-Entwicklungsabteilung in Paderborn weiß auch keinen Rat und sagt mittlerweile, dass dies so ist...
Selbst eine getestete DX90-S2 macht im Spiegelbetrieb dieselben Mucken..... Und auch nur unter Windows..
Hat hier jemand eine Idee oder hat dieselben Probleme??
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Schlechte Write-Performance mit Fujitsu DX90 und RemoteCopy
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
redest du hier eigentlich immer über VM's, oder hast du die Diskrepanzen zwischen physikalischen Servern?
Weiterhin ist der Durchsatz abhängig von der IO Größe, daher solltest du überprüfen, ob ihr beim Testen immer die gleiche IO Size verwendet.
Du kannst ja mal mit vscsiStats überprüfen, was die Linux und Windows VM wirklich machen.
Da VMFS mit 1 MB Blocksize arbeitet gehe ich davon aus, das beim Erzeugen einer vmdk auch mit dieser Blocksize geschrieben wird.
Wenn eure Grafik und Werbeabteilung fast ausschließlich mit großen Dateien arbeitet, warum nehmt ihr dann ein NTFS Filesystem mit 4k Blocksize?
Je nachdem, mit welcher Blocksize dein Array intern arbeitet, können kleine Write IO's massiv auf die Performance drücken.
Verwendet dein Array z. B. 64 KB Blocksize, dann passiert bei 4 K sequentieller Write IO's folgendes.
Der erste Write kommt, das Array liest den 64 KB Track in den Array Cache und überschreibt den Bereich, der durch den 4 K Write IO geändert worden ist.
Der zweite 4K Write IO ändert Daten an einer anderen Position im 64K Track, das Lesen sollte nicht mehr erforderlich sein, da der Track sich noch im Array Cache befindet.
Allerdings muß der zweite IO warten, bis der erste fertig ist, da ja der gleiche Track geändert werden soll.
Würdest du stattdessen gleich 64KB schreiben, dürfte das deutlich schneller sein, denn ein 64 K IO braucht eben meistens nicht so lange wie 16 * 4K IO's.
Und wenn du das Filesystem alligned hast, wird gleich der komplette Track geändert und somit muß der ursprüngliche Track nicht mehr eingelesen werden.
Die Parity Berechnung erfordert einen ähnlichen Aufwand und würde von größeren IO Sizes ebenfalls profitieren.
Und dann könntet ihr noch folgendes Dokument auswerten.
Performance Tuning Guidelines for Windows Server 2008 R2
Viel Erfolg,
Ralf
redest du hier eigentlich immer über VM's, oder hast du die Diskrepanzen zwischen physikalischen Servern?
Weiterhin ist der Durchsatz abhängig von der IO Größe, daher solltest du überprüfen, ob ihr beim Testen immer die gleiche IO Size verwendet.
Du kannst ja mal mit vscsiStats überprüfen, was die Linux und Windows VM wirklich machen.
Da VMFS mit 1 MB Blocksize arbeitet gehe ich davon aus, das beim Erzeugen einer vmdk auch mit dieser Blocksize geschrieben wird.
Wenn eure Grafik und Werbeabteilung fast ausschließlich mit großen Dateien arbeitet, warum nehmt ihr dann ein NTFS Filesystem mit 4k Blocksize?
Je nachdem, mit welcher Blocksize dein Array intern arbeitet, können kleine Write IO's massiv auf die Performance drücken.
Verwendet dein Array z. B. 64 KB Blocksize, dann passiert bei 4 K sequentieller Write IO's folgendes.
Der erste Write kommt, das Array liest den 64 KB Track in den Array Cache und überschreibt den Bereich, der durch den 4 K Write IO geändert worden ist.
Der zweite 4K Write IO ändert Daten an einer anderen Position im 64K Track, das Lesen sollte nicht mehr erforderlich sein, da der Track sich noch im Array Cache befindet.
Allerdings muß der zweite IO warten, bis der erste fertig ist, da ja der gleiche Track geändert werden soll.
Würdest du stattdessen gleich 64KB schreiben, dürfte das deutlich schneller sein, denn ein 64 K IO braucht eben meistens nicht so lange wie 16 * 4K IO's.
Und wenn du das Filesystem alligned hast, wird gleich der komplette Track geändert und somit muß der ursprüngliche Track nicht mehr eingelesen werden.
Die Parity Berechnung erfordert einen ähnlichen Aufwand und würde von größeren IO Sizes ebenfalls profitieren.
Und dann könntet ihr noch folgendes Dokument auswerten.
Performance Tuning Guidelines for Windows Server 2008 R2
Viel Erfolg,
Ralf
Re: Schlechte Write-Performance mit Fujitsu DX90 und RemoteC
ADO1 hat geschrieben:Hallo liebe Gemeinde,
...
Aber warum zum Teufel haben wir eine ziemlich große Diskrepanz zwischen den Linux- und Windowsbasierenden Systemen?
Was macht Linux hier besser und wie könnten wir die Windows-Server pushen. Gerade unsere DEKO-und Werbeabteilung haben Probleme beim Speichern großer Grafiken.
Nen Tipp habe ich erst mal nicht, aber die Marketing Abteilung wird ja übers Netz speichern. Selbst mit 1Gbit ist da nicht mehr wie max 100-120MB/sek möglich.
Wenn die dann noch ein XP als Client-System haben, kaum mehr wie 30MB/s. Erst ein Vsta/Win7 bringt da bis zu 100-120MB/s.
Was wiederum nicht so weit weg wäre von deinen 75Mb/s.
Gerade bei mir getestet, Win7 mit Realtek nic auf SRV08 VM rund 110MB/s.
Vielleicht einfach erst mal lokal mit einer zweiten HDD als Ziel testen, ob es wirklich an der Geschwindigkeit der Storage liegt. Ggf sind halt wirklich die Daten so groß, das es halt dauert. (Einfach mal anders heran gehen an die Sache)
@kastir
Ja ich rede immer von virtuellen Servern. Physikalische sind bei diesem Problem nicht beachtet worden.
Das mit der großen Blockgröße ist schon richtig und ich bin mir dieser Thematik auch bewusst; allerdings fahren wir hier nur einen Fileserver wo nicht nur die Werbeabteilung drauf zugreift.
Und ich hatte auch einen Test mit 64Kb großen Zuordnungseinheiten gemacht. Da ist der Durchsatz genauso schlecht wie bei den 4Kb großen.
Der Tipp mit vscsiStats ist schon mal gut.
was mich hierbei stutzig macht: Trotz Blockgröße von 4096byte beim Windows-Server verstehe ich die Write Commands >524288 nicht ganz
Vorallem: Warum liest Windows dieselbe Anzahl an WriteCommands nochmal ein.
Beim Linuxtest sieht das anders aus.
Windows-Test (40GB seq-Schreiben]:
==================================
Histogram: IO lengths of Write commands for virtual machine worldGroupID : 54267, virtual disk handleID : 8216 (scsi0:1) {
min : 4096
max : 1048576
mean : 1034185
count : 41448
0 (<= 512)
0 (<= 1024)
0 (<= 2048)
0 (<= 4095)
358 (<= 4096)
0 (<= 8191)
17 (<= 8192)
10 (<= 16383)
13 (<= 16384)
24 (<= 32768)
25 (<= 49152)
21 (<= 65535)
7 (<= 65536)
33 (<= 81920)
36 (<= 131072)
25 (<= 262144)
14 (<= 524288)
40865 (> 524288)
Histogram: IO lengths of Read commands for virtual machine worldGroupID : 54267, virtual disk handleID : 8216 (scsi0:1)
min : 4096
max : 1048576
mean : 1045978
count : 40969
0 (<= 512)
0 (<= 1024)
0 (<= 2048)
0 (<= 4095)
3 (<= 4096)
0 (<= 8191)
0 (<= 8192)
0 (<= 16383)
0 (<= 16384)
81 (<= 32768)
0 (<= 49152)
0 (<= 65535)
0 (<= 65536)
0 (<= 81920)
2 (<= 131072)
4 (<= 262144)
14 (<= 524288)
40865 (> 524288)
Linux-Test (20GB seq-Schreiben):
================================
Histogram: IO lengths of Write commands for virtual machine worldGroupID : 48056, virtual disk handleID : 8213 (scsi0:0)
min : 4096
max : 524288
mean : 520631
count : 41279
0 (<= 512)
0 (<= 1024)
0 (<= 2048)
0 (<= 4095)
168 (<= 4096)
0 (<= 8191)
25 (<= 8192)
13 (<= 16383)
6 (<= 16384)
39 (<= 32768)
17 (<= 49152)
10 (<= 65535)
1 (<= 65536)
4 (<= 81920)
9 (<= 131072)
4 (<= 262144)
40983 (<= 524288)
0 (> 524288)
Histogram: IO lengths of Read commands for virtual machine worldGroupID : 48056, virtual disk handleID : 8213 (scsi0:0)
min : 4096
max : 262144
mean : 18682
count : 2949
0 (<= 512)
0 (<= 1024)
0 (<= 2048)
0 (<= 4095)
1983 (<= 4096)
0 (<= 8191)
152 (<= 8192)
91 (<= 16383)
91 (<= 16384)
219 (<= 32768)
59 (<= 49152)
46 (<= 65535)
17 (<= 65536)
110 (<= 81920)
176 (<= 131072)
5 (<= 262144)
0 (<= 524288)
0 (> 524288)
@Supi
Die Tests laufen alle auf virtuellen Maschinen und werden nicht über das Netzwerk durchgeführt.
Wenn mehrer sich mehrere virtuelle Server auf der selben LUN tummeln, dann hat der Fileserver nicht mehr die angestrebten 90Mb/s beim Netzwerkzugriff.
Es ist einfach so, das die LUN nicht mehr hergibt (unter Windowssystemen).
Ja ich rede immer von virtuellen Servern. Physikalische sind bei diesem Problem nicht beachtet worden.
Das mit der großen Blockgröße ist schon richtig und ich bin mir dieser Thematik auch bewusst; allerdings fahren wir hier nur einen Fileserver wo nicht nur die Werbeabteilung drauf zugreift.
Und ich hatte auch einen Test mit 64Kb großen Zuordnungseinheiten gemacht. Da ist der Durchsatz genauso schlecht wie bei den 4Kb großen.
Der Tipp mit vscsiStats ist schon mal gut.
was mich hierbei stutzig macht: Trotz Blockgröße von 4096byte beim Windows-Server verstehe ich die Write Commands >524288 nicht ganz
Vorallem: Warum liest Windows dieselbe Anzahl an WriteCommands nochmal ein.
Beim Linuxtest sieht das anders aus.
Windows-Test (40GB seq-Schreiben]:
==================================
Histogram: IO lengths of Write commands for virtual machine worldGroupID : 54267, virtual disk handleID : 8216 (scsi0:1) {
min : 4096
max : 1048576
mean : 1034185
count : 41448
0 (<= 512)
0 (<= 1024)
0 (<= 2048)
0 (<= 4095)
358 (<= 4096)
0 (<= 8191)
17 (<= 8192)
10 (<= 16383)
13 (<= 16384)
24 (<= 32768)
25 (<= 49152)
21 (<= 65535)
7 (<= 65536)
33 (<= 81920)
36 (<= 131072)
25 (<= 262144)
14 (<= 524288)
40865 (> 524288)
Histogram: IO lengths of Read commands for virtual machine worldGroupID : 54267, virtual disk handleID : 8216 (scsi0:1)
min : 4096
max : 1048576
mean : 1045978
count : 40969
0 (<= 512)
0 (<= 1024)
0 (<= 2048)
0 (<= 4095)
3 (<= 4096)
0 (<= 8191)
0 (<= 8192)
0 (<= 16383)
0 (<= 16384)
81 (<= 32768)
0 (<= 49152)
0 (<= 65535)
0 (<= 65536)
0 (<= 81920)
2 (<= 131072)
4 (<= 262144)
14 (<= 524288)
40865 (> 524288)
Linux-Test (20GB seq-Schreiben):
================================
Histogram: IO lengths of Write commands for virtual machine worldGroupID : 48056, virtual disk handleID : 8213 (scsi0:0)
min : 4096
max : 524288
mean : 520631
count : 41279
0 (<= 512)
0 (<= 1024)
0 (<= 2048)
0 (<= 4095)
168 (<= 4096)
0 (<= 8191)
25 (<= 8192)
13 (<= 16383)
6 (<= 16384)
39 (<= 32768)
17 (<= 49152)
10 (<= 65535)
1 (<= 65536)
4 (<= 81920)
9 (<= 131072)
4 (<= 262144)
40983 (<= 524288)
0 (> 524288)
Histogram: IO lengths of Read commands for virtual machine worldGroupID : 48056, virtual disk handleID : 8213 (scsi0:0)
min : 4096
max : 262144
mean : 18682
count : 2949
0 (<= 512)
0 (<= 1024)
0 (<= 2048)
0 (<= 4095)
1983 (<= 4096)
0 (<= 8191)
152 (<= 8192)
91 (<= 16383)
91 (<= 16384)
219 (<= 32768)
59 (<= 49152)
46 (<= 65535)
17 (<= 65536)
110 (<= 81920)
176 (<= 131072)
5 (<= 262144)
0 (<= 524288)
0 (> 524288)
@Supi
Die Tests laufen alle auf virtuellen Maschinen und werden nicht über das Netzwerk durchgeführt.
Wenn mehrer sich mehrere virtuelle Server auf der selben LUN tummeln, dann hat der Fileserver nicht mehr die angestrebten 90Mb/s beim Netzwerkzugriff.
Es ist einfach so, das die LUN nicht mehr hergibt (unter Windowssystemen).
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Olaf,
wie testet ihr eigentlich genau?
Nehmt Ihr dafür IO Meter oder kopiert Ihr einen große Datei?
Falls letzteres zutrifft, wo liegt denn die Quell Datei?
Mit vscsiStats hast du schon mal nachgewiesen, das Windows beim Kopieren großer Dateien mit großen IO Sizes arbeitet.
Daher sollte das Performance Problem also nicht kommen.
Ich kann mir aktuell nicht wirklich erklären, warum die Anzahl der Reads > 512KB identisch mit der Anzal der Writes ist.
EDIT
Verwendet Ihr Quatos?
Gruß,
Ralf
wie testet ihr eigentlich genau?
Nehmt Ihr dafür IO Meter oder kopiert Ihr einen große Datei?
Falls letzteres zutrifft, wo liegt denn die Quell Datei?
Mit vscsiStats hast du schon mal nachgewiesen, das Windows beim Kopieren großer Dateien mit großen IO Sizes arbeitet.
Daher sollte das Performance Problem also nicht kommen.
Ich kann mir aktuell nicht wirklich erklären, warum die Anzahl der Reads > 512KB identisch mit der Anzal der Writes ist.
EDIT
Verwendet Ihr Quatos?
Gruß,
Ralf
Hallo Ralf,
zum einen Testen wir mit iometer und einer vorgegebenen Einstellung von Fujitsu:
8 Worker, 67%Read, 8K, 75% Random.
Dabei bekommen wir ein Ergebnis von 126 Write IO's und einen Durchsatz von mageren 1,05MB Write (All Managers) (Read 2,09MB).
Und wir benutzen für die großen Dateien den h2testw von heise.
Der generiert die Dateien ja und kopiert sie aus dem RAM.
@~thc, Dayworker
Ob unser Officescan von TrendMicro aktiviert oder deaktiviert (bzw. nicht installiert ist), macht im Ergebnis leider keinen Unterschied.
zum einen Testen wir mit iometer und einer vorgegebenen Einstellung von Fujitsu:
8 Worker, 67%Read, 8K, 75% Random.
Dabei bekommen wir ein Ergebnis von 126 Write IO's und einen Durchsatz von mageren 1,05MB Write (All Managers) (Read 2,09MB).
Und wir benutzen für die großen Dateien den h2testw von heise.
Der generiert die Dateien ja und kopiert sie aus dem RAM.
@~thc, Dayworker
Ob unser Officescan von TrendMicro aktiviert oder deaktiviert (bzw. nicht installiert ist), macht im Ergebnis leider keinen Unterschied.
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
ihr verwendet die IOMeter Einstellung für die Tests in Linux und Windows VM, aber nur bei Windows bekommt Ihr so schlechte Werte?
Die vscsiStats Daten enthalten noch weitere interessante Informationen, vielleicht kannst du die mal über nen Filehoster bereitstellen.
Das Forum erlaubt leider keine Attachments mehr.
Für mich sieht das ganz so aus, als ob ihr immer schön brav darauf wartet, das der letzte IO vom Array bearbeitet worden ist, bevor ihr den nächsten sendet.
Und für so eine IO Verhalten sind moderne Arrays nicht wirklich ausgelegt, die wollen es lieber wild.
Gruß,
Ralf
ihr verwendet die IOMeter Einstellung für die Tests in Linux und Windows VM, aber nur bei Windows bekommt Ihr so schlechte Werte?
Die vscsiStats Daten enthalten noch weitere interessante Informationen, vielleicht kannst du die mal über nen Filehoster bereitstellen.
Das Forum erlaubt leider keine Attachments mehr.
Für mich sieht das ganz so aus, als ob ihr immer schön brav darauf wartet, das der letzte IO vom Array bearbeitet worden ist, bevor ihr den nächsten sendet.
Und für so eine IO Verhalten sind moderne Arrays nicht wirklich ausgelegt, die wollen es lieber wild.
Gruß,
Ralf
Hallo Ralf,
nein. Mit iometer haben wir unter Linux noch nicht getestet. Könnte ich aber mal machen.... (hab ich noch nicht dran gedacht).
Auf dem Linuxtestsystem mit dd nur 25GB geschrieben.
Ansonsten haben wir hier keine Linuxsysteme.
Ich habe Dir mal die Logs bereitgestellt:
http://www.load.to/eawjprpFqw/vscsistat-logs.zip
nein. Mit iometer haben wir unter Linux noch nicht getestet. Könnte ich aber mal machen.... (hab ich noch nicht dran gedacht).
Auf dem Linuxtestsystem mit dd nur 25GB geschrieben.
Ansonsten haben wir hier keine Linuxsysteme.
Ich habe Dir mal die Logs bereitgestellt:
http://www.load.to/eawjprpFqw/vscsistat-logs.zip
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Olaf,
so, genau wie ich es erwartet habe.
Die Ergebnisse der beiden Tests sind nicht miteinander zu vergleichen!
Den Punkt mit der doppelten Anzahl von IO's beim Windows Test hatten wir ja schon.
Da das Tool h2testw dazu gedacht ist, fehlerhafte USB Sticks zu entlarven, muß es halt jeden geschriebenen Block noch einmal lesen, um ein Verify durchführen zu können.
DD unter Linux macht das, was es soll, nämlich 25 GB schreiben.
Das erklärt schon mal den Unterschied in der Anzahl der erzeugten IO's beim Anlegen einer Datei.
Aber es kommt noch besser.
Beim Linux Test kriegt das Array bis zu 64 IO's auf einmal, der Windows Test stellt immer nur einen IO bereit.
Linux
Windows
Und das schlägt sich auch in den Antwortzeiten wieder.
Während beim Linux Test
Linux
Windows
Beim Windows h2testw Test werden pro Write IO 1 MB, beim Linux dd Test 512KB übertragen.
Allerdings sendet Linux gleich 64 IO's an das Array und Windows immer nur einen.
Wenn wir jetzt mal (zur Berechnung) von 100ms pro IO bei Linux und 5ms pro IO bei Windows ausgehen, ergibt sich gut 100 ms nach Testbeginn folgendes Bild.
Linux hat maximal 32 MB (64 * 512KB), Windows maximal 10 MB (5ms für 1 MB schreiben, danach 5ms für 1MB lesen um das dann zu vergleichen) geschrieben.
Somit erscheint Linux um den Faktor 3 schneller als Windows.
Meine persönliche Einschätzung ist daher, das die von euch festgestellten Werte maßgeblich durch die eingesetzten Tools und nicht durch das Storage Array verursacht werden.
Denn nach meiner Erfahrung lassen weder h2testw noch Linux dd sinnvolle Rückschlüsse für den operativen Betrieb zu, da sie kaum im normalen Lastverhalten einer produktiven Storageumgebung auftreten.
Somit stellt sich mal wieder die Frage, was für ein Anforderungsprofil Ihr eigentlich für die Umgebung habt, damit dann mit sinnvollen Tests überprüft werden kann, ob diese Anforderungen erfüllt werden können.
Aber da ihr ja schon gekauft habt stellt sich auch die Frage, ob ihr diesen Aufwand überhaupt noch betreiben wollt.
Gruß,
Ralf
so, genau wie ich es erwartet habe.
Die Ergebnisse der beiden Tests sind nicht miteinander zu vergleichen!
Den Punkt mit der doppelten Anzahl von IO's beim Windows Test hatten wir ja schon.
Da das Tool h2testw dazu gedacht ist, fehlerhafte USB Sticks zu entlarven, muß es halt jeden geschriebenen Block noch einmal lesen, um ein Verify durchführen zu können.
DD unter Linux macht das, was es soll, nämlich 25 GB schreiben.
Das erklärt schon mal den Unterschied in der Anzahl der erzeugten IO's beim Anlegen einer Datei.
Aber es kommt noch besser.
Beim Linux Test kriegt das Array bis zu 64 IO's auf einmal, der Windows Test stellt immer nur einen IO bereit.
Linux
Code: Alles auswählen
Histogram: number of outstanding Write IOs when a new Write IO is issued for virtual machine worldGroupID : 48056, virtual disk handleID : 8213 (scsi0:0) {
min : 1
max : 64
mean : 24 <=========
count : 41279
{
827 (<= 1)
656 (<= 2)
1717 (<= 4)
1740 (<= 6)
2057 (<= 8)
3996 (<= 12)
3643 (<= 16)
3559 (<= 20)
3211 (<= 24)
3511 (<= 28)
3129 (<= 32)
13233 (<= 64)
0 (> 64)
}Windows
Code: Alles auswählen
Histogram: number of outstanding Write IOs when a new Write IO is issued for virtual machine worldGroupID : 54267, virtual disk handleID : 8216 (scsi0:1) {
min : 1
max : 4
mean : 1 <=========
count : 41448
{
40984 (<= 1)
425 (<= 2)
39 (<= 4)
0 (<= 6)
0 (<= 8)
0 (<= 12)
0 (<= 16)
0 (<= 20)
0 (<= 24)
0 (<= 28)
0 (<= 32)
0 (<= 64)
0 (> 64)
}Und das schlägt sich auch in den Antwortzeiten wieder.
Während beim Linux Test
- 42% der IO's mehr als 50ms
- 24% aller IO's sogar mehr als 100ms
Linux
Code: Alles auswählen
Histogram: latency of IOs in Microseconds (us) for virtual machine worldGroupID : 48056, virtual disk handleID : 8213 (scsi0:0) {
min : 110
max : 308278
mean : 65449
count : 44228
{
0 (<= 1)
0 (<= 10)
0 (<= 100)
1396 (<= 500)
734 (<= 1000)
477 (<= 5000)
4534 (<= 15000)
4701 (<= 30000)
6751 (<= 50000)
14840 (<= 100000)
10795 (> 100000)
}
Windows
Code: Alles auswählen
Histogram: latency of IOs in Microseconds (us) for virtual machine worldGroupID : 54267, virtual disk handleID : 8216 (scsi0:1) {
min : 288
max : 2017098
mean : 8117
count : 82417
{
0 (<= 1)
0 (<= 10)
0 (<= 100)
77 (<= 500)
222 (<= 1000)
37347 (<= 5000)
35261 (<= 15000)
7657 (<= 30000)
1415 (<= 50000)
357 (<= 100000)
81 (> 100000)
}
Beim Windows h2testw Test werden pro Write IO 1 MB, beim Linux dd Test 512KB übertragen.
Allerdings sendet Linux gleich 64 IO's an das Array und Windows immer nur einen.
Wenn wir jetzt mal (zur Berechnung) von 100ms pro IO bei Linux und 5ms pro IO bei Windows ausgehen, ergibt sich gut 100 ms nach Testbeginn folgendes Bild.
Linux hat maximal 32 MB (64 * 512KB), Windows maximal 10 MB (5ms für 1 MB schreiben, danach 5ms für 1MB lesen um das dann zu vergleichen) geschrieben.
Somit erscheint Linux um den Faktor 3 schneller als Windows.
Meine persönliche Einschätzung ist daher, das die von euch festgestellten Werte maßgeblich durch die eingesetzten Tools und nicht durch das Storage Array verursacht werden.
Denn nach meiner Erfahrung lassen weder h2testw noch Linux dd sinnvolle Rückschlüsse für den operativen Betrieb zu, da sie kaum im normalen Lastverhalten einer produktiven Storageumgebung auftreten.
Somit stellt sich mal wieder die Frage, was für ein Anforderungsprofil Ihr eigentlich für die Umgebung habt, damit dann mit sinnvollen Tests überprüft werden kann, ob diese Anforderungen erfüllt werden können.
Aber da ihr ja schon gekauft habt stellt sich auch die Frage, ob ihr diesen Aufwand überhaupt noch betreiben wollt.
Gruß,
Ralf
@AD01
Hilfreich sind da immer vergleichbare Test auf unterschiedlichen Systemen.. Daher verweise ich mal die olle Kamelle http://vmware-forum.de/viewtopic.php?p= ... ght=#78549
Lege einfach mal eine neue Server 2008 (r2) vm an und test auf einem LW D ( zweite VMDK) mit dem OpenPerformanceTest.
Hier mal als Vergleich die Werte einer MD3000 / MD3220i per ISCSI.
Die Max Throughput Werte könnten sicher besser sein, aber wir haben nix an
"Disk.ScheNumReqOustandig" und "lun_queue_depth" sowie andere Dingen wie IO Path switching (Default 1000 I/O's)geändert. Quasi Stock ESXi 4.1 U3 aktuelle Patchstand.
Hilfreich sind da immer vergleichbare Test auf unterschiedlichen Systemen.. Daher verweise ich mal die olle Kamelle http://vmware-forum.de/viewtopic.php?p= ... ght=#78549
Lege einfach mal eine neue Server 2008 (r2) vm an und test auf einem LW D ( zweite VMDK) mit dem OpenPerformanceTest.
Hier mal als Vergleich die Werte einer MD3000 / MD3220i per ISCSI.
Die Max Throughput Werte könnten sicher besser sein, aber wir haben nix an
"Disk.ScheNumReqOustandig" und "lun_queue_depth" sowie andere Dingen wie IO Path switching (Default 1000 I/O's)geändert. Quasi Stock ESXi 4.1 U3 aktuelle Patchstand.
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
@bla!zilla
Thank you for the flowers....
Und würde ich ja gerne, aber man läßt mich ja nicht.
Aber der Transfermarkt öffnet im Winter ja wieder.
@Supi,
das du die "Disk.ScheNumReqOustandig" und "lun_queue_depth" nicht angepasst hast ist eher von Vorteil, denn damit beschränkst du den Zugriff auf die Resourcen.
Finde es sowieso verwunderlich, das ein Hersteller heute noch eine LUN Queue Depth von 8 fordert.
Schon mit ESX 3.5 wurde der Default Wert auf 16 gestellt, und das ist schon mehr als 4 Jahre her.
Changing the queue depth for QLogic, Emulex and Brocade HBAs
ESXi 5.x will mit 64 Queue Slots arbeiten, das ist um den Faktor 8 höher.
Somit sind die vom Storage Hersteller vorgegebenen Werte seeeeeeeeeeeeeeeeeeeeeeehr konservativ.
Ralf
Thank you for the flowers....
Und würde ich ja gerne, aber man läßt mich ja nicht.
Aber der Transfermarkt öffnet im Winter ja wieder.
@Supi,
das du die "Disk.ScheNumReqOustandig" und "lun_queue_depth" nicht angepasst hast ist eher von Vorteil, denn damit beschränkst du den Zugriff auf die Resourcen.
Finde es sowieso verwunderlich, das ein Hersteller heute noch eine LUN Queue Depth von 8 fordert.
Schon mit ESX 3.5 wurde der Default Wert auf 16 gestellt, und das ist schon mehr als 4 Jahre her.
Changing the queue depth for QLogic, Emulex and Brocade HBAs
ESXi 5.x will mit 64 Queue Slots arbeiten, das ist um den Faktor 8 höher.
Somit sind die vom Storage Hersteller vorgegebenen Werte seeeeeeeeeeeeeeeeeeeeeeehr konservativ.
Ralf
@kastir
Jetzt muss ich das auch mal loswerden:
Ich finde es bewundernswert was Du in diese Sache investierst.
Meine Hochachtung und vielen Dank dafür.
Doch leider wieder zum Problem:
Die hohe Anzahl an Read-IOs unter Windows lässt sich damit erklären, das h2testw einen Verify nach dem Schreibtest macht.
Eigentlich wollte ich das vorher abbrechen, damit der Read nicht in das Log einfließt......irgendwas kam wieder dazwischen.
Aber warum schreibt Windows immer nur ein IO? Kann man das beeinflussen??
Meine W2008-TestVM hat jetzt eine zusätzliche VMDK auf einer anderen LUN und einem anderen ControllerModul.
Ich habe jetzt mal eine 20GB Große Datei von einer LUN zu anderen kopiert.
Der Durchsatz ist laut Storage genauso miserable wie vorher.
Wenn es Dir keine Umstände macht, lege ich das Log nochmal ab.
http://www.load.to/ZtVIbCuAjn/vscistat2.zip
Schau Dir mal die Screenshots der Storageauslastung an:
Von V1-Raid10 werden die 20GB gelesen (Platten CE-Disk#0-11)
und auf V4-Raid5 geschrieben (Platten DE#2-Disk#1-9).
Interessant hierbei ist die Plattenauslastung mit ca.90%.
Bei dem Linuxtest liegen wir fast bei 100% aber einem dreifachen Durchsatz...
Wenn wir von unserem Anforderungsprofil reden:
Wir haben das Ganze von einem Systemhaus planen und aufbauen lassen.
Dabei wurden unsere Erwartungen an die neue Umgebung (komplett virtuell, Ausfallsicherheit für die Hosts, FC und das Storage) berücksichtigt und eingeplant.
Wenn wir aber jetzt unsere 30 VM-Server (u.a 2 Fileserver, ein SQL-Statistiksystem "Business Objects", eine Oracle-DB fürs Flottenmanagement, mehrere Anwendungsserver,
zwei Exchange-Server, TrendMicro NeatSuite, usw.) auf die drei LUN's loslassen, dann geht leider so gut wie gar nichts mehr.
Jetzt muss ich das auch mal loswerden:
Ich finde es bewundernswert was Du in diese Sache investierst.
Meine Hochachtung und vielen Dank dafür.
Doch leider wieder zum Problem:
Die hohe Anzahl an Read-IOs unter Windows lässt sich damit erklären, das h2testw einen Verify nach dem Schreibtest macht.
Eigentlich wollte ich das vorher abbrechen, damit der Read nicht in das Log einfließt......irgendwas kam wieder dazwischen.
Aber warum schreibt Windows immer nur ein IO? Kann man das beeinflussen??
Meine W2008-TestVM hat jetzt eine zusätzliche VMDK auf einer anderen LUN und einem anderen ControllerModul.
Ich habe jetzt mal eine 20GB Große Datei von einer LUN zu anderen kopiert.
Der Durchsatz ist laut Storage genauso miserable wie vorher.
Wenn es Dir keine Umstände macht, lege ich das Log nochmal ab.
http://www.load.to/ZtVIbCuAjn/vscistat2.zip
Schau Dir mal die Screenshots der Storageauslastung an:
Von V1-Raid10 werden die 20GB gelesen (Platten CE-Disk#0-11)
und auf V4-Raid5 geschrieben (Platten DE#2-Disk#1-9).
Interessant hierbei ist die Plattenauslastung mit ca.90%.
Bei dem Linuxtest liegen wir fast bei 100% aber einem dreifachen Durchsatz...
Wenn wir von unserem Anforderungsprofil reden:
Wir haben das Ganze von einem Systemhaus planen und aufbauen lassen.
Dabei wurden unsere Erwartungen an die neue Umgebung (komplett virtuell, Ausfallsicherheit für die Hosts, FC und das Storage) berücksichtigt und eingeplant.
Wenn wir aber jetzt unsere 30 VM-Server (u.a 2 Fileserver, ein SQL-Statistiksystem "Business Objects", eine Oracle-DB fürs Flottenmanagement, mehrere Anwendungsserver,
zwei Exchange-Server, TrendMicro NeatSuite, usw.) auf die drei LUN's loslassen, dann geht leider so gut wie gar nichts mehr.
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Olaf,
keine Ursache, abends läuft bei uns halt immer "Fashion Hero, The voice of Germany" und anderer Blödsinn.
Aktuell läuft z. B. "Wer wird Millionär - Promi Spezial".
Außerdem es ist mehr Aufwand, die Informationen hier ins Forum zu posten als sie aus den Daten zu ziehen.
Aber trotzdem danke für die Bestätigung.
So, und nun wieder zurück zu eurem Problem.
Ja, man kann das Verhalten von Windows beeinflussen, in dem man Tools verwendet, die Copy Jobs unter Verwendung von mehreren Threads durchführen.
Daher habe ich jetzt auch nicht in die neuen Daten geschaut, denn ihr habt ja nichts wesentliches geändert.
Wiederholt den Copy Job der Datei mal mit Microsoft Richcopy.
Im Abschnitt Thread number könnt Ihr unter File copy die Anzahl der Threads einstellen, wenn Ihr mit einer Datei testen wollt.
Testet mal mit einem Wert von 24, denn diesen Wert hattet Ihr im Mittel beim Linux Test.
Falls Ihr mal den Inhalt eines Verzeichnisses kopieren wollt, würde ich den Wert unter Directory copy erhöhen (z, B. 30) und dafür den File copy Wert wieder auf 1 setzen.
Das ihr bei der Konfiguration mit 30 VMs ein Problem habt, überrascht mich nicht im Geringsten.
Mal wieder etwas Mathematik.
Liest sich erst mal nicht schlecht, aber das ist das rechnerische Maximum, und das wird nie erreicht.
Zusätzlich müßtet Ihr einige VMware NMP Einstellungen nutzen, die (vermutlich) zumindest teilweise nicht von Fujitsu supported werden, nämlich
Somit stehen euren 30 VM's zeitgleich gerade mal 48 IO Slots zur Verfügung, und zwar maximal 24 pro ESX Host, 16 pro LUN.
Ihr könnt das relativ leicht überprüfen, in dem Ihr mal esxtop auf einem ESXi Server ausführt und mit u in den Disk Device View wechselt.
In der Spalte ACTV wird aufgeführt, wie viele IO's gerade ans Array übergeben worden sind, unter QUED wieviele IO's im Kernel darauf warten, ans Array übergeben zu werden.
Ich gehe davon aus, das in eurer Umgebung unter Last
Im Idealfall ist ACTV immer kleiner als DQLEN, QUED und KAVG/cmd annähernd 0.
Meine Empfehlung für einen Quick Win wäre, die Limitierung der Queue LUN Depth rückgängig zu machen.
Denn üblicherweise werden diese Parameter aus einem einzigem Grund eingesetzt, wenn das Array pro LUN eine feste Anzahl von Queue Slot hat.
Und durch das Anpassen dieses Wertes stellt der Hersteller sicher, dass das Array niemals einen IO wegen Queue Full ablehnen wird.
Bei der Berechnung zählen die Hersteller zur Sicherheit alle Pfade von allen Servern mit, auch wenn bei euch höchstwahrscheinlich immer nur ein Pfad pro LUN wirklich verwendet wird.
Ein weiterer Vorteil dieser Vorgehensweise wäre, das ihr das mit euren 2 ESX Server relativ schnell verifizieren könntet.
Stellt den Wert auf einem zurück auf 64, beim anderen verwendet ihr die aktuelle Konfiguration.
Dann könnt Ihr ganz einfach mit vMotion überprüfen, wie sich das Verhalten einer VM in Abhängigkeit vom verwendeten ESXi Server verändert.
Langfristig solltet Ihr darüber nachdenken, mehr LUN's nach draußen zu geben.
Aber das ist heute abend kein Thema mehr.
Gruß,
Ralf
keine Ursache, abends läuft bei uns halt immer "Fashion Hero, The voice of Germany" und anderer Blödsinn.
Aktuell läuft z. B. "Wer wird Millionär - Promi Spezial".
Außerdem es ist mehr Aufwand, die Informationen hier ins Forum zu posten als sie aus den Daten zu ziehen.
Aber trotzdem danke für die Bestätigung.
So, und nun wieder zurück zu eurem Problem.
Ja, man kann das Verhalten von Windows beeinflussen, in dem man Tools verwendet, die Copy Jobs unter Verwendung von mehreren Threads durchführen.
Daher habe ich jetzt auch nicht in die neuen Daten geschaut, denn ihr habt ja nichts wesentliches geändert.
Wiederholt den Copy Job der Datei mal mit Microsoft Richcopy.
Im Abschnitt Thread number könnt Ihr unter File copy die Anzahl der Threads einstellen, wenn Ihr mit einer Datei testen wollt.
Testet mal mit einem Wert von 24, denn diesen Wert hattet Ihr im Mittel beim Linux Test.
Falls Ihr mal den Inhalt eines Verzeichnisses kopieren wollt, würde ich den Wert unter Directory copy erhöhen (z, B. 30) und dafür den File copy Wert wieder auf 1 setzen.
Das ihr bei der Konfiguration mit 30 VMs ein Problem habt, überrascht mich nicht im Geringsten.
Mal wieder etwas Mathematik.
Code: Alles auswählen
Anzahl der LUNs: 3
Anzahl Pfade pro LUN: 4 (hier bin ich mir nicht sicher, aber das ist bei ALUA Arrays Standard)
Anzahl ESXi Server: 2
LUN Queue Depth: 8
Nun berechnen wir die MAXIMAL mögliche Anzahl von IO's, die ZEITGLEICH ans Array übergeben werden könnten.
Max IO's = LUN's * Pfade * Server * Queue Length = 3 * 4 * 2 * 8 = 192 IO
Liest sich erst mal nicht schlecht, aber das ist das rechnerische Maximum, und das wird nie erreicht.
Zusätzlich müßtet Ihr einige VMware NMP Einstellungen nutzen, die (vermutlich) zumindest teilweise nicht von Fujitsu supported werden, nämlich
- Round Robin
- IOPS = 1
- useANO=1
Code: Alles auswählen
MRU = 48 (nur ein Pfad wird verwendet)
Fixed = 48 (nur ein Pfad wird verwendet)
RR = 48 ++ (2 Pfade können verwendet werden, Pfadwechsel erfolgt jeweils nach 1000 IOs)Somit stehen euren 30 VM's zeitgleich gerade mal 48 IO Slots zur Verfügung, und zwar maximal 24 pro ESX Host, 16 pro LUN.
Ihr könnt das relativ leicht überprüfen, in dem Ihr mal esxtop auf einem ESXi Server ausführt und mit u in den Disk Device View wechselt.
In der Spalte ACTV wird aufgeführt, wie viele IO's gerade ans Array übergeben worden sind, unter QUED wieviele IO's im Kernel darauf warten, ans Array übergeben zu werden.
Ich gehe davon aus, das in eurer Umgebung unter Last
- der Wert unter ACTV nie über 8 steigen wird,
- unter QUED oft Werte ungleich 0 stehen,
- unter KAVG/cmd oft Werte größer 5 stehen werden.
Im Idealfall ist ACTV immer kleiner als DQLEN, QUED und KAVG/cmd annähernd 0.
Meine Empfehlung für einen Quick Win wäre, die Limitierung der Queue LUN Depth rückgängig zu machen.
Denn üblicherweise werden diese Parameter aus einem einzigem Grund eingesetzt, wenn das Array pro LUN eine feste Anzahl von Queue Slot hat.
Und durch das Anpassen dieses Wertes stellt der Hersteller sicher, dass das Array niemals einen IO wegen Queue Full ablehnen wird.
Bei der Berechnung zählen die Hersteller zur Sicherheit alle Pfade von allen Servern mit, auch wenn bei euch höchstwahrscheinlich immer nur ein Pfad pro LUN wirklich verwendet wird.
Ein weiterer Vorteil dieser Vorgehensweise wäre, das ihr das mit euren 2 ESX Server relativ schnell verifizieren könntet.
Stellt den Wert auf einem zurück auf 64, beim anderen verwendet ihr die aktuelle Konfiguration.
Dann könnt Ihr ganz einfach mit vMotion überprüfen, wie sich das Verhalten einer VM in Abhängigkeit vom verwendeten ESXi Server verändert.
Langfristig solltet Ihr darüber nachdenken, mehr LUN's nach draußen zu geben.
Aber das ist heute abend kein Thema mehr.
Gruß,
Ralf
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 11 Gäste