Ross S. W. Walker wrote:
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.
I understand, but my IO is not very significant... I think I'll use the
RAID5 for /vz/
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.
OpenVZ doesn't work with vz image. It works as a regular filesystem.
Thanks a lot for your advice.
Ugo
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
