LVM scripting

[Robin King_1]

Hi guys/gals

I've got a server rebuild to do this weekend, and I'm changing the LVM structure. To save myself some time, I want to script the LVM stuff. I'm on my own here, as far as HLVM knowledge is concerned, so would someone mind proof reading the attached command schedule for me. It's just to create vg01, vg02 and vg03 using PVG's, and strict mirroring.

Thanks in advance.

Robin

[John Poff]

Hi Robin,

I took a quick look at it and it looks good to me. Have fun!

JP

[Robin King_1]

Thanks John.

[Victor BERRIDGE]

Hi Robin,
I had also a quick look and it lookes fine to me also, but to add something -)
I would have started with a script that creates the VGs like:
cd /dev
umask 022
mkdir vg01 vg02 vg03;
mknod r5vg01/group c 64 0x010000
mknod /dev/r5vg02/group c 64 0x020000
mknod /dev/r5vg03/group c 64 0x030000
echo "VGs are created !!! "
then create all the lvols since newfs is almost the same this part would be in loops...

I would then append to /etc/fstab rather than editing it...

Now I wonder if I woulnd mirror before restoration - here It would be cool to have others comment the pros/cons...

Good luck
All the best
Victor

[Todd McDaniel_1]

Looks really good. I like the way you did the major number by using the VG#.

In your lvcreate commands you dont have the full LVOL listed only the VG... those commands will fail if you dont name a LVOL there...Here is your line...

lvcreate -s g -L 23200 /dev/vg02

Should be this:

lvcreate -s g -L 23200 -n lvol /dev/vg02


Also,one thing I like to do is name my LVOLS with a unique name that signifies the Filesystem it would be mounted by.

for example:

/dev/vg01/lvol1 mounted by /apps/oracle

I would create the LVOL as:

lvcreate -s g -L 1300 -n oracle /dev/v01
lvcreate -s g -L 1404 -n oraexp /dev/vg01

Just my personal way... but it makes the LVOLS very clear what they go to... and saves time by doing so.

[Robin King_1]

Victor. In the actual script, that I've created, I have actually put echo statements in to show the status, but I see your point about the structure. I was also wondering about the mirroring.

Todd - Thanks I would have missed that! I appreciate what you are saying about the names as well. I have done that at other companies, but I have to keep to the "standard"

Thanks for you help guys.

[Patrick Wallek]

Just to clarify.... If you do not use the '-n name' option of lvcreate, then the LV will be created with the default name of lvol#, where # is the next available number.

I also prefer using the '-n' option and name my LVs something a bit more descriptive, but if you must keep with HP-UX lvol# names....

[Todd McDaniel_1]

Understand Robin on the naming...gotta do the company way.


Patrick,

yes I know, but I rarely if never use the standard naming convention for LVOLs... It makes more sense for me to do them by application and use for naming, just my preference.

I do use the standard naming for VGs on the host, but application and other VGs I use VGxx or VGxxx numerical values only.

[Victor BERRIDGE]

Robin,
Just curious, how are your disks connected?
Because if you are using 2 interfaces, why arent you using alternate pathing - and if not what the use of having mirroring (HA) if on single controller (SPOF)?
As of standards I use prefixes on th vg names to remind me what I did e.g.
r5vg01 (vg01 in RAID 5)
S4vg02 (vg02 striped on 4 disks)

All the best
Victor

[Robin King_1]

Victor

The disks are on two seperate channels. Am I going to gain much in performance by alternating the primary disks on each controller?

[pétot stéphane]

hi
just a little thing for you
do a vgcfgbackup it can save you .

for your script it seems to be a good script but you can reduce numbers of line of your script with some for loops . for your mirroring you can a do a little lvsync.

i suppose that your filesystem may have some oracle database and maybe you ll have some file with a filesize > 2Go then do a
mkfs -F vxfs -o largefiles .....

[Todd McDaniel_1]

Alternating paths will give you some advantage of using more than one path for data...

In normal setup,whichever path is the ALT path will never be used until the PRI path fails, so many folks subscribe to alternating which controller has the PRI and ALT, so that you can at least send data down both channels on everyother disk.

This gives you some additional bandwidth. For OS filesystems it is negligible, however, for DB filesystems you get an increase in bandwidth... I would also recommend Striping DB filesystems if you can.

If your disks are all local, I dont know that you get that much advantage from this config, but if you have a Frame of somekind (emc, compaq) you should be running Powerpath or SecurePath to give you the maximum bandwidth which forces data down all paths all the time.

As opposed to merely alternating paths where the second channel is never used, except incase of a failure of the Primary path.