NFS migration from Celerra/VNX to ISILON

I was working on a few NFS migrations from our Celerra/VNX systems to the ISILON systems. I thought of putting a post with the steps and gotchas in a Celerra-ISILON migration. It took so long, and now it is the time for that post.

Our first step should be to identify the hosts accessing the export and to understand the type of applications running on the export. We should work with server/application teams for this and for finding the suitable window for a possible migration window. The size of the exports, network parameters, and the nature of applications being used – we should take many things into consideration as we do the pre-work of the migration. ISILON by default, do not support 32-bit exports running on the NFS exports and this need a special bit setting to be enabled. So, this is one thing we should be ready for as we plan the migration. We will discuss how this is done as we discuss the actual migration steps.

Once we are done with all the pre-works, we will start the migration steps. To reduce the downtime window during the actual data migration, we will run a pre-copy of the data to the target ISILON array.

Create the NFS export directory and a quota on the target ISILON array. While setting the quota limits, we should consider the source FS size. Here I am assuming a 100 GB source FS and setting 90GB advisory threshold on the target directory.

mkdir Test_NFS01

isi quota quotas create /ifs/data/Test_NFS01 directory –advisory-threshold 90GB –hard-threshold 100GB –container yes

You can try listing the quota and it should be showing 0GB as the current utilisation. Now initiate a full copy of the data from the source (Celerra/VNX) export to the newly created directory.

isi_vol_copy_vnx Cel097-dm2:/Test_FS/NFS01 /ifs/data/Test_NFS01 -sa NDMPuser:NDMPpass -full

The isi_vol_copy_vnx utility creates a snapshot of the source Filesystem and initiates data transfer from it. The NDMP credentials on the array need to be used in the command in the place of NDMPuser and NDMPpass. Once done, we have one full copy of the data on the target array. You can now list the quota again and you should be seeing the change in utilisation now.

isi quota quotas list | grep NFS01

Now we are all set for the migration window. (Note: In case if the number of days between full-copy and the actual cutover is high – maybe due to a change in schedule etc… – you may run another incremental copy with incr switch a few hours prior to the cut-over. This will ensure the delta will be less and will help in completing the migration faster.)

The application team will start the migration proceedings by stopping the application instances running on the export. The server team will unmount the exports from their end after all the applications are stopped. We can un-export the source export and this will ensure there are no new writes happening to the export being migrated.

server_export server_x  -unexport -perm /Test_FS/NFS01

We will initiate a final incremental copy of the export to migrate the changes from the source export.

isi_vol_copy_vnx Cel097-dm2:/Test_FS/NFS01 /ifs/data/Test_NFS01 -sa NDMPuser:NDMPpass -incr

After the successful completion of the data transfer, we are good to create a new export on the target directory. We will add the export permissions as in the source export. We will create an NFS alias for the export for our convenience. NFSZone in the below commands needs to be replaced with NFS Zone on your ISILON array.

isi nfs exports create /ifs/data/Test_NFS01 –zone NFSZone –root-clients host1, host2 –read-write-clients host1, host2 –read-only-clients host5 –description Test_migration -f

isi nfs alias create /Test_NFS01 /ifs/data/Test_NFS01 –zone NFSZone

Now the 32 bit part. As discussed already, if your application is 32 bit, you have to enable 32-bit settings on the new NFS export.

isi nfs exports modify EXPID –zone=NFSZone –return-32bit-file-ids=yes

Replace the EXPID with the ID of the target export. You can now verify the bit settings by viewing the export.

isi nfs exports view EXPID –zone=NFSZone | grep -i return

We are now done with the migration. The server team can now mount the new export on the servers and application can be run on the new export.

Next… ?

You may read our post on some of the common issues in migration and their troubleshooting steps.