Shared Memory Architecture for Virtual Machine Fault Tolerance
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current fault tolerance methods for virtual machines (VMs) are inefficient and costly due to the need for maintaining shadow copies of memory across different hosts, which requires significant resources and time-consuming memory checkpointing processes.
Innovation Solution
Implementing a shared pooled memory architecture where a primary VM has read and write access, and a secondary VM has read-only access, allowing seamless failover without the need for memory checkpointing, by utilizing the same shared memory partition across multiple hosts.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If shadow copy memory is maintained in different hosts, then fault tolerance is achieved, but resource usage and time consumption increase significantly
Solution Approach 1:
The patent merges the memory resources of the primary VM and shadow VM into a single shared memory location accessible by both VMs. Instead of maintaining separate memory copies in different hosts, the invention consolidates memory into one shared pool that both the primary and shadow VMs can access, thereby reducing overall memory resource consumption while maintaining fault tolerance capabilities.
Solution Approach 2:
The shared memory pool serves multiple functions simultaneously: it acts as the memory for the primary VM during normal operation and as the memory for the shadow VM during failover. This multi-functional approach eliminates the need for dedicated separate memory resources for each VM role, optimizing resource utilization.
2Reliability
If shadow copy memory is maintained across different hosts, then fault tolerance is achieved, but the process becomes time consuming
Solution Approach 1:
The patent implements preliminary action by having the shadow VM continuously access and maintain the shared memory in real-time during normal operation. Instead of performing time-consuming memory checkpointing only when needed, the shadow VM is kept synchronized with the primary VM through continuous access to the same memory location, eliminating the need for later checkpointing operations.
Solution Approach 2:
The shared memory maintains continuous synchronization between the primary and shadow VMs through ongoing read operations by the shadow VM. This continuous useful action ensures that the shadow copy is always up-to-date without requiring periodic time-consuming checkpointing interruptions, enabling immediate failover when needed.
3Reliability
If shadow copy is maintained in different hosts, then fault tolerance is achieved, but costs increase
Solution Approach 1:
The patent reduces device complexity by merging the memory subsystems of the primary and shadow VMs into a single shared memory pool. This consolidation eliminates the need for separate memory management infrastructure across multiple hosts, simplifying the overall system architecture and reducing the complexity of maintaining fault tolerance.
4Stability of the object's composition
If different memory pages are used in different hosts, then host isolation is maintained, but memory maintenance becomes inefficient
Solution Approach 1:
The patent introduces an intermediary mechanism where the shadow VM acts as a mediator that accesses the shared memory through controlled read operations. This intermediary approach allows the shadow VM to maintain a synchronized copy of the memory state without directly modifying the shared memory, preserving host isolation while enabling efficient memory maintenance through the shadow VM's continuous monitoring and access capabilities.
Data Source
AI summary
Examples provide a fault tolerant virtual machine (VM) using pooled memory. When fault tolerance is enabled for a VM, a primary VM is created on a first host in a server cluster. A secondary VM is created on a second host in the server cluster. Memory for the VMs is maintained on a shared partition in pooled memory. The pooled memory is accessible to all hosts in the cluster. The primary VM has read and write access to the VM memory in the pooled memory. The secondary VM has read-only access to the VM memory. If the second host fails, a new secondary VM is created on another host in the cluster. If the first host fails, the secondary VM becomes the new primary VM and a new secondary VM is created on another host in the cluster.