Distributed Coordination Engine Upgrade via Segmented Paxos Instances
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Distributed coordination engines in wide area networks face challenges in upgrading without disrupting application services or interrupting the flow of proposals and agreements, requiring a solution that maintains consistency across server nodes while allowing for continuous operation and fault tolerance.
Innovation Solution
The implementation of a distributed coordination engine (DConE) using an enhanced Paxos algorithm, which ensures consensus and ordering of transactions across nodes, supports active-active replication, automated recovery, and maintains consistency through a global sequence of agreements, allowing for seamless upgrades and minimizing the impact of network outages.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the distributed coordination engine is upgraded, then the system can obtain improved functionality and performance, but the application service may be disrupted and the flow of proposals and agreements may be interrupted
Solution Approach 1:
The system segments the coordination engine into multiple instances (first instance and second instance) that can operate independently. During upgrade, the first instance continues handling proposals while the second instance is upgraded, allowing functionality improvement without service disruption.
Solution Approach 2:
The second instance is prepared and upgraded in advance before the first instance completes its current workload. This preliminary action allows the upgraded instance to be ready to take over once the transition is initiated, ensuring continuous operation.
2Stability of the object's composition
If the distributed coordination engine maintains consistency across nodes, then data integrity is ensured, but upgrade operations become more complex and time-consuming
Solution Approach 1:
The system uses an intermediary mechanism where the first instance acts as a bridge during transition. It receives proposals, determines if they should be processed by the upgraded second instance, and routes them accordingly. This intermediary approach maintains consistency while managing upgrade complexity.
Solution Approach 2:
The system implements feedback mechanisms where the first instance monitors the state of the second instance and adjusts proposal routing based on readiness status. This feedback loop ensures data consistency is maintained throughout the upgrade process without requiring complex manual coordination.
3Productivity
If the system allows continuous operation during upgrades, then service availability is maintained, but ensuring deterministic and predictable updates becomes more difficult
Solution Approach 1:
The system dynamically adjusts the operational state of different instances based on their upgrade status. The first instance operates in normal mode while the second is upgraded, then transitions occur in a controlled sequence. This dynamic approach maintains service availability while preserving update determinism through structured state changes.
Solution Approach 2:
The system ensures continuous processing of proposals through multiple instances rather than stopping operations during upgrade. The useful action of proposal processing continues uninterrupted, with proposals being routed to appropriate instances based on their operational state, thereby maintaining both availability and determinism.
Data Source
Figure 1~3
Figure 4~5
Figure 6
AI summary
A computer- implemented method and distributed system for maintaining consistency of client applications on a plurality of server nodes may comprise providing a first and second versions of a distributed coordination engine (DConE). The first version of the DConE may receive proposals, reach agreements thereon and generate a first ordering of agreements that specifies an order in which the client applications are to execute the agreed-upon proposals and correspondingly update their respective states. A Change Version proposal may then be processed by the first version of the DConE, whereupon the first version of the DConE may stop reaching any further agreements. A second version of the DConE may then take over reaching agreements on the proposals and generate a second ordering of agreements, beginning with the agreed-upon Change Version proposal. Any agreed-upon proposal, received from the first version of the DConE after the agreed-upon ChangeVersion proposal, may be sent back to the second version of the DConE to enable the second version of the DConE to reach agreement thereon.