09-19-1999 11:11 PM
Having multiple volume groups is the way to go, the
Root vg should be isolated normally in vg00.
If you can and have the disk to do so you should keep all
of your apps in seperate volume groups. Especially things
like an Oracle database.
Hope this helps
09-21-1999 04:39 PM
That's a very complex subject you've touched on. I reckon you have to look at
the following issues:
1) Response/performance: with one large common VG, it is extremely difficult to
spread the load accross disks and channels, and hot-spots will be common.
2) Managability: while a large common VG is easy to manage, it is extremely
difficult or time-consuming to determine the space usage in a multi-app
3) Expandability: remember that there are certain kernel and VG constraints
when creating large VGs, and if certain params are not set, you pick up
Email me direct if you want more...:-)
09-27-1999 04:07 AM
Sorry about the last empty response, I hit the enter key by mistake. Anyway,
the decision is entirely your own, but my
experience has shown that more volume groups lead to better
segmentation of data. But that can also be done in a strictly LV only
environment. We currently have a system with 680 gig on it, broken down into 6
volume groups. Some of those volume groups have as little as 16 gig in them,
some have as much as
300+gig. My best suggestion would be to decide based on your need for disk
tuning. Data within a specific VG can be manipulated between disks a lot
easier that different VG's.
We use volume groups to identify the type of data that should be loaded. For
example, VG01 is strictly for filesystem data needed by vendor software. VG02
is for user testing filesystems,
and vg04 is for Oracle raw data info. By defining our VG's this way, we can
watch space growth on a larger scale, and charge back disk usage by ownership
of the VG.
10-05-1999 04:31 AM
the OS,applications ,database etc. under different volume groups.This way you
can keep root volume in vg00 and othe stuff under other vgs and you have
flexibility of disks groupings and exporting them and moving them freely.
10-07-1999 07:49 AM
>1) Response/performance: with one large common VG, it is >extremely difficult
to spread the load accross disks and >channels, and hot-spots will be common.
Just the opposite is true in my experience. Small volume groups require
logical volumes to be isolated on a smaller number of drives, and fewer
controllers. For optimally balanced I/O, mirrored and striped logical volumes
should be spread across as many controllers and physical drives as possible.
With one large common VG, or a small number of large VG's, it is actually much
easier to spread the load across disks and channels. Tools like pvmove and
Mirror/UX work only within a single volume group.
>2) Managability: while a large common VG is easy to manage, it >is extremely
difficult or time-consuming to determine the space >usage in a multi-app
I have found a single large common VG, or too few VG's can make it more
difficult to manage your storage. Never share vg00 with anything other than
operating system filesystems/LV's.
I agree that capacity planning is much easier when applications are given their
own volume groups.
My rule of thumb is to isolate vg00 as much as possible. User home directories
usually do NOT belong in vg00. Applications requiring a significant proportion
of the overall storage should have their own volume group(s). In designing an
LVM layout, I will start with applications being given their own VG, then
combine VG's as I have to to meet performance and capacity requirements.
Back Bay Software