Replicated State Machine for Distributed Node Membership

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional distributed multi-site collaborative computing solutions face limitations in real-time synchronization, scalability, reliability, and fault-tolerance due to issues such as repeated pre-emption in agreement protocols, reliance on central coordinators, and inefficient resource utilization, leading to delays and increased risk in software development and delivery.

Innovation Solution

A replicated state machine architecture with a proposal manager, agreement manager, collision/back-off timer, and storage reclaimer facilitates coordinated execution of proposals across nodes, ensuring real-time synchronization and efficient resource management, eliminating the need for central coordinators and improving scalability and fault-tolerance.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional distributed multi-site collaborative computing solutions are used, then basic distributed computing functionality is provided, but real-time synchronization capability is lost and fault-tolerance is reduced

Engineering Contradiction:
Improvereal-time synchronization capabilityVSAvoidsystem architecture complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system segments the monolithic centralized repository into multiple independent replica nodes, each capable of autonomous operation. Each node maintains a complete copy of the repository and can independently serve requests, eliminating the single point of failure while providing real-time synchronization through the replicated state machine architecture.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The replicated state machine acts as an intermediary layer between client requests and the underlying repository storage. It coordinates operations across replicas, ensures consistency through deterministic state transitions, and maintains synchronization without requiring a central coordinator, thus improving reliability while managing complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If central coordinators are used to manage distributed repositories, then coordination is simplified, but scalability is limited and single points of failure are created

Engineering Contradiction:
ImprovescalabilityVSAvoidfault-tolerance
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system extracts the coordinator function from the architecture entirely. Each node independently executes the replicated state machine and makes autonomous decisions about repository operations. The coordination that would have been performed by a central coordinator is distributed across all nodes through deterministic state machine execution, enabling both scalability and fault-tolerance.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system implements dynamic node membership where nodes can be added or removed from the replica set without system reconfiguration. The replicated state machine automatically adapts to membership changes, maintaining consistency and synchronization dynamically as the system scales, eliminating the need for static coordinator-based architecture.

Inventive Principle:
Principle #15Dynamics

3Productivity

If manual file merging and excessive branching are used to prevent overwriting, then data integrity is maintained, but productivity is reduced and development time increases

Engineering Contradiction:
Improvedevelopment speedVSAvoiddata integrity
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The replicated state machine provides self-service consistency management through deterministic state transitions. Each node independently maintains data integrity through the immutable state machine execution model, automatically resolving potential conflicts without requiring manual merging operations. This enables developers to work in parallel with full data integrity protection, significantly improving productivity.

Inventive Principle:
Principle #25Self-service

4Speed

If repeated pre-emption in agreement protocols occurs, then consensus is eventually reached, but scalability is adversely impacted and system speed decreases

Engineering Contradiction:
Improveconsensus achievement speedVSAvoidscalability
Core Design Contradiction:
SpeedVSAdaptability or versatility

Solution Approach 1:

The system performs preliminary actions by pre-establishing the replicated state machine configuration and membership before consensus operations begin. Nodes are pre-synchronized and ready to execute state transitions, eliminating the need for repeated pre-emption and reconfiguration during consensus operations. This preliminary setup enables fast consensus achievement that scales with the system.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP2939446B1Joining memberships in distributed computing systems
Publication Date: 2020.02.12 WANDISCO
  • EP2939446B1 patent drawingFigure 1
  • EP2939446B1 patent drawingFigure 2
  • EP2939446B1 patent drawingFigure 3~4

AI summary

A computer-implemented method of deploying a membership of nodes is a distributed computing system may comprise selecting nodes to be part of a membership of nodes; creating a membership task identifying a membership creator node as the node mat is creating the membership and comprising a membership target identifying at least one node of the distributed computing system that is to become a member of the membership; and creating a beacon configured to send a create membership message to each identified node, the create membership message comprising at least an identity of the membership task and an identification of the membership. Upon receiving a response from a node in the membership target the node from which the response was received may be removed from the beacon. The membership may be deployed when a response has been received from each of the nodes identified in the membership target.