Operating System - HP-UX
1855767 Members
7319 Online
104103 Solutions
New Discussion

Re: Volume Group architechture question

 
SOLVED
Go to solution
dictum9
Super Advisor

Volume Group architechture question


I am building a Ignite depot, I know that /var/opt/ignite should be a different logical volume, but my question is, does it needs its own volume group?

It's going to be on SAN disks.
15 REPLIES 15
James R. Ferguson
Acclaimed Contributor
Solution

Re: Volume Group architechture question

Hi:

You can mount '/var/opt/ignite' on a logical volume that either is a part of vg00 or isn't a part of vg00.

It's really your choice which simply needs to be factored into how you create Ignite recovery images for the server holding the mountpoint.

Regards!

...JRF...
Bill Hassell
Honored Contributor

Re: Volume Group architechture question

Not really. Volume groups are more of a mangement simplification. Ignite depots can be fairly large so creating a separate lvol and mounting that for your depot means that if the lvols fills up, it will not affect /var.


Bill Hassell, sysadmin
Jaime Bolanos Rojas.
Honored Contributor

Re: Volume Group architechture question

etc,

Usually running out of space in /var/opt/ignite is quite frequently, the forum is full of those cases:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1061718

That is why having its own lv is very good, specially from the administration point of view.

Regards,

Jaime.
Work hard when the need comes out.
dictum9
Super Advisor

Re: Volume Group architechture question

Oh, I understand that it won't affect /var, I just wanted to understand the nuances of whether it's in vg00 or not.

I decided to create a new VG for it, any problem with that? It uses SAN disks. I wanted to keep it separate from vg00.
dictum9
Super Advisor

Re: Volume Group architechture question

OK, I *know* /var/opt/ignite is a separate lvol, I am going to give it lots of GB, the question is if I need a separate *Volume Group*

Jaime Bolanos Rojas.
Honored Contributor

Re: Volume Group architechture question

Etc,

Either way will work, vg00 or a new vgXX, I would prefer the new vg becuase having the file system full in vg00 is always an issue, so that way you are always preventing something like that.

It should'nt matter if it's on SAN disks.

Regards,

Jaime.
Work hard when the need comes out.
Pete Randall
Outstanding Contributor

Re: Volume Group architechture question

It's entirely up to you. A separate VG will require a separate disk. If you have one available then you can make it a separate VG or vgextend your current vg00 onto the new disk and just have a separate lvol. If you don't have a separate disk but do have spare space within vg00 then you'll have to make it a separate lvol within vg00.

Your decision - I can't think of a single argument for either option.


Pete

Pete
dictum9
Super Advisor

Re: Volume Group architechture question


In the past, I would have just created a new lvol and left it in VG00. Now, I am not so sure anymore - I had a filesystem corruption on another box, one of the disks went bad and somehow it affected

See, I don't want to mix local and SAN disks in VG00, I don't want to deal with the consequences of bringing up the system and having data span across local and SAN disks.

Having /var/opt/ignite not just a separate lvol but separate VG seems a better, more robust design in case of a crash? Or am I missing something?
Henk Geurts
Esteemed Contributor

Re: Volume Group architechture question

Yes, I also would create its own VG with san disks, as it its difficult to size in advance. when it on a seperate VG it is easier to add a few LUN's..
just make sure you create the vg with the options that makes it easy to add disks.
(vgcreate -e xxxx -p xx )
Kevin Wright
Honored Contributor

Re: Volume Group architechture question

really, it doesn't make any difference. However, if you can carve up a LUN on a san, I'd recommend that you do that and create a new VG for it.

I prefer to keep vg00 small and clean.

One other thing, due to the size, when running ignite recovery tapes, if in vg00, you'll probably want to exclude /var/opt/ignite, then restore from backup tapes.
Pete Randall
Outstanding Contributor

Re: Volume Group architechture question

In that case, since it's going to be on the SAN, I would probably lean toward making it it's own, separate VG.


Pete

Pete
dictum9
Super Advisor

Re: Volume Group architechture question

Do I need -o largefiles option when creating the Lvol?
Pete Randall
Outstanding Contributor

Re: Volume Group architechture question

I can't think of a single reason to specify anything other than "largefiles", especially in this case. Odds are that you may, indeed, exceed the 2Gb limit imposed without the largfiles option.


Pete

Pete
A. Clay Stephenson
Acclaimed Contributor

Re: Volume Group architechture question

Enabling largefiles can never hurt and I would absolutely create an Ignite repository in another VG. It is wise to make vg00 as lean and mean as possible. After all, one of the things that you want to do for your Ignite server itself is create a make_tape_recovery image so that you can get the Ignite server back up as quickly as possible and then restore the other images from normal backups. A small vg00 makes that recovery task faster, easier, and more reliable.
If it ain't broke, I can fix that.
Ninad_1
Honored Contributor

Re: Volume Group architechture question

Hi,

>Do I need -o largefiles
The answer would be -
You would require largefiles - if you have any files >2 GB on filesystems in the servers you are taking ignite-backup of.
You need no have largefiles - if there isnt a single file > 2GB in any of the servers you are backing up using ignite.

But as an advice I would recommend you to go for largefiles, so that you dont end up not having backed up some server's data owing to any file > 2GB in that server. This wont harm in any way your ignite server.

As regards having seperate VG - I agree with those who recommend having seperate VG than vg00, even though this is not a compulsory thing.

Regards,
Ninad