VM-Granular SSD Caching via Host Filter Driver
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In virtualized environments, managing a solid state drive (SSD) as a second-level cache for multiple virtual machines (VMs) is challenging due to the need for per-VM caching policies and dynamic sharing, especially during VM migration, where cached data may be lost, and modifying guest operating systems to use SSDs as caches is undesirable.
Innovation Solution
A system architecture that maps unique identifiers for VMs to process identifiers (PIDs) to manage SSD caching within the hypervisor's I/O stack, using a cache module and management agent to allocate and invalidate cache space, ensuring VM-specific caching policies are maintained and applied across hosts, even during VM migration.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If second-level caching is implemented in the guest operating system, then caching functionality can be provided to VMs, but significant modifications or additions are required to both the virtualization layer and the guest OS
Solution Approach 1:
A filter driver is introduced as an intermediary component in the host OS kernel I/O stack. This filter driver intercepts I/O requests before they reach the storage device, identifies hot blocks, and manages caching operations. By placing the caching logic in the host OS rather than modifying guest OSs, the solution provides caching functionality while avoiding complex modifications to virtualized systems.
Solution Approach 2:
The caching functionality is extracted from the guest operating system and relocated to the host operating system's kernel I/O stack. This extraction eliminates the need to modify guest OSs while maintaining the desired caching behavior. The filter driver in the host OS assumes responsibility for caching operations, simplifying the overall system architecture.
2Productivity
If SSD is used as second-level cache, then I/O latency and throughput are improved, but managing per-VM caching policies and dynamic sharing becomes challenging
Solution Approach 1:
The filter driver automatically identifies hot blocks and manages caching operations without requiring manual configuration or complex policy management. The system self-services by monitoring I/O patterns and dynamically allocating cache space, simplifying management while maintaining high I/O throughput.
3Loss of time
If SSD is used as second-level cache, then I/O latency is reduced, but dynamically sharing SSD among multiple VMs is difficult
Solution Approach 1:
The filter driver provides universal caching functionality that serves multiple VMs simultaneously through a single component in the host OS. By intercepting and managing I/O requests at the host level, the system enables dynamic sharing of the SSD cache among multiple VMs without requiring separate caching mechanisms for each VM, thus reducing I/O latency while maintaining adaptability.
Data Source
AI summary
Methods are presented for caching I/O data in a solid state drive (SSD) locally attached to a host computer supporting the running of a virtual machine (VM). Portions of the SSD are allocated as cache storage for VMs running on the host computer. A mapping relationship is maintained between unique identifiers for VMs running on the host computer and one or more process identifiers (PIDs) associated with processes running in the host computer that correspond to each of the VM's execution on the host computer. When an I/O request is received, a PID associated with I/O request is determined and a unique identifier for the VM is extracted from the mapping relationship based on the determined PID. A portion of the SSD corresponding to the unique identifier of the VM that is used as a cache for the VM can then be accessed in order to handle the I/O request.