Storage IO Control / SIOC / Queue Depth

[pirx]

Hallo,

ich wollte eigentlich die Queue Depth der Software iSCSI Adapter auf den ESXi 4.1 Hosts verändern, die auf die LUNs der P4500 Lefthands zugreifen. Laut einigen Posts von HP Technikern im Lefthand Forum, sollte sie 1,5 - 2 x Anzahl der Disks pro Node x Anzahl Node sein.

Das wären dann hier z.B. 1,5 x 12 x 12 = 216

Dies kommt mir etwas hoch vor. Auf der anderen Seite habe ich gesehen, dass es zum Thema Verändern der Queue Depth sehr unterschiedliche Meinungen gibt. U.A. das es durch das mit ESXi 4.1 eingeführte SIOC nicht mehr nötig ist den Parameter selber anzupassen.

Bisher ist SIOC auf den Datastores nicht aktiv. Ich überlege nun es zu aktivieren. In den Beispielen die ich dazu gefunden habe wird aber immer mit Priorisierung von VMs über die Ressourcen Einstellungen gearbeitet (shares/slots...), dies nutzen wir bisher nicht (ist auch nicht geplant). Nun frage ich mich, ob SIOC dann überhaupt etwas bringt, bzw. ob sich ohne Priorisierung zur Methode ohne SIOC etwas ändert. Das IO damit nicht mehr über den Host, sondern über das Datastore fair verteilt wird, ist mir grundsätzlich klar. Nur wenn alle VMs die gleiche Prio haben, dürfte SIOC ja keinen Einfluss haben.

[kastlr]

Hallo,

auch ohne Priorisierung wird SIOC regulativ eingreifen, indem es allen VM's die gleiche Queuedepth gibt.
Nehmen wir mal an, 4 VM's liegen auf einem Datastore und die aktuelle LUN Queue Depth das HBA's steht bei 30.

Mit aktiviertem SIOC (und Überschreiten des eingestellten Latency Schwellwertes) wird dann sichergestellt, das z.B die 3 VM's auf ESX 1 je 10 Queue Slots erhalten und die eine VM auf ESX 2 auch nur 10 Queue Slots bekommt, obwohl sie eigentlich 30 nutzen könnte.

Wenn SIOC aktiviert ist, erfragt es die "maximum device queue depth per device" und verwendet diesen Wert.
Allerdings ist das in den allermeisten Fällen 32, weil die meisten Hersteller diesen Wert als "Default" verwenden.
Du könntest jetzt stattdessen den Wert 216 verwenden, allerdings glaube ich nicht, das du damit glücklich wirst.

Was meiner Meinung nach nämlich in der Berechnungsformel fehlt ist die Anzahl der Hosts sowie der Pfade zu jeder LUN.
Denn so wie ich die Formel verstehe, ist das der Maximal Wert des Storage Arrays!!!

Wenn du aber 2 Hosts mit je 4 Pfaden zu einer LUN hast, solltest du den Wert mindestens halbieren, um die LUN Queue im Array nicht zu fluten.

Und falls du als NMP Path Policy RR verwendest und dann auch noch IOPS = 1 eingestellt hast, müßtest du den Wert noch weiter reduzieren, da die Einstellung auf dem Host ja pro LUN gilt.
Und wenn die LUN vom Host über mehrere Targets gesehen wird ist dann auch schnell wieder die LUN Queue im Array überflutet.

Gruß & schönes Wochenende,
Ralf

[pirx]

Das die Anzahl der Hosts für die Berechnung der QD mit eingerechnet werden muss und mit einer höheren Anzahl von Hosts die QD eher kleiner werden muss, habe ich gelesen. Leider liest man viel unterschiedliches.

Noch mal zurück SIOC. In unserem Fall ohne Priorisierung würde es bedeuten, dass VMs die hohe IO Last erzeugen ausgebremst werden. Man also bei kritischen VMs zwangsläufig die Ressourcen priorisieren muss. Schlecht wäre es SIOC zu aktivieren und dann von den Anwendern dieser System hören zu müssen, dass ihre Systeme langsamer geworden sind. Die default QD ist hier 32.

[kastlr]

Hallo,

SIOC wird nur dann eingreifen, wenn die Disk Antwortzeiten über dem eingestellten Schwellwert liegen.
Und ohne SIOC würden deine Anwender das dann auch merken.

Das hier kennst du wahrscheinlich schon, aber für alle Fälle noch mal das VMware Dokument zum Thema SIOC.
Storage I/O Control Technical Overview and Considerations for Deployment

Der QD Wert von 32 ist die Standard Einstellung des Treibers, den könntest du gemäß deinen Wünschen anpassen.

Hier ein guter Artikel zum Thema Queue Depth Kalkulation.
Increasing the queue depth?

Gruß,
Ralf

[pirx]

Ich habe nun SIOC auf allen Lefthand iSCSI Datastores aktiviert. Seit dem erhalte ich regelmäßig folgende Meldung im vCenter für jedes Datastore:

Code: Alles auswählen

Alert External I/O workload detected on a datastore


Das Verhalten wird u.A. hier beschrieben:

http://www.yellow-bricks.com/2011/01/20 ... atastores/

http://kb.vmware.com/selfservice/micros ... Id=1020651

Dort ist beschrieben, dass dies auftreten kann wenn z.B. SIOC nicht auf allen Datastores aktiviert ist, was hier aber nicht der Fall ist.

Muss ich mir Sorgen machen?

[pirx]

So... nach dem was ich bisher gefunden habe, sind diese Meldungen bei der Lefthand nicht unerwartet.

26179 Einträge in den Logfiles der ESX Hosts seit Fr. sind aber reichlich viel.