Open Replicator sessions

It'll be 1 session with 10 device pairs. You can have up to 512 device pairs running in 1 or in more than 1 session, as long as there are no more than 512 device pairs.

The 512 is the value for the latest (and greatest) OR. the one I used about one and a half year ago only supported 128 device pairs.... (version 6.2 if I remember correctly).

thanks for the reply RRR

so if i have a Meta of 4 meta members(8 GB each) at the control side and a Meta of 2 meta members (16 GB each)on the remote side, then this would be counted as a 1 of 512 device pair limit. Did i get it right????

Karan

Luckily Open Replicator has worked very well for us so far and we have used it to migrate about 3 dozen host so far. We have not run into the recreate issue that you described at all.

The EMC PS team involved has commented that the newer versions of OR are a lot more robust and stable than it was just a year or so ago. Originally they were not recommending it, but as I mentioned our options were more limited with the LUN size change.

We are in the process of doing Open Replicator sessions to migrate a lot of our Windows fleet and you definitely can do mismatched meta-sizes as long as the target meta-LUN is the same (and I mean exactly the same) or larger size wise.

In fact that is the whole reason we are using OR because SRDF requires you to go like-to-like since it is copying at the symdev level where OR looks at the device as a whole LUN.

In our case we are going from 7GB hypers to 16GB hypers so for the most part all of our metas have less than half of the devices of the source.

Knock-on-wood the process has worked nicely though I think it is more labor intensive than doing an SRDF configuration...

Now that I think of it again, you are right. We migrated from metas which used 8.5GB symdevs to metas which used 17GB symdevs. Correct ! It works !

The one problem I faced a lot was that the recreate failed from time to time and the only way to solve this was to release the lock 9's, terminate the session and restart that partucular session from the beginning.

thanks Rob, i will go through the documentation.

so they just had to diskpart them to see the extra space ? have you migrated any *nix boxes ? If you have to go to bigger metas ..that extra space is lost forever ?

so as long as the target meta device is the same size as the source meta device regardless of underlying hyper size ..it's ok ?

Which version were (are) you using ?
My migration was almost 2 years ago with OR 6.2 or something. Enginuity code was 71.something (we had to move from 70 to 71 for this, they said).

Another issue we were seeing was that with AIX hosts that used SRDF, whenever we started an OR session, SRDF and Or seemed to fight for control over the control devices and the AIX lost connectivity to the lun's. We had to use cold push for those hosts (cold means create BCV's from the control deviices and have OR replicate these BCV's as soon as they are split from their sources).

The short answer is "it depends" on the specific *nix and the version they are at.

In our case we did not use OR because the Unix team was comfortable using VG commands to either mirror or move things within the VG which meant no outages for them. With OR you'd have at least a short outage for a "hot" copy or a longer outage for a "cold" copy which they did not want to take.

For Windows 2003 you just run diskpart and expand the volume into the space. There are a few caveats - you can't expand boot or pagefile volumes and you can only expand a single volume within a partition (i.e. more than 1 partition in a volume does not work) but otherwise it is pretty painless.

For *nix it totally depends on the specific OS, but most of the big ones like AIX, HP-UX, Solaris, etc. have support at their latest releases to expand a LUN dynamically. You have a better change of the VG settings causing you problem...

Same size or larger then yes it will work like a champ. You have to watch rounding - we got burned by one volume that was like 1 or 2MB too small on the target end when you did the rounding...

We've used the later to grow a few volumes in the process of the migration which has been one of the few benefits we have provided to our support teams for all of the work they have had to do

cool ..thank you for Open Replicator 101