+ All Categories
Transcript
Page 1: VTUG 2013: Hypervisor-based QoS: Helps with the symptoms but by itself not the cure

Hypervisor-Based QoS Helps with the symptoms but by itself not the cure

Adam Carter, Director of Product Management

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

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

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

What are we trying to avoid?

• Few resource hungry applications negatively affect all other volume performance

Traditional Multi-Tenant Performance

Noisy Neighbor

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

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

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

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

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

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.

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

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.

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

1620 Pearl Street,Boulder, Colorado 80302

Phone: 720.523.3278Email: [email protected]

www.solidfire.com

Questions?


Top Related