Technical Report

NetApp DataMotion for Volumes

Rishikesh Boddu, NetApp December 2010 | TR-3873

TABLE OF CONTENTS 1 INTRODUCTION .................................................................................................................................... 4

1.1 1.2 SCOPE ......................................................................................................................................................................4 INTENDED AUDIENCE AND ASSUMPTIONS .......................................................................................................... 4

OVERVIEW OF NETAPP DATAMOTION FOR VOLUMES.................................................................. 4

2.1 2.2 2.3 2.4 BUSINESS CHALLENGES........................................................................................................................................ 4 INTRODUCTION TO NETAPP DATAMOTION FOR VOLUMES ............................................................................... 5 DATAMOTION FOR VOLUMES SCENARIOS .......................................................................................................... 6 COMPONENTS OF DATAMOTION FOR VOLUMES ................................................................................................ 7

PHASES OF DATAMOTION FOR VOLUMES ...................................................................................... 8

3.1 3.2 3.3 SETUP PHASE .......................................................................................................................................................... 8 DATA COPY PHASE ................................................................................................................................................. 9 CUTOVER PHASE .................................................................................................................................................. 10

DATAMOTION FOR VOLUMES OPERATIONS ................................................................................. 14

4.1 4.2 DATAMOTION FOR VOLUMES DURING HIGH-PRIORITY OPERATIONS ............................................................ 14 DATAMOTION FOR VOLUMES DURING HA, UPGRADE, REVERT, AND NDU OPERATIONS ........................... 14

SUPPORTED CONFIGURATIONS ..................................................................................................... 16

5.1 5.2 5.3 5.4 5.5 HARDWARE AND SOFTWARE REQUIREMENTS ................................................................................................. 16 DISK TYPE SUPPORT ............................................................................................................................................ 16 SUPPORTED SCENARIOS ..................................................................................................................................... 17 COMPATIBILITY WITH OTHER NETAPP PRODUCTS .......................................................................................... 25 LIMITATIONS OF DATAMOTION FOR VOLUMES ................................................................................................. 27

6 7

DATAMOTION FOR VOLUMES BEST PRACTICES ......................................................................... 27 APPENDIXES....................................................................................................................................... 29

7.1 7.2 7.3 7.4 7.5 APPENDIX A: DATAMOTION FOR VOLUMES: MODES........................................................................................ 29 APPENDIX B: PAUSING DATAMOTION FOR VOLUMES...................................................................................... 34 APPENDIX C: ABORTING DATAMOTION FOR VOLUMES ................................................................................... 34 APPENDIX D: CHECKING THE STATUS OF DATAMOTION FOR VOLUMES ...................................................... 35 APPENDIX E: ENVIRONMENT VARIABLES .......................................................................................................... 35

REFERENCES ..................................................................................................................................... 35

LIST OF TABLES Table 1) Upgrade scenarios. ...................................................................................................................... 15 Table 2) Supported movement between disk types. .................................................................................. 16 Table 3) Supported DataMotion for Volumes scenarios. ............................................................................ 18 Table 4) Supported DataMotion for Volumes scenarios between RAID types. .......................................... 19

NetApp DataMotion for Volumes

Table 5) Supported DataMotion for Volumes scenarios between different drive types. ............................ 20 Table 6) Supported DataMotion for Volumes scenarios between volume types. ....................................... 21 Table 7) Supported DataMotion for Volumes scenarios between aggregate types. .................................. 22 Table 8) Supported DataMotion For Volumes in a heterogeneous environment using a V-Series system. .................................................................................................................................................................... 24 Table 10) DataMotion for Volumes support for NetApp products. .............................................................. 25

LIST OF FIGURES Figure 1) Logical view of DataMotion for Volumes. ...................................................................................... 5 Figure 2) DataMotion for Volumes between shelves. ................................................................................... 6 Figure 3) DMVol move from a highly utilized aggregate to an aggregate that has space for growth........... 7 Figure 4) SnapMirror Async mode. ............................................................................................................... 7 Figure 5) DataMotion for Volumes in setup phase. ...................................................................................... 9 Figure 6) DataMotion for Volumes in data copy phase. ............................................................................... 9 Figure 7) DataMotion for Volumes in cutover phase. ................................................................................. 11 Figure 8) Cutover failure. ............................................................................................................................ 12 Figure 9) Flow of the DataMotion for Volumes process. ............................................................................ 13 Figure 10) DataMotion for Volumes in an HA pair. ..................................................................................... 14

NetApp DataMotion for Volumes

1 INTRODUCTION
This document describes best practices for NetApp DataMotion for Volumes (DMVol).

1.1

SCOPE
Introduction to NetApp DataMotion for Volumes Components of DataMotion for Volumes When to use DataMotion for Volumes How NetApp DataMotion for Volumes works, and its phases Supported scenarios Supported hardware and software configurations Limitations of DataMotion for Volumes

This document covers the following topics:

1.2

INTENDED AUDIENCE AND ASSUMPTIONS

This report is for storage administrators, system administrators, and data center managers. It assumes basic familiarity with the following NetApp products: NetApp FAS systems, V-Series systems, and Data ONTAP operating system NetApp SnapMirror data replication solution

2 OVERVIEW OF NETAPP DATAMOTION FOR VOLUMES

2.1 BUSINESS CHALLENGES

In the past, data movement projects were scheduled to be performed during off-peak hours, but todays environment requires 24x7 availability, with no room for application downtime. It is therefore crucial for storage administrators to be able to transparently execute data movement operations without interrupting applications residing on Linux , AIX, VMware , or Microsoft Windows . NetApp DataMotion for Volumes may be required for any of the following reasons: Capacity management Load balancing Performance boosting Optimizing access to media type

Such operations assist in migrating data quickly and efficiently, while preserving data integrity.

NetApp DataMotion for Volumes

2.2

INTRODUCTION TO NETAPP DATAMOTION FOR VOLUMES

NetApp DataMotion for Volumes is a new feature introduced in Data ONTAP 8.0.1 7-Mode. DMVol can help move data nondisruptively; that is, without any application downtime. DMVol in Data ONTAP 8.0.1 7-Mode can be used to move a 7-Mode volume containing LUNs to another aggregate within the controller, providing nondisruptive volume movement for NetApp FAS and V-Series storage systems. All input/output (I/O) activity is then redirected to the moved volume. DMVol is completely nondisruptive, which means that applications accessing LUNs in the migrating volume are not required to be shut down. MANAGEMENT TOOLS DMVol in 8.0.1 7-Mode is operated through the command line by using the vol move command. This command provides the entire end-to-end workflow of DMVol for volumes that contain LUNs. It allows storage administrators to move a 7-Mode flexible volume and its LUNs to another aggregate within the same controller. The client I/O continues uninterrupted throughout the move process. It also enables invoking a dry run prior to movement, which ascertains whether the volumes satisfy all the prechecks. The process moves all volumes that contain LUNs (FCP, FCoE, or iSCSI LUNs inside), along with their Snapshot copies, their attributes, and their dataset relationships, such as backup, dump, restore, replica, mirroring, MetroCluster, and thin-provisioning settings. Note: Only one instance of vol move can be run in a controller. Log in as the root user to perform the data movement. For more information, see section 7.1, Appendix A: DataMotion for Volumes: Modes.
Figure 1) Logical view of DataMotion for Volumes.

NetApp DataMotion for Volumes

2.3

DATAMOTION FOR VOLUMES SCENARIOS

A 7-Mode volume may require the use of DMVol in the following situations: Moving Data ONTAP volumes from a performance bottleneck aggregate to a less-utilized aggregate Moving Data ONTAP volumes from an overcommitted or highly utilized aggregate to a less-utilized aggregate to balance load between aggregates Moving Data ONTAP volumes from FC or SAS disk to SATA disk or vice versa, based on the application criticality determined by end customers Moving Data ONTAP volumes from a full aggregate to an aggregate that has space for growth

DATAMOTION FOR VOLUMES BETWEEN SHELVES

In Figure 2, DMVol is employed to move data between shelves.

Figure 2) DataMotion for Volumes between shelves.

Using DMVol, you can: Move applications residing in volumes of one disk type, such as SATA, to another disk type, such as FC or SAS, to increase performance or for capacity management Move all the data from older to newer shelves to decommission older shelves Move applications based on the SLAs between SSD, FC, SAS, and SATA disk arrays for performance optimization

NetApp DataMotion for Volumes

DATAMOTION FOR VOLUMES BETWEEN AGGREGATES

In Figure 3, DMVol is employed to move data from a highly utilized aggregate to an aggregate that has space for growth.
Figure 3) DMVol move from a highly utilized aggregate to an aggregate that has space for growth.

Using DMVol, you can: Move Data ONTAP volumes from an aggregate that has been a performance bottleneck to an aggregate that has space for growth Move Data ONTAP volumes from an overcommitted aggregate to an aggregate that has space for growth to evenly balance critical applications across aggregates

2.4

COMPONENTS OF DATAMOTION FOR VOLUMES

The following combination of NetApp features are used to enable DataMotion for Volumes. NetApp SnapMirror Async Mode NetApp SnapMirror replicates data between two NetApp storage controllers. The source and destination can exist in the same data center, or each can be in a physically separate location.
Figure 4) SnapMirror Async mode.

DMVol uses asynchronous SnapMirror. Following the baseline transfer, it initiates successive SnapMirror updates to synchronize the destination volume with the source and constantly monitors the delta lag between the two volumes. The cutover phase is initiated when the delta lag between volumes is small, so that the destination volume can be fully synchronized within the cutover window.

NetApp DataMotion for Volumes

After successfully completing the move, DMVol handles the following post-cutover activities: 1. Removes the SnapMirror relationship between the source (which is now moved to the destination aggregate) and destination volumes. 2. By default, destroys the source volume, unless the user specifies otherwise by using the k option. For more information about NetApp SnapMirror, see TR-3466: SnapMirror Async Overview and Best Practices Guide.

3 PHASES OF DATAMOTION FOR VOLUMES

DataMotion for Volumes operates in three phases to complete the nondisruptive movement of a 7-Mode FlexVol volume with LUNs: 1. Setup phase 2. Data copy phase 3. Cutover phase

3.1

SETUP PHASE

In the setup phase, prechecks are performed to make sure that the whole operation can be completed successfully. These prechecks are run each time DMVol is started and when the cutover phase is entered. Some of the prechecks performed are: The source volume should not be the root volume. The destination aggregate must have adequate space to accommodate the volume to be moved. The source volume should not be exported to the NFS or CIFS client. The source volume should not have a qtree that is a SnapVault secondary. The source volume should have sufficient space for Snapshot copies created during the DMVol process. The source volume should not be a SnapMirror replica or a SnapVault destination volume. The source volume should be in the default vFiler unit (vfiler0). The source volume guarantee setting should not be set to file. The source volume should not be a FlexClone volume. The source volume should not contain compressed data.

For more information about supported configurations, see section 5. Once DMVol is initiated, the prechecks are run on the objects (such as source volume, source aggregate, and destination aggregate) involved in the move. If any of the prechecks are not successful, 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). All errors must be resolved before reinitiating DMVol. After all prechecks have successfully completed, DMVol enters the setup phase and does the following: Creates a temporary placeholder volume in the destination aggregate. using the naming convention ndm_dstvol_<timestamp>.

Triggers the baseline transfer to establish the SnapMirror relationship between the source volume and the placeholder volume. This is the longest phase, and its duration is directly proportional to the size of the source volume as the entire volume contents are transferred. Note: Do not run a SnapRestore operation on the source volume, source aggregate, or destination during migration; this can cause DMVol to abort.

NetApp DataMotion for Volumes

Figure 5) DataMotion for Volumes in setup phase.

3.2

DATA COPY PHASE

After the baseline transfer is complete, the data copy phase is invoked, during which successive SnapMirror updates are initiated to synchronize the destination volume with the source. At the end of each successful SnapMirror update, DMVol estimates the delta lag between the two volumes. This delta lag is notified as the estimated time for the next update operation by an EMS message, which is also logged to the console. DMVol remains in the data copy phase as long as the delta lag is high. Conversely, if the delta lag is small, it enters the cutover phase, so that the delta can be applied at the destination volume within the cutover window to synchronize the destination volume completely with the source volume. In both the setup and data copy phases, the source volume serves I/Os without being interrupted. Further, execution by the end user of any conflicting operations (mentioned in section 3.1, "Setup Phase") aborts the process. The error is reported as an EMS message and is also logged to the console.
Figure 6) DataMotion for Volumes in data copy phase.

The frequency and duration of each update depend on the rate of change of data, which corresponds to write (I/O) on the LUNs in the source volume. If the rate is small, the duration of each update is small, and

NetApp DataMotion for Volumes

therefore fewer updates are required to synchronize the placeholder destination volume. During the DMVol operation, the destination volume is read-only and the LUNs are unmapped. The status of each update is logged as an EMS message, which is also logged to the console and to the log file (/etc/log/ndvm).

3.3

CUTOVER PHASE

PRECUTOVER PHASE

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 phase before the cutover phase, in which it is determined that all the objects involved in DMVol and the system environment are favorable for cutover. In addition to the prechecks mentioned in section 3.1, the following are verified during the precutover phase. Long-running operations such as SIS, SIS clone, dump, restore, SnapVault restore, and Vol Copy are not running on the source volume. NVLOG is less than 90% full. System CPU and disk utilization are below the threshold limit. If they exceed the threshold limit, the cutover is aborted and the data copy phase is resumed, which triggers successive SnapMirror updates.

Data ONTAP 8.0.1 7-Mode has the option to set the threshold limit for DMVol. The limit is 100 by default for both of the following options: vol.move.cutover.cpu.busy.limit vol.move.cutover.disk.busy.limit

The cutover phase is the final and most critical phase of the DMVol process. Once the destination volume is synchronized completely, the identity of the source volume is transferred to the destination; as a result, I/Os are serviced from the migrated volume at the destination. The cutover must complete within the cutover window, which is by default 60 seconds and corresponds to the SCSI timeout interval for most host initiators. By default, the cutover phase starts automatically unless it is specified to be manually triggered.
MANUAL CUTOVER

DataMotion for Volumes offers an option to do manual cutover by disabling the default automatic cutover. In manual cutover, DMVol continues in the data copy phase, performing successive SnapMirror updates and without monitoring the delta lag between the two volumes. However, it estimates the time for the next SnapMirror update operation and logs this to the EMS and the console. Note: Examine the past estimated times before explicitly triggering cutover. As with automatic cutover, manual cutover also performs prechecks before executing the cutover. Prechecks can be disabled by turning off the following registry option: options.vol.move.cutover.manual.precheck.enable

10

NetApp DataMotion for Volumes

SUCCESSFUL CUTOVER

Figure 7 depicts a successful cutover.

Figure 7) DataMotion for Volumes in cutover phase.

The following processes take place during the cutover phase: All LUNs in the source volume are in a suspended I/O (quiesced) state. The quiesced state prevents new I/Os from being scheduled on the LUNs, and it drains pending I/Os on the LUNs. Any new I/O post-LUN quiesce is simply dropped and no response is sent to the initiator. The source volume is quiesced. The volume quiesce fails new commands on the volume with busy status and drains pending commands on the volume. As part of the quiesce operation, WAFL captures the final delta lag in a Snapshot copy, which is named according to the convention ndvm_final_<timestamp>. The destination volume is then synchronized completely with the source volume with the delta from ndvm_final_<timestamp>. This is the last SnapMirror update between the two volumes before servicing the I/O from the destination volume. The placeholder volume is stamped with the name and file system ID (FSID) of the source volume, and vice versa; that is, the identities of the source and placeholder volumes are swapped. The migrated volume at the destination is brought online with the identity of the original source volume and the LUNs are unquiesced. This effectively exposes the LUNs at destinations that are ready to accept user I/O; that is, the LUNs are in an online and mapped state. The source volume is deleted (unless the user specifies retaining it). If the source volume is retained, DMVol renames the volume as <source volume name>_old_<timestamp>, where <timestamp> is the current time of the controller. The ndvm_final_<timestamp> Snapshot copy is retained in the moved volume at the destination. This is the final Snapshot copy of the original source volume before cutover.

Note: The source volumes clones are not moved. If the user chooses to move a source volume that has been deduplicated or compressed, the fingerprint database and change logs are not moved.

11

NetApp DataMotion for Volumes

IMPACT ON APPLICATIONS DURING DATAMOTION FOR VOLUMES

iSCSI and FCP clients experience up to a 60-second pause in I/O.

CUTOVER FAILURE

If the cutover is not completed within the default 60-second window, the DMVol process aborts and reenters the data copy phase. The user is notified by an EMS message about the failure, which is also logged to the console. By default, DMVol makes three cutover attempts. If cutover is not successfully completed in three attempts, then the move is paused and an error is logged as an EMS message and to the console as well. User intervention is required to resume the move operation. Cutover defaults: Cutover attempts: 3 Cutover window: 60 seconds

Figure 8) Cutover failure.

DMVol works in the recommended automated mode for cutover. If you choose to trigger a manual cutover, its best to invoke it during minimal load on the system to avoid any problems. The cutover forbids CLI, Manage ONTAP , scheduled tasks, and other operations on the source volume. Some of these operations are Snapshot copy creation, file or LUN FlexClone creation, and SnapMirror or SnapVault updates. The fencing means that there is no change of state of volume or its attributes during cutover. The fencing operation continues until cutover is complete.

12

NetApp DataMotion for Volumes

Figure 9 illustrates an overview of the DMVol process.

Figure 9) Flow of the DataMotion for Volumes process.

13

NetApp DataMotion for Volumes

4 DATAMOTION FOR VOLUMES OPERATIONS

4.1 DATAMOTION FOR VOLUMES DURING HIGH-PRIORITY OPERATIONS

High-priority operations include forced or negotiated takeover (TO), forced or negotiated giveback (GB), controller halt, and reboot. DMVol is not affected during these operations. As long as the motion is not in cutover phase, high-priority operations have no impact on DMVol. Upon boot, DMVol is automatically resumed and continues from the previous consistent checkpoint of SnapMirror. Data availability may be delayed if TO or GB or controller halt or reboot coincides with the cutover; that is, the data availability is controlled directly by the boot time. In any case, TO and GB operations either service the I/O from the source volume (if cutover did not complete at the time of TO or GB), or from the destination volume (if the cutover was successful).

4.2

DATAMOTION FOR VOLUMES DURING HA, UPGRADE, REVERT, AND NDU OPERATIONS

DATAMOTION FOR VOLUMES IN AN HA PAIR

Data ONTAP 8.0.1 7-Mode supports one instance of DMVol running within a controller. Therefore, in an HA pair, there can be a maximum of two instances running in the controllers. During takeover mode, the active node can run two instances of the DMVol operation.
Figure 10) DataMotion for Volumes in an HA pair.

14

NetApp DataMotion for Volumes

UPGRADE OPERATIONS

DataMotion for Volumes does not support data movement for releases prior to Data ONTAP 8.0.1 7Mode; to use this feature, you must upgrade to Data ONTAP 8.0.1 7-Mode. In an HA pair, both nodes should have Data ONTAP 8.0.1 7-Mode to successfully move the data during TO or GB. The configuration file for DMVol resides in the root volume of the controller as the ndm.config file.
Table 1) Upgrade scenarios.

Data ONTAP Version on Node A

8.0

Data ONTAP Version on Support for DataMotion for Volumes Node B

8.0 Not supported DMVol can be initiated on node A. 1. If node B takes over node A, the ndm.config file will be deleted from node A. 2. If node B gives back node A, DMVol will not start because the ndm.config file has been deleted due to takeover. 3. In both cases, user intervention is required to do a cleanup on node A.

8.0.1

8.0

8.0.1

8.0.1

DMVol can be initiated on both the nodes simultaneously. 1. 2. DMVol can be initiated on node A. If node B takes over node A, then the ndm.config file will not be deleted. The user must give back node A to restart the DMVol operation.

8.0.1

7.x

REVERT OPERATIONS

If you choose to revert to a release prior to Data ONTAP 8.0.1 7-Mode, the operation will not succeed if DMVol is active (paused or running); the appropriate EMS message is logged in the console. For a successful revert operation, first abort; or, if the DMVol process is in the cutover state, wait until it is completed successfully. A successful revert operation deletes all configuration files that pertain to DMVol.
NONDISRUPTIVE UPGRADE

Nondisruptive upgrade (NDU) is prohibited if DMVol is active or running. It must be paused or aborted before attempting an NDU.

15

NetApp DataMotion for Volumes

5 SUPPORTED CONFIGURATIONS
5.1 HARDWARE AND SOFTWARE REQUIREMENTS

HARDWARE NetApp FAS2040, FAS3040/3070, FAS31X0, FAS32X0,FAS60X0, and FAS62X0 systems NetApp V-Series V3040/3070, V31X0, V32X0,V60X0, and V62X0 systems

SOFTWARE Data ONTAP 8.0.1 7-Mode or later Supported protocols FCP or iSCSI No CIFS or NFS support at this time FCP, iSCSI

Data ONTAP licenses

5.2

DISK TYPE SUPPORT

DataMotion for Volumes supports data movement between the disk types shown in Table 2.
Table 2) Supported movement between disk types.

Source Aggregate Disk Type

SATA ATA SAS SSD FC SATA SATA SATA SATA ATA ATA ATA ATA SAS

Destination Aggregate Disk Type

SATA ATA SAS SSD FC ATA SAS SSD FC SAS SSD FC SATA SSD

16

NetApp DataMotion for Volumes

Source Aggregate Disk Type

SAS

Destination Aggregate Disk Type

FC

SAS SAS SSD SSD SSD SSD FC FC FC FC

For V-Series Systems

SATA ATA FC SATA ATA SSD SATA ATA SSD SAS

Third-party storage array Native disk shelves Native disk shelves

Native disk shelves Third-party storage array Native disk shelves

5.3

SUPPORTED SCENARIOS
For the current release, Data ONTAP 8.0.1 7-Mode, DMVol is a controller-based solution, which means that the DMVol process is within the controller between aggregates. DMVol does not allow any data movement between controllers in an HA pair or across the controllers of an HA pair. DMVol does not support data movement between two individual controllers.

17

NetApp DataMotion for Volumes

Table 3) Supported DataMotion for Volumes scenarios.

Movement Scenario

Description

Supported?

Within controller

Yes

Between HA pairs

No

Across controllers

No

18

NetApp DataMotion for Volumes

Movement Scenario

Description

Supported?

Across HA pairs

No

DATAMOTION FOR VOLUMES BETWEEN DIFFERENT RAID TYPES DMVol supports NetApp RAID-DP , RAID 0, and RAID 4.
Table 4) Supported DataMotion for Volumes scenarios between RAID types.

Movement Scenario

Description

Supported?

Between RAID-DP and RAID 4

Yes

Between RAID 4 and RAID-DP

Yes

19

NetApp DataMotion for Volumes

Movement Scenario

Description

Supported?

Between same RAID types

Yes

Between RAID 0 in V-Series system

Yes

DATAMOTION FOR VOLUMES BETWEEN ALL DRIVE TYPES

Table 5) Supported DataMotion for Volumes scenarios between different drive types.

Movement Scenario

Description

Supported?

Between different drives and speeds

Yes

20

NetApp DataMotion for Volumes

Movement Scenario

Description

Supported?

Between same drives and speeds

Yes

DATAMOTION FOR VOLUMES BETWEEN VOLUME TYPES DMVol supports movement between volumes that contain LUNs within the controller.
Table 6) Supported DataMotion for Volumes scenarios between volume types.

Movement Scenario

Description

Supported?

Between volumes with LUNs

Yes

Between NAS volumes

No

Between FlexClone volumes

No

21

NetApp DataMotion for Volumes

Movement Scenario

Description

Supported?

Source child clones are not moved

No

Between traditional volumes

No

DATAMOTION FOR VOLUMES BETWEEN AGGREGATE TYPES DMVol supports 32-bit and 64-bit aggregate types.
Table 7) Supported DataMotion for Volumes scenarios between aggregate types.

Movement Scenario

Description

Supported?

Between same aggregate types

Yes

Between 32-bit and 64-bit aggregates

No

22

NetApp DataMotion for Volumes

Movement Scenario

Description

Supported?

Between same aggregate types

Yes

Between 64-bit and 32-bit aggregates

No

23

NetApp DataMotion for Volumes

DATAMOTION FOR VOLUMES IN A HETEROGENEOUS ENVIRONMENT NetApp DataMotion for Volumes, introduced in Data ONTAP 8.0.1 7-Mode, is interoperable with thirdparty arrays by using a V-Series system.
Table 8) Supported DataMotion For Volumes in a heterogeneous environment using a V-Series system.

Movement Scenario

Description

Supported?

Between native disk shelves and third-party storage array

Yes

Between third-party storage arrays

Yes

Between native disk shelves

Yes

24

NetApp DataMotion for Volumes

For more information about V-series support for third-party arrays, see http://now.netapp.com/NOW/knowledge/docs/V-Series/supportmatrix/. Using DMVol on a V-Series system, you can: Move Data ONTAP volumes between aggregates Move all data from one aggregate to another aggregate; for example, before decommissioning a third-party storage array Move applications between aggregates on native disk shelves and aggregates on third-party storage arrays, based on SLAs

5.4

COMPATIBILITY WITH OTHER NETAPP PRODUCTS

Table 10 shows the compatibility of various NetApp technologies with DataMotion for Volumes.
Table 10) DataMotion for Volumes support for NetApp products.

NetApp Product

Supported for DataMotion for Volumes?

Yes

Comments

7-Mode Flexible Volumes

Data ONTAP 8.0.1 supports DMVol for 7-Mode flexible volumes.

Thin-Provisioned Volumes Flexible Volumes Flexible Volumes with FlexClone Volumes

Yes Yes Partial DMVol will not move FlexClone volumes to the destination volume (see section 6, "Data Motion for Volumes Best Practices").

Fabric MetroCluster Qtree SnapMirror

Yes Yes The source volume should not be the qtree SnapMirror destination; the operation is fenced during the DMVol cutover process. The source volume should not be the SnapVault destination; the operation is fenced during the DMVol cutover process. The source volume should not be the SnapMirror destination; the operation is fenced during the DMVol cutover process. DMVol does not support SnapLock volumes.

SnapVault Volumes

Yes

Volume SnapMirror Async

Yes

SnapLock Compliance, SnapLock Enterprise FlexCache SyncMirror

No

No Yes

DMVol does not support FlexCache volumes. The operation is fenced during the DMVol cutover process.

25

NetApp DataMotion for Volumes

NetApp Product

Supported for DataMotion for Volumes?

No

Comments

Operations Manager

No integration presently; Operations Manager does not provide any interface to operate the DMVol process. DMVol does not support NAS-CIFS or NFS volumes. DMVol will not move the fingerprint DB and change logs of a deduplicated volume to the destination. NDMP or DUMP must not start when DMVol operation is in cutover mode. The running sets of the source volume that is cached in the PAM card will no longer be valid because after DMVol, deswizzle rewriting of the PVBNs on the destination volume will start; the working set needs to be populated againthe PAM needs to be "warmed up." SnapDrive for UNIX uses volume names to connect the LUN, and DMVol retains the same source name after data movement. Do not attempt or mandate LUN restore while connecting to LUNs after cutover. No integration presently; SnapManager does not provide any interface to operate DMVol. No integration presently; SnapManager does not provide any interface to operate DMVol. No integration presently; SnapManager does not provide any interface to operate DMVol. No integration presently; SnapManager does not provide any interface to operate DMVol. No integration presently; SnapManager does not provide any interface to operate DMVol.

NAS Volumes

No

Deduplication

Partial

NDMP, DUMP

Yes

PAM I Flash Cache (PAM II)

No No

SnapDrive for UNIX or Linux v4.x

Yes

SnapDrive for Windows v 6.1.1 SnapManager for Oracle 3.0.3 SnapManager for SAP 3.0.3

Yes

No

No

SnapManager 5.0 Microsoft Exchange SnapManager 5.0R1 Microsoft SQL Server SnapManager 2.0 for Microsoft Office SharePoint

No

No

No

26

NetApp DataMotion for Volumes

5.5

LIMITATIONS OF DATAMOTION FOR VOLUMES

Data ONTAP 8.0.1 7-Mode has the following limitations on DataMotion for Volumes. DMVol cannot be performed on: NAS volumes (volumes that have been NFS or CIFS exported). An offline volume. Traditional volumes, FlexClone volumes, individual LUNs, and root volumes. Volumes that have the guarantee set as file. Volumes between controllers in an HA pair or across an HA pair. SnapMirror destination volumes. SnapLock volumes and FlexCache volumes. Source volumes that have a qtree, that is, a SnapVault secondary. Fingerprint databases and change logs of a deduplicated volume. Volumes that do not reside in the default vfiler0 (pfiler) unit. Individual LUNs or volumes that are being accessed via FTP, SFTP, or HTTP. Between 32-bit aggregate and 64-bit aggregates.

6 DATAMOTION FOR VOLUMES BEST PRACTICES

NetApp recommends not running vol rename or changing volume attribute settings and LUN attribute settings in the source volume during the DMVol operation. Do not start any conflicting operations until the DMVol operation is complete. If any operation starts when the process is not in the cutover phase, DMVol initiates an abort. In the cutover state, DMVol fences all storage administrator operations. DMVol offers threshold options to set the system CPU and disk utilization limits for entering the cutover phase. For every update in the data copy phase, it calculates the percentage of average CPU utilization and maximum disk utilization. Before starting cutover, DMVol compares the systems current CPU and disk utilization with these threshold values. If the threshold values are exceeded, it will not start the cutover state. By default, the values of these parameters are 100. These options are vol.move.cutover.cpu.busy.limit vol.move.cutover.disk.busy.limit. These threshold options are visible and can be adjusted by a storage administrator based on the system load. NetApp recommends that the CPU and disk utilization be kept below 50% to complete the cutover smoothly. By default, manual cutover reruns a precheck every time it is invoked. To disable this option, set options.vol.move.cutover.manual.precheck.disable. NetApp recommends not changing the default behavior, because it provides the advantage of rechecking the system settings. If you made any changes to the source volume, the system prevents DMVol from starting the cutover state and logs the error on the console as an EMS message. To maintain data integrity, initiate a pause before a manual reboot or halt is triggered by the user. In an HA pair, always make sure that both nodes are running Data ONTAP 8.0.1 7-Mode to have a successful DMVol during graceful or system-initiated takeover or giveback. Be sure to check the system health and load before you initiate DMVol.

27

NetApp DataMotion for Volumes

DMVol is a controller-based solution. It's not necessary to install any host-based software or to change host and switch configuration settings. If manual cutover is initiated, NetApp recommends examining the delta lag between the two volumes before triggering cutover. Also check the load and utilization of the system. To prevent interference with cutover, NetApp recommends not scheduling long-running operations such as SIS, SIS clone, DUMP, restore, Vol Copy, LUN clone split, NDMP copy, and SnapVault restore during the DMVol process. Do not change any configuration for the source volume or SnapMirror, such as the snapmirror.conf file.

SNAPMIRROR AND SNAPVAULT

If DMVol has not reached the cutover state, SnapMirror or SnapVault updates will be successful. If an update occurs during the cutover phase, the transfers may not succeed because cutover fences the operation. After cutover is complete, the transfer will succeed on the next update. In case of a manual cutover, NetApp recommends doing the cutover when no updates or transfers are in progress.

SNAPDRIVE AND SNAPMANAGER

During cutover: LUN provisioning and Snapshot copy management operations in SnapDrive for Windows (SDW) will be unsuccessful. Any backup and restore operations will be unsuccessful for SnapManager products (SME, SMSQL, SMVI, SMHV, SMO, SMSAP, and SMOSS) that are on top of SDW. The next scheduled backup job will succeed.

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

DMVol partially supports the movement of FlexVol, which has child clones. DMVol moves only the source FlexVol volume; FlexClone volumes are not moved. After DMVol is complete, the original FlexVol volume is retained in an offline state and the child-parent relationship is untouched. The FlexClone volume must be split from the parent FlexVol volume before moving the FlexClone volume. DEDUPLICATION DMVol does not move the fingerprint database and change logs of a deduplicated FlexVol volume. Similarly, compressed volumes cannot be moved. If deduplication is active on the source FlexVol volume, then it must be stopped for a successful cutover. However, after the DMVol process is complete, users must execute sis start -s to rebuild the fingerprint DB at the destination.

28

NetApp DataMotion for Volumes

7 APPENDIXES
7.1 APPENDIX A: DATAMOTION FOR VOLUMES: MODES

DataMotion for Volumes moves a Data ONTAP volume nondisruptively between aggregates within a controller. Clients can continue to access the data inside the LUNs during the process. Data ONTAP 8.0.1 7-Mode can operate the DMVol cutover phase in two modes: automatic and manual. A dry run of the DMVol operation checks whether the source volume meets all of the supported requirements and logs on the console any conflicting settings that might prevent DMVol operations. If the dry run completes with no errors, then it is safe to initiate the process. The vol move command is used to trigger DataMotion for Volumes. 1. To run DMVol: Before initiation, make sure that it satisfies all requirements. 2. Initiate a dry run to avoid any conflicting settings. 3. Initiate DataMotion for Volumes. 4. Check the status of the DMVol process. 5. After DMVol is complete, recheck the status of the volume and the mapped LUN.
AUTOMATIC DATAMOTION FOR VOLUMES

DMVol with deletion of the source volume In this example, volume test1 in source aggregate aggr1 is moved to the destination aggregate aggr2 within the controller. After the successful move, the source volume is destroyed and the destination aggregate contains the source volume test1 to serve I/Os. 1. Make sure that the source volume is online and mapped to the server:
f3070-237-102> vol status test1 Volume State Status Options test1 online raid_dp, flex Volume UUID: 2b06ef18-b66b-11df-984e-00a0980b4b83 Containing aggregate: 'aggr1' f3070-237-102> lun show -v /vol/test1/lun001 /vol/test1/lun001 49g (80530636800) (r/w, online, mapped) Serial#: Hn/6L4Y4KyBe Share: none Space Reservation: enabled Multiprotocol Type: linux Maps: Linux_Server=9 Occupied Size: 30.8g (33058717696) Creation Time: Mon Jul 26 03:40:04 EDT 2010 Cluster Shared Volume Information: 0x0

2. Make sure that the destination aggregate aggr2 has adequate space for the volume to be moved. 3. Initiate a dry run to check the configuration:
vol move start <srcvol> <dstaggr> -d

The -d switch initiates the dry run.

f3070-237-102> vol move start test1 aggr2 -d vol move: Specified source volume is present in /etc/exports. If vol move is to run/continue on this source volume, then its corresponding entry needs to be removed from /etc/exports.

29

NetApp DataMotion for Volumes

Check the error in the console and resolve the same before proceeding further, above example shows that the source volume is NFS exported and the entry needs to be removed

4. After error resolution, initiate the DMVol process:

vol move start <srcvol> <dstaggr>

This initiates DataMotion for Volumes with default cutover attempts and a cutover window.
f3070-237-102> vol move start test1 aggr2 f3070-237-102: vol.move.Start:info]: Move of volume test1 to aggr aggr2 started. f3070-237-102: DBG: Assigning uuid '49ccb348-b66a-11df-984e-00a0980b4b83' to new flexible volume 'ndm_dstvol_1283242546' (FSID 0x18621ae) [wafl.scan.start:info]: DBG: Starting active bitmap rearrangement on volume ndm_dstvol_1283242546. Creation of volume 'ndm_dstvol_1283242546' with size 53687091200 on containing aggregate 'aggr2' has completed. Volume 'ndm_dstvol_1283242546' is now restricted. [vol.move.transferStart:info]: Baseline transfer from volume test1 to ndm_dstvol_1283242546 started. Transfer started. Monitor progress with 'snapmirror status' or the snapmirror log. [wafl.scan.start:info]: DBG: Starting volume deswizzling on volume ndm_dstvol_1283242546. [vol.move.transferStatus:info]: Baseline transfer from volume test1 to ndm_dstvol_1283242546 took 56 secs and transferred 2838080 KB data.

5. Check the status of the destination aggregate aggr2. A temporary read-only destination volume is created to initiate the baseline transfer:
f3070-237-102> aggr status -v aggr2 Aggr State Status aggr2 online raid4, aggr 32-bit Options nosnap=off, raidtype=raid4, raidsize=7, ignore_inconsistent=off, snapmirrored=off, resyncsnaptime=60, fs_size_fixed=off, snapshot_autodelete=on, lost_write_protect=on, ha_policy=cfo

Volumes: ndm_dstvol_1283242546.

6. Check the status of the DMVol process:

vol move status <srcvol> -v verbose f3070-237-102> vol move status test1 Source Destination CO Attempts test1 aggr2 3

CO Time 60

State setup

f3070-237-102> vol move status -v test1 Source: test1 Destination: aggr2:ndm_dstvol_1283242546 State: setup Cutover Attempts: 3 Cutover Time: 60 Last Completed Transfer: Data Transferred = 0 KB Time Taken = 0 s Current Transfer Size = 0 KB

7. Check the status of the baseline transfer:

f3070-237-102> snapmirror status

30

NetApp DataMotion for Volumes

Snapmirror is on. Source Destination 127.0.0.1:test1 f3070-237-102:ndm_dstvol_1283242546 Status Transferring (1268 MB done)

State Uninitialized

Lag -

8. Check the status of DataMotion for Volumes:

f3070-237-102> vol move status test1 Source Destination CO Attempts CO Time State test1 aggr2 3 60 move f3070-237-102> vol move status -v Source: test1 Destination: aggr2:ndm_dstvol_1283242546 State: move Cutover Attempts: 3 Cutover Time: 60 Last Completed Transfer: Data Transferred = 2 GB Time Taken = 56 s Current Transfer Size = 200 KB

This shows that DMVol is in the second phase (data copy), in which successive SnapMirror updates are going on in order to synchronize with the source volume test1. When the delta lag between the two volumes is small enough to fully synchronize within the cutover window, the move enters the cutover phase.

f3070-237-102> f3070-237-102: vol.move.cutoverStart:info]: Cutover started for nondisruptive move of volume test1 to aggr aggr2. f3070-237-102> vol move status test1 Source Destination CO Attempts test1 aggr2 3

CO Time 60

State cutover

f3070-237-102> vol move status -v test1 Source: test1 Destination: aggr2:ndm_dstvol_1283242546 State: cutover Cutover Attempts: 3 Cutover Time: 60 Last Completed Transfer: Data Transferred = 3 MB Time Taken = 4 s Current Transfer Size = 0 KB

The cutover completes within the cutover window of 60 seconds. If it does not, then the process moves back to the data copy phase and continues successive SnapMirror updates. By default, DMVol makes three attempts to complete the move within the cutover window before pausing the process.

[vol.move.cutoverStart:info]: Cutover started for vol move of volume test1 to aggr aggr2. Transfer started. Monitor progress with 'snapmirror status' or the snapmirror log. [wafl.scan.start:info]: DBG: Starting active bitmap rearrangement on volume test1. [wafl.scan.start:info]: DBG: Starting volume deswizzling on volume test1. [vol.move.cutoverEnd:info]: Cutover finished for vol move of volume test1 to aggregate aggr2 - time taken 10 secs. wafl.vvol.destroyed:info]: Volume ndm_dstvol_1283242546 destroyed. Volume 'ndm_dstvol_1283242546' destroyed. [vol.move.End:info]: Successfully completed move of volume test1 to aggr aggr2. [wafl.scan.ownblocks.done:info]: Completed block ownership calculation on volume test1.

31

NetApp DataMotion for Volumes

9. When DMVol is complete, the destination aggregate contains the moved volume. To check the destination aggregate status, enter:
f3070-237-102> aggr status -v aggr2 Aggr State Status aggr2 online raid4, aggr 32-bit Options nosnap=off, raidtype=raid4, raidsize=7, ignore_inconsistent=off, snapmirrored=off, resyncsnaptime=60, fs_size_fixed=off, snapshot_autodelete=on, lost_write_protect=on, ha_policy=cfo

Volumes: test1

10. Recheck all LUN status, attributes, volume options, and Snapshot copies.

DMVol keeping the source volume intact In this example, the volume test1 is moved to the destination aggregate aggr2. After successful completion of the DMVol operation, the source aggregate retains the source volume by renaming it <source vol>_old_<timestamp> (if the user wants to keep the source volume intact). 1. Repeat steps 1 through 3 from the previous section, "DMVol with deletion of the source volume." 2. Move the source volume test1 from the aggr1 aggregate to the destination aggr2 aggregate:
vol move start <source volume> <destination aggr> -k

Use the -k switch to keep the source volume intact after DMVol is complete. 3. Repeat steps 5 through 8 from the previous section, "DMVol with deletion of the source volume." 4. After successful completion of the DMVol process, check the status of the source aggregate and the destination aggregate. The source volume is offline and renamed as shown below. Source aggregate status:
f3070-237-102> aggr status -v aggr1 Aggr State Status aggr1 online raid4, aggr 32-bit Options nosnap=off, raidtype=raid4, raidsize=7, ignore_inconsistent=off, snapmirrored=off, resyncsnaptime=60, fs_size_fixed=off, snapshot_autodelete=on, lost_write_protect=on, ha_policy=cfo

Volumes: test1_old_1280213958

Destination aggregate status:

f3070-237-102> aggr status -v aggr2 Aggr State Status aggr2 online raid4, aggr 32-bit Options nosnap=off, raidtype=raid4, raidsize=7, ignore_inconsistent=off,

32

NetApp DataMotion for Volumes

snapmirrored=off, resyncsnaptime=60, fs_size_fixed=off, snapshot_autodelete=on, lost_write_protect=on, ha_policy=cfo Volumes: test1

MANUAL DATAMOTION FOR VOLUMES

In Data ONTAP 8.0.1 7-Mode, the vol move command provides an option to disable the default behavior of the automatic cutover. By disabling the automatic cutover, DMVol continues to be in the data copy phase. DataMotion for Volumes with manual cutover In this example, the volume test1 in aggr1 is moved to the destination aggregate aggr2 using manual cutover. 1. Repeat steps 1 through 3 from the earlier section "DMVol with deletion of the source volume." 2. Initiate DMVol with a manual cutover:
vol move start <srcvol> <dstaggr> -m

Use -m to initiate the DMVol process for a manual cutover. Append -k to keep the source volume intact after the DMVol operation, if desired.
f3070-237-102*> vol move start test1 aggr2 -m f3070-237-102: vol.move.Start:info]: Move of volume test1 to aggr aggr2 started. DBG: Assigning uuid '49ccb348-b66a-11df-984e-00a0980b4b83' to new flexible volume 'ndm_dstvol_1283242546' (FSID 0x18621ae) [wafl.scan.start:info]: DBG: Starting active bitmap rearrangement on volume ndm_dstvol_1283242546. Creation of volume 'ndm_dstvol_1283242546' with size 53687091200 on containing aggregate 'aggr2' has completed. Volume 'ndm_dstvol_1283242546' is now restricted. [vol.move.transferStart:info]: Baseline transfer from volume test1 to ndm_dstvol_1283242546 started. Transfer started. Monitor progress with 'snapmirror status' or the snapmirror log. [wafl.scan.start:info]: DBG: Starting volume deswizzling on volume ndm_dstvol_1283242546. [vol.move.transferStatus:info]: Baseline transfer from volume test1 to ndm_dstvol_1283242546 took 56 secs and transferred 2838080 KB data. f3070-237-102*> vol move status test1 Source Destination CO Attempts test1 aggr2 NA

CO Time 60

State setup

The cutover attempts are labeled NA (not applicable) because the move operation will continue to be in data copy phase until a manual cutover is triggered by the user. 3. Check the present state of the DMVol process. 4. Initiate a manual cutover of volume test1:
vol move cutover <srcvol> -w <cutover window> f3070-237-102> vol move cutover test1 w 60

33

NetApp DataMotion for Volumes

[vol.move.cutoverStart:info]: Cutover started for vol move of volume test1 to aggr aggr2. Transfer started. Monitor progress with 'snapmirror status' or the snapmirror log. [wafl.scan.start:info]: DBG: Starting active bitmap rearrangement on volume test1. [wafl.scan.start:info]: DBG: Starting volume deswizzling on volume test1. [vol.move.cutoverEnd:info]: Cutover finished for vol move of volume test1 to aggregate aggr2 - time taken 10 secs. wafl.vvol.destroyed:info]: Volume ndm_dstvol_1283242546 destroyed. Volume 'ndm_dstvol_1283242546' destroyed. [vol.move.End:info]: Successfully completed move of volume test1 to aggr aggr2. [wafl.scan.ownblocks.done:info]: Completed block ownership calculation on volume test1.

5.

Check the status of the volume. Also check that the LUNs are mapped correctly.

7.2

APPENDIX B: PAUSING DATAMOTION FOR VOLUMES

The DMVol process can be paused at any time during the setup and data copy phases:
vol move pause <srcvol>

The following example shows initiating a pause for the test1 volume:
f3070-237-102> vol move pause test1 [vol.move.paused:info]: Move of volume test1 to aggregate aggr2 paused : User initiated

Resume the DMVol process in either automatic or manual cutover mode: -m: Switches DMVol from automatic to manual cutover. -r: Switches DMVol from manual to automatic cutover. -k: Resumes DMVol by keeping the source volume intact.

The syntax is:

vol move resume srcvol [-k] [-m | -r num_cutover_attempts] [-w cutover_window] [-o]

7.3

APPENDIX C: ABORTING DATAMOTION FOR VOLUMES

The following command aborts the DMVol operation:

vol move abort <srcvol>

This example shows canceling of the DMVol operation for the test1volume:
f3070-237-102> vol move abort test1 [replication.dst.err:error]: SnapMirror: destination transfer from 127.0.0.1:test1 to ndm_dstvol_1283245439 : replication transfer failed to complete. [replication.src.err:error]: SnapMirror: source transfer from test1 to f3070-237102:ndm_dstvol_1283245439 : transfer failed. [vol.move.abortStart:info]: Aborting move of volume test1 to aggregate aggr2 : User initiated. [wafl.vvol.offline:info]: Volume 'ndm_dstvol_1283245439' has been set temporarily offline [wafl.vvol.destroyed:info]: Volume ndm_dstvol_1283245439 destroyed. Volume 'ndm_dstvol_1283245439' destroyed. [vol.move.abortEnd:info]: Aborted move of volume test1 to aggregate aggr2. [wafl.scan.ownblocks.done:info]: Completed block ownership calculation on volume test1.

34

NetApp DataMotion for Volumes

7.4

APPENDIX D: CHECKING THE STATUS OF DATAMOTION FOR VOLUMES

To check or monitor the status of DMVol: vol move status <srcvol> -v

7.5

APPENDIX E: ENVIRONMENT VARIABLES

Data ONTAP 8.0.1 7-Mode has the following DMVol environment variables: ndm-no-initialize If set to true, disables DMVol from the system. To reenable this, reset the variable and restart the system. ndm-no-restart If set to true, prevents DMVol from resuming automatically after a reboot, takeover, or giveback. If there is an active DMVol instance, the system pauses the process. You may need to resume the operation to complete the process.

8 REFERENCES
SnapMirror Async Overview and Best Practices Guide http://www.netapp.com/us/library/technical-reports/tr-3446.html Nondisruptive Operations Community http://communities.netapp.com/groups/non-disruptive-operations

35

NetApp DataMotion for Volumes

NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customers responsibility and depends on the customers ability to evaluate and integrate them into the customers operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.
Copyright 2010 NetApp, Inc. All rights reserved. No portions of this document may be reproduced without prior written consent of NetApp, Inc. Specifications are subject to change without notice. NetApp, the NetApp logo, Go further, faster, Data ONTAP, FlexCache, FlexClone, FlexVol, Manage ONTAP, MetroCluster, RAID-DP, SnapDrive, SnapLock, SnapManager, SnapMirror, SnapRestore, Snapshot, SnapVault, SyncMirror, vFiler, and WAFL are trademarks or registered trademarks of NetApp, Inc. in the United States and/or other countries. Linux is a registered trademark of Linus Torvalds. Microsoft, SharePoint, SQL Server, and Windows are registered trademarks of Microsoft Corporation. Oracle is a registered trademark of Oracle Corporation. SAP is a registered trademark of SAP AG. UNIX is a registered trademark of The Open Group. VMware is a registered trademark of VMware, NetApp DataMotion forAll Volumes Inc. other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such. TR-3873-1010

36