In the majority of cases, the size of user storage will only continue to grow. However there are a few instances where a NSS volume is too large and the data on it needs to be moved to a smaller location. There has not been a direct method for shrinking a NSS volume or pool, so I will share the method I used to move data from one clustered Pool/Volume to another, without having to create a new cluster resource.
In my case, the problem arose during a migration of my shared SAN storage. The vendor’s LUNs on the new SAN were smaller than on the old, even though the physical drives were the same size. When configuring the NCS cluster the first time, I had simply made my NSS pools the size of the entire LUN, rather than reserving some space for overhead. Lesson learned. An easier solution would have been to simply add more drives to each LUN, however that was seen as a waste of space, as the space actually in use by the Pool/Volume on each LUN was not even close to the full size of the LUN.
For safety’s sake, prior to working with the pools/volumes, I moved all resources off one of the nodes in my cluster and off-lined the resource I was going to copy from. It may be possible to do this with cluster services stopped (rcnovell-ncs stop) but my way doesn’t require that.
In the following steps, either NLVM, NSSMU, or iManager are all acceptable methods for performing the steps. Personally I used NSSMU for this experiment.
On the physical node:
- Create a new pool. In this example I will use source_pool_new.
- Give it no IP
- Do not advertise using NCP, AFP or CIFS
- Do not share it
- Do not make it active on creation
- Activate the source_pool_new pool.
- Create a new volume within source_pool_new. I called mine source_volume_new.
- Optional – create a volume quota, to make sure if the volume gets filled, the pool does not.
- Mount the source_volume_new volume.
- Activate the source_pool holding the volume to be copied.
- Mount the source_volume holding the data to be copied.
- Copy the data from source_volume to source_volume_new. The way this is done is dependent on the type of data on the volume. If it is a GroupWise post office, DBCopy might need to be used. If it is user files, JRB Netcopy might be useful. In any case, get the data to the new location, in as similar a format to the old location as possible.
- Rename source_volume to source_volume_old
- Rename source_volume_new to source_volume
- Rename source_pool to source_pool_old
- Rename source_pool_new to source_pool
- Online the cluster resource. (cluster online resource_name) If it goes online, or comatose, that’s fine. Immediately offline it again (cluster offline resource_name).
- Using iManager, modify the load, unload and monitor scripts for the cluster resource, you have just off-lined again. Remove all traces of _old in each script.
- Double check your work and online the resource (cluster online resource_name). It should pick up the name changes and be using the new location.
- Delete the source_pool_old which will delete the volume as well.
Congratulations, you’ve successfully migrated data to a smaller NSS clustered volume.