VMware-Forum

Hi Leute

Wir haben hier in der Bude zwei Datacore Nodes mit je 36 Disks (immer im zweier RAID1-Pärchen, SAS, 10k, total 18 Raid1-Sets).

Diese 18 Sets werden auf Datacore Ebene zu einem grossen Pool gesponnen und von da aus entstanden die vDisks.

Ist alles per FC verbunden inkl. ALUA und 96GB RAM auf beiden DC-Nodes.
Rund 50 Vms laufen auf diesem Konstrukt, meist win. Eine Hand voll Exchange, SQL etc., sonst nur Beigemüse/TS-Server.

Es läuft soweit, aber nicht gerade berauschend. Wir hören davon und sehen auch selber immer wieder ein "laggy" Verhalten auf den VMs. Verzögerungen bei der Eingabe und schleppende Performance.

Der VMNT Standard iometer test ergab eigentlich gute Werte.

|*TEST NAME*|*Avg Resp. Time ms*|*Avg IOs/sec*|*Avg MB/sec*|*% cpu load*|
|*Max Throughput-100%Read*|2.65|20835|651|85%|
|*RealLife-60%Rand-65%Read*|2.02|13096|102|94%|
|*Max Throughput-50%Read*|2.42|20585|643|94%|
|*Random-8k-70%Read*|1.05|31458|245|97%|

Habt Ihr noch Anhaltspunkte, wo ich mich reinhängen sollte?
esxtop ergibt zumindest im Betrieb und während den tests keine Auffälligkeiten für die Metrik DAVG (nie mehr als 1.7 ms).

Grüsse

Was für ein Storage Subsystem?
Datacore Write Cache an?
Die VMs auf wieviele vDisks verteilt?


Die IO Werte sehen erstmal OK aus...
Lassen sich die Probleme wirklich aufs Storage reduzieren?
Was sagt CPU RDY%?

Angesichts der Latenzen würde ich auch erst einmal keine Probleme vermiten. Wie sind denn die Latenzen, die vom vCenter aufgezeichnet werden. Insbesondere physicsl Device Read und Write Latency?

Wie sehen die Werte für %RDY, CSTP und CPU Latency aus? Verwendet ihr Reservierungen oder Limits an einer Stelle?

Hi Leute

Die Nodes bestehen aus zwei 380 G8 mit je zwei P822 (2GB Cache).

Der Write Cache ist aktiviert und die VMs sind auf insgesamt 11 vDisks verteilt.

physical read und write latencies:

(um 13:00 ging der iometer Test los, 13:05 war RealLife 60%random, 65% read dran. Keine Ahnung was der Ausschlag am Schluss war.)

iometer results von vorhin:
|*TEST NAME*|*Avg Resp. Time ms*|*Avg IOs/sec*|*Avg MB/sec*|*% cpu load*|
|*Max Throughput-100%Read*|2.64|20272|633|85%|
|*RealLife-60%Rand-65%Read*|2.56|9593|74|93%|
|*Max Throughput-50%Read*|2.54|18881|590|90%|
|*Random-8k-70%Read*|1.14|29275|228|96%|

CPU Ready ist im Schnitt bei 0.3 %.

Anbei noch ein esxtop batchfile, welches während dem iometer-Test lief (kann z.B. mit esxplot dargestellt werden):
esxtop-batch_29_10_14_13_00.csv


Der relevante datastore, auf welchem iometer lief, hat den identifier naa.60030d9039edb306da7fd45fd77053fb.

Wir verwenden keine Reservierungen oder limits.

Grüsse und vielen Dank für die Unterstützung!