VTUG 2013: Hypervisor-based QoS: Helps with the symptoms but by itself not the cure

Post on 29-Nov-2014

507 views 2 download

Tags:

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: info@solidfire.com

www.solidfire.com

Questions?