Search the docs

Key Configuration Parameters

Manage Data with Objectives

Hammerspace uses objective-based policies to automate data placement and other data services across all storage volumes under management. Unlike reactive policies, objectives enable customers to create plain-language business rules for how different classes of data should be managed. These objectives are applied on each site to specific directories or an entire share and act as the primary controller for data movement, including Replication.

Data can be dynamically moved on a file-granular basis between storage systems or sites to accommodate different performance requirements or other use cases, without interruption to users/applications. In addition, multiple instances of files can be replicated between sites for data protection, tiering, workflow staging, migration to new storage, or other needs in the background, without interruption to user access. These are not file copies, but instantiations of the same files, made possible by the shared Global File System metadata, which is kept synchronized and consistent across all sites.

In other words, since the Global File System spans all sites, users see the same data sets globally—​across silos, sites, and clouds—​regardless of where the physical bits of the files are stored today or may be moved to tomorrow.

No client software is required on user systems or application servers. They simply see their data as files or objects via the protocol they prefer, except now they have global visibility across all silos, sites, and cloud instances.

"LogXfer" Objective

By default, logxfer is an objective that’s applied to all shares and kicks in when a share becomes replicated. This feature creates a local snapshot of a file when ownership changes, acting as a form of data protection and a way to manually recover from user errors or conflicts.

"Keep on cloud" Objective

Configures the owning site to upload data to the shared cloud bucket. This is essential for enabling other sites to pull data and for disaster recovery scenarios.

"Keep on site X" Objective

Configures a specific site to maintain a local copy of data. This can be used to proactively pull data to a site, ensuring local availability even if the owning site goes offline.

Asynchronous Reservation tag-Based Objective

This capability allows a user to apply a tag to a file, effectively "reserving" it for exclusive write access by a specific site. A tag is set on the file, indicating the owning site. An objective is configured to make the file read-only on all other sites.

Note that this is an advisory lock; any user with write permissions can remove the tag. It does not provide hard, synchronous locking.

  • Replication Dependency: This mechanism is entirely dependent on Replication being in sync. The tag must replicate to all other sites for the read-only objective to take effect.

  • Usage:

    • Set Lock: Use an hs command to apply a tag (e.g., siteA_lock) to the file.

    • Wait for Replication: The user or an automated script must wait for this tag to replicate to all other sites before proceeding with modifications.

    • Release Lock: Use another hs command to remove the tag when done.

NOTE: Reference Appendix A to see example Replication use cases with objectives applied. For more information on setting up Objectives, see the How to Configure Hammerspace Objectives [Support article may require login to view.] article.

Snapshot Strategy

Snapshots can be user-initiated or scheduled,and are used primarily for data recovery from accidental deletes or overwrites, or for long-term archival, rather than for frequent versioning. The current best practice is to take a single snapshot once a day on one site. It is not recommended to take full snapshots with high frequency (e.g., hourly). Daily or weekly snapshots are generally sufficient.

  • Taking a real snapshot initiates a copy-on-write process for files currently open for write, which can be resource-intensive, especially if underlying storage does not support offloaded cloning. This process is not instantaneous and introduces a "fuzz" in the "point-in-time" of the snapshot. Any files opened for write after that snap was created will also need to copy-on-write the data.

File Versioning and Undelete

While undelete and versioning are alternative options for data recovery, they are not currently recommended as a replacement for snapshots.

Data Durability & Availability

Replication configurations must prioritize data durability, especially for actively modified files. It’s recommended to use three-way client-side mirroring (CSM) for Tier 0. This ensures that even if one instance is dropped due to a COW Split (copy-on-write) or a node is in maintenance, there are still two active instances, providing data safety until re-silvering occurs. Note that 3-way CSM may also be beneficial for other storage tiers that do not possess RAID or Erasure Coding.