HPE Storage Users Group

Is there an optimum size for virtual volumes? Would this be different for vmware vs HP-UX? Would this be different for a local only volume compared to a volume using remote copy?

Regards,
dsb

No there's no specific recommendation based on O/S or whether it's local or remote etc. There may be more practical reasons related to O/S / 3PAR maximums and backup / recovery timescales etc

In some cased there are some minimums you might want to consider for relatively small volumes if they're performance sensitive and you want them to benefit from touching every backend disk of a given class.

e.g
RAID5 3+1 has a step size (SSZ) of 4 (3 data + 1 parity)
In order to ensure your volume touches as a minimum every disk of a given class you would need to use the below formula.

Minimum VV Size = Total #drives class * (SSZ-1) * (Chunklet Size) / SSZ / 1024
On older systems such as F & T class chunklets will be 256KB vs 1024KB on the 7000 and 10000 series.
e.g
120 disks * (4-1) * 1024 / 4 /1024 = 90GB
or
64 disks * (4-1) * 1024 / 4 /1024 = 48GB

But note this isn't in any way a requirements it's really just about ensuring relatively small volumes can take full advantage of the aggregate performance of all available disk. As such you would typically only use it on performance critical volumes.

Thanks you for your prompt reply.

dsb

Cleanur, you touched on something that I've been trying to figure out and I'm wondering if your magic formula can be adapted to help me?

Let's say I create a 1TB VV under a 48 drive CPG using RAID 5 (2+1). Whenever I start filling the volume I can see in the performance monitor that all of my drives in the CPG are being utilized and they are pretty even in terms of IOPS. However, let's say I create a 1TB VV under a 48 drive CPG using Raid 5 (8+1) - Now I am seeing gaps where some drives aren't being hit at all and the ones that are have dramatically uneven usage.

I am very new to 3PAR so I am still learning all the ropes but I think the growth rate has something to do with the answer to my problem. By default it's allocating 32GB but I'm wondering if I adapt your formula and increase my growth rate will it even out my distribution?

Using your logic, can I apply 48 disks * (9-1) * 1024 / 9 / 1024 = 43GB to give me a growth size that would even out the load?

Yes it should do, it's to do with how the LD's are created / grown underneath the CPG.

I have used this version in the past but looks like they provide the same result.

Growth Increment = #Drives * (1/SSZ) * (SSZ-1) * #Node Pairs

Raid5 5+1 64 disks - 4 Nodes
64 * (1/6) = 10.66 * (5) = 54 * 2 = 108GB

Raid5 3+1 32 disks - 2 Nodes
32 * (1/4) = 8 * (3) = 24 * 1 = 24GB

Raid5 8+1 48 disks - 2 Nodes
48 * (1/9) = 5.33 * (8) = 43 * 1 = 43GB

If you want to optimize upfront rather than just let the system sort itself out over time as it fills, then you can use the above. You'd want to create a new CPG and then tune volumes into this new space to take full advantage of the newly created LD's. The only problem with doing this kind of thing is that very rarely do systems remain static. E.g more disks and nodes get added over time so the numbers will change and if you want to maintain these, then you'll end up micromanaging the system, which isn't really 3PAR's design goal.

This is a pretty decent guide for setting the growth size on the CPGs

https://www.youtube.com/watch?v=zgVXWjq3W_c


Basically - RAID Data * Number of disks / Data plus parity.


So for R5 3+1 this is 3 * Disks in that class (48 in my case) / 4 which works out to 36GB.


We only have 3 CPGs and we ran that math on all 3 before we started creating volumes and we see all the disks participate in IO.





Changing a few growth numbers and running Tunesys is hardly micromanaging. How often do you really add disks? Once a year? Once every few years? It's a minor thing to change to get the best performance out of all the drives you've paid for.

It's pretty much the same formula just the numbers aren't called out explicitly and there's no multiplier for the node count.

As to micro managing, it was just a standard disclaimer for the feint hearted / inexperienced. If you make these changes (just for the sake of it....because you read the email trail...or you just like fiddling) without understanding and thinking through the implications, you can dig yourself a hole for the future.

I've been playing around with this and now my disks are being utilized pretty evenly across the entire array.

Thanks again!!