Distributed VM Pooling via Message Queues
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current cloud platforms face challenges in ensuring consistent and reliable availability of virtual machines (VMs) due to infrastructure as a service (IaaS) failures, leading to inefficiencies in scaling and application maintenance, particularly when existing solutions like Hazelcast and database-based approaches require additional locking mechanisms and favor availability over consistency.
Innovation Solution
A distributed virtual machine pooling service utilizing messaging middleware to manage VMs, where task executors invoke the IaaS platform to create new VMs and cloud controllers receive VMs from the pool, leveraging message queues to ensure consistent state transitions and eliminate the need for additional locking mechanisms.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional IaaS-based VM provisioning is used, then VM creation is simple, but VM availability and consistency cannot be ensured due to infrastructure failures
Solution Approach 1:
The patent introduces a message queue system as an intermediary layer between the VM provisioning system and the IaaS infrastructure. This message queue decouples the system components, allowing the VM pooling service to maintain reliability through persistent message storage and retry mechanisms while abstracting away the infrastructure complexity from the provisioning logic.
Solution Approach 2:
The system pre-provisions and maintains a pool of VMs in advance before they are actually needed. By maintaining a ready pool of VMs through continuous monitoring and proactive creation, the system ensures immediate availability when VMs are requested, eliminating the need to create VMs on-demand and ensuring consistent availability without requiring complex real-time provisioning logic.
2Reliability
If Hazelcast or database-based approaches are used for VM pooling, then VM availability is improved, but additional locking mechanisms and complexity are required
Solution Approach 1:
The message queue serves as an intermediary that inherently provides thread-safe, ordered processing of VM provisioning operations. By using the message queue's built-in persistence and delivery guarantees, the system achieves VM consistency without implementing additional locking mechanisms, as the queue itself ensures ordered, reliable message delivery to task executors.
Solution Approach 2:
The system uses the message queue's native persistence and reliability features to manage VM pool state, rather than implementing custom locking and consistency management logic. The message queue automatically handles message persistence, delivery guarantees, and retry logic, allowing the VM pooling service to benefit from consistency and reliability without the complexity of manual locking mechanisms.
3Productivity
If VMs are created on-demand from IaaS, then resource utilization is optimized, but scaling delay occurs when VMs are needed immediately
Solution Approach 1:
The system proactively maintains a pool of pre-provisioned VMs that are ready for immediate deployment. By continuously monitoring the VM pool and proactively creating new VMs to maintain the desired pool size, the system ensures that VMs are available immediately when needed, eliminating scaling delays while maintaining optimal resource utilization through dynamic pool management.
Solution Approach 2:
The system implements continuous monitoring of the VM pool size and performance metrics, using this feedback to dynamically adjust the pool size and trigger new VM creation as needed. This feedback mechanism ensures the pool maintains the optimal size for immediate scaling while avoiding unnecessary VM proliferation, balancing productivity gains with resource efficiency.
Data Source
AI summary
A first message from a first state transition queue is obtained by a first task executor of a virtual machine (VM) pooling service node. The operation to be performed on the VM is triggered. Whether the operation to be performed on the VM is successfully performed is determined. If it is determined that the operation to be performed on the VM is successfully performed, a second message is placed into a second state transition queue, and the second message represents the VM that is in a transitional state, the second message is obtained by a second task executor of the VM pooling service node, and whether the VM reaches a target state is determined by performing a check on the VM. Otherwise, the first message is returned to the first state transitional queue.