On Wed, January 29, 2014 11:57, Lists wrote:
> On 01/29/2014 08:15 AM, Matt wrote:
>> If I am putting both 4TB drives in a single RAID1 array for /vz would
>> there be any advantage to using LVM on it?
>
> My (sometimes unpopular) advice is to set up the partitions on servers
> into two categories:
>
> 1) OS
> 2) Data
>
> OS partitions don't really grow much. Most of our servers' OS partitions
> total less than 10 GB of used space after years of 24x7 use. I recommend
> keeping things *very* *simple* here, avoid LVM. I use simple software
> RAID1 with bare partitions.
>
> Data partitions, by definition, would be much more flexible. As your
> service becomes more popular, you can get caught in a double bind that
> can be very hard to escape: On one hand, you need to add capacity
> without causing downtime because people are *using* your service
> extensively, but on the other hand you can't easily handle a day or so
> to transfer TBs of data because people are *relying* on your service
> extensively. To handle these cases you need something that gives you the
> ability to add capacity without (much) downtime.
>
> LVM can be very useful here, because you can add/upgrade storage without
> taking the system offline, and although there *is* some downtime when
> you have to grow the filesystem (EG when using Ext* file systems) it's
> pretty minimal.
>
> So I would strongly recommend using something to manage large amounts of
> data with minimal downtime if/when that becomes a likely scenario.
>
> Comparing LVM+XFS to ZFS, ZFS wins IMHO. You get all the benefits of LVM
> and the file system, along with the almost magical properties that you
> can get when you combine them into a single, integrated whole. Some of
> ZFS' data integrity features (See RAIDZ) are in "you can do that?"
> territory. The main downsides are the slightly higher risk that ZFS on
> Linux' "non-native" status can cause problems, though in my case, that's
> no worry since we'll be testing any updates carefully prior to roll out.
>
> In any event, realize that any solution like this (LVM + XFS/Ext, ZFS,
> or BTRFS) will have a significant learning curve. Give yourself *time*
> to understand exactly what you're working with, and use that time
> carefully.
Our default partitioning scheme for new hosts, whether virtualised or not,
looks something like this:
df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg_inet01b-lv_root 8063408 1811192 5842616 24% /
tmpfs 1961368 0 1961368 0% /dev/shm
/dev/vda1 495844 118294 351950 26% /boot
/dev/mapper/vg_inet01b-lv_tmp 1007896 51800 904896 6% /tmp
/dev/mapper/vg_inet01b-lv_log 1007896 45084 911612 5% /var/log
/dev/mapper/vg_inet01b-lv_spool 8063408 150488 7503320 2% /var/spool
The capacities assigned initially vary based on expected need and available
disk. As everything is an lv expanding volume sizes when required is not
exceedingly burdensome. I used to keep / as a non-lv but for the past few
years, since CentOS-5 I think, I have made that an lv as well and my
experience to date has been positive.
Anything expected to continually increase over time goes under /var as a new
lv. For example: On systems with business applications that store
transaction files we have a dedicated lv mounted at /var/data/appname (for web
apps) or /var/spool/appname (for everything else). On a system hosting an
RDBMS we generally give /var/lib or var/lib/dbmsname its own lv although on
the dedicated dbms hosts we typically just mount all of /var as an lv.
This is based on past experience, usually bad, where the root file-system
became filled by unmanaged processes (lack of trimming stale files), or DOS
attacks (log files generally), or unexpectedly large transaction volumes
(/var/spool). As all but one of our hosts have no local users besides
administrative accounts /home is left in root. On the remaining host that has
local user accounts /home is an lv as well.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
