Basic question on creating volume groups for service guards

[Kurz]

Hi,

I'm confused about how to create a volume group on 2 nodes for use in a ServiceGuard environment.

The physical storage is actually on 2 EVA systems (will be mirrored later), and I have created VGs with EVA storage groups successfully before.

So far, I did the following:

# ioscan -kfn > /tmp/ioscan_hp6_12_Juni_2008_before.txt
# insf
# ioscan -fn > /tmp/ioscan_hp6_12_Juni_2008_after_insf.txt
# re.txt /tmp/ioscan_hp6_12_Juni_2008_after_insf.txt <
131a132,133
> disk 100 0/3/1/0.101.18.19.0.6.7 sdisk CLAIMED DEVICE HP HSV200
> /dev/dsk/c12t6d7 /dev/rdsk/c12t6d7
157a160,161
> disk 101 0/3/1/0.101.19.19.0.6.7 sdisk CLAIMED DEVICE HP HSV200
> /dev/dsk/c14t6d7 /dev/rdsk/c14t6d7
297a302,303
> disk 98 0/7/1/0.102.18.19.0.6.7 sdisk CLAIMED DEVICE HP HSV200
> /dev/dsk/c16t6d7 /dev/rdsk/c16t6d7
323a330,331
> disk 99 0/7/1/0.102.19.19.0.6.7 sdisk CLAIMED DEVICE HP HSV200
> /dev/dsk/c22t6d7 /dev/rdsk/c22t6d7
#
-> Devices found ok.

Persistent device files on hp6:

# ioscan -m dsf | grep t6d7
/dev/rdisk/disk94 /dev/rdsk/c10t6d7
/dev/rdsk/c8t6d7
/dev/rdsk/c18t6d7
/dev/rdsk/c20t6d7
/dev/rdisk/disk102 /dev/rdsk/c16t6d7
/dev/rdsk/c22t6d7
/dev/rdsk/c12t6d7
/dev/rdsk/c14t6d7
#

Don't bother about the mirror now, let's just assume I only want to use /dev/rdisk/disk94

Next, I would do:
pvcreate /dev/rdisk/disk94
mkdir /dev/vg50
mknod /dev/vg50/group c 64 0xhh0000
...

I think this will be no problem on the 1st node.

What I am confused about, is how do I proceed on the 2nd node. My main concern is: If I create a map file vg50.map on the 1st node, it will certainly refer to the physical device /dev/rdisk/disk94?

This would not be very helpful on the 2nd node, because after insf there the device file name will be different. How do I create a ServiceGuard compliant configuration and still tell the system the correct device names somewhere? (Mirroring not considered.)

best regards,

M. Kurz

[Ivan Krastev]

Don't bother about device files.
Whan you export vg to map file, LVM writes VGID in this file.

After importing to another node, LVM will look for disks with the same VGID's and will use it for this VG.

regards,
ivan

[Anka]

If you only use the -m option while exporting and importing then you should point the disks which the VG should contain.
#vgimport -v -m /tmp/vg01.mymap /dev/vg01 disk1 disk2.....

if you use the also the -s option together with the -m option when you export and import the VG, then every disk is scanned and checked if it will match the VGID. If so it is added to the VG that is imported:

#vgimport -v -s -m /tmp/vg01.mymap /dev/vg01 <- no disks are specified!

See the man page for more infos, there is a short explanation vgimport(1M) and vgexport(1M)
Note that you should export the VG in preview mode (-p option) with -s or/and -m option in order to be able to import also with the -s or/and -m option.

[Kenan Erdey]

Hi,

if two node's hardware is the same and you do the the same configuration device file names should be same. But no problem if they are different. lvm cares vgids. when you run vgimport in the other node you will have the same vg with same disks

Kenan.

[Stephen Doud]

The goal is to update /etc/lvmtab on other nodes such that they have an accurate representation of the volume groups that are shared. That includes the correct disk special files that represent the disks that belong to that volume group. To that end, there are 2 procedures to do this. The most common way is to create a map file that contains the VGID at the top of the file, copy it to the other node(s) and then on the other nodes, vgimport using that map file and allow LVM locate the disk special files to load into /etc/lvmtab. The less common but valid way is to vgimport the volume group on the other node(s), specifically mentioning the same disk special files of the disks representing the volume group, but in a different order than a VGID-based map file would help LVM find them. The latter method is only used when specific load-balancing is needed.

Using 'vgexport -p -v -s -m vg50.map /dev/vg50', the resulting map file only contains the following:
line 1: the unique VGID of the volume group
lines 2-??:
first column: a list of logical volume numbers
second column: actual names of the logical volumes. The second column is used to preserve custom names.
Note that no special files are identified in the map file.
If the VGID is represented (-s option used), then '-s' is required on the vgimport, to match the special files that comprise the disks in the volume group. If the VGID is not present in the map file, the user must explicitly identify the disks during the vgimport.
Hence the more common procedure is:

On the node where the VG was created:
# cd /etc/lvmconf
# vgexport -pvs -m vg50.map /dev/vg50
(This does not export the VG (per -p flag) but simply creates the map file)
# scp vg50.map :/etc/lvmconf

On the other node where /etc/lvmtab needs to be updated:
# ll /dev/*/group
Use this output to identify the next free minor number, or verify the same minor number the VG used on the first node is available for use on this node (preferred).
# mkdir /dev/vg50
# mknod /dev/vg50/group c 64 0xNN0000 (NN=unique minor number)
# vgimport -vs -m /etc/lvmconf/vg50.map /dev/vg50

This last command will identify the correct special files, load them into /etc/lvmtab, and create the special pseudofiles that represent the custom logical volume names in /dev/vg50/

[Court Campbell]

Your question has already been answered, but I wanted to point out that this info is also contained in the serviceguard manual which should have come with the software. If not it can be ordered and can be found at docs.hp.com.

http://docs.hp.com/en/B3936-90079/ch05s04.html#d0e10936

[Kurz]

Hi,

thanks for all your help! I was working according to the manual here, but I wanted to understand what I was doing. I was checking the map-File, but could not see any device file information in it, so I was wondering if it worked also if the device file names are different. They are, BTW.

The manual just says: "In the event that the device names are different on the different nodes, make a careful note of the correspondences." - It doesn't really say how to use the information.

I had to do some disaster recovery, because I accidentally hit ENTER in the middle of a command (SHIT),
executing "vgimport -s -m /tmp/vg55.map /dev"
instead of
"vgimport -s -m /tmp/vg55.map /dev/vg55"

I had to vgexport /dev to get rid of it.
This caused /dev/config to disappear and not even ioscan worked. After restoring the file and doing an ioscan, device files were back, vgimport worked, but the non-persistent names have changed now :-(.
I hope they weren't used elsewhere...
(So, don't ever do this...)

vgimport worked, but it uses the non-persistent device files only, and this is not what I wanted. I will retry and follow the suggestion to specify the device names in the command line.

best regards,

M. Kurz

[Kurz]

Thanks for all your help!!!
Sorry for dividing up the points, obviously you can give maximum points for all answers.

[Rita C Workman · Accepted solution]

Whatever point the vendor was trying to make, may be applicable in other platforms.

For HPUX, relax the O/S will "remember". So don't worry about different c-t-d- for the the same disk on different nodes. And don't worry about them changing. The VGID is still on the disk - so the server will find it just fine.

/rcw