HA Cluster Volume group

[J.N.]

Hi all,

I’m not that deep into UNIX but I can manage.
So, I have HPUX high availability cluster server including MC service guard and two packages. I have successfully created a new (volume group, logical volume and defined VxFS filesystem and set a mount point) on node2 which it’s package is responsible to access this volume group and made it a HA volume group by “vgchange -a n myvg” and “vgchange -c y myvg”. After that I added it to three sections in package2 configuration file (pkg2.cntl).

1)

# VOLUME GROUPS
# Specify which volume groups are used by this package. Uncomment VG[0]=""
# and fill in the name of your first volume group. You must begin with # VG[0], and increment the list in sequence.
#
# For example, if this package uses your volume groups vg01 and vg02, enter:
# VG[0]=vg01
# VG[1]=vg02
#
# The volume group activation method is defined above. The filesystems # associated with these volume groups are specified below.
#

VG[0]=vg1

2)

# FILESYSTEMS
# Specify the filesystems which are used by this package. Uncomment # LV[0]=""; FS[0]=""; FS_MOUNT_OPT[0]="" and fill in the name of your first # logical volume, filesystem and mount option for the file system. You must # begin with LV[0], FS[0] and FS_MOUNT_OPT[0] and increment the list in # sequence.
#
# For example, if this package uses the file systems pkg1a and pkg1b, # which are mounted on the logical volumes lvol1 and lvol2 with read and # write options enter:
# LV[0]=/dev/vg01/lvol1; FS[0]=/pkg1a; FS_MOUNT_OPT[0]="-o rw"
# LV[1]=/dev/vg01/lvol2; FS[1]=/pkg1b; FS_MOUNT_OPT[1]="-o rw"
#
# The filesystems are defined as triplets of entries specifying the logical # volume, the mount point and the mount options for the file system. Each # filesystem will be fsck'd prior to being mounted. The filesystems will be # mounted in the order specified during package startup and will be unmounted # in reverse order during package shutdown. Ensure that volume groups # referenced by the logical volume definitions below are included in # volume group definitions above.
#
#LV[0]=""; FS[0]=""; FS_MOUNT_OPT[0]=""

LV[0]="/dev/vg1/lvol1"; FS[0]="/fs1"; FS_MOUNT_OPT[0]="-o rw"

3)

# NFS: Specifies all exported NFS directories with export options. The # directories must be defined in the above mounted file system FS list.
# These variables are used by the command "exportfs -i" to export # the file systems and the command "exportfs -u" to unexport the file # systems.
# Example: XFS[0]="-o ro /pkg1"
# Example: XFS[1]="/pkg2"

XFS[0]="-o async,anon=65535,root=node1:node2:pkg1:pkg2 /fs1"

I restarted pkg2 on node2, synchronized both nodes and the process went well and everything is up and running so, my question is:
When pkg2 fail over to node1, is the volume group, logical volume and filesystem will be accessible when its running there since I synchronized both nodes and pkg2.cntl will take care of that when it fails over OR do I need to export the volume group and its contents to node1? If so, how?

Appreciate the assistance.

[melvyn burnard]

As this is a shared VG in the cluster you MUST use vgexport/vgimport to update the 2nd node with the VG details.

[J.N.]

Thanks for passing by.
How do I do that exactly???

[madhuchakkaravarthy]

hi

refer to the attachment


regards

MC

[melvyn burnard]

follow the steps as laid out in the Managing Serviceguard manual at:
docs.hp.com/en/ha under the Serviceguard link

[nightwich]

HI J.N.


You need to do something like this:

vgexport -p -s -m /tmp/Vg_you_create.map /dev/vg_you_create


scp to node 1:
scp /tmp/Vg_you_create.map node1:/tmp/Vg_you_create.map


In the node1 do



mkdir /dev/vg_you_create
mknod /dev/vgome/group c 64 0x060000 ( this should be equal to the number in the other node)
vgimport -s -m /tmp/vg_you_create.map /dev/vg_you_create

That's all, If you have any problem please inform.

Best regards.

[J.N.]

Hi,

Thanks everybody. I have three wonders now:
1. I guess I have to work on export/import vg while the volume group is deactivated and the file systems is not mounted, is that correct?
If yes, then how to do so? Is it enough to halt the package that already include that volume group to deactivate it and unmount it? And then start working n export/import things.
2. This volume group include 4 LUNs on my SAN storage but the device files are different between both nodes:
Node1: Node2:
/dev/dsk/c15t2d4 /dev/dsk/c13t2d4
/dev/dsk/c15t2d5 /dev/dsk/c13t2d5
/dev/dsk/c15t2d6 /dev/dsk/c13t2d6
/dev/dsk/c15t2d7 /dev/dsk/c13t2d7
Is that OK? Does the map file of the export volume group will take care of that?
3. After importing the vg, does it import with its contents of logical volume and mount the filesystem? And then all I have to do is to include it the package cntl file to acticate it and mount it.

[RC Park]

I'll try to answer your 3 questions:

"1. I guess I have to work on export/import vg while the volume group is deactivated and the file systems is not mounted, is that correct? "

LVM is usually pretty good about not allowing you to take destructive steps either by refusing to act (and telling you why) or asking for confirmation prior to acting. With that in mind, if you're exporting a VG in preview mode (in order to create the mapfile so you can use that do do your import on the other cluster node), NO, you don't have to have it (the source VG) inactive. If in fact you want to export a VG (remove it from your system), you must first DE-activate it.

"If yes, then how to do so? Is it enough to halt the package that already include that volume group to deactivate it and unmount it? And then start working n export/import things."

I would really recommend you consider that the folks here who answer questions (I don't do this very often) like to see that the person asking the question isn't being lazy. You should make it clear that you've tried things - show the results - that you've read the available docs and checked this forum. Effectively, you're asking this forum to train you for nothing with questions like this - and sometimes, generouse folk respond, AND when they do, please be so kind as to ASSIGN POINTS as soon as you see and value an answer. If you're doing that you'll find this forum MUCH more willing to give you free advice, even if you haven't done your homework.

First of all, as previously mentioned by another response to your thread, there is very good documentation on this available online. 2nd, if your company was wise enough to purchase software support, you can actually put a call in to HP, and if you pose your questions well, they might assist you in getting past any problems you have in getting this put together. This is a complex activity, and I went through 4 HP training courses (each 4-5 days and cost my company over $10,000) to get me ready to do clustering. You might be able to get others to give you nice procedures, but these can be dangerous since minor differences in your configuration can require important changes in procedures, and if you don't have the experience/training to see that, you'll just end up with trouble. Hence, I hesitate in giving you much detail. What would be better? Go read the docs (Have you ever heard the phrase, RTFM?), give things a try, and when you're stuck, present your case here, and folks typically are remarkable about giving GOOD responses that can help you get past your trouble.

2. This volume group include 4 LUNs on my SAN storage but the device files are different between both nodes:
Node1: Node2:
/dev/dsk/c15t2d4 /dev/dsk/c13t2d4
/dev/dsk/c15t2d5 /dev/dsk/c13t2d5
/dev/dsk/c15t2d6 /dev/dsk/c13t2d6
/dev/dsk/c15t2d7 /dev/dsk/c13t2d7
Is that OK? Does the map file of the export volume group will take care of that?

I have had situations like this and it is not a problem, BUT, there are ways (I don't recall immediately) to synchronize the volume labels - but again, it isn't required.

3. After importing the vg, does it import with its contents of logical volume and mount the filesystem? And then all I have to do is to include it the package cntl file to acticate it and mount it.

Sorta works in this order:

1. Export the active VG on node 1 to create the mapfile
2. DeActivate the VG on node 1
3. Change the VG to be shared (and if necessary, cluster aware)
4. On node 2, create the VG devices (must read the docs for this, but it's basically making a directory and creating the character device that represtents the VG (group)
5. On node 2, run vgimport using the mapfile created on node 1 (and copied over to node 2)
6. Assuming that worked (no errors), activate the VG and verify that the LV's are present.
7. Create any associated mount points for the LV's, and manually test the mounting of the FS's.
8. Unmount, De-activate the VG, and go back to node 1.
9. Modify your cluster packace with the necessary info to start/use the associated VG. Save the package file and copy it across to the other cluster node. Check and apply the package config and start the package (note, I never had you reactivate the VG).
10. Review the results - if your VG starts and associated FS's are mounted, you're good. Stop the package and restart it on the other node to verify there, and you're done.