Minimum system vg00

[Larry Basford]

I want to offload the busy IO from my root disk.
We do lots of printing so(/var/spool ?)
or all of /var (is this possible with no consequence.
Run Universe database from /u1uv on vg00
it will be moved off to our EMC disk system.
Probably /home

What else should I consider ? /tmp




Filesystem kbytes used avail %used Mounted
/dev/vg00/lvol3 204800 69496 134280 34% /
/dev/vg00/lvol1 196656 74000 102984 42% /stand
/dev/vg00/lvol8 819200 636488 182352 78% /var
/dev/vg00/lvol7 1273856 1129480 144104 89% /usr
/dev/vg00/lvol9 614400 461563 143360 76% /u1/uv
/dev/vg00/lvol6 5120000 394760 4689600 8% /tmp
/dev/vg00/lvol5 1024000 873384 149504 85% /opt
/dev/vg00/lvol4 204800 147728 56984 72% /home

[Mel Burslan · Accepted solution]

moving print spool temporary storage off of the system disk may be a good idea if your system is fielding a lot of huge print requests. But the main kicker is the database in my opinion. Again, this is a very open to personal point of view matter but, you should not run any application which is not system related, storing data on the vg00, hence the system disks. Of course vg00 and the logical volumes underneath it can be neatly arranged so that app volumes get located on off system disk locations but all it takes is a careless sysadmin to merge the two and you find yourself in a bind very easily.
Once you move your database container volume off to EMC space, you may not even notice the high IO due to just printing.

My humble 2 cents worth of opinion.

[Paul_481]

Hi Larry,

If you have the disk space available, do not put any non-system related files/filesystem on vg00. This will keep your vg00 clean and will reduce the change of disk failure.

Regards,
Paul

[Devesh Pant_1]

I think what you have in mind is just fine. If you still find a very busy system disk, /tmp could be the only candidate.

thanks
Devesh

[Devender Khatana]

Hi,

I think the load on root disk in /dev/vg00 will be maximum because due to swap most of the time. How much swap you have ? Printing I do not think will put much load on root disk as reading a small file takes much less time then printing it. Even if you have around 15-20 printers you could not conclude that utilization is high due to more printing jobs.

Yes high utilization on /tmp can also be a issue. How did you conclude that utilization on disk is high ? I think you need to find out the processes which cause this. Use top commands & tools like glance plus extra for more detailed diagnostics.

Morover find out at which path your applications use /tmp I mean /tmp/uv or something. Then mount a file system on that path for transferring load to mounted file system. As adding a storage disk to vg00 will not be a recommended option even if it is supported.

HTH,
Devender

[Jino.P.V]

Hi Larry,
I am sure that you have monitored the io on the root disk. It is a non writen standard that the root vg(vg00) should have only OS related filesystem and files. as a standard we keep all application related filesystem in other VGs.

So my suggestion is to move /u1/uv to EMC box. that should resolve your worry about io on root disk. If it is not bringng the io down, then you can think about /tmp also. Most probably once you move your application to EMC the problem may be solved.

[DCE]

I concur - VG00 should ony be used for OS related files. You also need to ensure you do not cause inadvertant problems by moving OS directories fully out of VG00

Definitely move the database out of VG00. I would also recommend moving /var/spool to the EMC disk as its own mount point.

Dave

[Larry Basford]

All good suggestions.

Here is what I am thinking.
I have and EMC mirrored lun of 8GB available on all 9 systems I want to configure this way.

I use a golden image to install servers. After an install I always need to recover from backup /u1uv /home /tmp for the system I import the /vgdata volume for. If I make it say vg01 and put these filesystems on it I can do a vgimport of the /data and /vg01 to am image and be mostly done.

This vg01 would also go to our disaster recovery site (SRDF) and be available for import.

I also want to create an ignite image of the server which I can ignite from disk (another EMC logical volume part of SRDF)

This will make my systems very portable and make recovery at our disaster site very quick.

Maybe a /var/spool link for print jobs?
and /etc/lp link or mount over /etc to retain my printer configs?

I have as many as 300 printers/system to consider.

What is minimum?
Can I do this?

move these all off to vg01
Ignite my image
Change the fstab to vg01 and reboot?

/dev/vg00/lvol4 /home vxfs
/dev/vg00/lvol5 /opt vxfs
/dev/vg00/lvol6 /tmp vxfs
/dev/vg00/lvol7 /usr vxfs
/dev/vg00/lvol8 /var vxfs
/dev/vg00/lvol9 /u1/uv
Change to
/dev/vg01/lvol4 /home vxfs
/dev/vg01/lvol5 /opt vxfs
/dev/vg01/lvol6 /tmp vxfs
/dev/vg01/lvol7 /usr vxfs
/dev/vg01/lvol8 /var vxfs
/dev/vg01/lvol9 /u1/uv

Or am I asking for trouble? The original home opt tmp usr var in vg00 would be there just not mounted.

By the way swap is not a problem and the /u1/uv is the $DATAHOME not the data.
It gets a lot of reads.

Devender good point about /tmp
I just put a link to a different filesystem vg to offlose the IO

Sorry for all the rambeling. Just trying to create the big picture. If I'm nuts just tell me. Maybe it will spark other ideas.

[Mel Burslan]

Again this is my opinion but moving /usr and /var to a non vg00 volume, you may find yourself in a bad situation if one of those volumes decide not to cooperate at the boot time. /home, /tmp and /opt are not that much of a concern but think about /var not being able to mount at the boot time and you need to "vi" your /etc/rc.log to determine the cause. Which will require creating a temporary file in /var/tmp. Guess what ? There is no /var hence no /var/tmp. This is one of the mishaps that I can think of really quick off the top of my head, without drinking my morning coffee, but splitting the two filesystems, i.e., /var and /usr, I think you are asking for trouble.

Other than that, I can not see any downsides to your methodology. Also, I see that you mention the diseaster recovery in the context. Actually it is a very good approach. Just don't be too hasty ofloading all volumes to SAN.

Another thing you may consider for DR purpose is to place your root disk mirror on the SAN totally.

Hope this helps.

[Larry Basford]

Thanks for the encouragement.

I thought I'd leave a copy of the vg00
/var /usr /opt /tmp on the root disk for such emergencies. Just not mount them.

I tried putting the root mirror on the EMC but was told not to because the internal disk needed bad block turned on and the EMC needed it off.

I have heard of just booting from the EMC and have tried it sucessfully but EMC will not recommend it. It is much a faster system when I did that though. Part of the reason I want to offload most of the filesystems to EMC disk.