reason for more than one vg?

[Konrad Hegner]

Hi all,

We have to install new HP Servers (rp7400) with HP-UX 11.11 and a special application. I ask myself now, what is better or what for reasons can be for use 2 volume groups (one for HP-UX and one for the application)?
The machines are used only for the application. But not all is installed in the application directory, some parts of the programm is also in the /usr/-directory.

It is today necessary to use more than one volume groups (or why I should use more than one volume group)?

Many thanks! Konrad

[Karthik S S]

There are many reasons for it,

1. Easy of administration.
2. If you want to do some maintenance activities on the application disk which involves deactivating the VG.
3. You reduce the risk of failure in app. disk failing the entire VG00 by having a separate VG for the application.
and so forth ..

-Karthik S S

[Mark Grant · Accepted solution]

There's a good argument for only one volume group in my view. However, taking volume groups offline, moving them to other machines, not exceeding the maximum number of physical volumes per volume groups are all good reasons for grouping volume groups per applciation.

Also, Ignite backups are a lot more annoying if you have everything in one volume group and remeber too, if you accidently break a volume group, you'll be breaking everything if that volume group is your only one.

Most people use vg00 for the OS and swap and create separate volume groups for each major application. Personally, I think this is a waste of disk space but somewhere in the middle is probably a good thing. At least have one for the OS and one for everything else.

On the other hand, if you really don't want to have more than one volume group, you don't have to.

[Mobeen_1]

Konard,
The usual parctise if to have one volume group for your system, which is referred to as the rootvg and then depending on your application you can have one or more additional volume groups for your applications. This is the standard practise followed.

Some of the reasons why there is a need for having different volume groups for system as well as applications are

1. System Recovery
Having seperate volume groups for your
system and application mean that you can
escape from rebuildng your system, in
the event that your application volume
group needs to be recovered.

2. IO Considerations

If you have a database type of application (Sybase, Oracle, etc) on your server, then the tendency is to typically have different volume groups for your data, log and dumps. This is again suggested keeping an eye on the recovery aspects of the RDBMS.

Hope i have given you a clear answer, if not, some one will step in to elaborate

Regards
Mobeen

[Mobeen_1]

Konard,
There you go, Mark has provided some additional insights :)

rgds
Mobeen

[Sanjay Kumar Suri]

Since in your case, the server is going to be used for only one application, one volume group should take care of OS+Application.

So when ignite backups are done application's executable also gets backed up. Please do compare the backup media capacity and the amount of data being backed-up.

sks

[Pete Randall]

Konrad,

It's primarily a matter of personal preference, but I would never mix my application data in with my Operating System. You run the risk of overlaying your app when doing maintenance, particularly where you've got "some parts of the programm is also in the /usr/-directory". I would like to see everything separated into it's own Volume Group.


Pete

[Konrad Hegner]

@mobeen

What you mean with
'IO Considerations'?

Do you think the 'IO consideration' is about the database (the application works with a oracle-db) or is it about 'splitting' the hdd-heads or so?

Thanks Konrad

[Trond Haugen]

If you don't have mirroring and have all disks in on VG a HW problem with one disk would likely render the hole VG useless.

Regards,
Trond

[Edward McCouch]

Look at it this way--when your disks go bad (and they eventually will) would you rather rebuild the entire server or just whatever was on the disk (or disks) that went bad?

My preference is to keep vg00 for the OS and swap only. Mirror it and that will minimize unexpected disk failures taking your system down. Make regular Ignite tapes and system backups. It is much easier to maintain a system when applications are kept in separate volume groups from vg00. It makes recovering the system easier as well. Dependent on the application, it also can help a little with performance by keep the application related I/O on separate spindles.

-Ed

[Victor BERRIDGE]

Well Konrad,
I would look at things a more pragmatical way:
You havent mentionned what configuration you have, whats the point of discussing vg if you have 1 disk, if you have 2 the questions are same size? and do you have mirror-ux?
...
Now if you say you have external devices via scsi or a connection to a san. It seems to be a general rule to use internal disks for vg00 and mirror them, then what is being added to the system on new volume groups , with a few PV in them and use alternate pathing to take advantage of the extra IO bandwith if possible e.g. for oracle I often make use of LVM stripping to emulate dynamic load balancing...

All the best
Victor

[Geoff Wild]

It is better to have more then one vg - mainly because of administration as well it will save you headaches.

For example, if you just use vg00, which is the default system vg, and your app is huge - it might not fit on a make_tape_recovery tape.

Another example - if using Oracle, you want to place redo logs on different disks then data - hard to do in a single vg - esay with multiple.


Here's a guidline I follow:

Vgcreate volume groups as per the following standard
Preamble: VG00 - VG09 are internal disks, VG10 and higher are reserved for EMC.
VG00
The root volume group VG00 should be mirrored and only contain OS files.
Primary swap should be 1 x memory
/ - 140MB (HP Default)
/usr - 1 GB
/var - 1GB
/tmp - 512MB
/stand - 128MB
/var/adm/crash - 1 x memory + 512MB
/opt - 1GB
/home - 512MB with quotas (32MB soft, 64MB hard)
Note: /var/tmp should be a symbolic link to /tmp. /tmp should be 1777 (sticky bit).
VG01
/app - 512MB
/usr/local - 512MB
/app/admin - 512MB
VG02
File system swap
VG03
Applications
VG04-VG09
Reserved
VG10 - VG19
Log volumes (redo, archive, etc)
VG20 - VG256
Data volumes

Miscellaneous
Don't use strict/contiguous when creating logical volumes.
Create file systems with "large file" support (fsadm).
Mount file systems with "delaylog".


Rgds...Geoff