What is a good formula to calculate HP StoreVirtual IOPs??

[Tom Lyczko]

Two servers, each with 10 x 15k 600GB SAS drives in RAID 5, then the HP StoreVirtual puts these into network RAID 10.

What's the proper formula to calculate the theoretical IOPs available?? (assume 60% read 40% write)

Do I calculate the IOPs per RAID5 server?? -- then how do I account for the network RAID 10 part????????

Thank you, Tom

[Stor_Mort]

It's a long, complicated discussion, but this will get you started.

http://www.techrepublic.com/blog/the-enterprise-cloud/calculate-iops-in-a-storage-array/

[Tom Lyczko]

---

@Stor_Mort wrote:

It's a long, complicated discussion, but this will get you started.

http://www.techrepublic.com/blog/the-enterprise-cloud/calculate-iops-in-a-storage-array/

---

I skimmed the article -- all I need is a reasonable calculation of the theoretical IOPs I should get from our HP VSA cluster.

I remain confused though that the physical arrays are RAID5 but the cluster array is Network 10, which I interpret to be the same as calculating a 10+1 type RAID array with 20 disk drives in it.

It seems to me the most reasonable calculations come from assuming the HP VSA cluster is RAID 10+1 and estimate as low as possible to account for the RAID5 of the physical array??

This is what most of us figuring and explaining IOPs for an HP VSA cluster need to understand...

Thank you, Tom

[Stor_Mort]

You should view StoreVirtual transaction processing as a network raid volume such as NR10 built on top of physical raid volumes, often raid 5.

If you run a read transaction, the NR10 volume will provide the block from cache if possible (no latency for those) or with one physical disk read. That's all there is to reads.

For writes, we need to do two write transactions to the virtual NR10 volume. Each of these is processed in parallel by storage nodes into their raid 5 disk array, which requires a read-modify-write procedure. (Again, the cache speeds this up a lot if all the pending transactions fit.) This will take two disk rotations to complete, but each storage node completes the operation in roughly the same amount of time, on the average. Parallelism helps.

I'm sure there is someone that could work all this into a formula for you, but I can't. It depends on the data localization and we haven't even talked about what happens when a write transaction is bigger than the disk stripe size (hint: it takes longer.) Even with a steady-state lab test environment, there is a certain amount of probabalistic fuzz. In a real-world production environment, there's no telling what results you will see.

[Tom Lyczko]

My translation: 'In the interest of redundancy and sharing all the HP VSA storage across all the host servers, a storage configuration was implemented wherein it's impossible to even estimate what the IOPs should be, even theoretically."

Nevertheless, the statement about controller cache was very helpful in addition to your earlier explanations about disk latency and disk queue.

Each of our two servers has a P420i array controller with 2GB cache already, could the cache be increased or is it reasonable to put in a RAID controller with a bigger caches?? If so what items should we look at??

I think for our particular issues disk latency and disk queue are easier to work with and explain to other people though.

Thank you, Tom

[Stor_Mort]

Every manufacturer has "special sauce" to improve their price/performance ratio that makes it very hard to describe performance in terms of a single number. It was much easier to model performance back when scsi interfaces were more primitive.

The P420i has a 2GB maximum cache size. HPE does make some Smart Array models which can take 4GB cache, but I doubt you will see a big performance gain over 2GB. Tweaking the read/write ratio with the hpacucli program can make a significant difference. Often they are set to 50/50 by default. Depending on your transaction characteristics, 25/75 or 10/90 may work better. The results with your production data are the only results that matter.