Re: Booting Software RAID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux