This post is more than 5 years old
10 Posts
0
5895
January 5th, 2012 01:00
migrating existing file system to new file system within the same celerra
Hi,
We are planning to migrate some existing file system to newly created file system within the same celerra to reduce the backend raid group workload. How should I do it? What is the best practice? With Celerra replicator? Can we do it without service outage?
Can someone guide me the step by step procedure.
Appreciate your help.
Regards,
Fahis
No Events found!
christopher_ime
2K Posts
0
January 8th, 2012 21:00
When you created the replication session, you likely assigned the desired storage pool (for file) and kept the default "None" when prompted for the VDM. This is actually the right choice as it would have errored if you tried to select the same VDM as the source filesystem. On a side note, if you are instead running Unisphere 1.1, you wouldn't even be able to select the same VDM as the source (when using the loopback interconnect) as it filters it out from your choices. You also could manually create a new filesystem on the same VDM (with of course a different filesystem and mountpoint name), and then Replicator would let you select it as an "Existing File System". However, you are going to be performing a series of unmounts, filesystem renames, and mounts anyways so the fact that you are replicating from a filesystem on a VDM to one on the physical DM really doesn't matter when we are dealing with migrations. On the other hand, it would make sense for an ongoing replication but that is a different use-case and has other considerations.
For the sake of the procedure below, the example environment is as follows:
- "FS" = original filesystem
- "FS_replica1" = new target filesystem
- From the information provided, I am assuming just CIFS is involved
- Default mountpoint directory naming which is to use the same name as the filesystem
In general, to perform a filesystem migration as you proposed, the process would be as follows:
1) Create filesystem Replicator session using loopback interconnect:
a) Provide the Destination Pool and keep default of "None" for VDM
- It will create a filesystem and mountpoint appending "_replica1" and assign to the physical datamover
- Again, it would error if you tried to select the same VDM as the source (when using loopback interconnect)
b) Or, you can manually create the target filesystem
- Can be on the same VDM as the source but of course requires different filesystem and mountpoint names, but for the migration (not ongoing replication) you are going to be performing a shell-game anyways.
2) After the replication session has finished its initial sync and when ready to perform the cut-over, select "Switchover" on the replication session
As part of the Switchover:
a) Any queued up changes are flushed from the source
b) Source filesystem: FS becomes R/O
c) Target filesystem: FS_replica1 becomes R/W
d) At this point, the CIFS shares are still available but R/O because as they are still pointing to the original mountpoint.
- As you will note throughout the process, the CIFS shares are never touched; just the filesystems mounted to the mountpoint the CIFS shares are associated with
3) At this point, you would then have to delete the following for the remainder of the process (specifically the filesystem renaming) to work:
a) Replication Session you created in step #1
b) Any checkpoints associated with the production filesystem
4) Unmount both filesystems: FS and FS_replica1 as follows:
a) Under "Mounts" tab, I recommend first taking a screenshot of the options on the original FS along with expanding the "Advanced Options" for reference later when you remount
b) While still on "Mounts" tab, select "Delete" on both of the filesystems
- unmounts filesystem (and deletes the mountpoint directory)
- It goes without saying make sure you are not on the "File Systems" tab as "Delete" has a different context there (of course)
5) Rename the filesystems
a) From the GUI, select the original filesystem: "FS" -> Select "Properties" -> rename to "FS_old"
b) Select the new filesystem "FS_replica1" and rename to "FS"
6) Remount just the new filesystem "FS" (you can leave "FS_old" unmounted at this point)
a) From the GUI, select the "Mounts" tab and select "Create"
b) Select the filesystem "FS", assign to the appropriate VDM, and use the options from the original mount (that you copied from step 4)
7) Test your CIFS shares
8) Delete "FS_old"
The process above used steps via the GUI; it is trivial to map the functions in the GUI to the proper CLI command. The commands of interest would be:
1) server_mount
2) server_umount
3) server_mountpoint (where the GUI unmounted/mounted and also deletes/creates the mountpoint with the supplied path, it is two steps in the CLI)
4) nas_fs
5) nas_replicate
Hope this helps. Again, this is a general overview and should be considered as a "template" for your migration strategy. As Rainer noted, please test first with non-production data.
Rainer_EMC
4 Operator
•
8.6K Posts
0
January 5th, 2012 05:00
Or create a small test file system on your production machine to practice the procedure
How the “cutover outage” will look like depends on whether your are using CIFS or NFS
dynamox
9 Legend
•
20.4K Posts
0
January 5th, 2012 05:00
Celerra Replicator or nas_replicate command, see this manual for instructions on how to setup replication session. Yes there will be an outage but very brief.
Using Celerra Replicator (V2) 6.0.41 A03
If you want to practice the process, grab this Celerra simulator and test test test
VNX File Simulator (OE 7.0.35.3) - One Data Mover
Fahisk
10 Posts
0
January 5th, 2012 22:00
Hi Dynamox, Rainer
Thanks for your reply.
Is it possible to unmount the destination file system from Physical DM and mount it into VDM. I did some test and the replicated file system is automatically mounted on Physical DM after the replication. So now I need to unmount the source file system from the VDM and need to mount the destination file system to that mount point. Appreciate your help.
Regards,
Fahis
Fahisk
10 Posts
0
January 8th, 2012 22:00
Hi Chris,
Great explanasion. Thanks alot.
Regards,
Fahis