RM/SE to RM 5.1 migration

Hi George,

Well, if you are using RM/SE, I would expect you may have a smallish number of jobs. My recommendation to you, while it is possible to install and upgrade to RM 5.0 and then upgrade to RM 51, I would simply perform a clean uninstall of RM/SE and install RM 5.1 instead.

Here in RM 5.x, you have one RM server (Server/Client architecture) as opposed to Client peer - Client peer architechure, so the management is streamlined, so creating and configuring your appsets, shouldnt take too long.

The advantage also with RM, is you can create storage pools, so you can lock down what clones are used in what jobs, so you have better storage control.

So, in terms of what you are mentioning about assigning replicas, its all ok. As long as the mount host (be it the RM server or another designated host) is in a Clariion Storage group and with a permanent lun assigned to it, RM will know to add the replica LUNs to that storage group in order to mount.

Remember, in RM, you have one Clariion Storage Group for clone luns, which is not configurable, EMC Replication Storage. So be sure to put all your clone luns into that storage group (and none other).

Cheers
James.

Hi James,

Thanks very much for your post. I understand how both RM/SE and RM operate. I have carried out a few RM/SE implementations in the past couple of years. I recently did the 5 day RM5.x training course provided by EMC to their partners here in Australia.

Let me see if I can explain myself better:-

When you run a clone job in RM/SE for the first time, it creates a "replica pair" between the source LUN and an unused LUN located in the RM/SE equivalent of the EMC Replication Storage Group. So the next time that job is run, a full re-sync is not required because this replica pair has been established.

If I do a clean uninstall of RM/SE and then install RM 5.1, RM will have no knowledge of these replica pairs, correct? I'll be forced to setup the EMC Replication Storage Group with a bunch of empty LUNs and re-create my clones from scratch, correct?

If what I've written is correct so far, what happens if I need to access the data in any of my existing clones that were created with RM/SE? My theory is that I'll have to either (a) find some empty space on the CLARiiON with which to create a new bunch of clones LUNs in, or (b) assign the existing clones to my backup server via Navisphere Manager, back them up to tape (so that I can restore them when needed), destroy and re-create the clone LUNs and assign them to the EMC Replication Storage Group, which means that full re-syncs will need to be done when I get RM going. Am I right?

The same proposition would be the case for not only clones, but snaps and SANCopy's as well, right?

Thanks,
George.

Very welcome

Why was the RM/SE migration function stripped out of RM5.1? Didn't it work properly in RM5.0?

When I did the RM5.x training, the "RM/SE migration to RM5.0" lab worked fine.

George.

Ahhh, thanks James

I did not realize that RM is able to"honor" existing clonegroups. That's cool to know.

Thanks, George.

Hi George

No, if a source and clone lun are in an existing clone group (a relationship), which would have a valid fractrure log to allow for incremental syncs, then you can indeed uninstall RM/SE and install RM and those relationships will persist.

RM does not break down clonegroups during uninstall. RM will only ever take a clone out of a clonegroup if it has no choice and that is the only clones available for a job. So, that was on to my point, but sure to create storage pools for your jobs and add those existing clones for those old jobs and config your new job to use those pools.

RM is also clever enough that it finds the best match for replication during storage selection. It will "cost" each potential clone lun and see which one already has an existing relationship and so the clone which is in a clone group already will be used.

All you are doing here is moving those clone luns into a storage group for RM, not affecting relationships.

Snaps will need to be re-created, but thats at no cost, they dont stay around very long anyways. SanCopy sessions will need to be started from scratch alright to fit in with the way RM uses particular schemas in naming and whatnot for those.

Hope this helps

James.

It worked properly in RM 5.0 no doubt.

But like any product cycle for migrations, the defined migration plan was RM/SE 3.1x to RM 5.0 which co-incided with a good overlap of the end of life of RM/SE and the GA date of RM 5.0.

Cheers
James.