HPE Storage Users Group

Hi,

Does anyone have Priority Optimization running in a prod environment? If so have you configured the all_others group where all the other VVs sit which do not need to be QOS'd?

Consider the following scenario
VV1 - has no QOS
VVQ1 - has Min Goal of say 2000 IOPS

Now if VV1 was running hot and all of a sudden VVQ1 wanted its Min Goal, I was under the impression that the system may reduce the IOPS on VV1 to grant VVQ1 more IOPS?

Granted if everything was running hot then there will be no IOPS to share.

Thanks

My understanding is that you need to enable the "all_others" rule which is effectively a catch all bucket/group for anything without a specific QOS rule, without a QOS rule assignment volumes will not be subject to throttling.
How things actually get throttled will depend on the priority you set for each, so if VVQ1 is of higher importance than "all others" you would set a higher priority, which would then throttle the "all others" in order to meet VVQ1's latency goal.

"Care should be taken to help ensure that the system rule is allocated enough IOPS and bandwidth resources to satisfy the requirements of the volumes it governs."

http://www8.hp.com/h20195/v2/GetDocumen ... A4-7604ENW
Pages 8 & 9 discuss relative priorities and the "all_others" rule.

Thanks for reply, I have set this rule however it is very much an unknown at this stage as to whether the all_others VVs will suffer or not. Still not in production but will be soon enough!

My concern is backups, as this draws fair bit of IOPS and may slow down backup jobs.

So do you guys have this setup running ?

Well backups shouldn't actually generate that many IOps, what it will generate is MB/s but your not going to know unless you do some testing under load, maybe run something like IO meter to see where your policies kick in. If you really want to complicate things you could have a schedule for different QOS levels at different times, but you can very easily over engineer the whole QOS thing just for the sake of it.

I'd keep it simple at least initially until you have a feel for how things are performing and how much headroom you have in the system, really QOS should only be applied where needed.

Well in my world MB/s generate IOPS ;o)

Sure thing monitoring during backups is the right thing to do. We are not live yet with live data so I will have to keep an eye on this. Scheduling is my next option if qos is kicking in heavy during backups.

On a separate note, I found something slightly different to ioMeter in case you are worried about the cache on the array being hit during load test: there is a tiny app called 'Random Data File Creator (RDFC)' which writes random stings into a txt file which almost guarantees that the array cache is not hit. Run enough of these as a batch file and you get a good idea of what IOPS you can pull with and without qos.

Cheers!

Yes backup streams do create IOPs but they're typically sequential and so packaged into a much larger size than your day to day random access IOps, as such you'll tend to do many fewer. e.g moving 100MB with different IO sizes

102,400KB / 24K IO = 4266 IOPs
vs
102,400KB / 256K IO = 400 IOps

But as always it depends on you unique mix of apps / backup types etc, the point being it's all just conjecture until you actually do the testing