HP-UX Serviceguard and data migration from EVA 3000 to EVA 6400

[jose da silva]

The environment consists of 2 nodes and an EVA “ currently live environment”. A new EVA will be introduced and the data must be migrated from the old EVA to the new one. The question is what is the best practice taking into consideration also the cluster lock disk?

I thought of several options but do not know which is the most efficient and with no downtime if possible or disruption to the current live cluster.
One of them was to distribute the array disks into the package groups with pvmove command e.g. new disk array lun is /dev/dsk/c0t3d0 and the old EVA LUN is /dev/dsk/c1t2d3” vg03 ,so then pvcreate /dev/rdsk/c0t3d0 and vgextend /dev/vg03 /dev/dsk/c0t3d0 then pvmove /dev/dsk/c1t2d3 /dev/dsk/c0t3d0 > move1.txt 2>&1 etc.

The other which probably would be better is to ensure the new EVA is presented to the primary node and then create new volume groups and then restore the data from a backup of the old EVA to the new EVA luns etc.

The other is to use Continuous Access but without map files to import the luns what would be the lvm implication and cluster.

Or would it be better to mirror the cluster vgs and then break the mirror?

My request is for a guide with step by step procedures on best practices for the above scenario.

[Avinash20]

NO downtime.

Best option is to do Create the same VG's and LV's and do mirroring.

If the mirroring is perfect, you could just switch off the old EVA, and the data access will still be there on the mirror disks.

The better way is to do mirror

lvextend -m 1

and then break the mirror

lvextend -m 0

[jose da silva]

Thanks for the info.
Regarding the cluster lock disk, if it is not part of a clustered volume group would it be necessary to add a second cluster lock disk to the cluster ascii file?

[Sani]

What is ur data size?
Is it a database server?

[jose da silva]

The database size is approximately 850GB " EVA3000 with two disk shelves" which is not that much and it is backed up by HP Data Protector.

The serviceguard nodes are databases " running ORACLE".

[Sani]

Hi Jos ,

If you have CA license , that will be the best option.Otherwise use backup/restore option and oracle replication (data guard).

Regards
Sani

[Steven E. Protter]

Shalom,

Data migration, including the cluster lock disk will almost certainly require a bit of downtime.

Good news is the EVA comes chocked full of GUI tools that can permit business copy between arrays and make it relatively painless.

Factors to consider: A database app is going to constantly be updating the data. If you have online JFS you could take an image and migrate while database writes go to a temporary lvm.

Specifics to your questions.

Useful links, though you may need more than one to cover this operation:
http://docs.hp.com/en/B7660-90019/ch02s03.html

http://docs.hp.com/en/T2346-90008/ch01s03.html

http://docs.hp.com/en/B7660-90016/ch04s03.html

SEP

[Stephen Doud · Accepted solution]

The paths to the current cluster lock disk (from both nodes' perspective) is in the cluster binary file.
$ cmviewconf | grep lock

Therefore, a cmapplyconf is needed to change them.
Page 359 in the 15th Edition of Managing Serviceguard discusses a online configuration change of the cluster lock PVs, but it has restrictions and requires down-time on a node at a time.
http://docs.hp.com/en/B3936-90135/B3936-90135.pdf

[jose da silva]

Hi All

Thanks for your replies and valuable recomendations, I will revise all aspects and come back later if I have more questions.Apologies that I did not responde earlier. THANKS ALL once again