topic Re: PVG vs. VG in Operating System - HP-UX

PVG vs. VG

Marius Paulauskas — Thu, 16 May 2002 03:38:16 GMT

Hello,

Can anybody explain the difference between using physical volume groups and not using them. Why it is important to use it to have "true" mirroring? If I create volume group with vgcreate, then vgextend with one more disk (on different controller) and when creating logical volume specify to keep mirror copies on physical volumes (check box in lvcreate SAM page) that should do everything since it supposed to ensure mirror copy will go to separate physical device. What advantage or extra features PVG does provide?

Thanks,
/Marius

Re: PVG vs. VG

Tom Geudens — Thu, 16 May 2002 03:45:46 GMT

Hi,
Imagine an SC10 rack with 2 controllers. Some of the disks are on 1 controller, some on the other. For high availability you would want a logical volume to be created on a disk that is on one controller and mirrored on a disk that is on another controller. However, the concept of "controller" is unknown in LVM. Hence PVG's. You create one for the disks on one controller, another for the disks on the other controller, make your logical volumes PVG-strict ... and you are set.

Hope this explains,
Tom

Re: PVG vs. VG

S.K. Chan — Thu, 16 May 2002 03:55:18 GMT

In my own way I call it a "dirty" mirror vs a "clean" mirror. Imagine you got 4 disks (A,B,C,D) and you're going to setup you VG.
Clean-mirror
============
You would setup the VG by putting A and B in PVG1 & C and D in PVG2 when you create your VG the first time using "-g" option to define the PVG name. Now when you create you LVs and you want to mirror say 1 copy you would want the mirrored copy to reside in a separate PVG instead so that you know your mirrored copies are always in PVG2 for example. This would also help in disaster recovery situation. The "lvcreate" command has "-s g" option that tells it to do a PVG-strict mirror. Going forward extending your existing LVs would just be a straight forward "lvextend" since it was already defined as PVG-strict.
Dirty-mirror
============
You setup the VG in a normal manner. In the creation of your LVs, if you simply say mirror 1 copy and let LVM figure out where to put it's mirrored copy then you may end up in a siuation whereby your mirrored copy can reside anywhere in A,B,C,D even on the disk where the primary copy sits ! Having said that you can actually tell lvextend to put your mirror-copy to a specific disk but then you would have to keep track of the PEs, etc, etc. If PVG is setup this is done automatically.

Re: PVG vs. VG

Marius Paulauskas — Thu, 16 May 2002 05:11:30 GMT

Tom:
in vgextend you actually define specifically which disk to include. Hence, you can put in say two disks which are on different controllers. There is full control on that in vgextend. I kind of agree with K.S. that in case of two same size disks only PVG does not really give any advantage. But if there are larger groups it is probably easier to manage.

Re: PVG vs. VG

Tom Geudens — Thu, 16 May 2002 05:37:41 GMT

Hi,
I agree with S.K. as well, but take the follwing configuration (to explain my explanation) :

root/sv00138#more /etc/lvmpvg
VG /dev/vgdisk138
PVG original
/dev/dsk/c0t1d0
/dev/dsk/c0t0d0
/dev/dsk/c0t2d0
PVG mirror
/dev/dsk/c6t0d0
/dev/dsk/c6t1d0
/dev/dsk/c6t2d0

Now, when I create a filesystem, can create this on a disk in PVG "original". If I lvcreate the logical volume PVG-strict, the mirror will automatically be on PVG "mirror", thus ensuring the mirror is on a different controller.

Regards,
Tom

Re: PVG vs. VG

Duncan Edmonstone — Thu, 16 May 2002 07:07:47 GMT

My argument would be why not use PVGs? What reasons are there to not use them?

Here's two good reasons to use PVGs:

1. OK, so *you* know where each disk is, and what channels to mirror down, so with careful planning and diligent use of the LVM commands you can ensure I/O seperation without using LVM.

But what about some other admin/operator in your company? Maybe a Solaris admin who isn't familiar with HPUX, maybe the poor sap they hire when you leave for that dream consulting job in Barbados!

Anyway... an inexperienced sysadmin might just go and use SAM to extend a logical volume in your non-PVG volume group... this only has to happen a few times to result in chaos (believe me I've seen the result of this situation!)

Using PVGs would have prevented this to some extent (OK so if they created an entirely new LV they wouldn't be bound by PVG-strict), and they're very simple to use, so why not?

2. If you are working in a MCSG environment there are certain resource monitors (EMS HA monitors for disk - the pv_summary metric)which are dependent on you using PVGs... without them the system cannot successfully work out whether you still have access to your data from a particular node.

HTH

Duncan