Dynamic Replication Topology Selection for Cloud Write Latency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing replication management systems in cloud computing face challenges in maintaining strong consistency across geographically disparate data centers, leading to high latency and throughput issues, especially in environments with fluctuating replica performance and network partitions.

Innovation Solution

A dynamic replication management system that selects write request dissemination topologies based on client and network parameters, using disseminating modules to route write requests through a dynamically chosen topology, ensuring strong consistency and optimizing latency and throughput by adapting to node performance and network conditions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional chain replication protocols are used to maintain strong consistency across geographically disparate data centers, then reliability is improved, but write latency increases significantly

Engineering Contradiction:
Improvestrong consistencyVSAvoidwrite latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system dynamically selects dissemination topologies based on current network conditions and replica performance metrics. Instead of using a fixed chain replication protocol, the system adapts the dissemination structure in real-time to optimize for low latency while maintaining strong consistency guarantees across geographically distributed data centers.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes key parameters of the replication protocol including the dissemination topology structure, batch size, and synchronization timing based on monitored network conditions and replica performance. This allows the system to adjust between different operational modes to minimize write latency while preserving reliability.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If write requests are disseminated to all replicas to ensure strong consistency, then reliability is improved, but throughput decreases due to network overhead

Engineering Contradiction:
Improvestrong consistencyVSAvoidwrite throughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system segments the replication process into multiple phases and groups replicas into different dissemination groups. Write requests are processed in batches rather than being propagated to all replicas simultaneously, allowing parallel processing and reducing network overhead while maintaining consistency guarantees.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs partial dissemination of write requests by sending them to subsets of replicas in different batches rather than to all replicas at once. This partial action approach reduces immediate network overhead while still achieving eventual strong consistency across all replicas.

Inventive Principle:
Principle #16Partial or excessive action

3Device complexity

If fixed dissemination topologies are used, then device complexity is reduced, but adaptability to fluctuating replica performance and network conditions deteriorates

Engineering Contradiction:
Improvereplication management complexityVSAvoidadaptation to network conditions
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The system implements dynamic topology selection where dissemination structures are automatically adjusted based on real-time monitoring of network conditions and replica performance. This dynamic adaptation allows the system to respond to fluctuating conditions without requiring complex manual configuration or management.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The replication management system performs self-configuration by automatically monitoring its own performance metrics and network conditions, then autonomously selecting appropriate dissemination topologies. This self-service capability eliminates the need for external manual tuning while maintaining adaptability to changing conditions.

Inventive Principle:
Principle #25Self-service

4Reliability

If synchronous replication is used to ensure strong consistency, then reliability is improved, but write latency increases due to waiting for all replicas to confirm

Engineering Contradiction:
Improvestrong consistencyVSAvoidwrite confirmation time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system uses periodic batching where write requests are collected and disseminated in time-bound batches rather than requiring immediate synchronous confirmation to all replicas. This periodic approach reduces waiting time while maintaining consistency through structured batch processing and confirmation mechanisms.

Inventive Principle:
Principle #19Periodic action

Solution Approach 2:

The system achieves strong consistency through partial synchronous confirmation by requiring acknowledgments from a quorum of replicas rather than all replicas, or by using staged confirmation processes. This partial action reduces the time required for write confirmation while preserving reliability guarantees.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS9002939B2Adaptive and dynamic replication management in cloud computing
Publication Date: 2015.04.07 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US9002939B2 patent drawing
  • US9002939B2 patent drawing
  • US9002939B2 patent drawing

AI summary

A system for communicating information among a plurality of nodes of a network. The system comprises a plurality of disseminating modules installed in a plurality of nodes of a network which hosts a plurality of replicas of data having a plurality of objects, each the disseminating module has access to a dataset defining a plurality of write request dissemination topologies. Each disseminating module is defined to receive a write request from a client, to select dynamically one of the write request dissemination topologies according to at least one parameter of the client, and to disseminate the write request according to the selected write request dissemination topology.