Cloud Snapshot Management via Secondary Controller
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current storage systems face challenges in managing remote data snapshots, particularly in containerized environments, where users cannot individually select snapshots for deletion and face difficulties in managing snapshots after the storage system instance is deleted.
Innovation Solution
Implementing an API to interact with storage volumes and remote object stores, allowing users to select and delete individual snapshots, and using a secondary controller to manage snapshots even after the original container is destroyed, enabling on-demand restoration of snapshots from the cloud.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If snapshots are stored remotely in the cloud, then data security and mobility are improved, but the ability to individually manage and delete specific snapshots is lost
Solution Approach 1:
A secondary controller is introduced as an intermediary between the user and the remotely stored snapshots. This secondary controller maintains metadata about the snapshots and enables users to individually select, view, and delete specific snapshots even after the original storage system instance has been destroyed. The secondary controller acts as a mediator that preserves snapshot management capabilities without requiring the original storage system to remain active.
2Adaptability or versatility
If the storage system is implemented in a container, then deployment flexibility is improved, but the system may not exist when users need to retrieve or manage data snapshots
Solution Approach 1:
The storage system is segmented into two independent components: the primary storage system running in the container that handles data operations, and a secondary controller that handles snapshot management. The secondary controller is designed to survive independently of the container lifecycle, ensuring that snapshot management capabilities remain available even when the containerized storage system is destroyed and recreated.
3Device complexity
If snapshots are managed by the storage system instance, then management operations are simplified, but snapshot management becomes impossible after the instance is deleted
Solution Approach 1:
Snapshot metadata and management information are prepared and stored in advance in the secondary controller before the container is destroyed. This preliminary action ensures that when the containerized storage system is recreated, the secondary controller already has all the necessary information to resume snapshot management operations, maintaining continuity without requiring complex recovery procedures.
Data Source
AI summary
Systems, methods, and machine-readable media for creating, deleting, and restoring volume snapshots in a remote data store are disclosed. A storage volume and a storage operating system are implemented in a software container. Through a user interface, a user may create a snapshot of the volume to a cloud storage. A user may also delete individual snapshots from the cloud storage. Further, deletion of a most recent snapshot may occur by awaiting deletion (though marking as deleted to the user) until a next snapshot is received. Snapshots in the cloud storage are manipulatable even after destruction of the source volume (by destruction of the container, for example). A controller outside the container is used by implementing the same API as the controller in the container had. Full restores of snapshots in the cloud are also possible even when the original container and volume have been destroyed.