Skip to main content

We've Moved!

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

Migrating data to a local cluster

It is possible to take a span that is virtualized by UVM and migrate it to the local storage, using Hitachi Storage Administrator Migrator functionality.

The two principal advantages of migration are:

  • A span residing locally is faster than one accessed over UVM (especially if the local storage is newer).
  • The server regains the ability to check for free space and protect the HDP pool from running out of space.

If the existing span violates the HDP rules introduced in release 12.1, for example, by spreading a single NAS stripeset across DP-Vols from multiple HDP pools, a migration can bring it into compliance. The best practice is to have one span per thinly provisioned HDP pool.

Making efficient use of disk space

To migrate data to a local HDP pool, that local HDP pool must be thickly provisioned, even if the external LUs are not. For example, for a remote HDP pool with six 10 TiB pool volumes and twenty 8 TiB DP-Vols, on migrating the data to local storage, the local HDP pool needs to provide 160 TiB of pool volumes or parity groups, instead of the 60 TiB that were present on the remote storage.

If the remote HDP pool contains multiple spans, it is possible to mitigate this inefficiency as follows:

Procedure

  1. Identify the span with the largest amount of free space - that is, the largest difference (in TiB) between the total capacity of the filesystems and the capacity of the span.

  2. If you have recently deleted filesystems from the span and you are confident that you will not need to undelete them, run the filesystem-recycle --all-filesystems command against the span.

  3. Migrate this span using Hitachi Storage Administrator Migrator functionality. Wait for migration to complete.

  4. When migration is complete, the free space on the local HDP pool falls by the capacity of the span (rather than just the capacity of the filesystems on it).

  5. Run the span-unmap-vacated-chunks --unused-chunks command against the span. This command launches a background process that gives unused space back to the local HDP pool. Within a few minutes, the free space on the local HDP pool starts to rise slowly as the storage zero-initializes the HDP pages that the server has returned to the HDP pool. It keeps rising as the storage continues to zero-initialize HDP pages, even after the unmapping process logs an event on the Admin Service to say that it has finished. To reduce the performance impact on the system, use the span-throttle-unmapping command. You can check the free space on the HDP pool using the span-list --sds command, but the server has no way to monitor or manage the zero-initialization process.

  6. As soon as the local HDP pool has space, migrate the second span, selected in the same way as before.

  7. Continue with this process until all spans are migrated.

When to avoid block-level migration

For optimal performance, a span should have a single stripeset (it should never have been expanded). The stripeset should contain a large number of system drives, and it should reside on a thinly provisioned HDP pool. The more a span differs from this ideal configuration, the poorer the performance, even after migration to new storage.

The worst case is a span for which the span-list -s command shows a large number of stripesets of one or two SDs each and also where the span-space-distribution command shows that the filesystems are not evenly spread across those stripesets.

A second configuration that cannot be helped by migration is a filesystem that is much smaller than the current maximum size, but which, according to the filesystem-scalability command, cannot expand because it has used up most or all of the available chunk runs.

For these configurations, use Object Replication or Universal Migrator.

 

  • Was this article helpful?