HNAS to Dell Unity NFS Export Migration Guide for Managed Linux Hosts
On October 31st, 2019, the Hitachi NFS hardware will be retired. The replacement Dell Unity NFS appliance is in place and ready for data migration. This article is a guide for performing data migration. However, data migration is the responsibility of the service owners.
More information about the storage change can be found on the storage teams wikis:
NFS Export Inventory
- Create an inventory of all the HNAS (aka "old") NFS exports in use by the service hosts, (the hosts on which each export is mounted and the mount points.) Permanent mounts are listed in the /etc/fstab file, the ‘df’ command will list all exports currently mounted on a system.
- Identify the applications and processes that use the HNAS export and how (e.g. active or scheduled read / writes) on each host. All read / writes must be stopped during the final rsync. The "lsof" command can show active processes currently using the export
# lsof OLDNFS:/export_name
- For each HNAS export, identify the matching Dell Unity (aka "new") export. This information is required and will have been sent via email from the ITS Storage team.
Unity NFS shares are available on the NFS servers as listed below.
Mounting the Export
The new export can be mounted with the NFS server hostname or IP address followed by the export name. For example, the export path for the test_export export on the NFS server ducp1-nas01.austin.utexas.edu can be mounted in one of two ways shown below.
Copying the data
Transferring data to the new NFS export will requiring mounting the new export, copying the data, removing the old export and then remounting the new export. How long it takes to copy the data will depend on how much data there is and if it is being actively used. If the old export is being actively used, multiple syncs may be needed with all activity being stopped before the final sync is performed. For each export, select a server (on which the export is mounted) for the copy operation. This server should have available CPU, memory and disk resources plus good bandwidth.
(See footnote below about rsync options)
- The new NFS export should be mounted at a temporary location such as /mnt and use the same version NFS as currently using.
# mount -t nfs NEWNFS:/export_name /mnt
- Use rsync to copy the data from the old NFS export to the new one.
# rsync --exclude .snapshot -avh /src/dir/ /mnt
- If the source export is in use by an application, the application will need to be stopped and a final rsync be performed. Use the applications preferred method to stop the service.
# service application stop
- To ensure that no application is writing to the source export it can be remounted as read only. Then do a final rsync.
# mount -o remount,ro OLDNFS:/export_name /src/dir
# rsync -avh /src/dir/ /mnt
- Next unmount the both the original source NFS export and the new one.
# umount /src/dir
# umount /mnt
- Edit the /etc/fstab and replace the OLDNFS:export with the NEWNFS:export
- COMMENT OUT /etc/fstab: OLDNFS:/export_name /mnt nfs rw,hard,nosuid,noac,intr,vers=3 0 0
- ADD /etc/fstab: NEWNFS:/export_name /mnt nfs rw,hard,nosuid,noac,intr,vers=3 0 0
- Mount the new NFS volume
# mount /src/dir
- Restart any application that may have been stopped during this process. Use its preferred method.
# service application start
Other rsync options that may be needed are A, H, or X if you need to preserve ACLs, hard links or extended attributes.
Note: It is important to remember NFS volumes may be shared. All services that access the NFS share on all hosts must be stopped during the final rsync and the new mount must be setup on all systems at that time. So, if there the same export is on three prod systems, the final rsync must be done while service on all three is stopped and then move to the new mount on all three systems must be done concurrently.