About 9 years ago the architects at my company started a product with a simple thought: Effective contention management could yield far better efficiency, whereas contention avoidance yielded 25-35% utilization by dedicating spindles to applications. From this premise, we invented QoS for storage. While common in networking, QoS for storage, or the idea that a first-in-first-out queue wasn’t optimal, was not.
There have been many attempts to explain QoS, some penned by me. Recently, one of our senior technical marketing guys, Chris Wood, did a terrific job describing QoS and how it works in the Axiom. Please check out this recorded WebEx “QoS: A Better Approach to Storage, Explained”– you will probably enjoy it and it is only ~20 minutes long.
If you watch the link above, you’ll see that there is way more to QoS than “Data Banding.” Interestingly enough, some of our competitors copied only the “Data Banding” aspect of QoS. I’m not sure why because banding can do way more harm than good if not done properly.
Just for fun, I thought I would show you the idea applied to SATA disk banding. (We do not band FC disk, and of course the lack of physical seeking means banding SSD would be silly.) Take for example a 7200 RPM SATA disk drive with an access time profile that looks like this:
Which translates into a random IOPS rate that looks about like this:
By “banding” application data, you can do a lot worse than otherwise. For example, take a case where there is contention between two applications that present equal IO request rates. Without QoS, banding causes the higher priority application to suffer terribly because there is no contention management and the disk drive will seek between bands a long distance apart (the heads thrash or ping-pong between the inner and outer part of the disk). With Pillar’s QoS, the bands although separate, have IO’s queued and prioritized. Just look at this comparison of “Data Banding” with and without QoS.
Competitors who copy the data banding part of the Axiom clearly don’t understand what a prioritized queue manager is or why you need one. When I was in college at UC Berkeley, I was a “reader,” meaning I graded people’s homework for professors. Good bucks for me at the time, and it was actually fun sometimes. Now and then I would notice people who cheated. The cheaters would copy each other’s stuff and repeat the same artifact, like solving the problems perfectly in the same but wrong order.
If you copy people’s stuff, make sure you understand what you are copying and why.