Distributed Multi-Cloud Orchestration With Concurrent Raft Commit
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Multi-cloud management is challenging due to difficulties in maintaining a healthy infrastructure, balancing workload performance, and optimizing operation costs across multiple clouds, with existing centralized and distributed management protocols facing issues in fault tolerance, high availability, and complexity.
Innovation Solution
A distributed multi-cloud orchestration management protocol utilizing a Raft consensus approach with an inquire-propose-commit-respond four-phase consensus protocol, incorporating a concurrent commit phase to enhance parallelism and throughput, and avoid deadlock situations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If a centralized management protocol is used, then resource allocation is simplified, but fault tolerance and high availability deteriorate
Solution Approach 1:
The system segments the centralized management function into multiple distributed management nodes that each manage specific cloud platforms. Instead of a single centralized controller, multiple nodes work in parallel, where each node can independently handle resource allocation for its managed cloud platforms. This segmentation provides fault tolerance because the failure of one management node does not affect the others, while maintaining relatively simple management protocols at each node.
Solution Approach 2:
The patent introduces an intermediary consensus mechanism (Raft protocol) that coordinates between distributed management nodes. This intermediary layer enables fault tolerance by ensuring consistent state across nodes through leader-election and log-replication mechanisms, while keeping the individual node implementations relatively simple and manageable.
2Reliability
If a distributed management protocol is used, then fault tolerance is improved, but system complexity increases
Solution Approach 1:
Each management node implements the full management functionality locally, with each node capable of independently performing resource allocation, status monitoring, and decision-making for its managed cloud platforms. This local quality approach means that while the system is distributed, each node maintains complete management capabilities, reducing the need for complex inter-node coordination and simplifying the overall protocol design.
Solution Approach 2:
The system uses partial action by having management nodes only communicate when necessary for consensus operations rather than continuous complex coordination. The Raft consensus protocol is invoked selectively for state changes, allowing nodes to operate independently most of the time, thus reducing overall system complexity while maintaining fault tolerance.
3Stability of the object's composition
If sequential commit operations are used, then consistency is maintained, but throughput and parallelism deteriorate
Solution Approach 1:
The system performs preliminary actions by having management nodes pre-agree on resource allocation proposals before executing commit operations. The inquire-propose-commit-respond protocol allows nodes to evaluate and agree on proposals in advance, so that when commit time arrives, the operations can be executed in parallel with guaranteed consistency, thereby improving throughput while maintaining state consistency.
Solution Approach 2:
The consensus protocol operates in periodic phases (inquire, propose, commit, respond) rather than continuous sequential operations. This periodic structure allows multiple parallel commit operations to be initiated at different phases, improving throughput while maintaining consistency through the structured phase transitions that ensure proper coordination.
4Loss of information
If resource allocation inquiries are sent to all management nodes, then complete resource information is obtained, but communication overhead increases
Solution Approach 1:
The system extracts and caches resource information at each management node locally, so that when resource allocation inquiries are needed, nodes can provide information from their local caches rather than requiring all nodes to communicate extensively. This extraction of information to local storage reduces communication overhead while maintaining complete resource information availability through the distributed cache structure.
Solution Approach 2:
Multiple resource information queries are merged into single consensus operations. Instead of separate communication exchanges for each piece of resource information, the system combines information gathering with the inquire-propose-commit-respond protocol, allowing nodes to exchange and aggregate resource information in a single coordinated process, thereby reducing overall communication overhead while obtaining complete resource information.
Data Source
AI summary
A system can receive a request from a client to perform a job via a multi-cloud platform at a leader management node. The system can, based on receiving the request, send respective first inquiries to respective management nodes of a group of management nodes, wherein the respective first inquiries inquire about respective available processing resources of the respective cloud platforms to perform the job. The system can, based on receiving respective responses from the respective management nodes, determine a first proposal for reservation of computing resources for the request among the respective cloud platforms. The system can select a subgroup leader node from the group of management nodes, wherein the subgroup leader node is configured to perform a commit operation for the reservation of the computing resources in parallel with the leader management node sending respective second inquiries to the respective management nodes and determining a second proposal.