Planning for using SnapMover to change workload distribution

About this section

If the quantity of requests sent to a gFiler becomes high enough to affect performance, you can use SnapMover to move request servicing from one gFiler to another. This section provides information to help you plan for using SnapMover.

SnapMover described

SnapMover works in conjunction with the MultiStore feature. Its sole purpose is to enable you to move MultiStore vFilers quickly and efficiently between gFilers that are sharing the same storage subsystem. SnapMover uses the disk (LUN) ownership scheme to migrate (move) a vFiler instead of copying it, which makes migration quite fast. In contrast, the standard Data ONTAP vFiler migrate facility, which uses SnapMirror, copies data. Copying the data is time-consuming.

Licenses required

Two licenses are required to use SnapMover--one for SnapMover and one for MultiStore.

MultiStore vFiler technology described

With MultiStore, you can partition a single gFiler (or filer) into multiple logical units referred to as vFilers. Each vFiler owns its own exclusive storage and networking resources; no sharing of resources occurs even if the resources are on the same system. vFilers allow a lot of flexibility in how data can be partitioned and managed. For example, you could

Create a vFiler to logically separate data belonging to a specific service provider from the data belonging to another service provider.
Create a vFiler for data that you want to process on days 1 to 10 of the month and another vFiler for data on that you want to process on days 11 to 20 of the month. You could then move the vFilers, as necessary, to free up CPU processing.

The Data ONTAP MultiStore Guide provides more examples of how you can use vFilers to partition and manage your data.

Requirement to associate vFilers with volumes

Before you can create a vFiler, you must define (create) one or more units of data storage called NetApp volumes on your gFilers. Then, when you create the vFiler, you identify the volume associated with the vFiler.

Note
The purpose of SnapMover is to move vFilers. You cannot use SnapMover to move a spare LUN, which is not part of a volume.

What the volume-level vFilers used with SnapMover are

SnapMover supports volume-level vFilers only; that is, vFilers for which all storage elements are composed of complete volumes. In practice, this means a vFiler with paths of the form /vol/<volname>. The data structure /vol/<volname>/<subvolname> is not supported for SnapMover.

The following illustration shows the configuration that is supported for SnapMover.

When SnapMover moves a vFiler, SnapMover moves all volumes associated with the vFiler, as the following illustration shows.

Information that is moved provides details about what data SnapMover moves with the vFiler.

Requirements

The following requirements exist for using SnapMover and MultiStore to change the workload distribution:

The following licenses must be installed on each gFiler after the disk (LUN) assignment process is complete and Data ONTAP is installed:
- MultiStore
- SnapMover
Other licenses used by the vFiler must match. For example, if CIFS is licensed on the source gFiler, it must be licensed on the destination gFiler. Otherwise, moving the vFiler causes CIFS to be unavailable after the vFiler is moved to the destination.
Both the source gFiler and the destination gFiler (the gFilers between which you are moving a vFiler) must be connected to the same storage subsystem. The LUNs must be visible to both the source and destination gFilers.
(Highly recommended) To ensure that disk (LUN) ownership changes are transparent to NFS users, the destination gFiler must have an Ethernet connection to the same subnet that the source gFiler uses.
The volume that the vFiler will be using must be created before the vFiler is created. See Creating a volume.
A vFiler must be created on the source.
The vFiler's storage units must all be composed of complete volumes; that is, a vFiler with paths of the form /vol/<volname>.
- The volumes for vFiler configuration information must be writable.
- The IP address used by the vFiler must be unconfigured when you create the vFiler.
At least one of the following protocols must be available: rsh, NFS, CIFS, or iSCSI

Guidelines for setting up volumes to support volume-vFilers for SnapMover

When SnapMover moves a vFiler, all volumes associated with that vFiler are moved. Therefore, when you create the vFilers, consider the following:

SnapMover cannot move part of a volume when it moves a vFiler.
The destination gFiler must be able to accommodate the size of the vFiler with all its associated volumes.
There is a limit on the number of volumes and vFilers on a gFiler, depending on the memory capacity of the hosting gFiler. See Volume metrics for the limit on the number of volumes. You can create up to 32 vFilers on a gFiler (64 in a cluster), depending on the memory capacity of the hosting gFiler. (A gFiler containing the maximum number of vFilers actually has 33 vFilers: vFiler0 plus the 32 vFilers that you, the system administrator, can create.)
The names of the vFilers and volumes being moved from the source to the destination must be unique.
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 gFiler uses NFS to export a file system, the volume name is part of the exported path name. NFS clients are accustomed to trying to mount to the old path name; in order to access the data after the vFiler has been moved, clients will need to remount using the new path name.

Note
The Data ONTAP MultiStore Guide provides information about planning for, creating, and managing vFilers. Most of the information provided is applicable to volume-level vFilers. However, keep in mind when reading the instructions for creating a vFiler that the standard vFilers do not need to be a complete volume as is required for SnapMover.

qtree migration is not supported

You cannot migrate qtrees through SnapMover.

Information that is moved

When SnapMover moves the vFiler, it automatically updates the data associated with volumes, such as IP address, permissions, vFiler ID, and disk ownership (such as IP addresses). NFS clients are unaware that the vFiler is being moved. To CIFS client workstations, it appears as if the server was rebooted.

SnapMover command

The SnapMover command is vfiler migrate -n nocopy.

What the vfiler migrate -m nocopy command does

The vfiler migrate -m nocopy command does the following:

Ensures that no vFiler with the same name exists on the destination
Ensures that the SnapMover license is installed on both the source and destination gFilers
Ensures that licenses and WAFL® versions are the same on both the source and destination gFilers
Rewrites the disk ownership record so that the ownership of the volumes passes from the source vFiler to the destination vFiler
Saves the IP configuration and binding information that you supplied when you created the vFiler
Saves the quota information from the source vFiler's /etc/quotas file (how much disk space individual users can use)
Stops the source vFiler
Destroys the source vFiler
Re-creates the vFiler on the destination gFiler

Reverting if you are using SnapMover

If you have migrated a volume vFiler and you want to move it back to the source, you cannot do so unless the both the source and destination gFiler are running Data ONTAP 6.5 or later. You either need to revert the source gFiler to the same pre-6.5 Data ONTAP version as the destination gFiler or upgrade the destination gFiler to 6.5 or later.