CIFS Migration using Celerra replicator V2

Hi,

Please go through the VDM replication part from the Celerra replicator document.

Sameer Kulkarni

I simply wanted to expand a bit on this. 

1) Check DART compatibility

Firstly, you need to make sure you are running compatible versions of DART.  If you aren't running the same version of DART on each array, make sure you are at least compliant per the NAS Support Matrix available on PowerLink via the following breadcrumb trail:

Home > Support > Interoperability and Product Lifecycle Information > Interoperability Matrices

[...]

System Requirements for Replicator v2

Following are the Replicatorv2 system requirements:
• NAS 5.6 or greater is required for Replicator v2.
• Replicator works with any backend systems supported for Celerra and VNX File..
• Replication between DART 5.6.x and DART 6.x and VNX File 7.x is supported with DART 5.6.47 and higher.
• Total storage capacity per DM (including Replicator SavVol and SnapSure SavVol) not exceed the limits listed in the NAS Interoperability Matrix.

[...]

Also review the PDF for other considerations such as various maximums related to replicator.

2) White Paper: "Migrating Data from an EMC Celerra Array to a VNX Platform Using Celerra Replicator"

This is a good walk-through of the process, and is available on PowerLink via the following breadcrumb trail:

Home > Support > Technical Documentation and Advisories > Hardware/Platforms Documentation > VNX Series > White Papers

Even though the target array in the paper is a VNX, you should be able to follow along since the interface for the Replicator configuration hasn't really changed (once you find the page they are referring to in the guide). 

3) CIFS server (along with the corresponding filesystems) must be mounted on a VDM (not the physical data mover)

What the whitepaper assumes though, is that your CIFS server on the source array is already assigned to a VDM.  If it instead is mounted to the physical data mover (along with the associated filesystems), then you'll want to follow the instructions in the following KB article before you begin:

emc170111: "How to move a CIFS server from a physical Data Mover to a Virtual Data Mover (VDM)"

4) Reference Guide: "Using Celerra Replicator (V2)"

You should also download a copy of "Using Celerra Replicator (V2)" for reference as needed.  It is available from PowerLink via the following breadcrumb trail:

Home > Support > Technical Documentation and Advisories > Hardware/Platforms Documentation > Celerra Network Server > Installation/Configuration

5) Additional features (not handled by replicator)

Then there are other things that you will need to plan for such as enabling/configuring on the new array those features which were in use on the original such as:

1) NDMP

2) CAVA
3) FTP
4) Usermapper

etc...

The actual data itself will of course get copied via Replicator, but there are features/integration that would need manual intervention such as enabling any relevant services, recreating users (DHSM, NDMP, etc), redefining or export/import of configuration files, etc.

Thank You, Christopher for the detailed explanation.

I did go through all the documents you suggested and started the replication between the NS-20 (5.6.52) and NS-120 (6.0).

I was able to successfully replicate the VDM and the file systems that are mounted on the VDM.

The problem is when I finally decided to move them to the NS-120, I stopped the VDM replication and changed the state of the VDM to loaded state. And for the file systems I just switched them over, so that the file system on NS-20 became r/o and on the NS-120 they became r/w. When I changed the state of the VDM to loaded the CIFS servers and the shares that are on the VDM appeared on the NS-120.

But when I tried to map the share on the server they are still mapping to the source NAS NS-20 and the share became r/o.

The CIFS server name and share names are the same.

Did I miss to do anything or did I do anything wrong as it is still seeing the old share which is r/o.

Please let me know if I have to do anything during migration.

Thank you,

Harsheeta

Christopher,

Every step you explained here was correct. I did not want to switch over the VDM because there are other files on the VDM which I don’t want to move to the NS-120. That’s the reason I manually loaded the VDM on the NS-120.

Let me explain my situation. We have a NS-20 on which we have both prod and non-prod files. We bought a new NS-120 for production. As a part of moving the prod stuff to the new NS-120 I started the replications.

I this case I have to use the VDM’s on both the NAS devices.

Suggest some way that I will not affect any of the file on both the NAS devices.

Thank You,

Harsheeta

Harsheeta,

It sounds as if you manually manipulated the VDM instead of performing the same SWITCHOVER on the VDM session as you had done on the filesystems.

As the system had done for you on for the filesystems, SWITCHOVER of the VDM performs similarly:

1) Flushes any queued up changes first

2) Unloads the VDM on the source

3) Loads the VDM on the target

4) Binds CIFS server to the "same-named" interface on the target

5) Via dynamic DNS, updates the DNS records to the new IP

As a result of the DNS update, similiarly your clients' DNS records will need to be updated either manually or wait until the next automatic update from your DNS server.  For instance, you could, as you know, instruct the clients to run: ipconfig /flushdns or log out/login in to see the results now.

Having said that though, the way you performed the work on the VDM directly (instead of issuing the SWITCHOVER on the session), you would need to then simulate the steps manually, and I suspect you simply need to unload the VDM on the source, then having loaded the VDM on the target verify DNS record on your DNS server was updated, and then flush dns on the clients (or wait until the TTL expiry as set for your DNS).  Unless you performed it in this manner so you could retain the same IP as the source?

If you have the chance, I'd consider instead performing it again but using SWITCHOVER on the VDM session.  I'll assume you first tried on a test environment first to rehearse it before trying it on production?

#2 should read:

2) Or, (unlikely the scenario), you have filesystems/shares but for the same CIFS server that you want accessible either on "NS20" or "NS120" (but not both)?

So I take it that you have:

1) CIFS server "A" (and its filesystems) that you want to remain accessible on the NS20 and separate CIFS server "B" (and its filesystems) that you want to available from NS120?

2) Or, (unlikely the scenario), you have filesystems/shares but for the same CIFS server that you want accessible either on "A" or "B" (but not both)?

I'll assume the former (#1) above.  In this case, I would definitely recommend each CIFS environment in their own separate VDM so you have the granularity of switching-over one but not the other.  Unless you have information associated with the VDM that needs to be shared between both CIFS server?  The obvious would be a filesystem that you want accessible by both CIFS servers?

The (2) is the scenario that I have right now.

I have file systems that share the CIFS server on both NS-20 and NS-120. I need the same CIFS server for the remaining file systems on NS-20.

So what I understood from your point is to create a separate VDM for the other shares and migrate them that VMD.

Is it that what you said.

Thank You

-Harsheeta

The comment about separate VDM's was for scenario #1 where you have 2 separate CIFS servers in production on the NS20 each which their own filesystems (not shared between the two CIFS servers).  Then you are attempting to migrate that to the NS120.  In that case, having each instance in their own VDM would let you SWITCHOVER one but not the other.  Scenario #2 above as I have described it isn't possible (at least natively) but asked just to make sure I understood your scenario.

I'm not entirely clear on your situation (but it is likely just me); however, what I would recommend is creating a separate thread at this point as you are beyond the basics of using Celerra Replicator for migration and what appears to have a unique use case.  By starting the thread with the details of your situation, it won't be lost in this busy thread.