Operating System - HP-UX
1833875 Members
1541 Online
110063 Solutions
New Discussion

Online McData SAN migration for ServiceGuard cluster

 
Francis van Dun
Occasional Advisor

Online McData SAN migration for ServiceGuard cluster

Hello,


We have an old SAN (2 x McData ED-1032) for some HPUX 11.11 ServiceGuard A11.16 two node clusters with EMC PowerPath running Oracle RAC with LVM and Veritas CVM 3.5.

We need to move to a new SAN (2 fabrics with McDatas ED-140).
We wanted to build the new SANs completely seperate from the old one, but KEEPING THE SAME DOMAIN ID and move the HP's one path at a time. This would have allowed an online migration.

But it seems the old McDatas have domain id 33 and 34.
The new McDatas start domain id's at 97. So were are in a pickle.

My questions:
Is there any way to online migrate a dual attached Service guard/RAC cluster to another SAN? I think the cluster lock will need a reboot?

Alternatively:
Does anybody know how to set the domain ID of the McDatas ED-140 directors to for example 33 or 34?

Many thank's in advance for a way out

Francis
4 REPLIES 4
Stuart Abramson
Trusted Contributor

Re: Online McData SAN migration for ServiceGuard cluster

I think that the RAC is the problem. You can't change the cXtYdZ device file names on one server while the other server is running. The VGs are shared in "shared" mode, not in "exclusive" mode.

I think that you are going to need an outage...

Off the top of my head...

If you were running "normal" MC/ServiceGuard, where the VGs were shared in "exclusive" mode you could remove the Alternate Link, replace the 2nd path with the new SAN connection; vgextend in the new path; remove the other old path; add in the 2nd new path. Then vgexport/vgimport the whole VG to the other side. But you can't do those kinds of trickw with RAC.
Stuart Abramson
Trusted Contributor

Re: Online McData SAN migration for ServiceGuard cluster

Also, I don't know how to change the Domain ID of a running switch.

BUT if you try to do that I'm going to bet that that would crash your servers. All of the cXtYdZ device file names depend on the Domain ID of the swithc.

So, you'll need an outage for that...

See what the other folks say, but I'm thinking outage.

Also, try asking "emc_list@yahoogroups.com"...
Tim Nelson
Honored Contributor

Re: Online McData SAN migration for ServiceGuard cluster

Here would be my initial plan, not sure what wrench SG would play.

Add new switches to current fabric ( i.e. zone the new switches in to the old )

connect a storage path to the new switches, leave an existing path on the old.

connect a server path or move one path to the new switches

zone the new server and storage path

assign storage to new path if needed

ioscan and insf to disover and create devices files for new path

powermt check, config and save

add new path to VG so it shows as alternate

check ios down new path

remove old path

repeat all the above for the other switch/path, repeat all the above for the SG node.

I am sure something here is out of order, or may have missed a step but this should give you an idea. Now, how does SG respond to this ???

Some of this assumes you have extra FA ports to allocate to the new switches or can take away from the old.

Put in the plumbing, check all the connectors, turn on the water and look for leaks, turn off the other valves and away you go :) ( I think this is how a submarine works )


Francis van Dun
Occasional Advisor

Re: Online McData SAN migration for ServiceGuard cluster

Thank's for the replies.

But I think I will need to look a bit further.

We are using EMC powerpath and not pvlinks.


Thank's,

Francis