Nimble Performance Testing, Metrics, & datasheet with I/O Info on all Models

[KimberlyWeber]

Hi,

I'm looking for a few documents or info. One one the I/O read/write for all the Nimble Models, AF & HF, not the datasheet. Also, for performance testing, what are the best metrics to use for each model. As well as alternate tools used to test besides vdBench. Any suggestions or insight would be helpful.

Thanks,

Kimberly Weber

[Nick_Dyer]

Hi Kimberly,

We do not publish hero numbers for Nimble arrays, as frankly they're misleading. Instead, please engage with your local storage specialist team who will be able to advise you on your requirements.

We recommend any performance testing to be carried out using VDBench, with proper parameters set for deduplication & compression, a working set of multiple-TB in size, and long runtimes. Any other tools (such as IOMeter, SQLIO/DiskSPD, CrystalDiskmark) should NOT be used.

[KimberlyWeber]

Hi Nick,

Thank you. However I am not looking for hero numbers. Just a set to test with and also something a little bit easier to use with the customer to measure performance other than VDBench. It is not a practical tool for onsite testing with the hassle of either having to set it up on their system or myself trying to gain access to their network(which in many cases is not possible, as it a secure site). However, I've reached out to Nimble support who has given myself a few different options that I believe may work a bit better than what you have suggested. Again, thanks for trying to help.

Best,

Kimberly Weber
Technical Consultant

HPE Pointnext

[rmay_bk]

4-6 instances of DiskSPD run in parallel across the same number of of hosts will hammer an array rather nicely.  I use a large test file (-c40G) and random, uncompressible data (-Z1G).  With this method I can make a coughunitycough blow smoke into the datacenter if volume dedupe is turned on.  Haven't tried it against the Nimble yet...  But now I will.  8-)

[Nick_Dyer]

Unfortunately, DiskSPG typically yields inconsistent results. By all means, give it a go - but the industry standard and recommended tool is VDBench - across all vendors. There are tools out there that put a nice GUI on it (HCIBench, for example). 

Also - why would you switch dedupe on an array, yet test it with unreducible data? This isn't a real-world test either. The right answer is to populate it with a dataset which you expect to reduce (eg specify in the host 2x) and see what the system your testing gets - as it will show how good/bad your system is at yielding those results. If your system only gets 1.3x but you specified 2x in the host - then that is poor.

[Nick_Dyer]

Hi Kimberly. You should search the internal Yammer forums as well as watch the HPE Tektalk series. Again, VDBench is the right and correct tool to use to model a workload, over and above any other tool such as IOMeter, DiskSPD or an-other.

If a customer wants to use SLOB, or JetStress of course that is fine too.

[rmay_bk]

"why would you switch dedupe on an array, yet test it with unreducible data? This isn't a real-world test either"

Actually it is relevant for us.  We have a number of SQL servers with encryption enbled but no accurate way to identify and separate them onto their own volumes where dedupe is disabled.  It's what happens when IT operations is sliced into tiny pieces each with a separate reporting chain.  When these things start writing to storage heavily they can bring that other vendor's array to its knees.  DiskSPD with -Z does a good job of simulating heavy writes from these SQL boxes in terms of how the array is impacted.  I understand the numbers produced by DiskSPD runs are not totally reliable or perfectly repeatable but as a load generator its utility is undeniable.  I'm not sure if OP's end-goals are actual numbers or just validating array responsiveness under load...