Walking Through the Komprise Architecture and How it Works Under the Hood.
First, let’s look at how Komprise provides a redundant, transparent, hierarchical filesystem that bridges file and object data without superimposing a single namespace or metadata layer. Instead, Komprise delivers transparent file access to cold data from any of your sources.
Let’s examine how cold data, identified by Komprise, is stored and managed on your cloud or on-prem targets. The Komprise solution includes a filesystem interface which is not merely self-serving vis-à-vis data ingestion, but also forms a vital cog that provides seamless and transparent access as the data temperature varies over its lifetime. Komprise Targets can be public/private clouds, LTO/archival devices or other NAS filers. Data moved to any of these targets looks to users and applications as if it were still on the original source and remains fully accessible, exactly as before.
To understand how Komprise works and provides transparent access, watch our five-minute demo.
Portal to Cold Data
The Komprise Filesystem has been designed to address the following:
- Fidelity in preservation and representation of file metadata and namespace hierarchy
- Secure and bandwidth optimized for transport over WANs to public clouds (but not limited to just public clouds)
- Seamless, transparent translation between files and objects (key, value pairs) when object stores are the at rest targets
- Source filer NAS protocol agnostic
- Preserve data access on the target
- Provide a single namespace to all moved data without fronting all the metadata or data paths
- Transparent file gateway that bridges NAS, object and cloud storage
- Enable access to data from primary and secondary storage without lock-in
Read how Komprise stitches NAS to cloud.
Komprise addresses these with a patent-pending redundant, transparent, hierarchical filesystem that is not creating any new storage or metadata repositories. Instead, Komprise leverages the sources and targets themselves to create a redundant, overarching namespace. By leveraging open standards and creating a distributed design, Komprise is able to provide unified visibility and management without creating lock-in.
To learn more about the Komprise architecture, read the Komprise Architecture Whitepaper.
Workloads Supported
The filesystem instances on the Komprise Observer Virtual Appliance are operationally transparent to users of the Komprise solution and entirely managed autonomously. Although not particularly having affinity to any particular workload, the following are what are typically expected over the lifetime of the Komprise management of data:
- Migration and Copy
- Cold and archival data transfer from the source shares to Komprise targets
- Client and application accesses
- Redirections from source share links or stubs
- Direct access over Komprise exported mounts
- Typically for browsing the directory hierarchies for a global view
- Off-grid cloud hosted read-only gateways for file based access in and from public clouds
- Recalls
- Policy based at folder granularity to have a level of control over egress costs from public clouds
Availability and Scalability
The filesystem instances running on various nodes of the Komprise grid serve up both migration and access traffic. They are also provisioned for dynamic load balancing across the Komprise Observer Virtual Appliance Grid, using a co-operative distribution algorithm.
In concluding this post, it should be highlighted that we have built the filesystem to enable a variety of data management use cases, across a customer’s storage environment, without creating any lock-in. Open up possibilities beyond those permitted by pedestrian data mover applications, which are generic and require extensive customization and manual management to address each use case. Learn more about why organizations choose Komprise.
Watch for more under-the-hood topics in this series.
Vikram Krishnamurthy is a Principal Engineer at Komprise and has been involved with the product design and development from the early stages. Prior to Komprise, he has worked extensively in the Storage industry with stints at IBM and NetApp.
