Witness-Based Raft Replication for Fault-Tolerant Two-Node Clusters
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional Raft consensus algorithms face challenges in two-node and even-node clusters due to quorum requirements that cannot be met during node failures or network partitions, leading to potential data loss and inefficiencies, and existing workarounds introduce resource overhead and latency.
Innovation Solution
A modified consensus algorithm that includes a witness node for data storage, allowing message commitment with quorum-1 acknowledgments, reducing the need for external resource interaction and maintaining fault tolerance by recording metadata on a shared storage location.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional Raft consensus algorithms are used in two-node or even-node clusters, then quorum requirements ensure data consistency, but fault tolerance is reduced during node failures or network partitions
Solution Approach 1:
The system segments the quorum requirement into two independent components: (1) a reduced quorum threshold that can be satisfied with fewer acknowledgments, and (2) a separate witness node that stores metadata independently. This segmentation allows the main cluster to operate with lower quorum requirements while the witness provides independent verification, resolving the contradiction between maintaining reliability and improving availability during failures.
Solution Approach 2:
A witness node is introduced as an intermediary entity that stores metadata (term, subterm, replication set) independently from the main cluster nodes. This intermediary allows the system to verify consensus state without requiring traditional quorum acknowledgments from all cluster nodes, enabling the system to maintain fault tolerance while improving availability during node failures or network partitions.
2Reliability
If quorum requirements are strictly enforced, then data consistency is maintained, but latency increases during node failures
Solution Approach 1:
The system performs preliminary actions by having the witness node continuously store and maintain metadata (term, subterm, replication set) in advance. When a message needs to be committed, the system can quickly verify consensus by checking the pre-stored witness data rather than gathering quorum acknowledgments, significantly reducing commit latency while maintaining data consistency.
Solution Approach 2:
The system uses partial action by requiring only quorum-1 acknowledgments instead of full quorum, and supplements this with witness verification. This partial acknowledgment approach, combined with the witness's independent verification, maintains data consistency while reducing the time required to achieve consensus during normal operation and failure scenarios.
3Reliability
If witness nodes are added to the cluster, then fault tolerance is enhanced, but device complexity increases
Solution Approach 1:
The witness node is extracted as a separate, dedicated component with a single responsibility: storing and verifying metadata. This extraction simplifies the overall system architecture by separating consensus verification from the main cluster operations, making the system easier to configure and manage despite adding an additional node, as the witness has a well-defined, simple role.
Solution Approach 2:
The witness node serves multiple functions: it stores metadata, verifies consensus state, and provides independent verification for message commits. This multi-functionality justifies the addition of the node by providing multiple benefits (enhanced fault tolerance, reduced latency, simplified verification) from a single added component, effectively managing the increase in device complexity.
Data Source
AI summary
The disclosed technology includes fault-tolerant data replication system implemented by a cluster of compute devices. The system includes a witness comprising persistent data storage and multiple nodes configured to selectively execute leader node operations when serving as a leader of the cluster. The leader node operations include detecting an availability status change for a follower node of the cluster and, in response, updating a subterm and a replication set. The subterm identifies a total number of availability status changes detected within the cluster over a given time interval, and the replication set identifies set of entities designated to provide acknowledgments counted when determining whether to commit a message following message replication. The leader node operations further include writing the replication set, the subterm, and other metadata to the witness in response to receiving a first client message from a client application following the availability status change.