Service-Level Agreement Engine for Cloud Storage Consistency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Cloud storage services face significant performance and consistency trade-offs due to high communication latencies between data centers, especially with geo-replication, making it challenging to balance user satisfaction with quality of service (QoS) and quality of data (QoD) in a cloud storage environment.

Innovation Solution

A service-level agreement engine is introduced to determine the most appropriate node for transaction requests based on specified performance and consistency guarantees, using latency and consistency data to select nodes that can fulfill transaction requests within defined latency bounds and consistency levels, allowing applications to prioritize their requirements and pay for desired levels of service.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If data is replicated across different regions (geo-replication), then data availability and survivability are improved, but communication latency and consistency performance deteriorate

Engineering Contradiction:
Improvedata availabilityVSAvoidcommunication latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent applies local quality by allowing different replicas to serve different consistency requirements. Local replicas provide fast eventual consistency for non-critical operations, while a primary replica provides strong consistency for critical operations. This resolves the contradiction by optimizing each replica's function according to its location and role in the distributed system.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent implements dynamics by allowing the system to dynamically switch between strong consistency and eventual consistency modes based on operational requirements. The service-level agreement engine dynamically selects which consistency model to apply for each transaction, enabling the system to adapt to changing conditions and balance availability with latency requirements.

Inventive Principle:
Principle #15Dynamics

2Reliability

If strongly consistent reads are performed, then data consistency is improved, but read performance deteriorates due to multiple replica coordination

Engineering Contradiction:
Improvedata consistencyVSAvoidread performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies local quality by designating specific replicas (primary vs. secondary) with different consistency roles. Strongly consistent reads are directed to the primary replica which maintains the authoritative data state, while eventually consistent reads can be served by local secondary replicas. This specialization resolves the contradiction by ensuring strong consistency only where necessary while improving overall read performance through local caching.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent introduces an intermediary mechanism (the service-level agreement engine and replication coordinator) that manages consistency requirements. This intermediary directs read requests to appropriate replicas based on consistency needs, avoiding the performance penalty of coordinating multiple replicas for every read operation. The intermediary resolves the contradiction by intelligent request routing rather than forcing all reads to wait for multi-replica coordination.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Productivity

If eventual consistency is used, then read performance is improved, but data freshness and consistency guarantees deteriorate

Engineering Contradiction:
Improveread performanceVSAvoiddata freshness
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent implements dynamics by allowing the consistency model to be dynamically selected based on service-level agreements. The system can switch between eventual consistency (for performance) and strong consistency (for freshness) on a per-transaction basis. This resolves the contradiction by allowing the system to optimize for performance when data freshness is less critical, while maintaining freshness guarantees when required by the application's consistency requirements.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent applies parameter changes by introducing service-level agreement parameters that define acceptable consistency levels. Applications can specify their consistency requirements as configurable parameters, allowing the system to adjust the consistency model accordingly. This resolves the contradiction by making consistency a tunable parameter rather than a fixed system property, enabling optimization of both performance and data freshness based on application needs.

Inventive Principle:
Principle #35Parameter changes

4Reliability

If multiple replicas are coordinated for strongly consistent transactions, then consistency guarantees are improved, but system complexity and coordination overhead increase

Engineering Contradiction:
Improveconsistency guaranteesVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies local quality by concentrating strong consistency coordination at the primary replica rather than requiring symmetric coordination among all replicas. Secondary replicas can operate independently with eventual consistency, reducing the coordination overhead. This resolves the contradiction by localizing the complexity of consistency management to only where it is necessary (primary replica) while allowing simpler operation at secondary replicas.

Inventive Principle:
Principle #3Local quality

Data Source

PatentEP2904737B1Consistency-based service-level agreements in cloud storage environments
Publication Date: 2020.11.18 MICROSOFT TECHNOLOGY LICENSING LLC
  • EP2904737B1 patent drawingFigure 1
  • EP2904737B1 patent drawingFigure 2
  • EP2904737B1 patent drawingFigure 3

AI summary

An application programming interface is provided that allows applications to assign multiple service-level agreements to their data transactions. The service-level agreements include latency bounds and consistency guarantees. The applications may assign utility values to each of the service-level agreements. A monitor component monitors the various replica nodes in a cloud storage system for latency and consistency, and when a transaction is received from an application, the monitor determines which of the replica nodes can likely fulfill the transaction in satisfaction of any of the service-level agreements. Where multiple service-level agreements can be satisfied, the replica node that can fulfill the transaction according to the service-level agreement with the greatest utility is selected. The application may be charged for the transaction based on the utility of the service-level agreement that was satisfied.