Seite 1 von 1

Queue Depth bei IBM SVC (bzw. Anpassung generell)

Verfasst: 02.10.2015, 16:53
von pirx
Im Rahmen der Cases wegen unseren Ausfällen bei Störungen im Storage, haben wir nun von IBM die Empfehlung bekommen unsere Queue depth anzupassen (IBM SVC, V7000, Flash+SATA, Easy Tiering).

http://www-01.ibm.com/support/knowledge ... ml?lang=en

Wenn ich das damit berechnen, kommen ich auf Queue depths von 1-6 (je nach dem, mit welchen Werten wir rechnen). Dieser Wert sei laut IBM auch realistisch.

Mir kommt so ein geringer Wert seltsam vor, hat jemand hier bei einem vergleichbaren Storage den Wert auch schon in diesem Bereich anpassen müssen?

Verfasst: 02.10.2015, 18:45
von kastlr
Hallo,

das Thema holen die Storage Hersteller immer mal wieder aus der Versenkung.

Dreh die Frage doch einfach um und frag mal nach, wie oft deine SVC denn schon in einen Queue Full Event gelaufen ist.
Denn soweit mir bekannt ist senden aktuelle Arrays nur dann eine Queue Full Message, wenn alle IO Slots des Controllers (und nicht einer einzelnen LUN) verbraucht sind.
Sie sollten nämlich in der Lage sein, ihre Resourcen dynamisch an die Last anzupassen.
Soll heißen, wird eine LUN besonders belastet erhält diese dynamisch mehr Cache Slots zugewiesen als LUN's ohne Last.
Wenn die Last wandert psast das Array sich diesem Verhalten an und gibt dem neuen HotSpot mehr Resourcen.

Mit deiner Einstellung erlaubst du jedoch nur max 6 zeitgleiche IO's je Device Pfad.
LUN's die gerade wenig zu tun haben wird das nicht stören.
Bei LUN's mit hoher Last wird dadurch der Host gedrosselt, und zwar unabhängig davon, das der Storage Controller nicht verwendete IO Slot's anderer LUN's verwenden könnte.

Wie oft zeigt dir esxtop denn unter QUED überhaupt einen Wert ungleich 0 an?
Denn nur in diesem Fall muß dein Host so lange auf dein Array warten, dass er in der Zwischenzeit alle vorhandenen IO Slots des HBA's mit Anfragen belegt hat.

Dass sollte eigentlich die absolute Ausnahme sein, wenn du häufiger Werte ungleich 0 unter QUED siehst ist dein Array zu langsam.
Aber da gibt es sicher auch etwas von Ratiopharm ;-).

Gruß,
Ralf

Verfasst: 02.10.2015, 21:32
von pirx
Der erste Ausfall geschah durch einen geplanten Shutdown eines SVC Knoten und dem ATS Heartbeat Problem das ab 5.5 bei bestimmten Arrays auftritt.

Der zweite Ausfall kam durch eine Störung im SVC (ein DWDM Verbindung weg, komisches SVC Verhalten mit Reboot der Knoten _nacheinander_). Es gab aber keine APD Situation, warum die vSphere Cluster auf das Storage nicht mehr zugreifen konnten, ist immer nicht nicht 100% klar.

Beim zweiten Ausfall kam es laut Support zu einer Queue Full Situation, daher die Empfehlung von IBM die Queue Depth anzupassen. Außerdem die Empfehlung von VMware ATS Locking auf den Hosts zu deaktivieren.

Beides macht mich nicht wirklich glücklich.