Migrating a vFiler unit between clustered nodes with SnapMover

When to use this section

You should read this section and perform the instructions provided in this section if you want to migrate a vFiler unit without copying its data from a physical storage system (source) to another physical storage system (destination).

What SnapMover vFiler unit migration on clustered nodes is

SnapMover vFiler unit migration on clustered nodes is the no-copy transfer of a traditional volume-level vFiler unit from one host node to the other. For example, if heavy traffic to one vFiler unit is affecting the performance of its host node, and the other cluster node is lightly loaded, you can transfer ownership of that vFiler unit to the host node's cluster partner to balance the load processing on the two nodes.

The SnapMover feature uses software-based disk ownership to transfer ownership of the physical volume that contains the vFiler unit from the original host node to its partner. Because the SnapMover feature carries out the vFiler unit migration through transfer of disk ownership rather than by copying data from one set of disks to another, the migration operation is quickly completed.

Requirements for vFiler unit migration on clustered nodes

Before you use SnapMover to migrate a vFiler unit between clustered nodes, make sure the following are true:

The following licenses must be installed on each clustered node:
- MultiStore
- SnapMover
Other licenses used by the vFiler unit need to match. For example, if CIFS is licensed on the source cluster node, it must also be licensed on the destination cluster node. Otherwise, moving the vFiler unit causes CIFS to be unavailable for that vFiler unit after it is moved.
Both the source cluster node and the destination cluster node must be connected to the same storage subsystem. The disks must be visible to both the source and destination cluster nodes.
To ensure that software-based disk ownership changes are transparent to NFS users, the destination cluster node must have an Ethernet connection to the same subnet that the source cluster node uses.
The volume assigned to the vFiler unit must be a traditional volume. You cannot move FlexVol volumes or the aggregates that contain those FlexVol volumes using SnapMirror. For information about traditional and FlexVol volumes, see the Data ONTAP Storage Management Guide.
The vFiler unit's storage units must all be composed of complete volumes -- that is, the vFiler unit's paths must use the form /vol/volname. SnapMover migration of storage units naming specific volume subdirectories--for example, /vol/volname/directory or /vol/volname/qtree, is not supported.
The volume containing the configuration information for the vFiler unit (/vol/volname) must be writable.

Guidelines for setting up volumes to support vFiler unit migration

When a vFiler unit is migrated, all volumes associated with that vFiler unit are moved. Therefore, when you create the vFiler units, consider the following:

SnapMover cannot migrate just a subset of the volumes that are managed by the vFiler unit it is migrating.
The destination cluster node must be able to accommodate the size of the vFiler unit with all its associated volumes.
You can create up to 32 vFiler units on a storage system.
The names of the vFiler units and volumes being moved from the source to the destination must be unique on the destination.
Although you can rename a volume, it is best not to do so if you have NFS clients, because the renaming of the volume is not transparent to NFS clients. When the storage system uses NFS to export a file system, the volume name is part of the exported path name. NFS clients try to mount using the old path name; to access the data after the vFiler unit has been moved, clients will need to remount using the new path name.

What happens during a SnapMover vFiler unit migrate operation

You use the vfiler migrate -m nocopy command to carry out SnapMover vFiler unit migration. This command does the following:

Ensures that no vFiler unit with the same name exists on the destination node
Ensures that the SnapMover license is installed on both the source and destination cluster nodes
Ensures that the licenses and Data ONTAP versions are the same on both the source and destination cluster nodes
Saves the IP configuration and binding information that you supplied when you created the vFiler unit
Saves the quota information from the source vFiler unit's /etc/quotas file
Stops the source vFiler unit
Destroys the source vFiler unit
Rewrites the disk ownership information so that the ownership of the vFiler unit volumes passes from the source cluster node to the destination cluster node
Re-creates the vFiler unit on the destination cluster node

Enabling SnapMover vFiler unit migration

To enable SnapMover vFiler unit migration between clustered nodes running MultiStore, complete the following steps.

Step	Action
1	On each cluster node, confirm that MultiStore is licensed. At the command prompt, enter the following command and make sure that Multistore is listed as a licensed feature: license
2	Temporarily disable the cluster by entering the following command: cf disable
3	On each cluster node, confirm that the software-based disk ownership is enabled by entering the following command in the command-line interface (CLI) of one of the cluster nodes: disk show
	If...	Then...
	The system displays disks in the cluster to which disk ownership is assigned	Software-based disk ownership is enabled. Go to Step 10.
4	Reboot each cluster node. During the boot process, press Ctrl-C to display the boot menu options.
5	Enter the choice for booting in maintenance mode.
6	On each cluster node, in maintenance mode, enter the following command: disk upgrade-ownership This command writes software-based disk ownership information to enable SnapMover.
7	Enter the following command on each cluster node to confirm the new software-based disk ownership scheme: disk show The system displays all the disks on the cluster to which ownership has been assigned. Disks assigned to either cluster node will be visible.
8	To halt each cluster node to exit maintenance mode, enter the following command: halt
9	Reboot each cluster node in normal mode.
10	On each cluster node, install the license for SnapMover: license add snapmover_license
11	To re-enable the cluster operation, enter the following command: cf enable

Migrating a vFiler unit from one cluster node to another using SnapMover

Once SnapMover vFiler unit migration is enabled on both cluster nodes, you can carry out a SnapMover vFiler unit migration with the vfiler migrate -m nocopy command. To carry out a SnapMover vFiler unit migration, complete the following steps.

Step	Action
1	On the destination cluster node, enter the following command: vfiler migrate -m nocopy vfilername@source_cl_partner vfilername is the name of the vFiler unit that you are migrating. source_cl_partner is the cluster node from which you are moving the vFiler unit. Alternatively, enter the following command: vfiler migrate [-m nocopy [-f]] [-l user:password ] [-e ifname:IP address:netmask,... ] vfilername@source_cl_partner user is the administrative login ID. password is the password for the login ID. ifname, IPaddress, netmask is the interface name, IP address, and netmask, respectively, for the destination vFiler unit. Note If you use the alternate command, skip Step 2.
2	Answer the prompts, including the following information: A valid administrative login ID and password The IP address and binding information for the destination vFiler unit Result The vFiler unit is migrated from the source cluster node to the destination cluster node.
3	Verify that the vFiler unit was moved by entering the following command on the destination cluster node: vfiler status -r vfilername

Step

Action

On the destination cluster node, enter the following command:

vfiler migrate -m nocopy vfilername@source_cl_partner

vfilername is the name of the vFiler unit that you are migrating.

source_cl_partner is the cluster node from which you are moving the vFiler unit.

Alternatively, enter the following command:

vfiler migrate [-m nocopy [-f]] [-l user:password ] [-e 
ifname:IP address:netmask,... ] 
vfilername@source_cl_partner

user is the administrative login ID.

password is the password for the login ID.

ifname, IPaddress, netmask is the interface name, IP address, and netmask, respectively, for the destination vFiler unit.

Note
If you use the alternate command, skip Step 2.

Answer the prompts, including the following information:

A valid administrative login ID and password
The IP address and binding information for the destination vFiler unit

Result

The vFiler unit is migrated from the source cluster node to the destination cluster node.

Verify that the vFiler unit was moved by entering the following command on the destination cluster node:

vfiler status -r vfilername

Storage expansion on clusters using software-based disk ownership

If you decide to expand the cluster storage system by adding a disk shelf, you can use the disk assign command to divide primary ownership of the disks on that shelf between both cluster nodes regardless of the physical A loop and B loop connections of that shelf.

Because software-based disk ownership is configured on clusters on which vFiler unit migration is enabled, the task of expanding storage on these clusters involves the software assignment of the new disks to one cluster node or the other.

To assign disks that are currently labeled "not owned," complete the following steps.

Step	Action
1	In the CLI of the cluster node to which you want to assign disks, use the `disk show -n` command to view all disks that do not have assigned owners.
2	On the cluster node to which you want to assign disks, use the following command to assign the disks that are labeled "not owned": *disk assign {disk1* [disk2] [...]\|all} [-p {0\|1}]** disk1 [disk2] [...] are the names of the disks to which you want to assign ownership. `all` is the option to assign all of the unowned disks to the current storage system head. `-p {0\|1}` is the option to specify a pool assignment (either 0 or 1) for the specified disk if SyncMirror® volume replication is set up on the current cluster node. Example The following command assigns six disks in the cluster to the storage system fh1: fh1> `disk assign 0b.43 0b.41 0b.39 0b.37 0b.35 0b.33` Result The specified disks are assigned as disks to the specified storage system.
3	Use the `disk show -v` command to verify the disk assignments that you have just made and survey the disks that remain to be assigned.

Step

Action

In the CLI of the cluster node to which you want to assign disks, use the disk show -n command to view all disks that do not have assigned owners.

On the cluster node to which you want to assign disks, use the following command to assign the disks that are labeled "not owned":

disk assign {disk1 [disk2] [...]|all} [-p {0|1}]

disk1 [disk2] [...] are the names of the disks to which you want to assign ownership.

all is the option to assign all of the unowned disks to the current storage system head.

-p {0|1} is the option to specify a pool assignment (either 0 or 1) for the specified disk if SyncMirror® volume replication is set up on the current cluster node.

Example

The following command assigns six disks in the cluster to the storage system fh1:

fh1> disk assign 0b.43 0b.41 0b.39 0b.37 0b.35 0b.33

Result

The specified disks are assigned as disks to the specified storage system.

Use the disk show -v command to verify the disk assignments that you have just made and survey the disks that remain to be assigned.

After you have assigned disks to one of the two cluster nodes, you can assign those disks to volumes on the storage system that owns them or leave them as spare disks on the storage system that owns them.

Disabling SnapMover vFiler unit migration and software-based disk ownership

To disable SnapMover vFiler unit migration between clustered nodes running MultiStore, and return to A loop B loop ownership assignment, you might first need to reconfigure your software-based disk ownership assignments to be consistent with A loop B loop ownership assignment.

To disable SnapMover vFiler unit migration and software-based disk ownership, complete the following steps.

Step	Action
1	On one of the cluster nodes, enter the following command to ascertain whether or not the current software-based disk ownership assignments align with the cluster's A loop B loop topology: aggr status -r For backward compatibility, you can also enter the following command: vol status -r Results In the output of this command, all disks assigned to the current cluster node are listed as volume disks or as spare disks; all disks assigned to the cluster's partner are listed as partner disks. All disks on the same shelf must be assigned to the same cluster node and all disk shelf assignments must be consistent with the A loop B loop topology of the cluster.
2	If	Then..
	The disk ownership deviates from the A loop B loop topology because you have migrated a vFiler unit with the `vfiler migrate -m nocopy` command...	Change it back with the same command. See Migrating a vFiler unit from one cluster node to another using SnapMover. Then go to Step 3.
	The disk ownership deviates from the A loop B loop topology because you have split ownership of a single expansion disk shelf between the two cluster nodes...	Use the `disk assign` command to assign all disks on the shelf to the cluster node attached to the shelf's A loop connection. See the section on modifying disk assignments in the Data ONTAP Storage Management Guide. Then go to Step 3.
	The disk ownership deviates from the A loop B loop topology because you have reassigned a spare disk with the disk assign command...	Change it back with the `disk assign` command. See the section on modifying disk assignments in the Data ONTAP Storage Management Guide. Then go to Step 3.
	The disk ownership reflects the cluster's A loop B loop topology...	Go to Step 3.
3	Disable clustering by entering the following command. cf disable
4	On each cluster node, uninstall the license for SnapMover. license delete snapmover
5	Reboot each cluster node, and when prompted, press Ctrl-C to display the boot menu options.
6	On each cluster node, enter the choice for booting in maintenance mode.
7	In maintenance mode on each cluster node, enter the following command: disk remove_ownership This command disables software-based disk ownership.
8	Halt each cluster node to exit maintenance mode: halt
9	Reboot each cluster node in normal mode. The system reverts to ownership based on A loop and B loop connections.
10	To re-enable the cluster operation, enter the following command: cf enable

Migrating a vFiler unit between clustered nodes with SnapMover

When to use this section

What SnapMover vFiler unit migration on clustered nodes is

Requirements for vFiler unit migration on clustered nodes

Guidelines for setting up volumes to support vFiler unit migration

What happens during a SnapMover vFiler unit migrate operation

Enabling SnapMover vFiler unit migration

Migrating a vFiler unit from one cluster node to another using SnapMover

Result

Storage expansion on clusters using software-based disk ownership

Example

Result

Disabling SnapMover vFiler unit migration and software-based disk ownership

Results