The traditional approach to moving data—take a volume offline, spend hours copying it to a new location, and then reconfigure and restart affected servers and applications—has become nearly impossible in an age of shared infrastructure and round-the-clock operations. This is why NetApp is bringing you a range of options to allow you to nondisruptively move data to a new location—with minimal hassles—whenever it becomes necessary.
If you're a regular reader of Tech OnTap, you already know about NetApp Data Motion (renamed NetApp® DataMotion for vFiler®), which allows you to move MultiStore® vFiler units and all associated data between storage systems in multi-tenant environments. With the Data ONTAP® 8.0.1 release, NetApp introduced a number of new capabilities, including DataMotion for Volumes, which allows you to nondisruptively migrate volumes containing LUNs between aggregates on the same storage controller.
This article describes DataMotion for Volumes, explains how it differs from DataMotion for vFiler, and looks at some of the best practices and possible use cases.
What Is DataMotion for Volumes?
DataMotion for Volumes is a new feature supported in Data ONTAP 8.0.1 running in 7-Mode. It allows you to nondisruptively migrate a volume from one aggregate to another on a single storage controller (you can't move volumes between the two different controllers that make up an HA pair). DataMotion for Volumes is designed to facilitate migration of any volume containing FC, FCoE, or iSCSI LUNs only. It does not support NFS or CIFS volumes.
NetApp DataMotion for Volumes lets you nondisruptively migrate volumes containing LUNs between different aggregates on a single NetApp® storage controller.
A key benefit of DataMotion for Volumes is that it maintains all the details associated with a volume after the migration, including:
You can move data between all types of media connected to your storage controller. For instance, you can move data from an aggregate containing FC or SAS disks to one consisting of SATA disks or vice versa. For the first release, you can move volumes between 32-bit aggregates or between 64-bit aggregates, but you cannot move volumes between 32-bit and 64-bit aggregates.
Differences between DataMotion for Volumes and DataMotion for vFiler
There are a number of important differences between DataMotion for Volumes and the DataMotion for vFiler technology you may already be familiar with. DataMotion for Volumes works at the level of the FlexVol® volume while DataMotion for vFiler works at the level of the vFiler and will migrate all NFS or iSCSI volumes associated with a given vFiler unit. DataMotion for vFiler allows you to migrate volumes between separate storage systems or HA pairs. DataMotion for vFiler is managed using NetApp Protection Manager. DataMotion for Volumes can only be invoked from the command line by using the vol move command.
These and other differences are summarized in Table 1.
Comparison of DataMotion for Volumes with DataMotion for vFiler.
How Does DataMotion for Volumes Work?
DataMotion for Volumes leverages proven NetApp SnapMirror technology for volume migration. Knowing a little bit about how the process works can help enable success. A migration occurs in three phases:
In the setup and data copy phases, the source volume continues to serve I/O requests without interruption.
Illustration of the full DataMotion for Volumes process.
In the setup phase, important prechecks are performed to make sure that the whole operation can be completed successfully. These prechecks are run each time DataMotion for Volumes is started and performed a second time when the cutover phase begins.
Prechecks verify the state of all the objects (such as source volume, source aggregate, and destination aggregate) involved in the move. If any of the prechecks are not successful, you'll be notified and the process will not start. All errors from prechecks are reported on the console and logged to the log file in the root volume of the controller (/etc/log/ndvm).
After all prechecks have successfully completed, DataMotion for Volumes:
DATA COPY PHASE
After the baseline transfer is complete, the data copy phase begins, during which successive SnapMirror updates are initiated to synchronize the destination volume with the source, which remains active. At the end of each successful SnapMirror update, DataMotion for Volumes estimates the delta lag between the two volumes. You receive a notification of this delta lag, which becomes the estimated time for the next update operation. DataMotion for Volumes remains in the data copy phase as long as the delta lag is high. When the delta lag is small, it enters the cutover phase.
The cutover phase can be either manual or automatic (the default).
Precutover. DataMotion for Volumes enters the cutover phase if the destination volume can be synchronized completely within the cutover window. The precutover phase is a transient period in which the initial prechecks mentioned above are reverified to make sure that nothing has changed and other important checks are run, including monitoring the state of the NVLOG and system CPU load.
You can set the CPU and disk threshold limit for DataMotion for Volumes. (The default is 100 for both of the following options):
Automatic Cutover. Once the precutover checks are completed, the cutover phase begins automatically. The cutover must complete within the cutover window, which is by default a maximum of 60 seconds. Once the destination volume is synchronized completely, the identity of the source volume is transferred to the destination and I/Os are then serviced from the destination.
The following processes take place during the cutover phase:
Cutover Failure. If cutover fails, DataMotion for Volumes reenters the data copy phase and tries again at a later time. By default, it makes three cutover attempts. After that, the cutover is aborted and I/O continues from the original location. User intervention is required in order for DataMotion for Volumes to continue.
Manual Cutover. In manual cutover, DataMotion for Volumes remains in the data copy phase, performing successive SnapMirror updates. It continues to estimate the time of the next SnapMirror update operation and logs this information. You should review this information before triggering a manual cutover.
Possible Use Cases
There are a variety of possible use cases in which DataMotion for Volumes makes sense.
I have heard considerable interest from users in all of these use cases, especially cases needing the ability to change media type. With the industry move from FC to SAS that's taking place, DataMotion for Volumes provides a relatively painless way to retire older media when the time comes.
I've also talked with users who believe the ability to change media type nondisruptively will allow them to be more aggressive in the deployment of SATA disk, especially in conjunction with Flash Cache performance acceleration. These users plan to deploy more applications on less-expensive SATA disk, knowing that if performance ever became an issue they could quickly migrate volumes to FC or SAS disk without disruption.
Attention to a few best practices will help enable your success with DataMotion for Volumes:
SNAPMIRROR AND SNAPVAULT
SNAPDRIVE AND SNAPMANAGER
HOST OPERATING SCSI TIME-OUT SETTINGS
NetApp recommends installing the NetApp Host Utilities Kit to avoid time-out errors. Refer to the "NetApp Host Utilities Installation and Setup Guide" for your host operating system at http://now.netapp.com/NOW/cgi-bin/software.
FLEXVOL AND FLEXCLONE
DEDUPLICATION and COMPRESSION
DataMotion for Volumes is a powerful data management tool that can increase the flexibility of your operations. Instead of having to carefully plan and initiate volume movements that can only be performed during long-planned downtimes, you can move volumes as necessary to achieve your objectives of load balancing, capacity balancing, or changing media type.
Got opinions about DataMotion for Volumes?
Ask questions, exchange ideas, and share your thoughts online in NetApp Communities.
This NetApp Community is public and open website that is indexed by search engines such as Google. Participation in the NetApp Community is voluntary. All content posted on the NetApp Community is publicly viewable and available. This includes the rich text editor which is not encrypted for https.