Container Volume Replication via Storage Manager Orchestration

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In datacenter deployments of containerized software applications, ensuring high availability and maintaining container-level consistency with changing application states is challenging, as existing solutions fail to recover the original state after corruption.

Innovation Solution

Implementing a container volume replication system using a container storage replication log and volume buffer synchronization, managed by a storage manager orchestrated by a job scheduler and service orchestrator, ensures data security and recovery of in-memory databases and application data.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If containerization is used to deploy software applications, then resource consumption is reduced and deployment efficiency is improved, but container-level consistency and data recovery capability are compromised when corruption occurs

Engineering Contradiction:

Improvedeployment efficiencyVSAvoidcontainer-level consistency

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The patent implements volume replication by creating and maintaining copies of container volumes across multiple hosts. When a container volume is created, the system automatically creates replicated copies on remote hosts, ensuring that data exists in multiple locations. This copying mechanism allows the system to maintain container-level consistency while enabling recovery from corruption events, as replicated volumes can be restored from their copies.

Inventive Principle:

Principle #26Copying

Solution Approach 2:

The system performs preliminary actions by proactively replicating volume data before corruption can occur. The volume replication is set up in advance and continuously synchronized, so that when corruption is detected, the system can immediately restore from the pre-prepared replicated copies without needing to perform time-consuming data recovery operations.

Inventive Principle:

Principle #10Preliminary action

2Duration of action of stationary object

If framework rescheduling is used to handle container corruption, then service continuity is maintained, but original application state is lost

Engineering Contradiction:

Improveservice continuityVSAvoidapplication state

Core Design Contradiction:

Duration of action of stationary objectVSLoss of information

Solution Approach 1:

The volume replication system creates and maintains copies of the original container volumes on remote hosts. When corruption occurs, instead of simply rescheduling the container framework (which would lose the original state), the system can restore the original volume from its replicated copy, thereby preserving the original application state while maintaining service continuity.

Inventive Principle:

Principle #26Copying

Solution Approach 2:

The system prepares cushioning measures in advance by continuously replicating volume data to remote hosts. This creates a safety buffer that protects against data loss. When corruption occurs, the pre-prepared replicated volumes serve as a cushion that prevents information loss, allowing the system to recover the original state rather than merely rescheduling.

Inventive Principle:

Principle #11Beforehand cushioning (Prior cushioning)

3Speed

If in-memory database is used for container volume replication, then data access speed is improved, but data persistence and recovery capability are reduced

Engineering Contradiction:

Improvedata access speedVSAvoiddata persistence

Core Design Contradiction:

SpeedVSReliability

Solution Approach 1:

The patent extends the data storage from a single in-memory location to multiple dimensions by replicating volumes across different hosts and storage locations. This dimensional expansion allows the system to maintain fast in-memory access for active data while simultaneously ensuring persistence through replicated copies stored in different locations, thus resolving the contradiction between speed and reliability.

Inventive Principle:

Principle #17Another dimension (Dimensionality change)

Solution Approach 2:

The system creates and maintains copies of in-memory database volumes on remote hosts. This copying mechanism ensures that while the primary in-memory database provides fast access, persistent copies exist elsewhere, guaranteeing data persistence and recovery capability even if the primary in-memory storage fails.

Inventive Principle:

Principle #26Copying

Data Source

PatentUS11954122B2In-memory database-managed container volume replication

Publication Date: 2024.04.09 SAP SE

AI summary

In an example embodiment, a solution is used to provide container volume replication via a container storage replication log and volume buffer synchronization, which is built on top of a container cloud platform whose container metadata and replication runtime configuration are all managed by a storage manager (a service orchestrated by its job scheduler and service orchestrator). This container volume replication ensures the data security for a long-running service in the container. In the case of any disaster, the in-memory database and application data inside of the container can be recovered via volume replication. This provides container volume replication for long-running containerized applications whose states keep changing.