Asynchronous Peer-to-Peer Data Replication via Piggybacked Messaging

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current remote replication solutions are expensive, complex, and not scalable, with synchronous replication being too costly and asynchronous replication often falling short in reliability and efficiency, limiting their widespread adoption for data protection and business continuity.

Innovation Solution

A peer-to-peer asynchronous data replication method using a master node and client nodes with a 'piggybacking' messaging system that allows bidirectional data replication between multiple sites, reducing bandwidth requirements and enabling scalable, cost-effective data replication with improved reliability and quick recovery capabilities.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If synchronous remote replication is used to maintain identical copies of data at multiple locations, then data reliability is improved, but network cost and performance penalty increase significantly

Engineering Contradiction:
Improvedata reliabilityVSAvoidnetwork cost
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the replication process into asynchronous operations where updates are propagated to multiple sites independently without requiring coordination or acknowledgment from all sites. This eliminates the need for complex synchronous protocols and reduces network overhead while maintaining data reliability through the use of update logs and sequence numbers.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies preliminary action by maintaining a local update log at each site that records all changes before they are propagated to remote sites. This allows the system to prepare and queue updates locally, then transmit them asynchronously to replicate sites, avoiding the need for waiting for confirmation from all sites before proceeding with the next operation.

Inventive Principle:
Principle #10Preliminary action

2Device complexity

If asynchronous replication with update logs is used, then network cost is reduced, but the amount of data that must be transmitted increases

Engineering Contradiction:
Improvenetwork costVSAvoiddata transmission volume
Core Design Contradiction:
Device complexityVSLoss of substance

Solution Approach 1:

The patent extracts only the essential update information (changes) from the complete data set and transmits only these differences to remote sites. By using update logs that record only modifications rather than transmitting entire data sets, the system significantly reduces the volume of data transmitted over the network while maintaining asynchronous replication benefits.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent uses copying by creating and maintaining update logs that contain replicated data changes, which are then transmitted to remote sites. Instead of transmitting the actual data files, the system copies and transmits only the change information, reducing network bandwidth requirements while ensuring data consistency across sites.

Inventive Principle:
Principle #26Copying

3Reliability

If traditional backup methods are used to protect data, then data protection is achieved, but recovery time and operational downtime increase significantly

Engineering Contradiction:
Improvedata protectionVSAvoidrecovery time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent implements continuity of useful action by maintaining continuous asynchronous replication of data updates to remote sites in real-time or near-real-time. This ensures that backup copies are continuously updated with the latest data changes, so when recovery is needed, the most current data is already available at remote locations, eliminating lengthy recovery processes and minimizing operational downtime.

Inventive Principle:
Principle #20Continuity of useful action

4Reliability

If geographic separation of data copies is implemented, then risk of data loss from local disasters is reduced, but restoring access to remotely stored data becomes more complex and time-consuming

Engineering Contradiction:
Improvedata loss protectionVSAvoiddata restoration ease
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent applies self-service by implementing automatic failover mechanisms where the system autonomously detects failures and restores data access without requiring manual intervention. When a primary site fails, the system automatically promotes a replicated site to primary status using the maintained update logs and sequence numbers, enabling rapid recovery and maintaining ease of operation despite geographic separation of data copies.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP2183677B1System and method for remote asynchronous data replication
Publication Date: 2019.01.23 DELL EMC
  • EP2183677B1 patent drawingFigure 1
  • EP2183677B1 patent drawingFigure 2A
  • EP2183677B1 patent drawingFigure 2B

AI summary

An asynchronous peer-to-peer data replication method implemented within a replication cluster comprising at least one master node and at least a first client node includes entering an update in a data volume of the master node and storing the update in a master node storage. Next, updating a first active session in a master log and then sending a first message from the master node to the first client node. The first message comprises a first message content and first "piggybacked" data indicating that the first active session in the master log was updated. Next, receiving the first message by the first client node, registering that the first active session in the master log was updated and signaling internally that the first active session in the master log was updated. Next, sending an update request from the first client node to the master node, processing the update request by the master node and sending the update to the first client node. Finally, receiving the update by the first client node and updating the first active session in a first client log.