Block Storage Replication via Partial Chunk Sync

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Block-based storage systems face performance degradation and latency issues due to increased I/O demands exceeding their capacity, leading to a loss of virtualized computing performance when durability state for data volumes cannot be maintained, often due to network partitions or system failures.

Innovation Solution

Implementing a method to reduce the durability state of data volumes temporarily, allowing operations to continue with minimal interruption by completing I/O requests at a master storage node while tracking changes, and later replicating these changes to a new slave storage node when conditions improve, thus enabling efficient data volume replication and maintaining performance.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If durability state is maintained through replication to slave storage nodes, then data reliability is improved, but I/O latency increases and system performance deteriorates when network partitions or failures occur

Engineering Contradiction:
Improvedata durabilityVSAvoidI/O latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system dynamically adjusts the durability state of data volumes based on operational conditions. When network partitions or failures are detected, the system automatically reduces durability requirements for affected volumes, allowing I/O operations to proceed with reduced replication guarantees. This dynamic adaptation resolves the contradiction by making durability flexible rather than fixed, enabling the system to prioritize performance when reliability can be temporarily compromised.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes the durability parameter (replication factor) of data volumes based on system conditions. By monitoring network health and storage node availability, the system adjusts replication settings in real-time, switching between full durability mode and reduced durability mode. This parameter change allows the system to optimize between reliability and performance by adapting durability requirements to current operational constraints.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If full replication to slave storage nodes is performed, then data durability is improved, but network traffic increases and replication overhead worsens system performance

Engineering Contradiction:
Improvedata durabilityVSAvoidnetwork traffic
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

Instead of performing complete replication of all data blocks to slave storage nodes, the system performs partial replication only for modified chunks. By tracking which data blocks have changed and replicating only those portions, the system reduces network traffic and replication overhead while maintaining sufficient durability. This partial action approach resolves the contradiction by eliminating unnecessary full replication operations.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system extracts and identifies only the modified portions of data that require replication, separating them from the unchanged data. By using change tracking mechanisms to identify which specific chunks need to be replicated, the system extracts only the necessary data for replication operations, significantly reducing network traffic compared to replicating entire data volumes.

Inventive Principle:
Principle #2Taking out (Extraction)

3Productivity

If replication is disabled during network partitions, then I/O performance is improved, but data durability and reliability deteriorate

Engineering Contradiction:
ImproveI/O throughputVSAvoiddata durability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

Rather than completely disabling replication during network partitions, the system dynamically adjusts replication behavior. It continues replication operations for volumes that can tolerate reduced durability while suspending or reducing replication for critical volumes. This dynamic approach allows the system to maintain I/O performance while preserving durability where possible, resolving the contradiction by making replication selective rather than uniform.

Inventive Principle:
Principle #15Dynamics

4Productivity

If durability state is reduced temporarily, then I/O operations continue with minimal interruption, but the risk of data loss increases

Engineering Contradiction:
ImproveI/O continuityVSAvoiddata loss risk
Core Design Contradiction:
ProductivityVSObject-affected harmful factors

Solution Approach 1:

The system performs preliminary actions by tracking data modifications continuously and maintaining change logs before durability state needs to be reduced. When network partitions occur, this pre-collected information allows the system to quickly identify which data blocks need replication and prioritize their transmission once connectivity is restored, minimizing the window of vulnerability and reducing data loss risk.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS9983825B2Efficient data volume replication for block-based storage
Publication Date: 2018.05.29 AMAZON TECH INC
  • US9983825B2 patent drawing
  • US9983825B2 patent drawing
  • US9983825B2 patent drawing

AI summary

A block-based storage system may implement efficient replication for restoring a data volume from a reduced durability state. A storage node that is not replicating write requests for a data volume may determine that replication for the data volume is to be enabled. A peer storage node may be identified that maintains a stale replica of the data volume. One or more replication operations may be performed to update stale data chunks in the stale replica of the data volume with current data chunks without updating data chunks in the stale replica of the data volume that are current. Stale replicas that are no longer needed may be deleted according timeouts or the amount of stale data in the replica.