Appendix a - Replication Examples
Example #1
Customer has two sites - a primary site (SITE A) and a DR site (SITE B). The DR site is only used if there is an issue with the primary site.
Customer utilizes a Pure Flashblade for online file storage and a Pure S3 at each site, on the same Flashblade system, for an archival and space-efficient tier.
The following three objectives are applied to all shares. This example is for SITE A, but SITE B uses an identical strategy. Each cluster places all online files and file snapshots in the Pure Flashblade buckets at both sites, a Hammerspace best practice for customers who leverage GFS for DR. Live file data that has been used within the last 90 days is kept online on a Pure Flashblade NFS volume. Customer does not use Hammerspace DSXs for storage; they are only used as a data mover.
[Name: place-on-SITEAPureS3, Applicability: 0, Removable: true]
[Name: place-on-SITEBPureNFS, Applicability: IS_LIVE AND LAST_USE_AGE<90*DAYS, Removable: true]
[Name: place-on-SITEBPureS3, Applicability: TRUE, Removable: true]
To complement their data protection strategies, snapshots are enabled, as are versioning, undelete, and log-xfer objectives. The versioning and undelete objectives utilize exclusions that avoid targeting unnecessary files.
[Name: versioning-1-day, Applicability: SUM(\{||#A=FNMATCH((\{".tmp";".TMP";".docx";".xlsx";"~.pptx"})[ROW],NAME)}[5])==0, Removable: true]*
[Name: undelete-1-day, Applicability: SUM(\{||#A=FNMATCH((\{".tmp";".TMP";".docx";".xlsx";"~.pptx"})[ROW],NAME)}[5])==0, Removable: true]*
Example #2
Customer has two sites, a primary and a DR site. The DR site is not used unless the primary site is unavailable.
Customer uses Hammerspace DSXs for online file storage, and Google Cloud object storage for both a DR archive, and to down-tier data that has not recently been used. Once the indicated time elapses, the online instance is dropped, leaving only the instance in the Google Cloud storage.
Customer uses Hammerspace tiers to direct the placement of files onto their DSX servers.
The dsx_mirror tier is configured to create two instances, while the dsx_any objective creates one instance on any available DSX. The shares use both tiers, but under different conditions as described below.
Name: dsx_any
Place on:
[node: dc1dsx2.company.com; node: dc1dsx1.company.com; node: dc1dsx3.company.com]
Name: dsx_mirror
Place on:
[node: dc1dsx2.company.com; node: dc1dsx1.company.com; node: dc1dsx3.company.com]
The following three objectives are applied to all shares.
For the first 24 hours after a file is created or modified, two online instances are kept to ensure the file has time to be copied to Google Cloud storage:
Name: dsx_local_mir_24h
Expression: IF MODIFY_AGE<24*HOURS&&DATA_ORIGIN_LOCAL THEN \{SLO('dsx_mirror')}
Locally edited or created files are kept online for two weeks:
Name: dsx_local_2weeks
Expression: IF MODIFY_AGE<2*WEEKS&&DATA_ORIGIN_LOCAL THEN \{SLO('dsx_any')}
FIles created or edited at the DR SITE Are also kept online for 24 hours:
Name: dsx_remote_24h
Expression: IF MODIFY_AGE<24*HOURS&&DATA_ORIGIN_REMOTE THEN \{SLO('dsx_any')}
One of the following two objectives are used on specific shares to ensure that if a locally created or modified file has not yet been copied to Google Cloud (!HAS_INSTANCE) and ( || ) has been modified within less than 24 hours, an instance is kept on a DSX.
Name: sharea_dsx
Expression: IF DATA_ORIGIN_LOCAL&&(!HAS_INSTANCE_ON("google cloud nearline::finance_records")||MODIFY_AGE<24*HOURS) THEN \{SLO('dsx_any')}
Name: shareb_dsx
Expression: IF DATA_ORIGIN_LOCAL&&(!HAS_INSTANCE_ON("google cloud nearline::hr_records")||MODIFY_AGE<24*HOURS) THEN \{SLO('dsx_any')}
The following two objectives are used on specific shares to ensure that an instance of each file is placed on one specific Google Cloud storage container, while the other ensures that they will not be placed on a different storage container.
[Name: place-on-google cloud nearline::hr_records, Applicability: ALWAYS, Removable: true]
[Name: exclude-from-google cloud nearline::finance_records, Applicability: ALWAYS, Removable: true]
Note: If a cluster has available object storage locations, and the default optimize-for-capacity objective is present, it will be downtiered to any allowed object storage container if no objective compels a file to stay online. This happens after 5 minutes by default, which is why it is important to define objectives that keep files online for as long as is needed or wanted, especially when utilizing object storage.