Migrating the vFiler
Before you start
Before you begin the migration, make sure the following are true:
- You have performed all the preparation steps listed under Storage checks and actions and Network checks and actions.
Note
The storage checks are not necessary if you are going to use disk ownership technology to migrate the vFiler.
- SnapMirror is licensed and enabled on both the source and the destination filer.
- The source and destination filers are on the same subnet.
Note
If the filers are not on the same subnet, you will need to run setup (and cifs setup if necessary) on the new vFiler after the migration, to configure authority servers as specified on your worksheet. See If you have moved the vFiler to a different subnet or Windows domain for details.
- The source and destination filers can communicate with each other over the network (for example by means of DNS lookup or entries in /etc/hosts).
- The source filer can communicate with the destination filer via the rsh command.
- If any of the source qtrees or volumes contain LUNs (virtual disks), the destination filer is running a version of Data ONTAP that supports virtual disks.
- If the source vFiler owns iSCSI LUNs, the destination vFiler must be running a version of Data ONTAP that supports iSCSI LUNs on vFilers.
- The destination volumes are online.
- You know the source filer's administrative ID and password.
How migrating a vFiler affects clients
If you migrate a vFiler to another filer on the same subnet, you see the following effects on clients.
- NFS volume-level mounts move transparently.
- NFS qtree-level mounts need to be remounted.
- CIFS clients experience the equivalent of a reboot.
- LUN access continues uninterrupted.
Although an iSCSI host is briefly disconnected from the source vFiler, an initiator hides this brief disruption from applications accessing the LUNs. To the applications, access continues without interruption.
For information on moving a vFiler to a filer on a different subnet, see If you have moved the vFiler to a different subnet or Windows domain.
Caution
The procedure that follows destroys the original vFiler after replicating it on the destination filer. If you want to leave the original vFiler intact and create a backup copy of it for disaster-recovery purposes, use the procedures listed under How to create and activate a disaster-recovery vFiler instead.
Migrating the vFiler
To migrate the filer, perform the following steps.
Step
|
Action
|
|---|
|
1 |
On the destination filer, enter the following command:
vfiler migrate start source_vfiler@source_filer
Note
This procedure locks up the console for the minimum amount of time. If this is not a concern for you (if you want to let the job run overnight, for example) you can perform the migration with a single command:
vfiler migrate source_vfiler@source_filer
If you do this, skip Step 4 and Step 5.
|
|
2 |
Respond to the login prompt with a valid administrative ID and password for the source filer.
|
|
3 |
Respond to the IP address and binding prompts, using the addresses you entered on the "new interface" lines on the worksheet.
|
|
4 |
Monitor the progress of the migration with the following command:
vfiler migrate status source_vfiler@source_filer
Note
The vfiler dr migrate command might take some time to complete, especially if a source qtree has many millions of inodes. |
|
5 |
When the status command reports that SnapMirror has replicated all the storage units of the source vFiler, complete the migration by entering the following command:
vfiler migrate complete source_vfiler@source_filer
Note
If you want to cancel the migration, you can do so now by issuing the following command on the destination filer:
vfiler migrate cancel source_vfiler@source_filer
This destroys the destination vFiler and removes the SnapMirror and other migration-related configuration information from the source vFiler.
Note
If the vfiler migrate complete command reports that the process cannot complete, wait a few minutes and then enter the same vfiler migrate complete command again. |
|
6 |
If you copied quota information into the destination filer's /etc/quotas file (see Step 8 of Preparing the destination filer earlier in this chapter) activate the quotas on that filer. For each volume you are activating quotas on, use the following command:
quota on volume
|
|
7 |
Make adjustments on the clients.
These will include remounting qtrees, but volume-level mounts should be intact.
|
|
8 |
If you have moved the vFiler to a different subnet, follow the steps in If you have moved the vFiler to a different subnet or Windows domain.
|
|
9 |
If the vFiler's storage units contain iSCSI LUNS, reconfigure iSCSI authentication.
See the Block Access Management Guide for iSCSI for instructions.
|
What the vFiler migrate commands do
The vfiler migrate start command does the following:
- Checks that the destination filer is capable of receiving the source data.
- Configures and runs SnapMirror to copy the data from the source to the destination vFiler.
- Saves the IP configuration and binding information you supply (see Step 3 in Creating the vFiler).
- Saves the quota information from the source vFiler's /etc/quotas file.
The vfiler migrate complete command does the following:
- Stops the source vFiler.
- Updates the data on the destination vFiler.
- Breaks the SnapMirror relationships.
- Configures IP bindings on the destination vFiler according to the information you provided to the vfiler migrate start command, adding the destination IP information to the destination /etc/rc file. (Any IP information that pertains only to the source vFiler is removed from the destination /etc/rc.)
- Configures any quota information saved by the vfiler migrate start command.
- Destroys the source vFiler.
- Brings LUNs online using migrated LUN maps and igroups.
If you have moved the vFiler to a different subnet or Windows domain
If you have moved the vFiler to a different subnet, you might need to configure the network servers and make adjustments on the clients. If you have moved the vFiler to a different Windows domain, you might also need to modify data-file security attributes.
Perform the following steps on the destination vFiler.
Step
|
Action
|
|---|
|
1 |
To configure NIS and DNS servers, run setup.
|
|
2 |
To change the name of the Windows domain controller, use the cifs prefdc command.
|
|
3 |
To change the Windows WINS server, run cifs setup.
Note
If the Windows domain has changed, you might need to change the permissions on the Windows data files to allow your users the same access they had in the old domain. |
|
4 |
To change the trusted host, do the following:
a. Edit the vFiler's /etc/hosts.equiv file, adding the name of the trusted host for administering the vFiler. (This is the hostname you entered on the worksheet as "new trusted host".)
Note
If the trusted host is a Windows system, or if it is a UNIX system and the trusted user is not the root user, you need to add the user name as well; for example adminhost joe_smith
b. Add the path to the root volume and the name of the trusted host to the vFiler's /etc/exports file.
Example
/vol/vol0 access=adminhost, root=adminhost
|
|
5 |
Make adjustments on the clients.
These will include remounting volumes and qtrees.
|
Copyright © 1994-2003, Network Appliance, Inc. All rights
reserved.
Part No. 210-00475
File: disast10.htm
Last updated: 11/24/03 16:11:49