Transferring XVLs as links during object replication

This solution requires only one migration target. It is most appropriate to use this solution when the single migration target is an external cloud entity provided by a third-party cloud provider.

At any time, there is only one 'correct' view of the data - the replication source live file system. Migrated and non-migrated data in other locations may be inconsistent with that view. This is because the migrated data is modified immediately, but the non-migrated data is modified only when the replication has taken place. This is of concern when migrated files are deleted or reverse-migrated (either explicitly or as a result of being auto-recalled). When the Transfer XVLs as links during object replication option is not enabled, the deletion or reverse migration of a migrated file would result in the data for that file on the migrated target being deleted.

As the data that has been deleted is now removed from the single migration target, the link to that data from the replication target(s) is now broken. To prevent this, two new CLI command options are available:

set delete-target-on-unlink-even-if-xvl-as-links

set delete-target-on-reverse-migration-even-if-xvl-as-links

These settings apply on the cluster hosting the replication source filesystem, but they can be set on all clusters hosting replication target filesystems in anticipation of one of the replication targets being promoted to read/write at a future date. The default value for these settings is false.

When the Transfer XVLs as links during object replication option is enabled for a filesystem and the above options are set to false, a deletion or reverse migration does not cause the migrated data to be deleted (or a retention policy to be set on HCP if configured), and the access to the migrated data at the replication target(s) is not broken.

After protected reverse migration

These settings preserve access to data at replication targets, but the data for reverse migrated or deleted files is preserved forever on the migration target unless the deleted files are manually removed from it.

After protected reverse migration and subsequent replication

As a consequence, with this setting, even when all files have been reverse migrated, the migration path is reported as in use.

If there is a requirement to promptly delete data for storage or regulatory reasons, the options should be set to true, but with the expectation that access to the migrated data from replication targets is imperfect until it is manually cleaned up.

For non-cloud externally migrated data, a list of migrated files for a filesystem can be generated using the Report Migrated Files migration type in the schedule configuration. This can then be compared to the data on the migration target to determine which files can be safely removed. This option does not exist for Data Migrator to Cloud.

Parent Topic

• Transferring XVLs as links during object replication

  When using object replication, the default behaviour is to 'rehydrate' data that has been migrated using either external migration or the Data Migrator to Cloud (DM2C) feature.

This solution requires a different migration target for each replication target filesystem.

It also requires a method of copying the migrated data between the migration targets. As there is more than one copy of the migrated data, this arrangement is suitable for use in a disaster recovery or backup scenario and is appropriate for internally provided cloud targets such as HCP. As there is no risk of deleting the link targets relied upon by the replication target filesystems, there is no requirement to protect the link targets from deletion or reverse migration.

If the replication has been configured in this way then the following CLI command options should be set to true to avoid having to manually remove the non-deleted link targets:

set delete-target-on-unlink-even-if-xvl-as-links true

set delete-target-on-reverse-migration-even-if-xvl-as-links true

These settings apply on the cluster hosting the replication source filesystem, but they can be set on all clusters hosting replication target filesystems in anticipation of one of the replication targets being promoted to read/write at a future date. The default value for these settings is false.

A time window still exists when the replication target and its migration target may be inconsistent, when one or other of the replications (either the NAS object replication or the copy of data between migration targets) has completed and the other has not. Scheduling of the replications should be configured to reduce this window to a minimum and minimize the opportunity for client access during the window.

Parent Topic

• Transferring XVLs as links during object replication

  When using object replication, the default behaviour is to 'rehydrate' data that has been migrated using either external migration or the Data Migrator to Cloud (DM2C) feature.

You can enable this option using the CLI or the NAS Manager.

You can enable the Transfer XVLs as links during object replication option as follows:

• Run the replication-xvl-as-links CLI command for each replication source file system

or

• Select the enable button for the Transfer XVLs as links during object replication option on the File System Details page on the NAS Manager.
  NoteThe replication source file system must be unmounted for this option to be available.

Configuring the migration path for the replication target file system

To enable access to the migrated data on the replication target filesystem, configure a migration path using the CLI or the NAS Manager (see the Data Migrator Administration Guide for details).

Migration paths are configured on a replication target filesystem in the same way as they are configured on a normal file system except for the following constraints:

• The migration path must have the same logical name as that on the replication source filesystem. For cloud paths, the logical name of the migration path is the name of the cloud destination in use by the path, and the cloud destination for the replication target must also have the same name as the one on the replication source. The cloud destination on the replication target also needs to have the same UUID as one on the replication source - creating a cloud destination with a specific UUID is only possible using the migration-cloud-destination-create CLI command and not through the NAS Manager.
• The cloud account on which the replication target's cloud destination depends has no constraints but must exist.
• It is not possible to configure multiple cloud destinations on the same cluster with the same name and/or UUID. If the replication source and target file systems are both on the same cluster, they must share the same migration target and cannot be configured to use different ones.

Example when source and target are on different clusters

Consider a replication source file system that has a cloud migration path configured as follows:

• Migration destination name: repln_src_mign_dest
• Migration destination UUID: a5de129e-8f75-11d3-9010-18de0fcebd7d
• Migration path name (same as the destination name): repln_src_mign_dest

To create the migration path for the replication target:

• Create a cloud migration account on the cluster that hosts the replication target file system using either the NAS Manager or the migration-cloud-account-create CLI command.
• Create a cloud destination with the name repln_src_mign_dest and UUID a5de129e-8f75-11d3-9010-18de0fcebd7d using the migration-cloud-destination-create CLI command.
• Create a cloud path for the replication target file system to the destination configured above using either the NAS Manager or the migration-add-external-path CLI command.

Parent Topic

• Transferring XVLs as links during object replication

  When using object replication, the default behaviour is to 'rehydrate' data that has been migrated using either external migration or the Data Migrator to Cloud (DM2C) feature.