Storage Location Virtualization for Multi-Source Cluster Data
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional virtualization containers face challenges in mapping storage locations across a cluster environment, particularly in combining and securing data from multiple distinct sources, as they typically allow only one-to-one mappings and lack the sophistication to manage multiple external storage sources efficiently.
Innovation Solution
The system implements storage location virtualization by identifying a volume storage location for an operating-system-level virtualization container, mapping it to multiple distinct source locations through an automated driver, and propagating changes to these sources, enabling seamless access and management of combined data across the cluster environment.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional virtualization containers use one-to-one mapping with local directory or file, then the mapping is simple and direct, but the container cannot access multiple distinct external storage sources efficiently
Solution Approach 1:
The patent merges multiple distinct external storage sources (local directories, network file systems, object stores) into a unified virtual storage namespace that can be mounted inside the container. This allows the container to access multiple storage sources through a single unified interface, resolving the contradiction between accessing multiple sources and maintaining simplicity.
Solution Approach 2:
The patent introduces a storage driver as an intermediary layer between the container filesystem and external storage sources. This driver handles the complexity of mapping and managing multiple storage sources, while presenting a simple unified interface to the container, thus resolving the contradiction by absorbing complexity in the intermediary layer.
2Ease of operation
If conventional solutions use object stores, network file system mounts, or distributed file systems, then multiple storage sources can be accessed, but selecting, combining, and securing data from these sources remains inconvenient and inefficient
Solution Approach 1:
The storage driver automatically performs selection, combination, and security management of data from multiple storage sources without requiring manual user intervention. The driver self-manages the complexity of coordinating multiple storage sources, making data access convenient for users while handling the underlying complexity automatically.
Solution Approach 2:
The storage driver is designed as a universal component that can handle multiple types of storage sources (local files, network file systems, object stores) through a unified interface and consistent management mechanism, making data access convenient across different storage types while managing complexity through a single multi-functional component.
3Adaptability or versatility
If virtualization containers run on any node within a cluster, then container placement is flexible, but mapping storage locations to varying nodes introduces complications
Solution Approach 1:
The patent resolves the storage mapping problem in cluster environments by introducing a virtualization dimension. Instead of directly mapping storage to physical nodes, the solution creates a virtual storage layer that abstracts the physical node variability, allowing containers to access storage reliably regardless of which node they run on.
Solution Approach 2:
The patent segments the storage management functionality into a separate storage driver component that operates independently of container placement. This segmentation allows the storage driver to manage storage access uniformly across all nodes in the cluster, maintaining reliable storage access while preserving container placement flexibility.
Data Source
AI summary
The disclosed computer-implemented method for performing storage location virtualization may include (i) identifying a volume storage location for an operating-system-level virtualization container that isolates an instance of user space, the volume storage location providing a working space for data accessed during the existence of the operating-system-level virtualization container, (ii) mapping, through an automated driver that performs location virtualization, the volume storage location to multiple distinct source locations outside of the operating-system-level virtualization container, rather than a single source location, and (iii) propagating, through the automated driver, changes to the data within the working space of the volume storage location during the existence of the operating-system-level virtualization container to the respective multiple distinct source locations outside of the operating-system-level virtualization container to preserve the changes. Various other methods, systems, and computer-readable media are also disclosed.