The user in this case is either a non-root user account on the base controller vFiler0 or any account visible within a new vFiler context, including the root user automatically created when the new vFiler was instantiated. At this point, the NDMP node should be available in the Enterprise and is configured to perform any data protection action, including Block backup and restore, agentless backup and restore, BMR, Instant Access, and virtualization.
Note that properly configured iSCSI access is essential to most recovery operations and for agentless backup. It is prudent to comprehensively test all desired backup and restore operations to assure that routing and iSCSI access is available to the hosts that will need to make use of these features. For vFiler's, it is generally convenient to create a new user account for data protection access using the default Administrators group.
The same is true for non-root accounts on the base controller or vFiler0; creating a non-root account in the group Administrators is most convenient. For environments where you need tighter control of NetApp storage roles, the following roles will be required for the desired user account:.
Contoso, Ltd. Home Knowledge Base - Home Print. Scanning in a NDMP Node Using Non-root Account The user in this case is either a non-root user account on the base controller vFiler0 or any account visible within a new vFiler context, including the root user automatically created when the new vFiler was instantiated. In the Configure Enterprise window, scan the node into the Enterprise. Use the desired user account and NDMP password generated in the previous step.
By default, quotas are allowed on all volumes. Only hosting filer administrators can allow or disallow quotas for a volume. Disallowing quotas on a volume has these effects on all vFiler units that have storage units in the volume:. If quotas are currently turned off, you or the vFiler administrator are prevented from turning quotas on for that volume.
If quotas are currently turned on, they are turned off immediately and are prevented from being turned back on. Release Candidate Documentation June 05 Allowing or disallowing quotas for a volume. Result: After you enter the quota allow command, you can turn on quotas for the specified volume from a vFiler.
After you enter the quota disallow command, vFiler units are prevented from turning quotas on for the specified volume. If any vFiler units currently have quotas turned on for the volume, quotas are turned off immediately for those vFiler units.
Turning quotas off using the quota off volume command deactivates the specified volume. You can turn quotas on and off on a per-volume basis for a vFiler. After you turn quotas on for a particular volume, Data ONTAP initializes quotas for the storage units residing on the volume, which are owned by the vFiler. Quota on or off states are persistent and stay set after reboots. Hosting filer administrators and vFiler administrators can turn quotas on and off for a volume as long as they own some storage space in the volume.
You can turn quotas on and off for a volume from a vFiler regardless of how the quota status for that volume is set from other vFiler units, including vFiler0. Enter the following command through an rsh connection to the vFiler: quota on off volume. When you enter the quota resize command from a vFiler to resize quotas for a volume, only the quota records for the vFiler are adjusted.
If the vFiler consists of qtrees, you can resize the quotas for this volume without turning quotas off and on for the entire volume. All path names in the file are complete path names. For each user or group quota, you can specify in the Type field the qtree or volume in which the quota takes effect.
You can specify only qtrees and volumes that are owned by the vFiler. If you omit the path name in the Type field, the quota takes effect in the filers root volume when quotas are turned on for the root volume. Recommendation: A vFiler administrator should specify a path name in the Type field even though the quota is for a user or group in the filers root volume.
This ensures that the quota remains applicable even after you change the root volume to a different volume. Result: The command displays quota status information about all volumes in which the vFiler owns storage space. The following messages are sample messages in the command output: vol0: quotas are on.
A quota report contains information for the vFiler from which you enter the quota report command. When you display the quota report for vFiler1, only the quota information pertaining to vFiler1 is shown. No information about the qtrees owned by vFiler2 or the hosting filer is included in the quota report. The disk space and the number of files owned by the quota targets in volumes and qtrees that do not belong to vFiler units other than vFiler0.
Information about users and groups in these qtrees, however, is not shown. The K-Bytes and Files fields include the limits for disk space and number of files in a qtree.
If the vFiler does not impose a tree quota on the qtree, the quota report does not include an entry for the qtree, although the qtree is restricted by the tree quota imposed by the filer. When you display a quota report for vFiler1, the entry for qtree1 shows that the maximum amount of disk space allowed is GB, even though qtree1 is actually limited by the more restrictive quota, which is GB.
The quota report command syntax for a vFiler is the same as the syntax for a filer, except that it also takes the -v argument. If you use the quota report -v command, the report displays the vFiler name before the Quota Specifier field.
Release Candidate Documentation June 05 Messages from exceeded quota thresholds and soft quotas. If a quota threshold or soft quota defined on a vFiler is exceeded, a warning message is logged to the filer console.
The following example is a warning message generated when a quota threshold is exceeded: [vfiler1 quota. Preparing a disaster-recovery or a backup vFiler and activating it if a disaster occurs. Moving a vFiler for example, if you are replacing an old filer with a new one either by copying data from one physical filer to another or by using SnapMover vFiler migration between clustered nodes.
Moving a vFiler is called migration. Note The procedures in this chapter do not cover migrating or replicating the hosting filer, vFiler0. The underlying vfiler migrate and vfiler dr commands do not operate on vFiler0.
Release Candidate Documentation June 05 Understanding disaster recovery and data migration. Although the reasons for preparing a disaster-recovery vFiler are quite different from the reasons for moving migrating a vFiler, many of the tasks involved are similar. In both cases, you need to take inventory of the source vFiler and make sure the destination filer has the storage capacity and characteristics, and the network connectivity, to host an identical copy of the original vFiler.
Then, in both cases, you use a small set of vFiler commands to actually create the new vFiler, populate it with the original vFilers data, and prepare its connections to the network. What the procedures do and do not cover: In both cases, the procedures that follow help you not only to move or copy the data using the SnapMirror technology , but also to configure all of the networking needed to serve the data.
But they do not cover adjustments on the client side for example, mounts onto a Solaris or Windows host. You will need to work closely with the administrators of those systems and with your network administrator to make those adjustments.
Note A SnapMirror license is required on both the source and destination filers. After the new vFiler has been created, the states of the source and destination vFiler units depend on how you will use the new vFiler. The new destination vFiler is inactive, and its IP addresses remain unconfigured, until you activate it in the case of a disaster that destroys or incapacitates the original vFiler.
The new destination vFiler becomes active and begins serving data as soon as the migration is complete. Before moving migrating a vFiler or setting up a disaster-recovery vFiler, you must perform the checks, and the accompanying actions if necessary, listed in Storage checks and actions and Network checks and actions in this section. Photocopy the worksheet Storage and network checklists on page and fill out the storage items as you perform the following steps. Note The storage checks are not necessary if you are going to use SnapMover vFiler migration to migrate the vFiler.
Action Check that the destination filer has enough storage space to hold the source vFilers volumes. On the source filer, use the vfiler status -r command to see what volumes the vFiler is using. Then use the df command on each of those volumes to check how much space is being used. The destination volumes must have at least that much free space; run df on the destination filer to check. Fill in the df results on the worksheet. Note If the source and destination filers use different-sized disks and have different block sizes, adjust the df numbers accordingly.
If necessary, install new disk shelves. Use the aggr add command to add new disks to the destination volumes. Action Make sure that the destination filer has the same volume structure as the source and that the volumes to be used by the destination vFiler are not used by any other vFiler.
The volumes to be used by the destination vFiler must have the same path names as those used by the source vFiler. The destination filer has volumes whose path names match those used by the source vFiler and the volumes to be used by the destination vFiler are not used by any other vFiler. The destination filer has a volume whose path name matches that of the source vFiler but the volume is used by another vFiler.
If the volume cannot be destroyed, use the vol rename command to rename the volume. Then, create a new volume with the old name of the volume you just renamed. If the volume can be removed, use the vfiler remove command to disassociate the volume from that vFiler.
If the volume is the root volume of the vFiler, use the vfiler destroy command to destroy the vFiler. Use the aggr create command on the destination filer to create volumes whose names match those being used by the source vFiler, or use aggr rename to rename a volume.
For FlexVol volumes, use the vol create command. Make sure there are no qtrees in the destination volumes whose names match those of qtrees in the source volumes. The migration process uses SnapMirror, which will replicate qtree names from the source to the destination volume, so these names should not already exist on the destination.
There are qtrees in the destination volumes whose names match those of qtrees in the source volumes. To rename a qtree, move it from a client as you would a directory or folder.
Continue with Step 7. Check whether quotas are being enforced from the hosting filer. Quotas enforced from the vFiler will be copied to the new vFiler, but quotas enforced from the hosting filer will not. To see where quotas are being enforced from, use the hosting filer to enter the following command: quota report. The output of the quota report command shows that quotas for qtrees used by the vFiler are being enforced from the hosting filer.
No quotas for qtrees used by the vFiler are being enforced from the hosting filer. Photocopy the worksheet Storage and network checklists on page and fill out the networking items as you perform the following steps. Use the command ifconfig -a on the source vFiler and on the destination filer to display information about all their network interfaces.
You can reuse the source IP addresses and aliases on the destination vFiler if the destination vFiler will be on the same subnet as the source vFiler. Note This is the default case assumed by the vfiler migrate command.
They are on different subnets. Obtain as many new IP addresses for the destination vFiler as are in use on the source vFiler. Note You might need to replicate subnet-separation arrangements that exist on the source vFiler.
For example, the source vFiler might use one IP address for a service network and another for an administration network. Make a note of the new IP addresses on the worksheet. The vfiler dr configure command will prompt you for these addresses; see Creating the disaster-recovery vFiler on page The vfiler migrate command will also prompt you for these addresses, but you might then need to run setup on the destination vFiler.
See If you have moved the vFiler to a different subnet or Windows domain on page Action Check whether the source vFiler uses the default IPspace. Use the command ipspace list on the source vFiler to display information about IPspaces and the interfaces assigned to them.
Use the command ipspace create ipspacename to create a corresponding IPspace with the same name on the destination filer. Use the command ipspace assign ipspacename interfacename to assign physical interfaces to the IPspace. These interfaces must all be attached to the same physical network. Check to see if the destination vFiler will have access to the same NIS servers as the source.
Note You can skip this check if the source and destination vFiler units are on the same subnet. Use the command nis info on the source vFiler to see what NIS servers are available to it. Tip: The ypwhich command shows which server the filer is currently bound to. The destination vFiler cannot use same NIS servers. Find out which NIS servers are available to the destination filer. Make a note of the IP addresses of those servers on the worksheet.
The vfiler dr configure command will prompt you for these addresses; see Creating the disasterrecovery vFiler on page The vfiler migrate command will not prompt you for these addresses. If you move a vFiler to a different subnet, you might need to run setup on the destination vFiler. Check to see if the destination vFiler will have access to the same DNS servers as the source. Use the command dns info on the source vFiler to see what DNS servers are available to it.
The destination vFiler cannot use the same DNS servers. Find out which DNS servers are available to the destination filer. Check to see if the destination vFiler will have access to the same WINS servers and the same Windows security network as the source.
Find out the name and type Windows NT 4 or Windows of the domain the destination vFiler will be in. Make a note of this information on the worksheet.
When you activate the disaster-recovery vFiler, you will need to configure it into the new domain. See Activating the disaster-recovery vFiler on page If you move a vFiler into a different domain, you will need to configure it into the new domain. Check to see if the destination vFiler can use the same trusted host for vFiler administration as the source vFiler. Find out the name of the new trusted host. You will need to configure the new trusted-host information after configuring the disaster-recovery vFiler, or after moving the vFiler.
See Creating the disaster-recovery vFiler on page or If you have moved the vFiler to a different subnet or Windows domain on page Its a good idea to photocopy the checklists on this page and the next page and fill them out as you go through the checks described earlier in this section. See Step 1 of the Storage checks and actions on page How much disk space is free on the destination filers volumes? Have you added enough disks to the destination volumes, if necessary?
See Step 2 of the Storage checks and actions. See Step 4 of the Storage checks and actions. See Step 6 of the Storage checks and actions. See Step 8 of the Storage checks and actions. See Step 2 of the Network checks and actions on page Have you created the number of non-default IPspaces, if any are required? See Step 4 of the Network checks and actions on page Have you gathered all the authority servers?
See Step 5 through Step 10 of the Network checks and actions. Release Candidate Documentation June 05 Can you use the same trusted host for vFiler administration? See Step 12 of the Network checks and actions. When you have finished the preparation by following the checklists listed in the previous sections, you are ready to create the destination vFiler.
If you are preparing a disaster-recovery vFiler, follow the directions under How to create, activate, or delete a disaster-recovery vFiler on page In this case the original vFiler remains intact and running. If you are moving a vFiler from one physical filer to another, follow the directions under How to move migrate a vFiler on page In this case, the original vFiler is destroyed after it has been replicated on the destination filer.
Release Candidate Documentation June 05 How to create, activate, or delete a disaster-recovery vFiler. Use the procedures listed in this section if you want to create a backup copy of a vFiler both the data and the vFiler configuration for disaster-recovery purposes. The procedures assume that the original vFiler will remain intact and running unless a disaster puts it out of action. If you want to destroy the original vFiler after the new vFiler is up and running, follow the procedures listed under How to move migrate a vFiler on page instead.
Before a disaster: To create a disaster-recovery vFiler, follow this process. Qualify and prepare the destination filer. Perform the checks listed in Preparing the destination filer on page Create the disaster-recovery vFiler. See Creating the disaster-recovery vFiler on page After a disaster: After a disaster has occurred, and the original vFiler is destroyed, incapacitated, or unreachable, follow this process.
Activate the disaster-recovery vFiler. To reactivate the original vFiler after the damage caused by the disaster has been repaired, see Reactivating the original vFiler on page Deleting a disaster-recovery vFiler: To delete a disaster-recovery vFiler, follow the process described in Deleting the disaster-recovery vFiler on page You have performed all the preparation steps listed under Storage checks and actions on page 99 and Network checks and actions on page To create the disaster-recovery vFiler, perform the following steps.
Caution On the disaster-recovery filer, protect any volumes that have the same names as volumes on the original vFiler. Otherwise, data in those volumes will be lost. If you want to set up synchronous SnapMirror between the source and destination filers, use the -s option of the vfiler dr configure command. You can set multiple paths from the source to the destination filers in SnapMirror.
The -a option of the vfiler dr configure command enables you to set multiple paths for the configure operation. Note The vfiler dr configure command might take some time to complete, especially if a source qtree has many millions of inodes. When the vfiler dr status command reports all the storage units of the source vFiler as snapmirrored, proceed to the next step. Note The disaster-recovery vFiler now exists, but has not been started.
See What the vfiler dr configure command does on page for more information. Release Candidate Documentation June 05 What the vfiler dr configure command does. Overwrites all data on the volumes of the destination vFiler. You must protect any volumes on the destination filer that have the same names as the volumes on the source vFiler. Creates a special type of vFiler, known as a DR backup vFiler, on the destination filer. This vFiler is stopped and cannot be started except as described under Activating the disaster-recovery vFiler on page Before activation, the vFiler will respond only to the vfiler dr delete, vfiler dr status, and vfiler dr resync commands.
You should not use ifconfig to configure its addresses. To activate the disaster-recovery vFiler on the destination filer, perform the following steps. Step 1. 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.
Converts the vFiler into an ordinary vFiler that can be started and that responds to all the commands vFiler units support. How to create, activate, or delete a disaster-recovery vFiler. To delete a disaster-recovery vFiler at any time after a disaster-recovery vFiler has been set up, complete the following step. Before removing the disaster-recovery vFiler, the vfiler dr delete command also removes all SnapMirror relationships, and any other configuration information related to the disaster-recovery vFiler, from the source vFiler.
If any errors are detected in SnapMirror relationships, the deletion of the vFiler is aborted. To ignore SnapMirror errors and remove the disaster-recovery vFiler, you can use the -f option available in the vfiler dr delete command.
Use this section when you want to bring the original vFiler back online after repairing or replacing the original filer following a disaster. How you do this depends on whether you have recovered the original filer, or are bringing up a new filer as a replacement. If you have recovered the original filer, follow the instructions under Ways to reactivate the original vFiler on page If you are bringing up a replacement filer, follow directions under Recreating the vFiler on a replacement filer on page If the filer was not damaged but suffered only a temporary failure, you can select one of the two following methods:.
If the storage element associated with the vFiler is a volume traditional or FlexVol , you can reactivate the vFiler by resynchronizing the original vFiler with the disaster-recovery vFiler and then bringing up the original vFiler by following the procedure Resynchronizing the vFiler on page You cannot use this method if the storage elements associated with the vFiler units are qtrees.
If the storage element associated with the vFiler is a qtree, you can reactivate the vFiler using SnapMirror commands, as described in the procedure Reactivating the original vFiler using SnapMirror commands on page If you are not comfortable using SnapMirror commands, follow the procedure described in the next bullet to reactivate the vFiler.
That procedure is less complicated, but requires more data movement. If the filer was severely damaged, or you are not comfortable using SnapMirror commands, follow the procedure Reactivating the original vFiler using vFiler dr commands on page This method not only saves you from deleting the original vFiler and creating a new vFiler, but also does not require a baseline transfer involving a large amount of data , which would otherwise occur between the new vFiler and the disaster-recovery vFiler.
If the original vFiler needs to be resynchronized, the vfiler dr resync command is executed on the filer on which that vFiler exists. If the disasterrecovery vFiler has been activated, the resync operation proceeds to update the original vFiler. After the update, the resync operation does not activate the original vFiler. The original vFiler becomes the disaster-recovery vFiler and the currently active disaster-recovery vFiler continues to serve data.
If you want to switch the roles of the two vFiler units, you must do that by using the vfiler dr activate command on the original vFiler. After the roles have been switched and the original vFiler has been reactivated, you can use the vfiler dr resync command on the now deactivated disasterrecovery vFiler to synchronize it with the original vFiler. The disaster-recovery vFiler goes back to being the backup vFiler, ready for use if the original vFiler goes down. When the vfiler dr resync command is executed on the filer on which the disaster-recovery vFiler exists, it can issue an update for the existing storage elements and add and remove storage elements from the disaster-recovery vFiler.
Note The vfiler dr resync command does not retrieve any configuration changes that might have been done on the disaster-recovery vFiler and preserves the IP information including DNS and NIS of the filer on which the command is run. Release Candidate Documentation June 05 Prerequisities for using the vfiler dr resync command. The storage elements for the vFiler are only volumes traditional or FlexVol and not qtrees.
To resynchronize the original vFiler on the original filer with the currently activated disaster-recovery vFiler, perform the following steps. Caution On the filer on which you are resynchronizing the original vFiler, protect any volumes that have the same names as volumes on the disaster-recovery vFiler.
If a volume with the same name exists, the volume is automatically added and initialized for SnapMirror transfers from the disaster-recovery vFiler. Any existing data on the newly added volume is lost. Ensure that the original vFiler the one you are trying to resync is in a stopped state.
If not, enter the following command to stop the vFiler: vfiler stop vfilername. The username is the login name of the administration host on the disaster recovery filer and the password is the password for that user name. If you do not specify the authentication information in the vfiler dr resync command, you are prompted for it when the command is run. The -a option of the vfiler dr resync command enables you to set multiple paths for the resync operation.
The vfiler dr resync command resynchronizes all storage elements belonging to the disaster-recovery vFiler, including the volumes that were added to the disaster-recovery vFiler after it was activated. When you run the vfiler dr resync command on the disaster-recovery vFiler to resync it with the original vFiler, you do not need to specify the -l, -a, and -s options. The values stored when vfiler dr configure was run for a baseline transfer to back up the original vFiler are used.
The original vFiler will be in a stopped, DR backup state. This is because the vfiler dr resync command does not activate the vFiler upon resynchronizing. The vFiler continues to behave like a backup disaster-recovery vFiler until you use the vfiler dr activate command to reactivate it.
For information on how to activate the vFiler, see procedure Activating the disaster-recovery vFiler on page For details of the vfiler dr resync command, see Step 2 of Resynchronizing the original vFiler on page The storage elements for the vFiler are qtrees. On the disaster-recovery filer, destroy the disaster-recovery vFiler by entering the following command on the disasterrecovery hosting filer: vfiler destroy vfilername. On the disaster-recovery filer, recreate the disaster-recovery vFiler.
From the original filer or its replacement, perform the procedure Creating the disaster-recovery vFiler on page If the vfiler dr resync operation is interrupted or does not complete, you must perform the following steps. Perform the steps listed in Reactivating the original vFiler using SnapMirror commands on page Enter the following command to check if the vFiler you were resyncing exists on the filer on which you were running the vfiler dr resync command: vfiler status.
If the vFiler exists, enter the following command to destroy it: vfiler destroy vfilername. Enter the following command to recreate the vFiler you destroyed earlier: vfiler create -r vfilername pathname. To reactivate the original vFiler on the original filer using SnapMirror commands, perform the following steps. Action Boot the original filer and interrupt the boot process by pressing the Del or Esc key while the memory self-test is in progress. Note If you dont press the Del or Esc key in time, you can press Ctrl-C when prompted later during the boot; then choose option 5 maintenance mode ; then enter halt.
At the OK prompt, set the no-vfiler-ips? This ensures that the filer does not try to bind IP addresses already being used by the disasterrecovery vFiler. When the filer boots, the original vFiler starts running, but it does not accept any read or write requests because its interfaces are unconfigured. Resynchronize the mirrored volumes and qtrees.
Troubleshooting: If the snapmirror resync command fails, telling you that there are no matching snapshots, you might have accidentally deleted the snapshots that SnapMirror depends on. Then continue with the next step of this procedure, but skip Step 7 when you get there. Action Find out if the snapmirror.
Enter the following command on the disaster-recovery filer: options snapmirror. The options snapmirror command returns a list of host names, and the name of the original filer is not in the list. Use the options snapmirror command to add the host name of the original filer.
Example: options snapmirror. Update the data on the original vFiler. Stop SnapMirror transfers to the disaster-recovery vFiler. For each volume and qtree owned by the original vFiler, enter the following command on the original filer: snapmirror quiesce pathname. Action Check that all the paths are quiesced by entering the following command: snapmirror status. Break the SnapMirror relationship.
For each volume and qtree owned by the original vFiler, enter the following command on the original filer: snapmirror break pathname. You might need to remap the LUNs and re-create initiator groups igroups. Stop the disaster-recovery vFiler.
On the disaster-recovery filer, enter the following command: vfiler stop vfilername. You are done reactivating the original filer. To ensure that you have a disaster recovery vFiler available for the vFiler on the reactivated original filer, go to the next step. Resynchronize the disaster-recovery vFiler. From the disaster-recovery filer, perform the procedure Resynchronizing the original vFiler on page To reactivate the original vFiler on the original filer, perform the following steps.
This ensures that the filer does not try to bind IP addresses already being used by the disaster-recovery vFiler. Destroy the original vFiler. Enter the following command on the original filer: vfiler destroy vfilername. Follow the procedure for Creating a replacement vFiler on the original filer or its replacement on page Follow these steps to create a replacement vFiler on the original production filer or its replacement. If you are reactivating the vFiler on the original filer, make sure you perform this procedure only after completing the preparatory steps in Reactivating the vFiler using the vFiler dr commands on page Prepare for the new vFiler on the original or its replacement filer: Perform the preparation steps in Preparing the destination filer on page Create the new vFiler on the original or its replacement filer, following directions under Creating the vFiler on page The original vFiler is now reactivated on the original filer or its replacement.
On the disaster-recovery filer, recreate the disasterrecovery vFiler. Use this section if you want to move a vFiler that is, the data and the vFiler configuration from one NetApp appliance to anotherfor example, from a filer that is overloaded to one that has spare capacity, or from an old filer to a new one.
This is sometimes called migrating a vFiler. The procedures in this section assume that you want to destroy the original vFiler once the new vFiler is up and running. 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, activate, or delete a disaster-recovery vFiler on page instead.
By copying data from a source vFiler to a destination vFiler. For more information, see Migrating the vFiler by copying data on page By changing the software-based disk ownership of the disks between clustered nodes using the SnapMover data migration technology, thus avoiding copying of data from a source vFiler to the destination vFiler.
For information about migrating data using SnapMover, see Migrating a vFiler between clustered nodes with SnapMover on page You should read this section and perform the instructions provided in this section if you want to migrate a vFiler by copying data from a physical source filer to another physical destination filer. You might want to copy data from one filer to another to maintain a backup copy of the data so that if the primary disks fail or the data on them becomes inaccessible, you can use the backup copy to restore services to clients.
The source and destination filers are on the same subnet. Note If the filers are not on the same subnet, you 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 on page for details. If you migrate a vFiler to another filer on the same subnet, you see the following effects on clients:.
LUN access continues uninterrupted. 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 on page Caution The procedure that follows destroys the original vFiler after replicating it on the destination filer.
To migrate the filer by copying data from one vfiler to another, perform the following steps. Note The following procedure uses the vfiler migrate command to migrate the vFiler by copying data. Action Qualify and prepare the destination filer. Note This procedure locks up the console for the minimum amount of time. If you do this, skip Step 5and Step 6. You can also specify the administrative ID, password, and IP address information in this command.
Respond to the login prompt with a valid administrative ID and password for the source filer. Respond to the IP address and binding prompts, using the addresses you entered on the new interface lines on the worksheet.
Note The vfiler migrate command might take some time to complete, especially if a source qtree has many millions of inodes. 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. Make adjustments on the clients. You will need to remount qtrees, but volume-level mounts should be intact.
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 on page Saves the IP configuration and binding information you supply see Step 4 in Creating the vFiler on page 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. To change the trusted host, do the following: a. This is the hostname you entered on the worksheet as new trusted host. You should read this section and perform the instructions provided in this section if you want to migrate a vFiler without copying its data from a physical filer source to another physical filer destination.
SnapMover vFiler migration on clustered nodes is the no-copy transfer of a traditional volume-level vFiler from one host node to the other.
For example, if heavy traffic to one vFiler is affecting the performance of its host node, and the other cluster node is lightly loaded, you can transfer ownership of that vFiler to the host nodes 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 from the original host node to its partner. Now, compare it to any traditional deployment where one has to update all the relationships manually.
You may think, how great it would be to make this an online process where none of the applications have to be taken down. Why Not?
We can do that too provided you can foresee a disaster and meet the distance limitations. Here is a demo that I shared in my previous blog that demonstrates exactly this. Looking at the current trends, this has a big use case in Hybrid Cloud environments apart from Public and Private Clouds and the traditional use cases. Who said Teleportation is difficult? We made it possible in the storage world a long time back.
No one had even thought about the possibilities of a Hybrid Cloud back then. After every few years our industry comes up with a new buzzword that takes control over Vendor Collateral, Webpages, Blogs, Tweets etc. When VMware started to grow rapidly, NetApp followed suit as it was ahead of the curve and ready for growth in Virtual Environments. I'm here for the refreshments. About cows, goats, and surviving in IT as a woman.
0コメント