Data Migration on Shared VG

[Phil_]

I need to migrate data on a 2-node SG shared VG from one disk array to another.
Unfortunately MAX_PVs does not allow a mirroring option, and management will not allow us to use the unsupported vgmodify to go down that route (11.23).

I am planning on doing the following and would appreciate feedback on this high level process as I do not have a lot of SG experience:

Stop cluster on NODE2 to protect existing VG config for quick backout.
Create NEWVG on NODE1 and copy the data from existing VG01.
Shutdown the cluster on NODE1.
vgexport VG01 and NEWVG on NODE1.
vgimport NEWVG as VG01 on NODE1.
Change the cluster_lock disk in the cluster conf and apply the changes.
Restart cluster on NODE1 and test package with new VG01.
vgimport the new VG01 on NODE2.
Restart the cluster on NODE2.
Test failover.

Will SG allow me to do this or does it store VGIDs/PVIDs somewhere?
Any advice will be greatly appreciated.

[Steven E. Protter]

Shalom,

I believe your plan will work.

You will need downtime as you can't make volume group changes to a shared volume group while its activated in shared mode.

Volume group will need to be deactivated for a short time to implement your plan.

Even the export will fail under these circumstances.

SEP

[AwadheshPandey]

its looks fine. prepare step by step command line procedure before proceeding. it will help u to reduce downtime.

[Duncan Edmonstone · Accepted solution]

Phil,

Where did you get the idea vgmodify wasn't supported from?

See whitepaper here:

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01920387/c01920387.pdf (BSC link updated by admin)

Or is this a Oracle RAC cluster (when you say shared are you talking 'active read-write on both nodes using the vgchange -c y -S y /dev/vg01)

HTH

Duncan

[Phil_]

Last time I looked vgmodify was only supported at 11iv3 - this changes things a lot!

Am I correct in assuming that, apart from a brief outage to deactivate the VG for the vgmodify and to update the cluster_lock disk, the whole process of vgextending onto a second mirror and finally reducing the old LUNs out can be done with the cluster running?

Also, regarding the cluster_lock disk, if I add a SECOND_CLUSTER_LOCK_PV entry for one of the new LUNs and leave the FIRST_ in place, will SG fail to start once the FIRST_ PV disappears, or will it automatically use the SECOND_ PV? Basically, do I need to reconfigure the cluster again before the FIRST_ PV goes, or can I just leave the entry in there until the next maintenance slot?

[Duncan Edmonstone]

>> Am I correct in assuming that, apart from a brief outage to deactivate the VG for the vgmodify and to update the cluster_lock disk, the whole process of vgextending onto a second mirror and finally reducing the old LUNs out can be done with the cluster running?

Yes - although I would advise you to read the whole whitepaper *very* carefully. Make sure you understand exactly what you are doing and once you have a list of commands you intend to run documented, I'd also log a call and get the sequence validated by Support as well.

Of course you need an outage to install the patch(es). The WP doesn't give you all the info here. there are some dependencies and you do need a kernel patch PHKL_36244 so thats a reboot.

Also remember that any large mirror sync operation is going to hit performance, so do it when the system is quiet.

>> Also, regarding the cluster_lock disk, if I add a SECOND_CLUSTER_LOCK_PV entry for one of the new LUNs and leave the FIRST_ in place, will SG fail to start once the FIRST_ PV disappears, or will it automatically use the SECOND_ PV? Basically, do I need to reconfigure the cluster again before the FIRST_ PV goes, or can I just leave the entry in there until the next maintenance slot?

No, you can't do this - the second cluster lock disk is a compound lock - not an either/or. Just change the cluster lock configuration at the same time you run your vgmodify.

HTH

Duncan

[Duncan Edmonstone]

>>"Just change the cluster lock configuration at the same time you run your vgmodify."

I did of course mean 'during the same outage', not literally 'at the same time'!

I'd actually plan to do it after you have completed your vgmodify and vgextends.

HTH

Duncan

[Phil_]

Thanks for the info and your time guys.
I think you have given me enough to put this in motion now.