After reading this Reddit thread about a customers recent experience with VSAN, I have been thinking about how customers can actually tell what the queue depth is for a particular storage controller? Currently, the VSAN HCL for storage controllers does not provide any queue depth information and from my understanding this information may not always be easy to find or documented.
I know Duncan Epping has even "crowd source" for some of this information and currently his list seems to be the best at the moment. However, if you look through his list carefully, you will see that it only contains a very small subset of the supported storage controllers found on the VSAN HCL as it also contains non-supported storage controllers. I was thinking about how can we build a more compressive list and more importantly, one that includes ALL the storage controllers found on the VSAN HCL to help our customers?
It then hit me, why not build on top of the effort Duncan has started and create a compressive list that includes all storage controllers found within the VSAN HCL and their corresponding queue depth? For this effort, I decided to take a slightly different approach on how I gather the information. Right now, a user is asked to must manually run through a series of commands in ESXTOP and then report back the vendor, make and the queue depth of a particular storage controller that may or may not be on the VSAN HCL. My goal was to make the process as simple as possible by automating the data collection but also adding some intelligence into the script which you will see as you read further.
If you currently look at the VSAN HCL for storage controllers (as of 07/18/14), there are currently 73 supported storage controllers:
| Vendor | Controllers |
|---|---|
| Cisco | 1 |
| Dell | 4 |
| Fujitsu | 6 |
| HP | 4 |
| IBM | 6 |
| Intel | 16 |
| LSI | 33 |
| SuperMicro | 3 |
Instead of asking a user to identify the proper storage controller, the make/model and the queue depth to submit, I have instead created a very simple python script that runs inside the ESXi Shell (this information is not available in the API) to help collect this information. The interesting thing about the script is not the collection itself as mentioned, but how it performs the collection. I have embedded the entire list of supported storage controllers found in the VSAN HCL and as the script scans through the storage controllers within an ESXi host, it will compare that to the list of supported controllers. If a supported controller is found, it will then display some basic information about the storage controller along with the current supported queue depth. The nice thing about this list if completed, is that when selecting a particular storage controller in the VSAN HCL, you can easily map that same device to the VSAN storage controller queue depth list and have confidence it is the same device!
To use the script, follow these 3 simple instructions:
Step 1 - Download the script here: find_vsan_storage_ctrl_queue_depth.py
Disclaimer: Please excuse my poor Python script, as a Python beginner, I am sure it can be better written and open to any fixes/suggestions
Step 2 - SCP it to your ESXi host and make sure you set the execute permission on the script before running (chmod +x find_vsan_storage_ctrl_queue_depth.py).
Here is an example of the script running on an ESXi host with a supported VSAN storage controller:
As you can see from the screenshot above, this is an Intel controller which supports a queue depth of 600.
Step 3 - Submit the results to the "Community" VSAN Storage Controller Queue Depth List which is hosted on Google Docs and is available for everyone to contribute
The easiest way to map the output to the Google document is to find the "Identifier" ID which is actually made up of the Vendor ID (VID), Device ID (DID), Sub-Vendor ID (SVID), and Sub-Device ID (SDID) within the Google document. Once you have found the match on the document and if no one has submitted the queue depth, go ahead and edit the document with the queue depth from the script.
For those of you who would like to contribute non-supported VSAN storage controllers, there is a variable in the script called show_non_vsan_hcl_ctr that can be toggled from False to True and this will provide a much longer list of controllers and their queue depth.
In addition to the assistance from the community, I also hope to see some of the storage controller vendors participate in this effort to help build a complete list of supported queue depth for every storage controller found on the VSAN HCL. I think this will benefit everyone and I look forward to seeing the collaboration from the community! Lets see how fast we can complete the list, I have faith in our powerful community!
