Introduction

Building a scalable cluster utilizing different storage classes can be complex. Extending this design across multiple sites adds to the complexity. Hammerspace Objectives provides a way to specify where each cluster should place (or provide multiple copies of) data - even between sites or in cloud object storage volumes. With the power of Hammerspace Objectives, you can customize your data’s behavior to match your business workflows, data lifecycle policies, and other needs.

This document provides an overview of Hammerspace Objectives and the conditions that determine when they apply.

This document will:

This document is not meant to be an authoritative source of information on all objectives or conditions, but merely a jumping-off point for configuring Hammerspace to achieve your data management requirements. Consult the Hammerspace documentation for additional information about using the Hammerspace platform.

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

Conditions are rules that control how objectives are enforced. They can be as broad or as granular as your data orchestration needs require.

To illustrate how an objective works, let’s look at one expressed in the following example.

Tiering Example

Goal: Keep on Tier 1 all recently accessed (< 8hrs) files or .docx files

In this example, the Hammerspace Objective Sweeper process checks two conditions and has two possible outcomes. Only one condition needs to be true to place the file on "Tier 1", though you can require both to be true.

Hammerspace Objectives can be broken down into three categories:

In the Using Metadata as Objective Conditions section of this document, you will learn how to use conditions to control precisely how objectives are applied. This is an important part of ensuring that your data orchestration goals are met.

In the Objective Scenarios and Solutions section of this document, you will see examples of how Hammerspace architects translate plain-language data orchestration requirements into Hammerspace Objectives and objective conditions.

The following are default objectives applied to each new share. In most cases, these objectives are left as is and you simply add your objectives. The purpose of these objectives is to define the default behavior for data placed on a Hammerspace cluster. In most cases, you will need to supplement these with your own, or modify them (where possible) to meet your own requirements to ensure that they are not counteracting your own objectives.

* This objective cannot be removed*

These default objectives can be broken down into four categories:

This document defines these objectives in greater detail in the Objective Definitions section, and discusses the conditions in the Using Metadata as Objective Conditions section.

To view the default objectives on a share or edit one, see Default Objectives and Editing an Objective in the Hammerspace Administration Guide.

One differentiating feature of Hammerspace is the relationship between the file share and the underlying storage it writes to. A Hammerspace share is, in effect, a virtual endpoint clients use to write data. Where that data is actually written depends on the share objectives, so by simply interacting with a file, the client indirectly influences where the data is placed.

The following diagram illustrates how the client sees their data versus the different ways the data may be placed. In this example, we have three potential volume group destinations, each containing volumes with specific characteristics. Files will ultimately be placed according to the objective configuration, which is constantly being re-evaluated in response to changes in file usage patterns, current date and time, and so on.

In this diagram, the client sees only the share itself. The client has no visibility into the objectives that control where the data is placed, and has no visibility into the actual volume where the file is located.

Objectives are applied on a per-share, per-cluster basis. In a global file share environment, each site will need its own objectives defined, and those objectives must be applied to the share at that site.

Best Practice: Always think of objectives on a per-site basis. Each site has different requirements, and the objectives only apply to the site at which they were applied.

You can optionally apply objectives with conditions that control when they are activated. These conditions, written in the Hammerscript, 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.). The Using Metadata as Objective Conditions section of this document will review some of the most common metadata objects that objectives target.

Objectives can also be configured to be overridden by other upstream objectives or removed by users with filesystem write attribute permissions:

For the full objective expression syntax, see Advanced Objectives in the Hammerspace Administration Guide.

When editing a share to apply objectives, the Hammerspace condition wizard helps you write the Hammerscript for optional conditions that control whether an objective is applied. The wizard supports the most common Hammerspace conditions.

The following screenshot shows how to use the condition wizard to build a Hammerscript expression. Select a value from the drop-down menu underneath Step 2: Define conditions. Complete the fields to build the condition (FNMATCH("*.orbit",NAME)?TRUE).