Corvettes and Open Replicator
by Jesse on Sep.18, 2008, under General
Ok – Maybe that was just a shameless attempt at grabing attention.
You know how you sit two cars side by side, say maybe an older, 1970′s corvette, and a brand new 2009, and compare them?
The 1970′s corvette in this metaphor is an old Symmetrix 8830. I love the 8830. It was by far one of the most solid machines EMC ever built.
I also love the 8830 because like the 1970′s Corvette, I can work on it. The DMX4 is so locked down that if I want to do something as simple as pull a binfile so I can export the volume map to a spreadsheet, I have to call in the CE to do it, and HE has to call EMC and generate a token.
[snark]I understand the need for security and change control, and I understand that customers were demanding that the systems be locked down, but there comes a point when you’re interfering with your own employees/contractors’ ability to work.[/snark]
The customer I’m working on right now is moving from an 8830 to a DMX-4. It’s quite the jump, and it’s been…well….fun….sort of…
8830 –> DMX4 SRDF is a one way trip. The only thing you can do if it doesn’t work is go back to the point in time that you split the RDF link. That means if anything was changed after the split and before the decision to go back is made, that’s lost and has to be reproduced the hard way (by re-entering the information after the fail-back is the usual way)
It went smoothly, and I’m glad, becuase there were enough problems with this account before I came into it. Now comes the fun part – configuring Open Replicator for a reverse replication for Test/Dev, which is going to be staying on the 8830.
Essentially it’s SANCOPY for DMX. This is a good thing because when you’ve got the basics the details fall into place.
The gotcha I ran into, and something of note. When replicating a device, you have to zone *ALL* of the ports that device is visible on to the target array. So if the device is presented to the host on 3aa/3ba/14aa/14ba, you have to zone all four of those ports across the fabric to the remote ports, even if those ports are only 3aa/14aa.
Otherwise any attempt to create a replication session will end with a cryptic error that bears almost no realationship to the actual problem
I hate that. 
Dont you just wish it would say something like “Hey Bozo – you’re zoning is wrong.”
September 18th, 2008 on 7:08 am
I’m fairly sure that the zoning requirement is only if you’re doing a hot push or a hot pull. OR can migrate the data from Sym to Sym over only a fraction of the total ports if you’re doing a cold push or cold pull. At least, I’ve been able to do it that way in testing.
September 18th, 2008 on 8:00 am
I believe that’s the case – but haven’t tried it or seen it so I don’t write it.
Since the systems I’m migrating are super extra special production, I have no option but hot push.
Sorry – I should have written that however I get stuck on this “if i haven’t seen it it doesn’t work” bent sometimes.
September 18th, 2008 on 1:31 pm
That’s correct — for a hot push/pull, all the FAs that a control device is mapped to must be able to “see” the associated remote device… so you’ll need to configure zoning/masking for all control FAs. For a cold copy, you only need a single path (although more is generally better).
September 18th, 2008 on 2:07 pm
I figured as much. I don’t see that it would be a good idea to leave that unzoned anyway, It seem to me you would always want to give yourself the option of doing a hot-push/pull. Because you never know when you’ll need it.