how many volume groups should I create (layout / design)?

[SLES 11 SP3, LVM2, lvm2-2.02]

Is there any recommendation / best practice guide on the design of volume groups:

how many should I have?

Currently we have two vgs to 6 TB each.

In the need of additional 6 TB - what are the pros and cons of creating another vg or growing the existing ones.

As the PVs are actually VMWare vdisks, the distribution of the RAID based storage is flexible with a two vg design, already.

Thanks for sharing your opinions

Thomas

Hi Thomas,

since the technical limits are pretty high these days, I opt to decide on more organizational reasons when creating my VGs:

  • one VG for everything system-related
  • one VG for everything application-related, that I might want to move to a different system at a later point

If I feel I later might want to move one chunk if stuff to one host, and a different chunk to another host, then I’ll split that up, obviously.

While I have never moved to two different follow-up hosts yet, I have rather often chosen to shut down (or even disconnect) the “data” VG during update, to protect it from wrong-doings during the update. And I’ve had cases where I simply switched the “system” VG devices, to test different system levels against the same data, prior to upgrading. Snapshots come in handy then, too.

Best regards,
Jens

On 09/11/2014 02:04 AM, swadm wrote:[color=blue]

[SLES 11 SP3, LVM2, lvm2-2.02]

Is there any recommendation / best practice guide on the design of
volume groups:

how many should I have?[/color]

All I know is the minimum number: 1. :slight_smile:
[color=blue]

Currently we have two vgs to 6 TB each.

In the need of additional 6 TB - what are the pros and cons of creating
another vg or growing the existing ones.

As the PVs are actually VMWare vdisks, the distribution of the RAID
based storage is flexible with a two vg design, already.[/color]

I suppose it depends on your needs. If you want to expand an existing
logical volume (LV), then adding new disks to a new volume group (VG) will
definitely not help you at all, so instead add new Physical Volumes (PV)
to existing VG so space is available to expand existing LV. If you want
to create new LVs, then new VGs are an option, though without a reason to
do that I am not sure why you would as a rule.

There may be reasons to add new LVs to new VGs which are being created
from higher or lower-end PVs; for example, you have your system working
today and you want to bring on some new super-fast storage for a
mission-critical application. Rather than adding your new fast disks (PV)
to an existing VG which also has existing slow disks, add them to a new VG
and then create a new LV from that and mount it somewhere like
/mnt/superfast or whatever. The same would apply if you were adding new,
but low-end (inexpensive) storage to a system, keeping it separate from
the existing storage powering an otherwise expensive system.

As usual, the answer is, “It depends.” Welcome to IT. :slight_smile:


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Thanks, I already do the separation of system and application related data suggested by Jens. And I added a second data related vg to have a rough idea of which RAID ressources are actually adressed within the vgs. That underscores what ab wrote.

I thought it might also be a question of desaster strategies, like - how many data do I need to recover from backup in the (hopefully unlikely) case of vg corruption.

To keep things straightforward, I probably will stick to this one plus two concept for the time being.

Thanks, Thomas