CentOS - Nov 2015 - C7: How to configure raid at install time

On Tue, Nov 24, 2015 at 10:32:16PM -0800, Gordon Messmer
wrote:
> On 11/24/2015 07:35 PM, Fred Smith wrote:
> >it seemed to max out at around 9900 MB. This for
> >sure won't do when I build it on real hardware, so I'm
wondering if
> >anyone else here has a clue what's going on??
> 
> IIRC, Anaconda can't create "raid1" LVM volumes.  That is,
you can't
> create LVs that are mirrored across multiple PVs.  You can create md
> RAID1 volumes and make a PV of the resulting RAID volume, though.
> 
> So I think what you're probably doing is creating 100MB /boot
> partition, and then two md RAID component partitions of 9900MB.
yeah, you're probably right. but for some reason, Anaconda is still
telling me there's a gigabyte of unused space remaining (105x megabytes
where i've forgotten what the "x" was.) Might that be because I
didn't put swap on both drives (and I think I set up swap as a gig)?

should I put swap on both drives? should it be RAID1 also, or just
two swap partitions not in any RAID volume?

(I remember seeing a somewhat technical article in the last couple
of  years that talked of a potential corruption issue if one puts
swap into a  Linux software RAID-1 volume, but no longer recall
the details.)

-- 
---- Fred Smith -- fredex at fcshome.stoneham.ma.us
-----------------------------
                    The Lord detests the way of the wicked 
                  but he loves those who pursue righteousness.
----------------------------- Proverbs 15:9 (niv) -----------------------------

On 11/25/2015 09:09 AM, Fred Smith wrote:
> should I put swap on both drives? should it be RAID1 also, or just
> two swap partitions not in any RAID volume?
I really recommend using the fewest partitions possible, since md RAID 
operates on partitions (Anaconda won't create full disk md RAID 
volumes), and replacing a disk will require you to handle each partition 
individually.  It's probably best to do a small /boot on RAID1 and use 
the rest of the disk for a second RAID1 volume, with LVM on that.

(If you haven't looked at the links I posted earlier, do consider that)
> (I remember seeing a somewhat technical article in the last couple
> of  years that talked of a potential corruption issue if one puts
> swap into a  Linux software RAID-1 volume, but no longer recall
> the details.)
There's no corruption.  If a write is canceled before it completes, you 
might end up with a block mis-match (or might have, I'm not sure if that 
still happens), but no corruption.  The mis-match is on a block that 
isn't mapped to anything, and will never be read by anything other than 
a RAID verify.  It's ugly because it means the verify operation is no 
longer useful, but it won't cause any read from the RAID volume to 
return bad data.

On Wed, 25 Nov 2015, Gordon Messmer wrote:
>I really recommend using the fewest partitions possible, 
>replacing
>a disk will require you to handle each partition individually.  
This is not a large burden, but I do agree to keep it simple.
>It's probably best to do a small /boot on RAID1 and use the rest of the 
>disk for a second RAID1 volume, with LVM on that.
The default configuration is a partition for /boot and one per drive for 
LVM PVs all of which are used by a single VG, in which LVs for / (which 
has a fixed upper size), swap (which uses a computed size) and if 
there's space available /home (which uses all remaining space).

And there's the problem, the installer uses all available space leaving 
none for a RAID of /boot/.

I believe this is due to an assumption that Red Hat makes, that their 
customers are mostly enterprise and thus the drives that the installer 
sees would be logical and backed by RAID.

I could wish that the installer would RAID /boot by default, which is 
small enough that it is unlikely to be a burden for those with RAID 
backed "drives" and a boon to those who do not.

What's needed is enough space for the installer to carve out additional 
partitions on the additional drives.  Which means manual partitioning, 
and in particular you must delete or resize /home -- remember, this is 
in the initial configuration so there's nothing to lose, and you can 
create/resize it a little later anyway.  If you have very small disks 
you probably need to shrink / and/or swap.

Reduce the space to be used by enough for another /boot and you can 
change /boot's device type to one of the RAIDs.

Reduce it to no more than what the first drive provides and you can also 
setup RAID under the PV -- modify the volume group redundancy.

After which you can make mount points for anything else, e.g., /var/www, 
and grow what you shrank.

If you like pain you can back into such a layout after installation is 
complete, but I do not recommend it.

When there are more than 2 drives possible I prefer MD RAID for /boot 
and LVM RAID for everything else -- the not likeable part is that even 
though LVM RAID leverages MD RAID the status is not presented via 
/proc/mdstat, which changes how one must monitor for failures.  When 
only 2 drives are possible odds are you want RAID1 and it might as well 
be under the PV.

Using LVM RAID is interesting in that it allows you to decide later 
without much effort the redundancy you want on a per mount point basis, 
e.g., on a 4 drive system it is just two commands to create mount points 
(LVs) using RAID10 for /var/lib/*sql but RAID5 for /var/www -- that's 
not impossible to do with MD RAID under PVs but it probably means lots 
more commands and even some juggling.


/mark