I've been thinking about my original question, Joachim Schipper suggestion concerning the use of /altroot, and hybrids there of for a file server for user accounts. Below are my notes thus far:

The basics behind doing a software RAID on OpenBSD were originally
gleaned from the following document:

        http://www.neverland.ch/netbsd/Mirroring.with.NetBSD-1.5.2.pdf

I started with the simplest layout that would work:

--wd0a----------    --wd1a-*--------
/ / wd0a and wd1a are complete
/etc                /etc              OpenBSD installations with
/bin                /bin              a bsd.raid kernel and all
/sbin               /sbin             necessary tools to build
/usr                /usr              and recovery from a failure.
/var                /var
/tmp                /tmp              wd1 should be bootable with
/home               /home             simple change of the BIOS
                                      or a switch of cables or
                                      ideally with no change at all
                                      when wd0 is completely hosed.
--wd0e----------    --wd1e----------
raid0               raid0             A single large slice is used.
                                      The advantages of this is its
   --raid0a-----       --raid0a-----  easy to understand, setup, and
   /                   /              manage.

   --raid0b-----       --raid0b-----  The disadvantages are it takes
   swap                swap           a long time to redo the parity
                                      in the event of a hard reboot
   --raid0d-----       --raid0d-----  or power failure. Replacement
   /tmp                /tmp           disks must be as large as the
                                      slice.
   --raid0e-----       --raid0e-----
   /usr                /usr


   --raid0f-----       --raid0f-----
   /home               /home


----------------    ----------------


Its been suggested that there is no need to make the entire disk
a RAID. Only those parts with critical data. Most of the binaries,
static and/or infrequently changing files could live on non-RAID
slices and use /altroot (see man afterboot) to backup this
daily. So for example the following disk layout could be used:


--wd0a----------    --wd1a-*--------
/                   /altroot           The ROOTBACKUP script
/etc                                   can be modified to
/bin                Contents of wd0a   update the fstab copy
/sbin               copied to here     so as to be bootable
/usr                daily.             straight from wd1 in
/bsd.raid                              the event wd0 dies.

--wd0b----------    --wd1b-*--------    
swap                swap

--wd0d----------    --wd1d-*--------
/tmp                /tmp

--wd0e----------    --wd1e----------
raid0               raid0

   --raid0d-----       --raid0d-----
   /var                /var


   --raid0e-----       --raid0e-----
   /home               /home



----------------    ----------------


Thus wd1a,b,d would remain idle for the most part, unless wd0 dies
then a BIOS switch to boot from wd1 and continue with the raid in
a degraded state until wd0 is replaced and reconstructed. However
the contents of /altroot/etc/fstab would require changing I suspect
so as to reference wd1 instead of wd0.

However, something has been naging me at the back of my mind as to
why the NetBSD paper would propose making /, swap, /tmp, and /usr
separate RAID themselves. There are two reasons I've thought of so
far.

First is flexibility. Smaller slices are more flexible in that
they allow for the use of disks of different sizes or unused
slices on other disks.

The second reason is stability and uptime. In the event of a disk
failure, having /, swap, /tmp, and /usr as a RAID (one large or
individually for flexibility), means the system can continue to
operate in a degraded fashion without needing to reboot to switch
root file system. The system remains up until the actual disk
replacement is to be installed (if you don't have hot swap drive
bays and disks).

Now a more advanced RAID layout might be:


--wd0a----------    --wd1a----------
/     (bootable)    /     (bootable)
/tmp                /tmp
/usr                /usr
/var                /var

--wd0d----------    --wd1d----------    
raid0    (root)     raid0     (root)

   --raid0a-----       --raid0a-----
   /                   /
   /usr                /usr


--wd0e----------    --wd1e----------
raid1               raid1

   --raid1b-----       --raid1b-----
   swap                swap

   --raid1d-----       --raid1d-----
   /tmp                /tmp

--wd0g----------    --wd1g----------
raid2               raid2

   --raid2e-----       --raid2e-----
   /var                /var


   --raid2f-----       --raid2f-----
   /home               /home


----------------    ----------------


wd0a and wd1a are small bootable slices containing the RAID enabled
kernel, the generic kernel, binaries and tools for recovery, and
probably the kernel sources in order to reconstruct the RAID kernel
if necessary.

raid0 contains most of the static seldom changing files. raid1
contains the swap and /tmp areas required for daily operation, but
not important enough to recovery in the event of a failure, ie.
their contents can be erased if necessary. raid2 contains user data
that must be preserved (email, web sites, home directories, etc.).

In the above its a matter of choice whether swap, /tmp, /var, or /home
should be individual RAIDs or grouped together as shown. One reason
for this grouping is that the default kernel configuration:

   pseudo-device   raid   4

specifies only 4 RAID drivers. This of course can be increased if
necessary.

The other reason for this grouping is that swap and /tmp tend to be
small slices even when joined together and so there might not be so
much an advantage to having them separate, unless you want a really
large /tmp.

/var and /home could and probably should be individual RAIDs and this
layout was just a matter choice and convenience.


--
Anthony C Howe          Skype: SirWumpus                    SnertSoft
+33 6 11 89 73 78         AIM: SirWumpus    Sendmail Milter Solutions
http://www.snert.com/     ICQ: 7116561      http://www.snertsoft.com/

Reply via email to