[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [linux-lvm] One VG or many?

> First, I would separate system (= containing the OS) and data area.
> Second, if you do not intend to stripe data across LVs I would create
> one VG for every logical business/application unit and assign disk
> space on demand. That means that you leave most disks in a pool and
> if you need more space in one VG you'll add the disk online with
> vgextend. Why not start with one disks per VG?

	I see how adding disks from a pool would work very well. The problem
with our arrangement is that we would like to combine disks into RAID 5 sets
and then use these RAID sets as the PVs. The optimal size of each RAID set
(optimal in terms of disk usage, controller redundancy, channel redundancy,
and enclosure fault-tolerance) is about 215GB; so we would have 8 PVs
available to use in VGs. This size seems insufficiently granular to use as a
"expansion unit" to each VG. In fact, even if we used the individual disks
in the array, they seem too large at 73GB. This is why we were thinking
about partitioning the RAID sets so they would appear to the host as smaller
disks which could be added to VGs (The disks, RAID sets and even partitions
are all externally managed on a Zzyzx RocketStor 2000).

	Let me ask a slightly different question - what is the advantage to
creating a VG for every logical business/application unit? Or perhaps, why
would I not want to use a single VG? Is it a good idea just in terms of
failure in one VG not wiping out everything? It would seem that a reasonable
analogy would be that one VG is like one disk with partitions (LVs) for each
business unit, whereas multiple VGs would be more like multiple disks. Both
seem to have sufficient ideological separation?

Thanks for you help,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]