Recovery Checkpoints for Distributed File System Replication

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Modern distributed file systems face challenges in managing file system recovery due to the complexity and size of hyper-scale systems, which can lead to significant storage and performance overhead, especially in determining objects for replication and managing state or protection information.

Innovation Solution

The implementation of a system that generates and stores recovery point information, including job identifiers and snapshot numbers, to facilitate efficient replication and recovery in distributed file systems, allowing for the identification of objects to be copied between source and target file systems, and enabling recovery from errors by reverting to known states.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If naïve backup strategies are used in hyper-scale distributed file systems, then complete data protection is achieved, but storage overhead and performance overhead increase significantly

Engineering Contradiction:
Improvedata protectionVSAvoidperformance overhead
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The patent extracts and stores only the essential recovery information (protection information indicating which objects have been replicated) separately from the actual file objects. This allows the system to achieve complete data protection while minimizing storage overhead by not duplicating entire file systems for backup purposes.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system performs preliminary replication of file objects to target storage before failure occurs, and stores protection information to track this state. When failure happens, the pre-stored protection information enables rapid recovery without needing to re-transmit already-replicated objects, reducing performance overhead.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If naïve backup strategies are used in hyper-scale distributed file systems, then complete data protection is achieved, but storage overhead increases significantly

Engineering Contradiction:
Improvedata protectionVSAvoidstorage overhead
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent extracts and stores only the essential recovery information (protection information indicating which objects have been replicated) separately from the actual file objects. This allows the system to achieve complete data protection while minimizing storage overhead by not duplicating entire file systems for backup purposes.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system creates lightweight copies of metadata (protection information) rather than copying actual file data. These protection information copies are stored in distributed fashion across the file system, enabling rapid recovery identification without consuming significant storage resources.

Inventive Principle:
Principle #26Copying

3Measurement precision

If the large number of files in modern distributed file system are visited to manage state or protection information, then accurate recovery tracking is achieved, but resource consumption increases

Engineering Contradiction:
Improverecovery tracking accuracyVSAvoidresource consumption
Core Design Contradiction:
Measurement precisionVSUse of energy by moving object

Solution Approach 1:

The system implements self-service by having file objects automatically report their replication status to the file system, which then stores this protection information. This eliminates the need for centralized visitors to traverse and query each file individually, achieving accurate recovery tracking with minimal resource consumption.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary replication of file objects to target storage before failure occurs, and stores protection information to track this state. When failure happens, the pre-stored protection information enables rapid recovery without needing to re-transmit already-replicated objects, reducing performance overhead.

Inventive Principle:
Principle #10Preliminary action

4Reliability

If replication jobs are interrupted due to errors, then system resilience is tested, but recovery complexity increases without recovery point information

Engineering Contradiction:
Improvesystem resilienceVSAvoidrecovery complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system performs preliminary replication of file objects to target storage before failure occurs, and stores protection information to track this state. When failure happens, the pre-stored protection information enables rapid recovery without needing to re-transmit already-replicated objects, reducing performance overhead.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The file system stores protection information that provides feedback about the replication state of each object. This feedback mechanism enables the system to quickly identify what has been replicated and what needs re-transmission after interruption, reducing recovery complexity while maintaining system resilience.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS11372735B2Recovery checkpoints for distributed file systems
Publication Date: 2022.06.28 QUMULO INC
  • US11372735B2 patent drawing
  • US11372735B2 patent drawing
  • US11372735B2 patent drawing

AI summary

Embodiments are directed to managing data in a file system over a network. A source file system that includes a plurality of objects may be provided. A replication job that copies each object associated with a source replication snapshot to a target file system may be executed. The replication job may be associated with a job identifier. Recovery point information that includes the job identifier, a source snapshot number that corresponds to the source replication snapshot, a target snapshot number that corresponds to a target replication snapshot may be generated. The recovery point information may be stored on the source file system and a copy of the recovery point information may be stored on the target file system. The recovery point information or the copy of the recovery point information may be employed to recover from errors detected during execution of a next replication job.