Skip to main content
Close

We've Moved!

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

Setting up LNAS and HNAS for virtualization

  1. Last updated
  2. Save as PDF

Before using the Hitachi NAS Universal Migrator, you must prepare the systems by associating the HNAS to the LNAS. The following steps describe this process. Note that your preparation must use the device names and IP addresses of your actual system.

Assuming a legacy NAS device with hostname LNAS at IP address 192.168.1.1, exporting a directory existing_data_dir as existing_export using NFSv3. The LNAS is configured such that a sub directory .snapshot exists in the root of existing_data_dir, to allow browsing of snapshot data.

Procedure

  1. Create a file system, <hnasfs>, using storage appropriate to contain the data set to be migrated from the LNAS.

  2. Create NFS exports to the file system, and any other HNAS configuration, as necessary. The directory on the HNAS file system that will be the root of the association must be empty.

    If you want to create exports within the root of the association, uncheck the Create path if does not exist checkbox on the SMU. If you use the CLI , use the nfs-export add command with the -i and -d (DONTCREATE) options for example, nfs-export add -i -d source_root/data1 FS1 /source_root/data1. This will ensure the root of the association remains empty until the virtualization starts.

  3. Add a new IP address to the LNAS, which the HNAS will use for the migration (assuming the LNAS's existing IP address will move to the HNAS when it is introduced into the environment).

  4. Create the association, <assoc1> at the HNAS console, using the following commands:

    virtualization-path-create -t <hnasfs> -n <assoc1> -s nfs://lnas/existing_export

    This can be modified if necessary using the following command:

    virtualization-path-modify

    NoteThis command cannot be used after issuing:

    virtualization-path-control -t <hnasfs> -n <assoc1> --start

    When the association has been created, virtualization-path-list will show Seen Dirs as 1, which is the root of the LNAS export.

  5. Add the .snapshot directory to the list of excluded directories for the association:

    virtualization-path-excluded-directory-add -t <hnasfs> -n <assoc1> -d .snapshot

    Again, this can be changed (virtualization-path-excluded-directory-list, virtualization-path-excluded-directory-delete) up to the point that virtualization-path-control -t hnasfs -n assoc1 --start is used.

  6. Prevent any further client access to the LNAS by renaming, or otherwise changing, the export. Ensure that existing export NFSv3 export is configured on the LNAS in such a way as to meet the suggested best practices. At this point all other methods for clients to directly connect to the LNAS should be disabled (for example, CIFS shares).

  7. If necessary, transfer IP addresses from the LNAS to the HNAS (apart from the one created in step 4).

Related Tasks
Parent Topic
Child Topics

Starting virtualization
When starting virtualization, you have two options. You can:
  • Stop at the end of the virtualization phase, and do not migrate any data.
  • Automatically start migrating data once virtualization is complete.

Procedure

  1. Start the virtualization.

    1. If you want to stop at the end of the virtualization phase, and not automatically migrate any data, use the following command:

      virtualization-path-control -t hnasfs -n assoc1 --start

      Wait for the virtualization to complete. This has the benefit that, at any time, the HNAS can be removed and you can revert back to using the LNAS, without having to reconstruct the data. The disadvantage of this is that the file system performance (seen by clients) will be significantly degraded while in virtualization mode.

    2. To start the data migration, use the command, virtualization-path-control -t hnasfs -n assoc1 --migrate immediately after using virtualization-path-control -t hnasfs -n assoc1 --start. The advantage is that the client access (for files) will automatically transition out of the poorly performing virtualization mode as soon as possible. It should be noted, however, that until the association is deleted and all objects are converted into TitanFile objects (that is, identical to objects that were only ever created on the HNAS outside of an association), the performance will not match that of a "normal" HNAS WFS file system. This is because it is only at this point that the requests by clients against the objects can be completely served in hardware. This has the disadvantage that, if you wish to revert back to using the LNAS on its own, you would have to manually recombine the data that is held on the HNAS with that on the LNAS.

  2. Once the virtualization has been started, it is possible for clients to access the data on the LNAS via the HNAS. This would normally be achieved by creating NFS exports and/or CIFS shares for hnasfs in such a way as to make the data available at the same location the clients were previously accessing: lnas:/existing_data_export. This also requires changing the configuration that is external to the HNAS, for example, DNS records and/or client mount points.

  3. Monitor progress of the virtualization/migration.

  4. Use virtualization-path-list -t hnasfs to display information about the association, including the counts of objects in various states.

  5. Events related to the association are raised in the event log. For example:

    Information: The virtualization path to filesystem hnasfs, association name assoc1, from URI nfs://lnas/existing_data_export has been created.

    Information: The status of the virtualization path to filesystem hnasfs, association name assoc1, has been modified: Virtualization has started.

    Information: The virtualization phase of filesystem hnasfs, association name assoc1 completed.

    Information: The status of the virtualization path to filesystem hnasfs, association name assoc1, has been modified: Migration has started.

    Information: The migration phase of filesystem hnasfs, association name assoc1 completed.

    Information: The virtualization path to filesystem hnasfs, association name assoc1, has been deleted.

  6. If you chose not to automatically proceed with virtualization, you can issue virtualization-path-control -t hnasfs -n assoc1 --migrate at any time, either before or after virtualization has completed. This prevents any further client access to LNAS. You must first ensure that existing_export NFSv3 export is correctly configured on the LNAS.

  7. Once migration has completed, you need to delete the association virtualization-path-delete -t hnasfs -n assoc1.

Parent Topic

Monitoring the association

The virtualization-path-list command can be used to display the state of associations. This includes a count of the file system objects in the association that are in various states. While this provides a good overview of the progress of the association, it may occasionally be unclear, especially when the association has been paused and restarted or when connection to the LNAS has momentarily been lost, and the HNAS is automatically recovering. Events are recorded in the event log when associations are created or deleted, and when the virtualization and migration phases complete.

Parent Topic

Incompatible features

It is not possible to successfully object replicate a file system containing associations.

Parent Topic

Performance Limitations

Once migration is complete, the performance when accessing data in the target file-system is that of a normal HNAS file system.

During the virtualization phase the performance is governed by a number of factors, including the capability of the LNAS, and the network connection to it. In addition the HNAS has to track the state of the objects in the association and send all modifying and IO operations to the LNAS. The result of this is that performance compared to a normal HNAS file system is significantly degraded. This is particularly the case when many (several hundred) parallel client operations are made on the virtualized data at the exact same time. If the desired use case of the feature is likely to include this type of load, it may be prudent to postpone widespread client access until after virtualization is complete, and migration is well underway.

Parent Topic

Upgrade and downgrade considerations

Any associations should be removed using the virtualization-path-delete command.

  • If in virtualization mode, the association can be deleted.
  • If part way through migration, it is best to wait until migration completes, and then delete the association. Data will be recovered onto the HNAS, rather than being in two different places.
Parent Topic