Implementing a storage QoS mechanism at the hypervisor, without similar enforcement at the storage level, does little to address the challenges imposed in a cloud infrastructure. In this session we will review key architectural requirements to look for to achieve storage QoS that compliments your existing hypervisor controls. We will also discuss the QoS benefits to be realized from a tighter API-based integration between hypervisors and storage systems through future APIs like VMware’s VVOLs.

1. Hypervisor-Based QoS
Helps with the symptoms but by itself not the cure
Adam Carter, Director of Product Management

2. Agenda • Hypervisor-based approach is good, but
not the total solution
• Storage is a necessary party in QoS
discussion
• Ideally hypervisor layer sets and
manages the QoS policy and storage
system enforces it
• Unfortunately, not all storage QoS is
created equal

3. What are we
trying to avoid?
• Few resource hungry
applications
negatively affect all
other volume
performance
Traditional Multi-Tenant
Performance
Noisy Neighbor

4. Hypervisor-based QoS
• Helps address some of the performance
variability of virtual machines
• But hypervisor has very little control or visibility of
the underlying storage system resources
• An environment that depends on predictable
performance demands a more coordinated
approach across both host and storage resources
ADD SOME SOIC or
hypervisor-based
picture

5. Key limitations of hypervisor-centric
approach to QoS
• Lack of IOPS control
• Performance Degradation
• Forced Overprovisioning
• Lacking Coordination
• Inability to set IOPS minimums
• Limited functionality

6. Lack of IOPS
Control
• Hypervisor can throttle IOPS, but it has
no control over maintaining the total IOP
pool available
• W/o governance from underlying storage
there is no way for a hypervisor to
guarantee a minimum IOP level
• Hypervisor will always be at the mercy of
the storage device.

7. Performance
Degradation
• Without visibility into back-end storage,
there is no way for the hypervisor to know
what resources remain available to it
• As storage system utilization increases
performance degradation becomes a real
concern
• With virtual resources contending for the
same pool of storage resources, the lack of
isolation creates an IOPS free-for-all.
• This performance variability is a non-starter
for a multi-tenant infrastructure hosting
performance sensitive applications.

8. Forced Over-
Provisioning
• Only way to ensure a large enough IOPS
pool for these VMs is to extensively
overprovision your storage.
• Underutilization kills economics of shared
storage environment

9. Lacking
Coordination
• Throttling IOP usage to VMs is a basic
form of storage QoS
• Lacks end-to-end coordination and
orchestration between the host and the
underlying storage system
• Coordination helps ensure each VM has
the resources it needs to properly support
the application.

10. Inability to set
IOPS
minimums
• Can cap performance
• Can prioritize relative to other apps
• But w/o minimum IOPS settings you can’t
guarantee any level of performance to a
specific application

11. SIOC
Limitations
• Doesn’t work with RDM
• Not supported with extents
• Can’t be managed by multiple vCenter
servers
• Lack of compatibility with auto-tiering

12. So what does
the future
hold?
• Forthcoming API integrations between
hypervisors and storage (i.e. VVOLs) will
provide a more holistic approach to
managing QoS
• End-to-end QoS dependent on
enforcement across the storage
infrastructure

13. Not all storage
QoS is
created equal
• Prioritization
– Cannot guarantee any app actually gets
the performance it needs
• Rate limiting
– No concept or capability for guaranteeing
minimum levels of performance
• Tiered Storage
– Combines multiple types of media to deliver different
performance levels
– Performance for every application varies as algorithms
move data between media

14. QoS is not a
feature, it’s an
architecture!
Purpose-built for QoS
• All-SSD Platform
– Deliver consistent latency for every IO
• True Scale-out Architecture
– Linear performance gains as system scales
• RAID-less Data Protection
– Predictable performance in any failure condition
• Balanced Load Distribution
– Eliminate hot spots that create unpredictable IO latency
• Fine-grain Quality of Service Control
– Guarantee volume performance
• Performance Virtualization
– Deliver performance resources independent of capacity
and on demand

15. Begin with the
end in mind
• Applications allocated
into performance tiers
• Changes are immediate
can be made on the fly
Traditional Multi-Tenant
Performance
Application of SolidFire
QoS controls

16. 1620 Pearl Street,
Boulder, Colorado 80302
Phone: 720.523.3278
Email: info@solidfire.com
www.solidfire.com
Questions?