cluster in hpux

[WilliamSmith11]

Hi
I have a cluster system with the following volumen.
/dev/vg01
/dev/vg02
/dev/vg03
/dev/vg04
/dev/vg05
/dev/vg06

all the disk in these system are 18GB.
I have created a new volomen with disk of 73GB as follow.

/dev/vg07
/dev/vg08
/dev/vg09
/dev/vg10
/dev/vg11

My question is
Witch will be the best way to do that.

Of course I have done a full backup the system.

The system scripts ,...

I will appreciate yor experiences and comments .

Thank you

RP.

[Geoff Wild]

Not too sure what your question is...

Do you mean to migarte data from 18GB drives to 73GB drives?

fastest method to copy is:

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

Rgds...Geoff

[WilliamSmith11]

yes I want migrate the data from this old disk of 18GB to the new one of 73GB, but I want preserve all the cluster properties.

[Geoff Wild]

Well - if you have a cluster lock disk (IE 2 nodes), then you will have to reapply your cliuster - as the dev for the cluster lock will change - if you are removing the old devs/volumes that is.

You could, if room permits in the volumegroups, instead of creating new vg's (like you did), just vgextend the existing volume groups, then use the pvmove command to move the data from the 18GB drives to the 73's.

Rgds...Geoff

[Sridhar Bhaskarla]

Hi Ralph,

One of the issues you may run into if you try to use 'mirror/split' or 'pvmove' is that you will need to add the 73gb luns to the existing volume groups. Unless you paid extra attention while creating the volume groups before with a non-default 'max PE per PV' value, you will not be able to make use of the entire capacity. There is an unsupported tool to modify the VGRA of the current volume group. But there is always a risk in using unsupported tools.

Since you have to create new VGs, you don't have a choice except to copy the data. So, I suggest the following approach.

1. Create new VGs with 73 GB disks.
2. Create lvols of same name as the current VGs and mount them as /nfilesystem1 etc.,
3. Bring down the application/package.
4. Manually mount the filesystems using 'vgchange -a e' and 'mount' commands.
5. Copy the data from the current filesystems to new ones. I used 'cp -Rp' and it worked fine. Or use any other command of your choice. Keep in view the limitations though like unpatched tar not supporting over 2 GB files etc.,
6. Once the copy is over, unmount the old filesystems and mount the new ones.
7. Startup the application if you can, manually and verify that it works fine. Unmount the new LVs and deactivate the VGs.
8. Export the old VGs using 'vgchange -c n vgxx', 'vgchange -a n vgxx' and 'vgexport -v -s -m /tmp/vgxx.map vgxx'.
9. Export the new vgs with map files and import them back with the old names. Repeat steps 8,9 on the failover node.
10. Add the vgs back into serviceguard using 'vgchange -a n vgxx', vgchange -c y vgxx' commands.
11. Edit your cluster configuration file and modify the CLUSTER LOCK devices if you are using. Reapply the cluster configuration after shutting down the cluster.

12. Bring up the cluster and the packages.

-Sri

[Steven E. Protter]

I would personally make a nice fbackup of all this data prior to start with all databases shut down so the copy is cold.

I have no diagreement with the methodology presented.

I would offer the principle of keep it as simple as possible.

You might find it faster to try this general methodoloy:

After restablishing the lock disks you need for Service Guard, set up the volume groups and filesystems and restore from the backup you have.

I've played around a few times with the more esoteric ways of moving data from disk to disk and always fallen back on the simplicity of destroying the old volume groups or logical volumes, building the volume groups logical volumes and restoring from a proven backup. Usually i have an extra tape stashed as well.

SEP