Vendor: Do we need Quality of Service with shared storage arrays?

"If I have more resources than required"

Might as well stop there. That never happens for long. Where there's capability to spare, new workloads will be added until that's no longer the case. It happens with CPU, it happens with memory, and it happens with storage. Always has and always will. The real question is how to maximize the value of the IOPS you're providing when you're providing as many as you can. That means letting higher-value IOPS (e.g. for higher-value apps or tenants) take priority over lower-value IOPS, and that's QoS.

Noisy Neighbour Avoidance

I found this article interesting: http://recoverymonkey.org/2016/04/08/the-well-behaved-storage-system-automatic-noisy-neighbor-avoidance/

QoS a different way

I'll second what Platypus said regarding new workloads eventually filling capabilities until someone (or everyone) suffers. Having the ability to prioritize IO for one application or group of servers over the another is great...but in practice what I'd also like to be able to do is to set a _minimum_ response time. Today, when a new application comes on board a new or lightly loaded storage array, I can set their QoS setting to the lowest tier possible and they're still going to get fantastic performance. As other applications with higher priority are added to the same array, that first application starts whining because their response times are X times longer than they used to be (regardless of the fact they paid for the lowest performing storage I have to give). If by setting that first application QoS to the lowest available I could guarantee IOs no faster than say, 15ms, I could leave resources available on the array to service higher priority applications. If the lower QoS'ed servers want better performance, they could pay for an incremental amount and I could set their minimum response times to 10ms, or 5ms, or whatever. Upon setting that the application would in theory be able to immediately see improved performance that was consistent. I get the mindset that we want to go as fast as we can all the time, but that mode of operation has downsides too.

Application I/O Demand

All manner of technology solutions are available, but none will help unless there is a thorough understanding of the problem to be solved, namely: very few people really understand the I/O requirement of their application. Start there.

Then think about what technology you need and what tools and processes must be in place in order to manage it properly.

QoS - really? Maybe for HDD and Flash....

Won't the adoption of 'faster than DRAM, slower than SRAM' non-volatile storage make QoS superfluous? That is, will FRAM, ReRAM, MRAM et al make 'just doing' the IO more sensible than spending lots of slow CPU cycles calculating QoS algorithms? QoS will become an unnecessary burden on a subsystem that doesn't really need it.

Sure, there will be contention on network/port access, but that is likely better dealt with by the network - not via QoS on the storage system.

These technologies will also mean we eventually shift to a 'shared memory' access model - so we'll worry about mutexes rather than queues and buffers. And why bother with cumbersome data copying (aka IO)? In fact we'll move to having both text and data pages in the non-volatile global address space, with volatile only used for stuff you explicitly want to disappear on an abend/bsod. Kinda back to the future?