[CentOS] Re: RAID, LVM, extra disks...

Thu Nov 29 18:34:22 UTC 2007
Ross S. W. Walker <rwalker at medallion.com>

Ugo Bellavance wrote:
> Ross S. W. Walker wrote:
> > 
> > What are you trying to accomplish storage wise?
> > 
> > Is this for commerical or personal use?
> Commercial, but non-critical use.
> > If for personal use, then it isn't as critical how it is 
> setup, but if 
> > this is for commercial use then you need to target your storage to 
> > your application.
> Nothing really very IO demanding.  Running an OpenVZ server 
> with many Virtual machines on it, but load is very low.
> > 
> > If you want this to be reconfigured on the fly without ever 
> rebooting 
> > then you may find your options limited on which RAID levels you can 
> > choose.
> > 
> > Typically I keep the system disks in a RAID1 and the data disks on 
> > separate RAID arrays setup depending on the application.
> > 
> > Scratch or temp files -> RAID0
> > File serving -> RAID5 or RAID6 (depending on disk size # of disks) 
> > Databases, large email, many VMS -> RAID10
> > 
> > Let us know what you want the storage for and we can suggest a 
> > configuration.
> > 
> > Top of my head though, I would use the 18GB for the OS and 
> keep the 4 
> > 36GB for application data either as a RAID10 or RAID5.
> That would make sense.  Use RAID1 18GB for /, /boot and /var and use a
> RAID4 with 4 36GB HDD for /vz (OpenVZ's virtual machines are 
> located there).
> Makes sense?

Makes sense to me, I have found in my environment that VMs generate a
lot of random io, so a RAID10 may be better suited, though it means
72GB of useable space instead of 108GB.

Also by using growing or sparse files for the vz images, a volume can get
fragmented pretty quickly. To minimzie that from happening, think about
creating LVs with separate small file systems to hold each vz image. If
the LVs start running out of space, you can grow them and the file
system as needed which will reduce the fragmentation tremendously.
You will still end up with LV extents fragmented, but since they are
larger it isn't as serious a performance issue.


This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.