Objective Definitions

This objective will place data on any file-based (online) volume, including DSX-based volumes or third-party NFS volumes in the cluster. It is also automatically assigned to data that is modified and/or created; however, if you use only the default objectives and share settings, data can move to offline storage volumes in as little as 5 minutes.

Best Practice: Keep-online is the simplest way to ensure files stay in an online storage volume, though it will use any available volume to do so. Most exercises in this document focus on other techniques for keeping important files online.

In this section, we will review how we explicitly define where data will be placed.

By default, a new Hammerspace share will try to place newly created data on any available online volume. This is achieved using a default keep-online objective with an IS_BEING_CREATED OR (HAS_ONLINE_INSTANCE AND IS_RECENTLY_USED)?ALWAYS condition that ensures that new files are kept in an online volume for at least 5 minutes.

The two primary objectives for explicitly stating where data will be placed are place-on and confine-to. Place-on requires at least one instance of a file to be placed in the specified location, while confine-to restricts all instances to the specified location.

Best Practice: Hammerspace recommends creating Volume Groups that contain the target volumes and using the default place-on and confine-to objectives created for those volume groups. The following screenshot shows the default objectives that were created for two different volume groups.

If you don’t use conditions, these objectives apply to all files in the share, including those in snapshots. If the cluster cannot enforce an objective, its reaction will vary. Some examples using the above objectives include:

The exclude-from-* objective prevents the specified volume group from being used. A common use case for exclude-from is when you are using keep-online, availability, and durability objectives that don’t target specific volumes/volume groups. However, you still want to exclude certain ones.

Best Practice: If it’s critical that a particular volume not be used, say to adhere to European GDPR, consider using an exclude-from objective.

One of the most common uses for objectives is to tier data to multiple storage classes. This is often used to tier data off expensive online volumes to much cheaper object storage volumes or even slower online volumes.

In the following example, we will use one of the more common metadata values for determining when data should be tiered, LAST_USE_AGE. Our target volume groups will be the ones used in the previous section.

Best Practice: When tiering, pair each place-on objective with an exclude-from objective that targets the other tiers. The following example shows this pairing.

The behavior of these objectives is fairly straightforward:

The exclude-from objectives remove the instance from the other tier as soon as the objectives align. Without them, removal depends on the share default objectives (optimize-for-capacity), and the file can keep an instance in both tiers until it is no longer recently used, or indefinitely if those defaults were removed.

Three Availability objectives enable the admin to specify how many nines of Availability the data should have. Each storage volume is assigned an Availability value. Data will be placed either on a storage volume that meets the Availability number (minimum is 1) or multiple file instances may be created to meet the requested number of nines.

The default Availability objectives let you specify 1, 3, or 5 nines. You can create custom objectives that allow up to 9 nines.

To apply an availability objective, see The Availability Number of Nines Objective in the Hammerspace Administration Guide.

Best Practices:

Update the Availability or Reliability values as needed:

Best Practice: The volume Durability value should always be larger than the Availability value.

Three durability objectives enable the admin to specify how many nines of Durability the data should have. Each storage volume is assigned a Durability value. Data will be placed either on a storage volume that meets the Durability number (minimum is 1) or multiple file instances may be created to meet the requested number of nines.

The default Durability objectives let you specify 1, 3, or 5 nines. You can create custom objectives that allow up to 9 nines.

To apply a durability objective, see Using the Durability Number of Nines Objective in the Hammerspace Administration Guide.

Best Practice: Durability and availability are calculated separately. Depending on the cluster volume configuration, each may require a different number of file instances.

The versioning, undelete, and file conflict resolution (log-xfer) objectives enable more granular control over data recoverability. They use the same methods as Hammerspace snapshots, but unlike snapshots, they are applied as an objective rather than a share option.

These objectives are available in 1-hour, 1-day, 1-month, and 1-week versions; the objective names and definitions are as follows:

To configure these objectives, see File Versioning (versioning and undelete) and Cross-Site Versioning (log-xfer) in the Hammerspace Administration Guide.

Each of these objectives stores its saved file versions in the share .snapshot/current directory. The files are removed once both the objective retention period elapses and the next snapshot expires.

Best Practice: Hammerspace recommends using exclusions to prevent these objectives from targeting unnecessary files. For example, a file that frequently updates a temporary file might cause excessive file versioning, which would needlessly consume cluster resources. When you apply these objectives using the Share Properties | Advanced menu (described in the next section), you’ll see some of the most common extensions customers typically exclude. You can customize these based on your needs, which Hammerspace recommends to ensure your data protection requirements are still met.

Enables Access-Based Enumeration (ABE) for both NFS and SMB clients, preventing users from seeing files and folders they don’t have permission to access.

If you add the ABE objective to a share, Hammerspace also recommends adding the DO-NOT-CACHE objective to ensure client permissions aren’t cached. Cached permissions prevent ABE from receiving permissions updates in real time and can cause it to display files and folders that a user can no longer access.

To enable ABE for a share or a folder, see Allowing Access-Based Enumeration in the Hammerspace Administration Guide.

The acl-compatibility-mode-ignore-chmod objective blocks permission mode changes — typically chmod from Unix clients. It is commonly used with shares that have specific NFS security requirements.

This objective does not block ACL changes from Unix clients or from any other client. Reading and writing the full NFSv4 ACL with nfs4_getfacl and nfs4_setfacl continues to work on a share with this objective applied.

Add the acl-compatibility-mode-non-posix objective to any share used only by SMB clients or by both SMB and NFS clients. This objective changes the Access Control List (ACL) compatibility mode to prevent the creation of inverse ACLs common in NFS-only POSIX file systems. If present, these ACLs can cause unexpected denies for SMB clients.

Best Practice: Contact Hammerspace support if you want this setting enabled at the cluster level, which is recommended if all shares will have either SMB-only or SMB and NFS clients. This ensures that new shares automatically have this setting applied. No objective is required.

The do-not-cache objective prevents a share from caching client permissions, ensuring it always has current data on user permissions (including group memberships). If using access-based enumeration, add this objective to ensure the filesystem view is always current.

Controls the layout behavior for NFS 4.2 protocol. Leaving it on generally improves the performance when files are opened and then written to. If using NFS v3 or SMB, this indirectly affects behavior, as the DSX node holds the layout rather than the client.

The no-atime objective prevents a share from updating file access timestamps. It is most commonly used in shares or folders where file atime is continually updated and therefore has limited use for objectives or auditing. This also reduces the metadata update workload on the cluster for those files.

This objective encourages files to move towards Object/Cloud storage whenever possible after the keep-online objective has expired and/or files are no longer in use.

Best Practice: If your Hammerspace cluster has an attached object storage volume and you notice files moving to offline object storage much faster than you want, consider removing the share default optimize-for-capacity objective or adding a keep-online or place-on objective that explicitly defines how long to keep data in online volumes. In nearly every case, you’ll add your own place-on or keep-online objective so that you can leave this default objective in place. Alternatively, you can also modify the share RECENTLY_USED_DURATION value, which will extend how long files are kept online by default. Refer to the IS_RECENTLY_USED section of this document for additional details.