For most data migrations from VNX to Isilon EMC recommends that you use the OneFS migration tool isi_vol_copy_vnx. It can often be more efficient than host-based tools (such as EMCopy and Robocopy) because the performance of host-based tools performance is dependent on the network connectivity of the host, while isi_vol_copy_vnx depends only on the network connection between the source device and the Isilon cluster. Below is a basic outline of the syntax, the steps required, and a few troubleshooting tips.
You might consider migrating data with a host based tool if one or more of the following conditions apply to your migration:
- The source device and Isilon cluster are on separate networks.
- Security restrictions prevent the source device and Isilon cluster from communicating directly.
Command Syntax:
isi_vol_copy_vnx --help
The source must contain a source host, a colon, and then the absolute source path name.
isi_vol_copy_vnx <src_filer>:<src_dir> <dest_dir> [-sa user: | user:password] [-sport ndmp_src_port] [-dport ndmp_data_port] [-full | -incr] [-level_based] [-dhost dest_ip_addr] [-no_acl] isi_vol_copy_vnx -list [migration-id] | [[-detail] [-state=<state>] [-destination=<pathname>]] isi_vol_copy_vnx -cleanup <migration-id> [-everything [-noprompt]] isi_vol_copy_vnx -get_config isi_vol_copy_vnx -set_config <name>=<value> isi_vol_copy_vnx -h | -help
Defaults: src_auth_user = root src_auth_password = ndmp_src_port = 0 (0 means NDMP default, usually 10000) ndmp_data_port = any dest_ip_addr = none
Note: This tool uses NDMP to transfer the data from the source VNX to the Isilon.
Migration Steps:
- Configure NDMP User
Create a new NDMP user on the source VNX. Log in to the control station and run the following command:
/nas/sbin/server_user -add <new_username> -ndmp_md5 -passwd
Select the defaults when prompted and be sure to make note of the password.
- Determine the absolute path of your filesystems and shares
If you’re using virtual data movers it changes the root path of your filesystem. Issue the following command to review your file systems and mount paths:
server_mount ALL
Note the the specific path for the file system that is targed for migration. The path when using a VDM will be similar to this:
FILESYSTEM1 on /root_vdm_1/FILESYSTEM1 uxfs,perm,rw
In this case the path will be /root_vdm_1/FILESYSTEM1, which will be used for the source path in the isi_vol_copy_vnx command.
3. Determine the target Isilon Data Location
Determine the destination location on the Isilon in the /ifs/data folder where the data will migrated. If the destination folder doesn’t exist on the Isilon, it will create it with the exact same NTFS permissions as the source. Create the command with the following syntax:
isi_vol_copy_vnx <datamoverIP>:<source_path> <target Isilon path> -sa : <-full or -incr> isi_vol_copy_vnx 10.10.10.10:/root_vdm_1/FILESYSTEM1 /ifs/data/FILESYSTEM1 -sa ndmpuser1: -full
- Migrate the Data
The command outlined above will run a full copy using the ndmpuser1 account and will prompt for a password, it does not have to be shown in plain text. The password can be specified in the command by using the appropriate syntax (<ndmpuser:password>), however you will still be required to follow the username with a colon.
If successful, the message “msg SnapSure file system creation succeeds” will appear, which means the NDMP session created a checkpoint successfully and is starting to copy data from that checkpoint.
Note that this does not migrate shares, just data. Sharedupe can be utilized for that or the CIFS shares/NFS exports can be manually re-created. It is recommended that any other data migrations on the source VNX be disabled prior to the copy so that you don’t run into performance issues.
Caveats:
- There is no bandwidth throttling option with this command, it will consume all available bandwidth.
- Isilon does not support Historical SIDs in versions 8.0.0 or earlier, which may result in permission issues due to being unable to resolve historical SIDs post migration from other platforms (see KB468562). If SIDHistory is in use on the source, then this is not the proper tool. From the comments section, please note that OneFS does support Security Identifier (SID) history beginning in 8.0.1 and later releases, and 8.0.0.3 and later releases (see latest docu44518_Isilon-Supportability-and-Compatibility-Guide).
- If fs_dedupe is enabled on the Celerra or VNX, you will need to change the backup threshold to zero for each filesystem. This means that when sending the data over NDMP send the full file, not the compressed or de-duped version. Note that there is a risk here of inflating existing backup sets if they are being done over NDMP.
- On the source the account performing the copy needs local administrator or backup operators permissions to the source CIFS Server, and full control over the source share.
- Standard NDMP backups and isi_vol_copy_vnx can affect each other and the data backed up by the two NDMP clients. See KB187008 for a workaround.
Troubleshooting Tips:
- Checkpoint Creation on the VNX
The most common issue when running the isi_vol_copy_vnx command is with checkpoint creation on the source VNX.
If you are receiving a message that’s similar to msg SnapSure file system creation failed during a copy session, the command is failing to create a snapshot of the source file system. It could be due to many reasons including a lack of available disk space. Try manually creating a snapshot on the source VNX file system to see if it fails, below is the syntax to do so:
#fs_ckpt Test_FS -name Test_FS-ckpt01 –Create
- Permission or Connection Issues.
In general the error message itself will be self explanatory. Make sure you are using the correct credentials for the NDMP user in the migration command. The user should have sufficient rights on the source system and target systems. The logged in user should be able to create and modify directories and the files contained within. As an example, in the case below, NDMP Port 53169 is blocked between the VNX and the Isilon. Opening the port on the firewall resolved the issue.
ISILON568-1# isi_vol_copy_vnx 10.10.10.10:/Volcopytest /ifs/data/Volcopytest -sa Volcopytest:Volcopytest -sport 53169 -full -dhost 10.10.10.11 system call (connect): Connection refused Could not open NDMP connection to host 10.10.10.10 isi_vol_copy_vnx did not run properly
3. 32bit Unix Application Issues.
If your app is 32bit, 32bit settings on the new NFS export must be enabled.
ISILON# isi nfs exports modify EXPID –zone=NFSZone –return-32bit-file-ids=yes Replace the EXPID with the ID of the target export, verify the bit settings by viewing the export. ISILON# isi nfs exports view EXPID –zone=NFSZone | grep -i return ISILON# _
4. Snapshot creation on the target Isilon array.
Snapshots can fail for many reasons, but most often it’s due to lack of available space. In the example below the snapshot creation failed because there was an existing snapshot with the same name.
ISILON568# isi_vol_copy_vnx VNX-SERVER3:/Test_FS/NFS01 /ifs/data/Test_NFS01 -sa ndmp:NDMPpassword -incr Snapshot with conflicting name ‘isi_vol_copy.011.1.snap’ found. Remove/Rename the conflicting snapshot to continue with further migration runs. snapshot already exists ISILON568-1#
Either delete or rename the existing snap to resolve the issue. In the example below the snapshot was deleted.
ISILON568-1# isi snapshot snapshots list| grep isi_vol_copy.011 134 isi_vol_copy.011.0.snap /ifs/.ifsvar/modules/isi_vol_copy/011/persistent_store 136 isi_vol_copy.011.1.snap /ifs/.ifsvar/modules/isi_vol_copy/011/persistent_store ISILON568-1# ISILON568-1# isi snapshot snapshots delete –snapshot=134 Are you sure? (yes/[no]): y ISILON568-1#
