Search the docs

Managing Data with Hammerspace

Hammerspace uses objectives to manage data placement across all storage volumes under management. Data can be placed in one location, be made redundant across multiple locations, and be moved, migrated, and tiered without disruption.

Hammerspace also makes the same data available across many sites, enabling workflows that go into the cloud or across data centers.

Each storage class in Kubernetes is tied to 1 or more objectives that can be modified without requiring any changes within Kubernetes. What does this mean?

The performance, reliability, and other characteristics of existing PersistentVolumes (PVs) can be modified without having to re-create the volumes themselves. In other words, the underlying storage can be changed without migrating the PV. Simply re-defining the objectives that a Storage Class maps to will achieve the desired outcome.

Hammerspace Objectives

Hammerspace Objectives are instructions that we use to implement our data orchestration goals, and control the behavior of the filesystem.

Objectives can optionally be applied with conditions that control when they are activated. These conditions can be based on the action being performed (file being created, file being opened, etc), the file characteristics (extension, name, etc.), or even the file type (is a snapshot, is a live file, etc.).

Objectives can be broken down into three categories:

  • Storage - The family of placement objectives controls where your data is placed (or not placed), and how many copies of that data will be created.

  • Data Protection - The versioning, undelete, and file conflict resolution objectives complement snapshots to enhance on-cluster data protection, and enable client self-recovery capabilities.

  • Behavior - These objectives control the behavior of the filesystem. Some examples include access-based enumeration, external antivirus integration, filesystem timestamp or ACL behavior, and various NFS/SMB protocol-specific options.

These Service Level Objectives are a new paradigm that empowers users to declare the intent of their data by coupling desired outcomes with programmable conditions. With this declarative control, data can be organized through metadata characteristics (inherent or custom) and tailored to achieve specific outcomes. Furthermore, "smart" macros objectives that include rules for when the underlying sub-objectives are in effect or not (predicated objectives) can be configured to further customize the workflow.

Declarative statements, like Hammerspace Objectives, are a far more effective and modern method of creating business outcomes from data than what historically has been available, especially when it comes to data management in Kubernetes.

Persistent Storage

There are three different methods for Hammerspace to manage data in Kubernetes that support a wide variety of applications, from high-performance databases to unstructured data applications.

Block Persistent Volume

A block volume exposes a block device inside the Pod. This block device can be directly used by the application. Common examples are databases and applications that share data over block, such as clustering tools. The main difference between this and a File Backed volume is that a Block persistent volume does not have a file system and needs to be managed by your application.

Block Volumes can be concurrently shared between Kubernetes pods. Be aware that raw block sharing requires applications to be aware of each other.

This volume should only be used with ASM or something similar. File Backed Volumes are recommended for most use cases.

File-Backed Persistent Volume

A file-backed mounted volume exposes a mounted, local, file system inside the Kubernetes Pod. This allows applications to use regular POSIX file system syntax to read and write data. This provisions a local non-shared file system to the Pod.

NFS-shared Persistent Volume

NFS persistent volumes provision a shared file-based interface to Pods and regular NFS clients. In a Hammerspace environment, external applications not running on the Kubernetes cluster can access the same volume over multiple supported protocols, including SMB. More importantly, this mode allows data to be shared concurrently between Kubernetes Clusters and Pods across multiple geographically dispersed sites and clouds.