MC Service Guard Help.

[Muda Ikhsan_3]

Hi i have 2 host. that clustered each others.
let say host A and host B. the host A is the primary server. if i added vg or changed the vg in server A, than i have to import it into server B.
Anybody knows how to do it ? i know it using vgexport to create a map file. but i afraid if i don't use the correct command it will erase my vg.
Thank you,

[Sridhar Bhaskarla · Accepted solution]

Hi Muda,

Export the affected VG completely on host B. On host A create map files and use them to import the VG on host B. Say, the affect VG is vg01.

#vgexport vg01

host A:

#vgexport -p -v -s -m /tmp/vg01.map vg01
#ll /dev/vg01/group

Note the minor number say 0x010000. Copy /tmp/vg01.map onto host B into /tmp. Note the 'p' option. It only does a preview export.

host B:

#vgexport vg01
#mkdir /dev/vg01
#mknod /dev/vg01/group c 64 0x010000
#vgimport -v -s -m /tmp/vg01.map vg01

Don't run any 'vgchange' commands as the VG is already activated on host A.

-Sri

host

[John Poff]

Hi,

It's not hard to do. Just follow the second example in the 'vgexport' man page:

vgexport -m my_vg.map -s -p -v my_vg

It will give you a warning that my_vg is already activated, but don't worry. It won't hurt anything. Then you can copy the map file to your second node and use the vgimport command. Again, use the second form in the man page. I follow it exactly and it works every time.

JP

[Muda Ikhsan_3]

hii.. and if i just added new Vg on hhostt A..am i only need to do vgexport in host A and import it inot host B ?

[Sridhar Bhaskarla]

Yes. The procedure I mentioned remains the same except that you won't be doing 'vgexport vg01' on host B as vg01 won't be there on it.

-Sri

[Muda Ikhsan_3]

any re-configuration i have to do in the cluster configuration ?

[Muda Ikhsan_3]

oh ya.. sorry can i do it online ? while the application are running.. i'm using SAP with informix DB

[Sridhar Bhaskarla]

Hi,

If you are changing the VG (like adding an LV or a PV etc.,), then all you have to do is to ensure you make changes to your package control file and when you get a chance, make sure you test them out.

If you are adding a new VG, then you have to be very careful. Best bet is to shutdown the package, add the VG to your cluster configuration file and VG and filesystems to your package control file, re-apply cluster configuration and start the package. However, if you don't want to distrub the cluster, ensure you do the following. This may not be supported by HP however.

1. Make the VG cluster aware.

vgchange -a n vgxx
vgchange -c y vgxx
vgchange -a e vgxx

2. Mount the filesystems.

Edit your package control file and add the VG and filesystems.. You have to be very careful here otherwise halting of your package may fail. When you get an outage window, shutdown the package, add the VG to your cluster ascii file and re-apply cluster configuration.

Make sure you synchronize all hte configuration files across both the systems.

-Sri

[Geoff Wild]

Yes - adding a vg and or a lvol can be done online.

For more info, see chapter "7 Cluster and Package Maintenance ", section "Reconfiguring a Cluster" of "Managing Serviceguard":

http://docs.hp.com/hpux/onlinedocs/B3936-90079/B3936-90079.html

That lists changes you can do to both a running and halted cluster.

Rgds...Geoff

[Ranjith_5]

Hi Muda,

The following steps are needed to perform the re-import of an LVM cluster VG. We assume that a cluster volume group vg01 with minor number 0x010000 needs to be re-imported.

Steps for the node that has the VG active:

1. Create a mapfile:

node1# vgexport â v â p â s â m /tmp/vg01.map vg01
Warning messages indicating that the VG is active should be ignored.


2. Copy mapfile to each other node (rcp, ftp, etc.)

node1# rcp /tmp/vg01.map node2:/tmp/vg01.map


3. Note VG minor number and permissions/ownership:

apps1:toor-/>telnet 172.17.112.141
apps1:toor-/>ls -al /dev/vg01
total 12
drwx------ 2 root sys 1024 Sep 13 03:07 .
dr-xr-xr-x 35 bin bin 5120 Oct 21 19:51 ..
crw------- 1 root sys 64 0x010000 Sep 13 03:07 group
brw------- 1 root sys 64 0x010001 Sep 13 03:07 lvol1
brw------- 1 root sys 64 0x010002 Sep 13 03:07 lvol2
brw------- 1 root sys 64 0x010003 Sep 13 03:07 lvol3
crw------- 1 root sys 64 0x010001 Sep 13 03:07 rlvol1
crw------- 1 root sys 64 0x010002 Sep 13 03:07 rlvol2
crw------- 1 root sys 64 0x010003 Sep 13 03:07 rlvol3
apps1:toor-/>


4. Export the VG:

node2# vgexport vg01


5. Re-create VG directory:

node2# mkdir /dev/vg01


6. Re-create VG group special file, use minor number noted above.

node2# mknod /dev/vg01/group c 64 0x010000



7. Run vgimport using the copied mapfile:

node2# vgimport â v â s â m /tmp/vg01.map vg01
Messages indicating that no backup for this VG may exist should be ignored.


8. Change permissions and ownership of the VG directory and its device special files
according to the information noted above.


9. Test the activation of the VG in read-only mode and perform vgcfgbackup:

node2# vgchange â a r vg01
node2# vgcfgbackup vg01
node2# vgchange â a n vg01


Hope this will clear ur doubt.There are lot of procedures available on docs.hp.com. You can even refer those too for m

[Ranjith_5]

Muda,
I find some probs while reading the commands.

So reposts the same.

The Re-Import VG Procedure
-------------------------------------------------------------------------------------------

The following steps are needed to perform the re-import of an LVM cluster VG. We assumethat a cluster volume group vg01 with minor number 0x010000 needs to be re-imported.
Steps for the node that has the VG active:

1. Create a mapfile:
node1# vgexport â v â p â s â m /tmp/vg01.map vg01
Warning messages indicating that the VG is active should be ignored.

2. Copy mapfile to each other node (rcp, ftp, etc.)
node1# rcp /tmp/vg01.map node2:/tmp/vg01.map
...
Steps to be performed on each other node:

3. Note VG minor number and permissions/ownership:
apps1:toor-/>ls -al /dev/vg01
total 12
drwx------ 2 root sys 1024 Sep 13 03:07 .
dr-xr-xr-x 35 bin bin 5120 Oct 21 19:51 ..
crw------- 1 root sys 64 0x010000 Sep 13 03:07 group
brw------- 1 root sys 64 0x010001 Sep 13 03:07 lvol1
brw------- 1 root sys 64 0x010002 Sep 13 03:07 lvol2
brw------- 1 root sys 64 0x010003 Sep 13 03:07 lvol3
crw------- 1 root sys 64 0x010001 Sep 13 03:07 rlvol1
crw------- 1 root sys 64 0x010002 Sep 13 03:07 rlvol2
crw------- 1 root sys 64 0x010003 Sep 13 03:07 rlvol3


4. Export the VG:
node2# vgexport vg01

5. Re-create VG directory:
node2# mkdir /dev/vg01

6. Re-create VG group special file, use minor number noted above.
node2# mknod /dev/vg01/group c 64 0x010000

7. Run vgimport using the copied mapfile:
node2# vgimport â v â s â m /tmp/vg01.map vg01
Messages indicating that no backup for this VG may exist should be ignored.


8. Change permissions and ownership of the VG directory and its device special files
according to the information noted above.

9. Test the activation of the VG in read-only mode and perform vgcfgbackup:
node2# vgchange â a r vg01
node2# vgcfgbackup vg01
nod