System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

Changing SAN on MC/SG cluster questions

 
SOLVED
Go to solution
Gino Castoldi_2
Honored Contributor

Changing SAN on MC/SG cluster questions

Hi

Servers: rp5470, HPUX 11.11 MC/SG (2 nodes), SAN (EMC SYM)

We are moving our 2 servers to another SAN (EMC SYM). My understanding is that in order for the cluster and systems to see the new disks we need to make configuration changes - Create new volume groups, LVM changes, quorum disk, change the cluster configuration, etc.

Does anyone have a list of procedures on what needs to be done?

10 points to any answer.
Thank you
-Gino
3 REPLIES
Calandrello
Trusted Contributor
Solution

Re: Changing SAN on MC/SG cluster questions

dear
this can be done in two ways
Firstly
you will use the disks that are now associated with the server in the new SAN
if this is necessary you should make the zonning that these disks are seen by the OS on the new SAN
run the command
vgexport-s -m -p vgname /tmp/vgname_map
after the new SAN you should recognize the disks with the command insf
and then importing the map created vgimport /tmp/vgname_map
If you plan to use new disks
just create new vgs
new lvols
change the scripts cluster /etc/cmcluster

Wim Rombauts
Honored Contributor

Re: Changing SAN on MC/SG cluster questions

Do you have MirrorDisk/UX available on your server ? If so, that could make the migration easier, since you could mirror the database on the old storage to the new storage, while you can keep one database instance operational.
Otherwise, you will probably have to make a cold copy, and shutdown your database completely during that time.
Steven E. Protter
Exalted Contributor

Re: Changing SAN on MC/SG cluster questions

Shalom,

1) Take a cold backup of any data. Things can go wrong.
2) Connect new SAN, pvcreate the new disks.
3) Stop the cluster
4) use lvextend -m 1 lvol_name new_disk

Step 4 requires mirror/ux. It will permit you to back copy the data very quickly. There are SAN utilities that are even faster.

5) Make changes to cluster configuration. Change you lock disk.
6) cmquerycl/cmcheckconf/cmapplyconf

Step 6 will have you end up with a new, hopefully working cluster.

The lesson here is to cover you options ahd schedule downtime. This can not be done safely on a running system, especially a database server.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com