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
![Page 1: VTUG 2013: Hypervisor-based QoS: Helps with the symptoms but by itself not the cure](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/1.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/2.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/3.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/4.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/5.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/6.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/7.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/8.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/9.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/10.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/11.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/12.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/13.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/14.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/15.jpg)
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](https://reader034.vdocuments.us/reader034/viewer/2022051817/547984bdb4af9f04148b457c/html5/thumbnails/16.jpg)
1620 Pearl Street,Boulder, Colorado 80302
Phone: 720.523.3278Email: [email protected]
www.solidfire.com
Questions?