Objective Scenarios and Solutions

All data will be stored on external NFSv3 volumes, so the DSX nodes do not require data disks (only boot disks)

A special condition is required to target only the latest snapshot, and all snapshots older than that

Create volume groups for each storage tier, and add the volumes for that tier to the appropriate group.

The same objectives apply to all sites.

Each site has only 1 volume per DSX node, so a simple keep-online objective will be fine for keeping needed files online.

Files will be copied to object storage 5 minutes after creation, creating the recommended second instance. This ensures that if a DSX node is unavailable, you can always retrieve the file from object storage.

We don’t have to tell an online file to be down-tiered to offline object storage. Since we already have an instance of each file in object storage for DR purposes, the online instance will simply be dropped (removed) when the keep-online objective condition no longer applies.

FNMATCH conditions are case sensitive. Verify that it is ok to match only work or WORK. If you need additional variations, such as Work, you will need to expand the supplied condition.

Snapshots are enabled on global file shares, so add an objective to ensure all global snapshot data is protected against site failure.

All shares are multi-protocol. The ACL-COMPATIBILITY-MODE-NON-POSIX objective will be required.

Access-based Enumeration is required to prevent users from seeing files and folders they do not have access to, so we will also need to add the do-not-cache objective.

Create volume groups for each storage tier, and add the volumes for that tier to the appropriate group.

There are two different types of online storage volumes (hdd and ssd), so you will need to create a volume group for each and place the correct volumes in them.

Files will be copied to object storage 5 minutes after creation, creating the recommended second instance. This ensures that if a DSX node is unavailable, you can always retrieve the file from object storage.

We don’t have to tell an online file to be down-tiered to offline object storage. Since we already have an instance in object storage for DR purposes, the online instance will simply be dropped (removed) when the keep-online objective condition no longer applies.

Snapshots are enabled on global file shares, so add an objective to ensure all global snapshot data is protected against site failure.

Create volume groups for each storage tier, and add the volumes for that tier to the appropriate group.

Although it will only be used on this site, create the NYC label on all sites, and verify the label’s internal ID matches across all sites.

NYC will only be copying files to object storage after 1 hour has passed, versus 5 minutes in LA. This is OK, but note that the Recovery Point Objective (RPO) will differ by site. Consider changing it to 5 minutes so that all sites have a similar RPO.

We don’t have to tell an online file to be down-tiered to offline object storage. Since we already have an instance in object storage for DR purposes, the online instance will simply be dropped (removed) when the keep-online objective condition no longer applies.

Snapshots are enabled on global file shares, so add an objective to ensure all global snapshot data is protected against site failure.

FNMATCH conditions are case sensitive; verify that it is ok to match only temp (lowercase), else add additional match conditions.

There is a requirement to keep files local once this site uses them, so we will need to use a combination of HAS_ONLINE_INSTANCE OR DATA_ORIGIN_LOCAL.

Although it will only be used on this site, create the MIA label on all sites, and verify that the label’s internal ID matches across all sites.

MIA will only copy files to object storage after 1 hour has passed, versus 5 minutes in LA. This is OK, but note that the Recovery Point Objective (RPO) will differ by site. Consider changing it to 5 minutes so that all sites have a similar RPO.

We don’t have to tell an online file to be down-tiered to offline object storage. Since we already have an instance in object storage for DR purposes, the online instance will simply be dropped (removed) when the keep-online objective condition no longer applies.

Snapshots are enabled on global file shares, so add an objective to ensure all global snapshot data is protected against site failure.

FNMATCH conditions are case sensitive; verify that it is OK to match only TMP or tmp, or add additional match conditions.

Create volume groups for each storage tier, and add the volumes for that tier to the appropriate group.

There are two different types of online storage volumes (hdd and ssd), so you will need to create a volume group for each and place the correct volumes in them.

Since certain file types will only be placed on a specific volume type, ensure those same files are not stored on the other volume type.

FNMATCH conditions are case-sensitive; verify that it is ok to match only png and mov (lowercase), else add additional match conditions.

Files will be copied to object storage 5 minutes after creation, creating the recommended second instance. This ensures that if a DSX node is unavailable, the file can always be retrieved from object storage.

We don’t have to tell an online file to be down-tiered to offline object storage. Since we already have an instance in object storage for DR purposes, the online instance will simply be dropped (removed) when the keep-online objective condition no longer applies.

Snapshots are enabled on global file shares, so add an objective to ensure all global snapshot data is protected against site failure.

There are two different types of online storage volumes (hdd and ssd), so you will need to create a volume group for each and place the correct volumes in them.

Unlike Seattle, there is no listed requirement to write all files to object storage. Per Hammerspace best practices, and to support continuity in the event of a site failure, add this objective to every site that hosts global file shares.

Since we write all data to object storage for DR purposes, there is less urgency to protect against the failure of the non-RAIDED HDD and SSD volumes. If, for some reason, writing all data to object storage isn’t practical, we should consider adding an availability-3-nines objective to each share so files are written to two different DSX nodes (each node is a failure domain, not each volume).

We don’t have to tell an online file to be down-tiered to offline object storage. Since we decided to place an instance in object storage for DR purposes, the online instance will be dropped (removed) when the keep-online objective no longer applies.

Snapshots are enabled on global file shares. Add an objective to ensure all global snapshot data is protected against site failure.

Create volume groups for each storage tier, and add the volumes for that tier to the appropriate group.

There are two different types of online storage volumes (hdd and ssd), so you will need to create a volume group for each and place the correct volumes in them.

For all shares but the Rome_HR share, we don’t have to tell an online file to be down-tiered to offline object storage. Since we decided to place an instance in object storage for DR purposes, the online instance will be dropped (removed) when the keep-online objective no longer applies.

For the Rome_HR share, we need to take every precaution available to ensure files are not written to US-based object storage volumes.

Snapshots are enabled on global file shares, so even though it is not mentioned, add an objective to ensure all global snapshot data is protected against site failure.

While not an objective, note that the Rome_HR share is not a global file share, so snapshots for this share will need to be enabled on the Rome site directly.

Create volume groups for each storage tier, and add the volumes for that tier to the appropriate group.