Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Pre-migration considerations for Hitachi NAS Universal Migrator

This section describes the pre-migration considerations for Hitachi NAS Universal Migrator.

Number and layout associations

The Universal Migrator is designed to deal with multiple associations per file system, concurrently; however, due to fundamental file system limitations, the simplest management is attained by configuring only one association per file system, mapped to a directory in the root of the file system.

NFS export on the LNAS used by HNAS

The export from the LNAS should have the following options set: rw, sync, no_subtree_check, no_root_squash. These options allow the HNAS to fully control the data and metadata of the files and directories. The export must also be configured to only allow access to the HNAS, as if other clients are able to access the data with rw and no_root_squash, then the HNAS's view of the data will not be consistent, and it will lose track of what has been virtualized or migrated. This could result in data loss.

Note If you are restricting the LNAS access on a per-IP basis on the export, include all IP addresses that an EVS can utilize.

The export should only contain real (not virtual) file systems. Examples of virtual file systems are directories such as /dev or /proc on a Linux server, or /.snapshot on a NAS device. It may be difficult or impossible to exclude /.snapshot, or similar, via the LNAS configuration. In this case the directory should be excluded at the HNAS using the virtualization-path-excluded-directory-* commands. The HNAS file system uses its storage resources in different ways to the LNAS; therefore, you cannot depend on the space being used being identical on each. Furthermore, during the process of virtualization and migration, the HNAS file system needs to use extra storage space to track the state of the processing.

The following arrangements on the LNAS should be avoided, as they will lead to unpredictable behavior.

  1. Nesting or overlapping exports on the LNAS used for associations.
  2. Hard links across multiple LNAS exports.

Export/shares from HNAS

It is recommended not to set no_root_squash in NFS exports. This prevents accidental modification of the file system objects that track the state of the association.

Backup and replication policies, disaster recovery

This section describes backup and replication policies and disaster recovery.

Virtualization

During virtualization the LNAS is the canonical store of the data. To ensure that there is no loss of data, if the live file system is damaged, it is necessary for backups/replications/snapshots to be configured on the LNAS. System administrators should ensure that they have sufficient backups/snapshots of the LNAS data set before connecting the HNAS.

While it is not necessary to have backups or replications configured for the HNAS during virtualization (because they would not contain any data that was not recoverable through the LNAS backup), it is recommended to configure these when the association is created. This reduces the risk of forgetting to start (or not knowing when to start) them when migration begins. It also allows time to be sure that everything is working correctly. Incremental backups/replication schedules started in the virtualization phase will pick up data added during the migration phase. When replicating during the virtualization phase, a message will appear in the replication log stating that "ingested files are excluded from this operation". This is normal.

In the event that recovery from a backup is required during the virtualization phase, the simplest course of action is listed below.

  1. Prevent client access.
  2. Delete the association, then remove all of the files/directories it created from HNAS. If the association was in the root of an HNAS file system, it is recommended that you format the file system after deleting the association. Use virtualization-delete-path --force command.
  3. Recover the LNAS from backup.
  4. Recreate the association.
  5. Start the virtualization.
  6. Allow client access.

Migration

During migration, some data is on HNAS only, while other data is on the LNAS only. This makes backups/replications and subsequent recovery more complicated, and depends on the replication/backup mechanism that is used.

Ideally, the replication/backup of data on the HNAS and LNAS would be synchronized, such that the data contained in the pair of backups is guaranteed to be consistent. A consistent set could be guaranteed by the following method:

  1. Prevent client access to the data.
  2. Pause the migration by issuing the virtualization-path-control --pause command.
  3. Wait for activity to stop by issuing the virtualization-path-list command and wait until the counts displayed in the list stop changing.
  4. Take snapshots of the LNAS and HNAS and start the backup/replications of these snapshots.
  5. Allow client access.

This method can, however, be undesirable because you must prevent client access. A more acceptable alternative is to have time synchronized snapshots of the HNAS and LNAS to use for the replication/backups. This runs the risk of having inconsistencies between the LNAS and HNAS. You could mitigate this by pausing the background processes and/or ensuring the backups are done at a quiet time for client access.

HNAS NDMP file replication and tape backups

Because object-based backup is incompatible with virtualization, file based replication must be used. The recovery of data from the HNAS backup, following damage to the live HNAS file system, has to encompass a manual merge of the LNAS and HNAS data. This is necessary because, although the IngestedFiles contained in the backup are preserved, the associated metadata is lost because it does not form part of the NDMP backup. The result is that, although the user data of migrated files and the directory structure that contained them will recover intact, the connection of this directory structure to the LNAS is not easily remade.

The sequence to recover, if NDMP replications or backups are used, is as follows:

Procedure

  1. Prevent client access.

  2. Delete the association (if it has not been lost in the file system damage).

  3. Recover HNAS data to a location other than that which will be used for the association.

  4. If necessary, recover LNAS data.

  5. Recreate the association and allow virtualization to complete.

  6. There are now two sets of files, those recovered from the LNAS and virtualized, and those that were previously migrated and have been recovered to a separate location. Depending on the volume/type of files that are in the latter set , and how many renames/moves have happened, you can do either of the following:

    1. Examine the files manually and copy the migrated files into the virtualized directory structure, file by file, depending on some case-specific judgment.

    2. Use an automated method (rsync/robocopy) to move the migrated files into the virtualized directory structure.

  7. Allow client access.

 

  • Was this article helpful?