vtug 2013: hypervisor-based qos: helps with the symptoms but by itself not the cure
DESCRIPTION
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.TRANSCRIPT
Hypervisor-Based QoS Helps with the symptoms but by itself not the cure
Adam Carter, Director of Product Management
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
What are we trying to avoid?
• Few resource hungry applications negatively affect all other volume performance
Traditional Multi-Tenant Performance
Noisy Neighbor
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
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
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.
PerformanceDegradation
• 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.
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
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.
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
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
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
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
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
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
1620 Pearl Street,Boulder, Colorado 80302
Phone: 720.523.3278Email: [email protected]
www.solidfire.com
Questions?