RAIN Storage Namespaces for Data Segregation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current data storage solutions for fixed content, such as traditional tape and optical storage, lack the necessary high availability and reliability for long-term archival needs, and existing RAIN systems are limited in scalability and flexibility for managing large volumes of data across heterogeneous nodes.

Innovation Solution

A redundant array of independent nodes (RAIN) architecture is implemented with logical partitioning of a content platform into namespaces, allowing for scalable and reliable storage through symmetric software components across heterogeneous hardware, enabling administrators to define tenants with specific permissions and configurations, thereby segregating and managing data effectively.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional tape and optical storage solutions are used for fixed content archival, then storage capacity is achieved, but high availability and reliability are insufficient

Engineering Contradiction:
Improvedata availabilityVSAvoidstorage solution flexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The storage system is segmented into multiple independent nodes forming a RAIN cluster, where each node stores a portion of replicated data. This segmentation provides both reliability through distribution and adaptability through modular node addition/removal, resolving the contradiction between data availability and system flexibility.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system changes the storage parameter from centralized (single tape/optical library) to distributed across multiple nodes with configurable replication factors. This parameter change enables both high availability through redundancy and adaptability through dynamic cluster configuration.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If RAIN architecture with node replication is implemented, then reliability and availability improve, but system complexity increases

Engineering Contradiction:
Improvenode failure compensationVSAvoidcluster management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The RAIN cluster implements self-service through automatic data replication and reconstruction. When nodes are added or removed, the system automatically redistributes and replicates data without manual intervention, maintaining reliability while reducing management complexity.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The cluster configuration is made dynamic, allowing nodes to join and exit freely. The system dynamically adjusts replication patterns and data distribution as nodes are added or removed, simplifying management while maintaining reliability through automatic adaptation.

Inventive Principle:
Principle #15Dynamics

3Reliability

If identical hardware components are used in closed RAIN systems, then system reliability improves, but scalability and flexibility are limited

Engineering Contradiction:
Improvesystem consistencyVSAvoidheterogeneous node support
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The RAIN cluster implements a universal interface and standardized data protocols that allow heterogeneous nodes with different hardware configurations to participate in the cluster. This universality maintains system consistency through standardized interactions while enabling adaptability through support for diverse hardware platforms.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Reliability

If data is replicated across multiple nodes, then availability and fault tolerance improve, but storage space efficiency decreases

Engineering Contradiction:
Improveautomatic compensation for node failureVSAvoidstorage capacity utilization
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The system allows dynamic adjustment of the replication factor parameter, enabling optimization between reliability and storage efficiency. Administrators can configure the degree of replication based on specific data importance and available capacity, resolving the contradiction by making replication adjustable rather than fixed.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

Instead of fully replicating all data across all nodes, the system applies partial replication strategically. Critical data receives higher replication factors while less critical data uses lower factors, optimizing the balance between reliability and storage efficiency through differentiated replication levels.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentEP2494460B1Fixed content storage within a partitioned content platform using namespaces
Publication Date: 2017.06.28 HITACHI DATA SYST CORP
  • EP2494460B1 patent drawingFigure 1
  • EP2494460B1 patent drawingFigure 2~4
  • EP2494460B1 patent drawingFigure 3

AI summary

Content platform management is enhanced by logically partitioning a physical cluster that comprises a redundant array of independent nodes. Using an interface, an administrator defines one or more "tenants" within the archive cluster, wherein a tenant has a set of attributes including, for example, namespaces, administrative accounts, data access accounts, and a permission mask. A namespace is a logical partition of the cluster that serves as a collection of objects typically associated with at least one defined application. Each namespace has a private file system such that access to one namespace (and its associated objects) does not enable a user to access objects in another namespace. A namespace has capabilities (e.g., read, write, delete, purge, and the like) that a namespace administrator can choose to enable or disable for a given data account. Using the interface, an administrator for the tenant creates and manages namespaces such that the cluster then is logically partitioned into a set of namespaces, wherein one or more namespaces are associated with a given tenant. This approach enables a user to segregate cluster data into logical partitions. Using the administrative interface, a namespace associated with a given tenant is selectively configured without affecting a configuration of at least one other namespace in the set of namespaces. This architecture enables support for many top level tenants, with multiple namespaces per tenant, and wherein configuration is effected at the level of a namespace.