Third Vote Consensus in Two-Node Clusters
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Small storage clusters face inefficiencies and data corruption issues due to the inability to establish a quorum upon node failure, as they lack sufficient votes to continue operation, particularly in two-node configurations where a single failure disrupts the voting majority.
Innovation Solution
A 'third vote' consensus technique is introduced, where a tie-breaking vote is utilized, allowing a surviving node in a small cluster to maintain a local copy of configuration changes on a third copy file system and access a shared copy stored on shared storage devices, enabling it to cast additional votes and maintain cluster operation even after a node failure.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a traditional quorum voting scheme is used in a small two-node cluster, then data corruption is prevented when both nodes are operational, but the cluster cannot continue operation when a single node fails due to loss of voting majority
Solution Approach 1:
A shared storage device is introduced as an intermediary third voting entity that can cast a tie-breaking vote when nodes are evenly split. The shared storage device maintains a copy of the cluster database and can participate in consensus decisions, acting as a mediator that resolves voting deadlocks without requiring additional active nodes.
Solution Approach 2:
The voting parameter structure is changed from a fixed node-based system to a dynamic system where the shared storage device can assume a voting role. When a node fails, the shared storage device's vote parameter becomes active, transforming the voting configuration from 2 nodes (1-1 split) to 3 participants (2-1 majority), enabling quorum establishment after failure.
2Speed
If each node maintains a local copy of the cluster database for fast access, then read performance is improved, but consistency and quorum determination become complex requiring additional coordination
Solution Approach 1:
Instead of requiring complex coordination between nodes for quorum determination, each node and the shared storage device maintains a local copy of the entire cluster database. This copying approach allows independent verification of data state and simplifies quorum logic, as each participant can independently determine consensus based on its local copy and vote casting rules.
Data Source
AI summary
A third vote consensus technique enables a first node, i.e., a surviving node, of a two-node cluster to establish a quorum and continue to operate in response to failure of a second node of the cluster. Each node maintains configuration information organized as a cluster database (CDB) which may be changed according to a consensus-based protocol. Changes to the CDB are logged on a third copy file system (TCFS) stored on a local copy of TCFS (L-TCFS). A shared copy of the TCFS (i.e., S-TCFS) may be stored on shared storage devices of one or more storage arrays coupled to the nodes. The local copy of the TCFS (i.e., L-TCFS) represents a quorum vote for each node of the cluster, while the S-TCFS represents an additional “tie-breaker” vote of a consensus-based protocol. The additional vote may be obtained from the shared storage devices by the surviving node as a third vote to establish the quorum and enable the surviving node to cast two of three votes (i.e., a majority of votes) needed to continue operation of the cluster. That is, the majority of votes allows the surviving node to update the CDB with the configuration information changes so as to continue proper operation of the cluster.