HP Service Guard question

[Bankrupt]

Dear Experts,

I am implementing a data migration service from a SAN to another SAN Storage in HP Service Guard.

My idea is to use pair up the SAN LUN using mirror to migrate the data from old SAN to new SAN. However, during this migration, I have to cater for the cluster.

Can I mirror the shared disk of the cluster by one of the server only?

Will there be any issue when the resource is failover to the passive node?

Should I stop the cluster service when working on this mirror using HP LVM mirror?

The Cluster is HP-UX active-passive Oracle.

Ban

[Zygmunt Krawczyk]

Hi,

I recommend stop the cluster and copy data volumes by dd command.

Regards,
Zygmunt

[Wim Rombauts]

You can start mirroring on 1 system, but then the LVM configuration is no longer correct on the other system, and you can run into serious trouble in case of a failover.
The absolute safest way is to stop your application (then there will be bo risk for failover), and then mirror or dd your data to other disks.
Even if you could start mirroring, what would you do with the mirrored copies ? They belong to the same volume group, and the only way to get those disks out of the volumegroup is to destroy the information on it. And if your current SAN storage isn't capable of taking a mirror copy of disk contents itself, I doubt that it has an intelligent way to move LV's out of a VG without destroying the data.

[Rajeev Shukla]

Hi Ban,
It is absolutely safe to migrate all your data from one Storage to another storage using mirroring.
I migrated all my data (disks) in MC/SG from XP256 to VA7100. Mirror the complete cluster and then split them to remove the old storage. You dont need to stop the cluster for migration, however there is a overhead on the system depending on the total size to be migrated.
Also the only time you need to stop the cluster, when you are changing the cluster lock disk.
Also consider using pvmove, that also will help in acheiving this result.

Cheers
Rajeev

[G. Vrijhoeven]

Hi Ban,

I agree. This is a good method to migrate data between two SANs. Just mind the lock disk.
I like to add one reminder. If you go for mirroring do not forget that the LUN sizes between two different SAN's can vary and so the PE size can give you problems.

You can only do it one server at one time per volumegroup.

If you have a failure during mirroring there can be a qourum problem when starting on an other server. This can be resolved manualy vgchange -q n.

When the data is mirrored reduce the primary and do a vgexport -p -v -m mapfile -f devfile vgname
copy this to the other nodes and do an vgexport and reimport the new config ( mind the instance numbers)

HTH,

Gideon



Regards,

Gideon

[Geoff Wild]

You can mirror - if room for pv's in your volume group - however - your cluster lock will have to change - small outage as you will have to re-apply your cluster ascii file...

If not enough room in the vg, then use vxdump/vxrestore to migrate the data - again, you will neeed an outage for that as well...

vxdump -0 -f - -s 1000000 -b 16 /tempmountold/oracle | (cd /oracle ; vxrestore rf -)


RGds...Geoff

[Bankrupt]

Thanks for all the suggestion.
Actually I have to think of a minmized downtime solution.
The time for Oracle & Application to be restarted = 1hr.

In conclusion would it be possible to do it like this?
1. Create mirror pair.
2. Wait until the mirror is completed.
3. Stop the Cluster, Application & Oracle
4. Split the mirror
5. Reconfigure the cluster lock disk
6. Start the cluster, Application & Oracle.

[Geoff Wild]

Should work - but, to split the mirror - you will have to remove the cluster membership first for all vg's in cluster:

vgchange -c n /dev/vgXX

then activate them:

vgchange -a y /dev/vgXX

reduce the mirror...then make them cluster aware again with a
vgchange -c y /dev/vgXX

To be honest though, I don't see why you can't do that while the cluster is up...

Like so:

1. Create mirror pair.
2. Wait until the mirror is completed.
3. Split the mirror
4. Stop the Cluster, Application & Oracle
5. Reconfigure the cluster lock disk
6. Start the cluster, Application & Oracle.
7. vgexport -s -v -p -m /tmp/vgXX.map /dev/vgXX
8. copy the map to the other node
9. on other node, vgexport /dev/vgXX
10. mkdir /dev/vgXX and mknod /dev/vgXX/group c 64 0xHH0000
11. then import: vgimport -s -v -m /tmp/vgXX.map /dev/vgXX
12. Health check - fail package(s) over to other node to make sure they work.

Rgds...Geoff

[Ralph Grothe]

Geoff,

when I have to copy filesystems I also prefer the various dump/restore tools (according to the underlying filesystem).
But I'm curious.
What puzzles me in your statement is that you specipfy a tape size with the -s option, which when I interpret vxdump's manpage correctly, simply waits for change of media, when this threshold in the dump has been reached.
This makes absolutely no sense to me when you don't use any tapes at all but pipe the dump in another process.
Could you tell me the supposed effect?



-s size size is the size of the dump tape, specified in feet.
When the specified size is reached, vxdump waits for
reels to be changed. If the -d option is specified, a
default size value of 2300 is assumed a for a reel
tape.

[Geoff Wild]

Basically, what I'm doing is "faking" out vxdump into thinking that my tape size is huge - if you don't, it may not be able to backup say a large file system - I know, sounds strange when going from disk to disk of same or larger size. Can't remember where I got that - but I know it works. I believe there is a default in vxdump - don't know what it is at the moment...

Rgds...Geoff