Fragen zur "Disk Queue Depth"

[Dayworker]

Im STH-Forum gab es unter ESXi 5.5 - Maximum Number of Passthrough Devices >4? ein interessantes Posting hinsichtlich der "Disk Queue Depth".

...

• LSI Parallel = Queue Depth 1 (fixeD)
• LSI SAS = Queue Depth 16 (fixed)
• PVSCSI = Queue Depth 32/64 (adjustable) -> IE. 255 Queue Depth plus Ring size=32

Dazu stellen sich mir mehrere Fragen:

• Wie kann man das verifizieren?
• Erklärt das, zusätzlich zur Abbildung des Platten-Controllers in SW, die geringere Schreibperformance innerhalb einer VM im Gegensatz zu realer HW?

[kastlr]

Hallo,

zum Punkt virtuelle SCSI Controller und Queue Depth gibt es von VMware offenbar nur Artikel für den PVSCSI Controller.
Changing Paravirtualized SCSI Controller Device Queue Depth in VMware ESXi 4.x and later
Large-scale workloads with intensive I/O patterns might require queue depths significantly greater than PVSCSI default values

Zum zweiten Punkt, das glaube ich weniger.
Der entscheidende Punkt beim Thema Queueing ist, das man eigentlich gar kein Queueing haben möchte.
Die Queues sind dafür gedacht, kurze Spitzen abzufangen.
Wenn dein System ständig queued, hast du eventuell ein Performance Problem.

Eine normale Disk kann im Prinzip immer nur einen IO bearbeiten, allerdings ist in der Lage, zeitgleich mehrere Anfragen anzunehmen.
Somit wird der Eindruck erzeugt, die Platte würde parallel arbeiten.
Das geht aber nicht, denn die R/W Köpfe können ja immer nur eine Position einnehmen.

Also werden z.B. 8 Anfragen angenommen und (eventuell optimiert) hintereinander abgearbeitet.
Somit muß die nächste Stelle (HBA) zwar nicht auf einen freien Slot zur Übermittlung der Anfrage warten, stattdessen wartet sie auf die Daten oder das ACK.

Dafür verwendet er die HBA Queue, die bei ESXi je nach HBA Typ wie folgt dimensioniert werden.
Changing the queue depth for QLogic, Emulex and Brocade HBAs

Somit wird über diese Einstellungen eigentlich festgelegt, wieviele aktive IO Requests an die Disk/array gesendet werden können.
Wenn diese Queue nicht ausreicht, wird das Queueing im ESX Server und/oder der VM aktiv.

Aus meiner Erfahrung ist eigentlich nur die HBA Queue Depth Einstellung wirklich von Bedeutung, und zwar aus folgendem Grund.
An dieser Komponente verläßt die IO Anfrage den GHz Bereich und wechselt in den kHz Bereich.
Ob du daher in anderen Schichten weitere Queues hast dürfte sich kaum auswirken, da sowieso alle auf die Disk warten müssen.

Das ist auch der Grund dafür, das man die Anzahl der LUN's nicht zu klein wählen sollte.
Welcher technische Grund spricht z. B. gegen 100 LUN's für einen ESX Cluster, auf dem 200 VM's laufen?

In der physikalischen Welt hatten die Systeme ja auch meistens zwei Platten.


Somit sollte der Overhead bei gezielten Lasttest zwar meßbar sein, aber im Regelbetrieb kaum Auswirkungen zeigen.

Gruß,
Ralf

[pirx]

H
Das ist auch der Grund dafür, das man die Anzahl der LUN's nicht zu klein wählen sollte.
Welcher technische Grund spricht z. B. gegen 100 LUN's für einen ESX Cluster, auf dem 200 VM's laufen?

Technisch spricht wahrscheinlich gar nichts dagegen. Unsere Windows VMs haben z.B. per Default 150 GB vDisks verteilt auf 3 Windows Laufwerke. Es häufen sich aber immer mehr VMs die auch einzelne vDisks > 200 GB haben. Manche auch > 1 TB.

Da wir sDRS Cluster nutzen, sollten die Datastores darin eine vergleichbare Größe haben. Wenn ich nun 100 kleine DS habe statt 25 Große, wird das schwierig. sDRS kann sonst bei Engpässen die VMs nicht mehr so gut verteilen. Da wir thin VMDKs verwenden, ist es für mich essentiell wichtig, dass VMs bei Engpässen von sDRS automatisch verschoben werden können. Je kleiner die DS sind, desto schwieriger ist das. Man will ja auch noch min. 10-20% Puffer pro DS vorhalten.

Bei insg. 192 VMs in dem Cluster liegen im Durchschnitt 10-15 VMs auf einem DS. In dem sDRS Cluster gibt es 25 DS mit 2 TB.

Bei 100 DS statt 25 hätte jedes DS nun noch 500 GB, wir würden als nun noch 2 Standard VMs dort unterbringen (sofern die Disks zusammen liegen sollen) und für die größeren VMs (vDisks) müssten wir einen extra sDRS Cluster verwenden.

[kastlr]

Danke für diese Antwort.

Denn Sie dokumentiert, wie in dem meisten Fällen das Sizing eines Arrays durchgeführt wird, nämlich ausschließlich an Hand der geforderten Kapazitäten.

Gruß,
Ralf

[pirx]

Die Kapazität ist meistens auch das einzige was man im Vorfeld kennt. Und auch da wird es schon schwammig. Ich würde hier gerne mehr planen, aber die einzige mir bekannte Größe für einen neuen Cluster ist i.d.R. "wir brauchen einen neuen Cluster der 2 Jahre hält". Und das Storage kommt hier vom Storage Team, welche Hardware dort angeschafft wird, bzw. was für den Cluster zur Verfügung gestellt wird, auch darauf habe ich keinen Einfluss.

[Dayworker]

Klingt nach der üblichen Praxis, daß die rechte nichts von der linken Hand weiß und demzufolge völlig übertrieben oder sogar komplett am Ziel vorbei investiert wird.

Ein weiteres Beispiel dazu. Da sich unsere Firma innerhalb eines Jahres von 20 nötigen Rechnern auf 40 an allen möglichen Stellen vergrössert hat, wurde der Server natürlich damals auch nur für 25 Leute konzipiert und hakelt jetzt bei jeder sich bietenden Gelegenheit. Mein optisches Inspektionsgerät beispielsweise darf ich seit längerem nicht mehr mit auf dem Server sichern. Die ohne OS in Summe anfallenden 300GB sind schon lange nicht mehr das Problem, inzwischen drückt die schiere Dateianzahl von gut 1.5Mio JPG-Dateien im Bereich von 10-50KB und täglich kommen weitere 10T Dateien hinzu. Da das Backup immer 1:1 gesichert wird, schafft das eingesetzte Sicherungprogramm es seit längerem nicht mehr, meine plus die restlichen Serverdateien in einem Zeitraum X wegzuschreiben und wir reden hier nur von Echtblech-Kisten.

[kastlr]

Das war jetzt auch in keiner Weise negativ gemeint.

Nur muß jedem klar sein, das dann Performance relativ schnell zum Thema werden kann.
Mit den bekannten Nachteilen, das Planungslücken dann während des Regelbetrieb ausgeglichen werden müssen.

Und dann ist die Frustration bei allen Beteiligten schnell sehr hoch, weil es nicht so läuft wie gedacht, obwohl es gut geplant war.

Btw, ich arbeite im Support und sehe täglich den Unterschied zwischen gut gemeint und gut gemacht.
Das ist auch der Grund warum ich aus dieser Ecke raus will, es ist auf die Dauer einfach frustierend, immer wieder die selben Fehler zu sehen und nichts daran ändern zu können.

Gruß,
Ralf

[pirx]

Aus meiner Erfahrung ist eigentlich nur die HBA Queue Depth Einstellung wirklich von Bedeutung, und zwar aus folgendem Grund.
An dieser Komponente verläßt die IO Anfrage den GHz Bereich und wechselt in den kHz Bereich.
Ob du daher in anderen Schichten weitere Queues hast dürfte sich kaum auswirken, da sowieso alle auf die Disk warten müssen.

Ich habe gerade mal auf einigen ESXi Hosts geschaut was dort in esxtop als AQLEN für die HBAs angezeigt wird.

HP LPe1150 4Gb FC: 1014
HP LPe12000 8Gb FC: 2038
QLogic ISP2532: 2176

Die DQLEN im aktuellen Cluster mit VPLEX lieht z.B. bei 64.

Wenn in dem VMware KB Artikel vom Vergrößern der HBA Queue Tiefe geschrieben wird und im Beispiel ql2xmaxqdepth auf 64 gesetzt wird, wie passt das mit meinen deutlich größeren Werten zusammen?

AQLEN ist doch laut Doku die Adapter Queue Depth (https://communities.vmware.com/docs/DOC-9279)

The storage adapter queue depth. This is the maximum number of ESX Server VMKernel active commands that the adapter driver is configured to support.

[kastlr]

Hallo,

die AQLEN ist die Adapter Queue Length und somit die für den Adapter verfügbaren Queue Slots.
Die DQLN ist die Device Queue Length und betrifft damit die einzelnen LUN's.

Gruß,
Ralf

[pirx]

Hallo,

die AQLEN ist die Adapter Queue Length und somit die für den Adapter verfügbaren Queue Slots.
Die DQLN ist die Device Queue Length und betrifft damit die einzelnen LUN's.

Das ist grundsätzlich klar. Also ist die HBA Queue Depth = Adapter Queue Length. Vielleicht fehlt mir da noch der Zusammenhang.

[kastlr]

Hallo,

ok, da saß der Fehler bei mir zwischen den Ohren.

Die HBA Queue Depth kannst du nicht einstellen, die Device Queue Depth schon.
Changing the >device< queue depth for QLogic, Emulex and Brocade HBAs

Gruß,
Ralf