1753946 Members
7337 Online
108811 Solutions
New Discussion юеВ

lvm best pratices

 
christian_derek
Regular Advisor

lvm best pratices

Hi All,

I need help on best practices regarding LVM, I currently have an hpux 11iv3 with an eva4400. I have setup vg00 with mirror ux on the internal drive, vg01 for my client data and vg02 for other things.

My question is on my vg01, here are the fact ...

1- I need a separated env for each of my client
2- each of my client need it's own prod, preprod and test env.
3- I don't want to affect prod env
4- I don't want to much maintenance

Should I build a LV on per client env, I would like to have something like ...

/data/opt/my company/client/prod/ db volume

what should I do?

Thanks,
10 REPLIES 10
Stephan.
Honored Contributor

Re: lvm best pratices

HI,
sounds to me like you are asking for best practice of your application and not of lvm.

What application do you use?
christian_derek
Regular Advisor

Re: lvm best pratices

Hi,

what will be the pro and cons of doing what I describe, it is ok?

- how should I do my mount point?
- should i just put every client env into the same bucket?
- is my naming convention ok lv_client1_env1, lv_client1_env2, lv_client2_env1?
- is my file system mount point ok /data/opt/my company/client/prod or should I use sym link?

Thanks,
Mel Burslan
Honored Contributor

Re: lvm best pratices

If you are talking about different companies using a single server, I'd suggest going as much separated environments you can get with the limitations you have. Single server situation takes the different storage zones out of consideration for the absolute isolation of the SAN contained data.

The next best thing you can do is to spread your clients into different volume groups, rather than giving them just a different logical volume. Then you can name your LVs according to the environment, as in DEV, TEST, PREPROD and PROD. When it comes to rest of the lv naming, as long as the data are contained in different volume groups, your LV names can even be the same for the ease of management. Mount points are just a matter of preference. I am sure you will have the right permissions and filesystem ownerships, so that one can not peek into other's data.

>3- I don't want to affect prod env
if they are on the same server, and you have to apply a reboot requiring patch, to the test environment, how is this going to happen ? More than likely it's not.

>4- I don't want to much maintenance
neither do I but life as a sysadmin is hard :)
________________________________
UNIX because I majored in cryptology...
christian_derek
Regular Advisor

Re: lvm best pratices

Hi Mel,

What will be the advantage of creating a volume group per client? what is the vg limitation?

Another questions, if I create my mount point to be /data/opt/comp/client/prod, if I build a file in /data/opt/test, where the directory will reside?

Thanks,
Mel Burslan
Honored Contributor

Re: lvm best pratices

Creating volume groups instead of LVOLs have an advantage when you do LUN based synching and such. If, let's say, your clients' backup times are not the same, when you take one VG off line will not impact the other. Also it is easier to do housekeeping when you have clearly separated volume groups rather than just LVs. I prefer the volume groups to be separate and LV names under those volume groups to be the same, so, provided these clients are running the same application, when I write a script, it will run on other environments without too much of an effort.

> if I create my mount point to be /data/opt/comp/client/prod, if I build a file in /data/opt/test, where the directory will reside?

In this case, a file created as /data/opt/test/somefile will reside on the same device/LUN level as /data/opt which is exactly the same thing as /data/opt/comp/client, provided none of these paths and their recursive upper directories are mountpoints.
________________________________
UNIX because I majored in cryptology...
christian_derek
Regular Advisor

Re: lvm best pratices

Hi Mel,

Should I do FS mount point ...

/data/opt/comp/client/env1

+

/data/opt/comp/client/env2

+

/data/opt/comp/client2/env1

or this will cause an error?

Thanks,
Patrick Wallek
Honored Contributor

Re: lvm best pratices

As long as your application can understand the different mount points, I don't see a problem.
christian_derek
Regular Advisor

Re: lvm best pratices

ok, so if I have a file system with a mount point /data/opt/comp/client1 and /data/opt/comp/client2 and I build a file in /data, where the file will reside, sorry I'm not a sys admin and I'm trying to understand
Patrick Wallek
Honored Contributor

Re: lvm best pratices

*********
ok, so if I have a file system with a mount point /data/opt/comp/client1 and /data/opt/comp/client2 and I build a file in /data, where the file will reside, sorry I'm not a sys admin and I'm trying to understand
*********

If you build a file in /data, that is where it will reside.

You have to build your files in the specific directories for each client. If both client1 and client2 need a file called "mydata", then that file would have to be build in each of /data/opt/comp/client1 and /data/opt/comp/client2. So you would then have /data/opt/comp/client1/mydata and /data/opt/comp/client2/mydata.