Blockchain-Based Failover Coordination for Distributed Applications
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current solutions for managing failover in distributed multi-cloud applications are centralized and prone to data inconsistencies and split-brain issues, especially when communication links fail, leading to challenges in maintaining application availability and performance across multiple cloud providers.
Innovation Solution
A quorum-based technique utilizing a blockchain network to determine the best cloud for restarting a distributed multi-cloud application after failure, ensuring consistent operation by comparing timestamps and designating a new leader cloud based on real-time data, thereby maintaining application availability and performance across multiple cloud providers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a centralized solution is used for managing failover in distributed multi-cloud applications, then coordination of failover actions is simplified, but data inconsistencies and split-brain issues occur when communication links fail
Solution Approach 1:
The patent introduces a blockchain network as an intermediary layer between distributed cloud members. This blockchain acts as a decentralized mediator that records and validates failover decisions through consensus mechanisms, eliminating the need for a centralized coordinator while ensuring data consistency across all members through cryptographic verification of the quorum-based decisions.
2Reliability
If a quorum-based technique using blockchain is used to determine failover, then data consistency and decentralized coordination are improved, but system complexity increases
Solution Approach 1:
The patent leverages the blockchain network's inherent multi-functionality to handle multiple tasks simultaneously: it serves as a decentralized database for storing failover states, a consensus mechanism for determining quorum, a communication channel for notifying members, and a trust layer for validating decisions. This universal approach reduces overall system complexity by consolidating multiple functions into a single proven technology platform.
3Reliability
If multiple passive members simultaneously attempt to start the distributed application after leader failure, then application availability is improved, but split-brain issues and resource waste occur
Solution Approach 1:
The patent implements preliminary action by requiring passive members to register their intent to become leader and receive blockchain notifications before actually starting the application. When the leader fails, the blockchain network proactively notifies the designated new leader, who then starts the application. This preliminary registration and notification mechanism prevents simultaneous startup attempts by ensuring only one member is authorized to become leader at any time, thereby avoiding split-brain issues while maintaining high availability.
Data Source
AI summary
Distributed application orchestration management is provided. A first passive member of a set of passive members sends a notification message to other members indicating that the first passive member is initiating start of a distributed application in response to the first passive member validating that a self-restart by a leader member failed. The first passive member compares timestamps associated with an attempt to start the distributed application by other passive members in the set of passive members. The first passive member stops a particular attempt to start the distributed application in response to the first passive member determining that a timestamp associated with the particular attempt to start the distributed application by the first passive member is newer than another timestamp of another passive member. The first passive member designates the other passive member having an older timestamp as a new leader member to continue starting the distributed application.