HP UX Cluster Migration from one SAN to another

[Mahesh_20]

Hello,

We are migrating a very very mission critical HP UX cluster from one EVA storage to another EVA storage.

I have gone through other threads regarding similar concern. However this migration differs from others in a sense that we are having a new sets of SAN switches as well.

So situation is existing cluster is connected to one set of SAN switches and EVA storage. We will be coping the data from one EVA to another EVA using using mx100 kind of device. Then we will be disconnecting the hosts from existing SAN Switches and EVA storage; reconnecting them to new SAN switches and new EVA storage.

Although we are very much clear about the Data migration; we are little skeptical about how to migrate VGs specially when they are part of cluster packages.

One good thing is; although the it is mission critical cluster; we have DR site and we are going to switch over to DR site during this activity hence shutdown; reboot is not an issue.

Now the help required is - Steps that we should take to migrate VGs in UX cluster on existing storage to new storage. If someone have done this exercise in already; please share your experiences.

Any kind of help would be highly appreciated.

If any further information is required; please let me know.

Thanks in advance.

Best Regards.

[Kapil Jha]

Ths thread gonna help u

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=619265

Over here you are changing the SAN switches so u gonna have different c#d#t# names, nothing complecated you just have to export and import with -s option.
Or you can move current lvmtab and do a "vgscan"

Take care of LOCK disk of cluster you will have to change it.

I think thats all (i wish m not forgetting anything)

BR,
Kapil+

[Olivier Masse]

The easiest way if you can afford downtime is doing it offline, possibly by recreating the volume groups from scratch and using a backup/restore. vgexport/vgimport won't be of much help since you'll be using new disks which don't hold any data. But you'll still need to do a vgexport -p/vgimport shenanigan to synchronize your VGs across your cluster once your done.

Some people also use LVM mirrors or Continuous Access to synchronize data between EVAs and switch from one to another online or almost-online. A third path is pvmove; depending on how much data you got you might find it actually easier to do it completely online using pvmove, but pvmove is more risky than an LVM mirror. Both procedures are complex and have lots of steps (especially if you boot on SAN) but can save you trouble in the long run. If you're not comfortable doing it yourself and have a migration budget, HP services have specialized teams in data migration who can possibly help.

Good luck

[Mahesh_20]

Missed a couple of points.

1) We have local boot disks.We are not booting cluster members from SAN disks.

2) We can not attach both the SAN simultaneously hence LVM mirror is ruled out.

3) We are pretty confident of Data migration using storage devices; little bit of help from LVM side to migrate cluster would be helpful.

Regards

[Torsten.]

If you move the data from EVA to EVA, you should take a mapfile from a preview vgexport of the "old" EVA and do a vgimport with the new array. If you have access to the "new" VGs, make sure to import this configuration to all cluster members.

[Viktor Balogh · Accepted solution]

Hi,

We do this procedure on a weekly basis for 3 months now, we a have pretty large DC to migrate. We do it offline, here are the steps:

1. create a LUN list:

no. of source box
no. of source LUN
size of source LUN

no. of target box
no. of target LUN
size of target LUN

2. check the above excel sheet with a script - the sizes should be at least equal (or the target lun should be bigger)
every source lun should have a pair on the target side
every visible lun should be in the list
etc...

3. ignite backup

4. downtime in monitoring system

5. create a list of external volume groups (excluded vg00 and vg01)

6. saving the output of read_lvmtab for further checking (contains the number of luns in every vgs)

7. serviceguard autostart off (/etc/rc.config.d/cmcluster), confidence reboot

8. exporting all external vgs - use the '-s' option for vgexport! (with a for loop, use the list generated in step 5)

9. shutting down both server, after it they can be de-cabled from the old SAN

10. data migration...
during the offline migration the servers can be restarted for patching and for ioconfig consolidation...

http://viktorbalogh.net/blog/hp-ux/hp-ux_sysadm/reorganizing-io-tree-general-steps

11. after patching shutting down the server for recabling to the new SAN

12. ioscan, insf...
if the luns were not detected check the FC HBAs with fcmsutil for link

13. import the vgs with a for loop (see list in step 5), use the '-s' option to vgimport!

14. compare the output of read_lvmtab with the old one (step 6), the no. of luns should be the same for each vgs, check if all vgs were succesfully imported

15. start the cluster and the packages, check package cntl logs, optionally enable cluster autostart if it was on

[AlexZhang]

I would do it online with LVM mirroring. You will have to let the servers see the new SAN&EVA. After that, just mirror the data from one EVA to the new EVA,which is totally online, then reduce the orignal copy on the old EVA. the concept and procedure will be the very simple.

[Viktor Balogh]

>I would do it online with LVM mirroring.

AlexZhang, read above carefully, this is not an option:

>>2) We can not attach both the SAN simultaneously hence LVM mirror is ruled out.