Skeleton Virtual Volumes for VM Boot Storm Optimization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing data storage systems face significant performance bottlenecks during 'boot storms' when hundreds or thousands of virtual machines start up concurrently, as they require extensive CPU cycles and disk bandwidth for creating and managing virtual volumes, leading to prolonged processing times and increased bandwidth consumption.
Innovation Solution
The system employs a technique where instead of deleting swap virtual volumes during shutdown, they are unbound and UNMAP requests are issued to free associated blocks, leaving a skeleton volume that can be reused upon subsequent startup, thereby avoiding the need for re-creation and reducing the number of VASA requests and processing time.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If virtual volumes are deleted during VM shutdown, then storage space is freed, but system startup time increases significantly during boot storms
Solution Approach 1:
The patent applies the discarding and recovering principle by unmapping physical storage blocks during VM shutdown while retaining the virtual volume structure. This allows storage space to be freed and reused by other VMs while the skeleton vVol structure remains available for rapid reuse, eliminating the need for complete vVol recreation during boot storms.
Solution Approach 2:
The patent implements preliminary action by performing unmapping operations during VM shutdown before the system needs to startup again. This advance preparation ensures that storage blocks are freed and available while the minimal vVol structure is already in place, so when a new VM needs to startup, it can immediately attach to the existing skeleton structure without waiting for creation or allocation operations.
2Reliability
If virtual volumes are recreated during VM startup, then storage functionality is restored, but CPU cycles and disk bandwidth are consumed
Solution Approach 1:
The patent applies the copying principle by creating a lightweight skeleton copy of the virtual volume structure that contains only essential metadata and configuration information. This skeleton vVol is sufficient for immediate VM attachment and functionality, eliminating the need to copy or allocate all physical storage blocks during startup. Full storage functionality is restored as the VM writes its own data blocks as needed.
Solution Approach 2:
The patent recovers computational resources by discarding the practice of recreating complete vVols during startup. Instead, the system recycles existing skeleton vVol structures that were preserved from previous sessions, avoiding the CPU cycles and disk bandwidth that would be consumed by creating new volume structures, allocating blocks, and initializing storage metadata.
3Loss of time
If complete virtual volumes are maintained across sessions, then startup is faster, but storage resources are wasted
Solution Approach 1:
The patent applies local quality by differentiating between the essential components of a virtual volume that must be preserved (metadata, configuration, skeleton structure) and the non-essential components that can be released (data blocks, allocated storage space). This selective preservation maintains the minimal structure needed for rapid startup while freeing actual storage resources for reuse by other VMs.
Solution Approach 2:
The patent discards unnecessary storage resources by unmapping and freeing data blocks while recovering and retaining the essential vVol skeleton structure. This allows the system to have both fast startup (by reusing the skeleton) and efficient storage utilization (by freeing actual data blocks for other uses).
Data Source
AI summary
A computer system includes a virtual machine (VM) host computer and a data storage system providing physical storage and mapping logic to store a virtual volume (vVol) for a VM. During a first operating session, first-session working data is stored on the vVol, the working data being session specific and not persisting across operating sessions. At the end of the first operating session, unmap operations are performed to deallocate underlying physical storage of the vVol, leaving the vVol as a skeleton vVol. At the beginning of a subsequent second operating session, and based on the existence of the vVol as the skeleton vVol, the VM host resumes use of the vVol for storing second-session working data of the VM during the second operating session. The retention of the vVol in skeleton form can improve system startup efficiency especially for a boot storm involving simultaneous startup of many VMs.