I learned something new recently. SVC has QoS, and has had it for quite some time (maybe since day 1?).
QoS is one of those fancy sounding terms that really means vendors have ways to slow stuff down (typical IBM marketing – we tend to call it throttling and other vendors call it QoS). Throttling is only really useful if you have enough performance contention on your storage to cause a performance problem. In the networking world, having contention like that is pretty standard, so QoS is always good. In the storage world however, as soon as you have that level of performance contention you probably have a real problem and QoS is unlikely to be much more than a band-aid. Of course that can’t be a blanket statement and there are no doubt some unusual instances where QoS on storage is really useful.
…but I’m not doing a great job of selling it so far am I?
So why is having QoS on SVC a good thing for IBM? Well one reason is that some folks who know it’s important in the networking world often assume it must be important in the storage world, and vendors who have it tend to talk it up, so QoS often appears on tick lists of requirements from customers, and some are insistent about its importance, and occasionally I expect it might actually be important.
Traditionally on SVC, I was aware of changes in SVC 4.21 that were designed to keep bandwidth hogs under control. The following bullets are based on a presentation I gave to a customer last year:
- QoS is not just about isolation; it’s about giving customers/apps what they need.
- In-flight volume migration between tiers is your primary QoS mechanism.
- The SVC cluster is capable of 270,000 IOPs so there is little need to worry about bottlenecks at that level. Performance is expected to rise by 50% with new HW nodes released in September 2009.
- Write Cache Partitioning (introduced in SVC 4.2.1) by Managed Disk Group. Max 25% of cache can be used by any one MDG. This helps prevent I/O hogs from dominating the cluster.
- SVC 5/6 provides the option of iSCSI which may be another way to offer a lower tiered QoS
So what I didn’t realise is that the CLI command svctask chvdisk -rate gives you fine-grained control of performance caps on every volume in your SVC environment.
The svctask parameter in question is
- -rate throttle_rate [-unitmb]
- (Optional) Specifies the I/O governing rate for the VDisk (volume), which caps the amount of I/O that is accepted. The default throttle_rate units are I/Os. To change the throttle_rate units to megabytes per second (MBps), specify the -unitmb parameter. The governing rate for a virtual disk can be specified by I/Os or by MBps, but not both. However, you can set the rate to I/Os for some virtual disks and to MBps for others.
This image came to me from an SVC customer in New Zealand who did their own testing.
The underlying code for the QoS function came out of an Almaden research project called SledRunner, and QoS on XIV is also based on SledRunner. SledRunner takes its name from the acronym Service Level Enforcement.