Priority Optimization - qos

[3padm]

Hi,

Is anyone using the 3par Priority Optimization features within a vmware environment? I wanted to know if you have come across any findings or surprises you would like to share.

For example if a VV has a qos of 1000 iops set against it and you have 5 VMs within, once you add say 2 more VMs, are you finding yourself spending time in 3par console amending the qos settings ?


This is just one gotcha I can think of are there any others?

Thanks

[hdtvguy]

We have not, but my understanding is the QOS is more of a throttle to prevent something from going over a set performance threshold. My philosophy is to use the least controls possible until/unless there is a reason to put a control in place. The most common scenario for the QOS would be backups, if you have your backups slamming the array then you might want to throttle the backups so they do not starve production IO. I want to let a resource have access to all the potential of the array unless it interferes with something else. The array does a very good job of handling different workload IO requirements.

[3padm]

Yup we are kind of working to that effect. Basically we are going to have dev and prod VMs on the same array and want to limit the dev. My question is has anyone got this running in a vmware setup? In that multiple vms compete for the same amount of iops is it first come first get? i.e. if 1 vm is using 700iops out of the 1000 then another vm asks for similar rate, do they only get 300 iops?

Im just wondering if it is better to do this within VMware itself rather than have the request go through the host hba > hit the fabric > then hit the 3par nodes ?

Thanks

[ailean]

I would expect VMware to share the available IO between VMs, the more aggressive VM might hog more thou but I think VMware will share the resource. It would be down to the VMware admin to be aware each LUN has X iops and to balance the VMs if they see latency issues (i.e. not put all high IOPS VMs on a single LUN).
At the moment we have only used the ESX IOPS limits for VM disks on our small NL pool to avoid spikes causing issues for other servers. I'm interested in the 3PAR method for non ESX hosts which at the moment can run away with things however the NL pool and it's array will be replaced at the end of the year and we probably won't use NL again. So we maybe more interested by then in the new service time reservation 3PAR method and apply it to critical business database LUNs.

[Cleanur]

Since the 3PAR QOS is enforced per VV set, then the rule effects multiple VM's on the same shared datastore. Due to the abstraction of the VMware hypervisor 3PAR QOS has no visibility of the underlying VM's and so can only enforce rules for the entire datastore.

This should change in the future as VMware introduces VVols and each VM effectively gets its own volume(s). But for now VMwares own internal IO scheduler handles the fairness within the datastore, however if one VM has a greater intensity workload, then it will likely hog the lion's share of the IO. The VMware scheduler will need to handle throttling this to ensure other VM's aren't starved, but there are no guarantees.

If you do need additional granularity of control today then I believe SIOC can provide this, in the future Vvols should help offload a similar level of granularity to the array.

[Cleanur]

Nice whitepaper on the new features of Priority Optimization in the 3.1.3 release.

Max limits, Minimum Goals, per VV set or per Virtual Domain, Nesting, Relative priorities and Latency goals to allow for bursting.

http://www8.hp.com/h20195/v2/GetDocumen ... A4-7604ENW