We've expanded our Celerra over the last few years and ended up with many of the original filesystems on the initial DAEs getting a disproportionate amount of the Disk I/O. I'd like to get some feedback on various data redistribution strategies that I can see available to us. Note that we are using AVM and the automatic storage pools so far.

We have been using the system clarata_archive storage pool and have the option of adding the latest DAE expansion to the same system storage pool or creating a new user storage pool.

Celerra LEVEL

1. Dumb data migration.

This would work (crudley) by creating new filesystems that will through the greedy policy that AVM uses use the newly available volumes. We then move data manually using robocopy/emcopy/NDMPCopy. Horrible, but has the advantage of allowing some user level cleanup of the filesystems at the same time (never a bad thing). We use a mix of DFS and user home locations in such a way that we can update these elements with little interruption.

2.1. Filesystem replication within the same storage pool.

Does DART even allow the use of replicator V2 within the same pool? It seems to. The new FS like for the Dumb strategy would end up on less full raidgroups.

2.2. Create the new user storage pool and use replicator V2 to shift the data.

I know this works: https://community.emc.com/docs/DOC-9221 The downside is that we add another storage pool that we don't absolutely require.

Both 2.x options from what I understand require some downtime while the mounts, filesystem names and VDM associations are reworked to make the filesystems available again (as per doc linked above).

Clarrion LEVEL SANCopy/LUN Migration

As far as I know this is not an end user supported operation on an Integrated Celerra? We don't have the SANCopy license anyway

OTHER?

Is there some other way I've missed to force re-distribution of the filesystem data? With other volume management tools like LVM it's easy to tell the system to vacate a particular physical volume. What I'm after here is to tell certain filesystems to move off certain volumes (The LUNS passed from the Raidgroups). All I'm really after is to move some of the existing filesystem volumes (metavolumes) to the new LUNs. Not even a complete LUN migration.

Many of the Copy on write filesystems out there automatically take advantage of new disks simply through their COW allocation policy, i.e. with no sysadmin intervention.