mirror, and stripe the pvg

[David Figgins]

Two questions,
first -- I would like reccomendatations on a good book on the subject of lvm, pvg, mirroring etc...

second --

I was wondering if someone would comment on this procedure that I composed. I have had limited exposure to the HP/UX system and was seeking some feedback.

*** introduction ****
I have an application on HPUX-10.20 that I wish to store data on in a
large volume group.

I have 8x 18 gig drives spread accross two controllers, 4 each, in two separate enclosures. c[0,1]t[9,11,13,15]d0

I plan on making two pvg from the redundant hardware and mirroring these.

primary pvg1 (c0t9d0 c0t11d0 c0t13d0 c0t15d0)#physical volume group 1

mirror pvg2 (c1t9d0 c1t11d0 c1t13d0 c1t15d0)#physical volume group 2

these volume groups will contain one 60M logical volume, lvol1.


*** procedure ***

#create/initialize physical drives
pvcreate -f /dev/rdsk/c0t9d0
pvcreate -f /dev/rdsk/c0t11d0
pvcreate -f /dev/rdsk/c0t13d0
pvcreate -f /dev/rdsk/c0t15d0

pvcreate -f /dev/rdsk/c1t9d0
pvcreate -f /dev/rdsk/c1t11d0
pvcreate -f /dev/rdsk/c1t13d0
pvcreate -f /dev/rdsk/c1t15d0

mkdir /dev/vg01
mknod /dev/vg01/group c 64 0x010000

question:
the identifier 0x010000 has to be unique -- across the system or vg01?

question:
this seems like a DANGEROUS command?
#create the physical volume groups.

vgcreate -g pvg1 /dev/vg01 /dev/dsk/c0t9d0 /dev/dsk/c0t11d0 /dev/dsk/c0t13d0 /dev/dsk/c0t15d0

vgcreate -g pvg2 /dev/vg01 /dev/dsk/c1t9d0 /dev/dsk/c1t11d0 /dev/dsk/c1t13d0 /dev/dsk/c1t15d0

#create a distributed logical volume
#with group restrictions and mirror
lvcreate -s g -D y -m 1 -L60000 /dev/vg01
question: this command seems VERY different then the standard drive mirroring commands,
am I missing something???

Use sam to format and mount /dev/vg01/lvol1

[Andreas Voss]

Hi,

sounds to me good.
The identifier 0x010000 has to be unique over the whole system.
Check this with:
ls -l /dev/vg*/group

Regards

Andrew

[Stefan Farrelly · Accepted solution]

Its difficult to find a really indepth book on mirroring/striping etc. on HP-UX, the best ive seen is the more general admin book;
HP-UX 11.X System Administration (Marty Poniatowski)

Now, your disk mirroring plan looks good.
1. Yes, when you use the mknod command the 0x0?0000 value must be unique across all your VG's. do an ll -d /dev/vg*/group to see all your existing ones so you dont use an existing one.

2. All your commands to setup your distributed VG01 look good.

However, the whole purpose of use the -D (distributed) option with PVG's is so that you can mix striping with mirroring. This you cant do normally, have to use -D option (or manual extent based striping+mirroring but thats a long story).
So, if you want to stripe your filesystems across your 2 controllers and mirror them for optimal performance then yes, go ahead, but change the disks in each PVG to rotate amongst your controllers, eg;
PVG0 c0t9d0 c1t11d0 c0t13d0 c1t15d0
PVG1 c1t9d0 c0t11d0 c1t13d0 c0t15d0
Then when you create an lvol across all of them (say 1 60+GB lvol) then you can use the lvcreate -I 64 -i 4 command to stripe them across PVG0, then afterwards use the lvextend -m 1 command to mirror to PVG1. This way your performance will be much better than if you dont stripe them or only stripe on 1 controller.

If you dont want to stripe+mirror then stick to your existing plan, its good.

[Dave Wherry]

I usually do not create the mirror when I create the lvol. I'm more of a control freak and do not like to leave it to the system to decide too many things.
When you do your lvcreate you do not tell it where to create the lvol and the mirror. My preference would be to take out the "-m 1" and add "pvg1" at the end. This way your lvol gets created using extent based stripping on the disks on your first controller.
Next I would do an "lvextend -m 1 /dev/vg01/lvol1 pvg2". This will force the mirror to be on the disks on your second controller.
The result is that if you lose a disk on either controller your are protected. If you lose a controller or disk enclosure you still have a full mirror on the other controller and enclosure.
Maybe lvm is smart enough to handle this. I would be concerned that you could have your primary and mirror for an extent on the same controller. I like more control.
Another result is you will balance I/O a little better. When using mirroring a write has to go to the primary, in this case down your first controller. When that completes the second write to the mirror goes down your second controller. Evenly balanced.
A read is satisfied from the controller with the least pending requests, either the mirror or the primary. Again balanced and the system does a pretty good job of balancing reads.
Maybe lvm will handle this OK. I just prefer to make more of the decisions.

As for a good book. I like Poniatowski's books, but, I think they lack detail. In another shop I worked at someone before me had taken the "Hands on with LVM and MirrorDisk/UX" at HP. I made a copy and it has been my best reference. I have not taken it, but, I suggest taking the course.

[Alan Riggs]

Regarding Dave's concern:

Setting the logical volume to a pvg-strict allocation policy (-s g in lvcreate) will tell LVM to allocate mirror extents only from a distinct pvg. If you have only 2 pvg's in the VG, then this will set up your striped, mirrored lvols appropriately. The advantage of establishing mirrors at creation time is speed. Because each extent need not be physically synced (the lvol is brand new, after all) the command returns much faster than extending a mirror after creation for large lvols.

[Dave Wherry]

Alan,
Thanks for clearing it up. I had not done it that way before. I guess I was still in the mindset of having to be more in controll. Comes from the days before the distributed option.
The end result is the same and the physical volume group method is faster. Go with it.

Dave

[David Figgins]

thanks for the help...
the feed back from those with
experience with the system is great!

I am going to go forward with the plan.


thanks again.

david