Software RAID5 and LVM with the Etch Installer
Posted by ElizabethBevilacqua on Thu 22 Mar 2007 at 09:18
Our team at LinuxForce recently put together a Debian server with LVM on a software RAID5 volume. This has been possible through complex installation procedures in the past, but today the Debian Etch installer is capable of handling such an installation if you follow the proper steps, which I outline in this article.
Among other things, we needed the flexibility to write partition tables for Xen on the fly, dependability that would allow a generous replacement window when harddrives failed, and as little possibility of data loss and downtime through harddrive failure as possible.
Assumptions about our example for this article
1. Our partition table will be as follows:
- 1G / - root
- 1G /tmp - tmp
- 3G /home - home
- 3G /var - var
- 500M swap
2. Our system has four drives (for RAID: three active drives, one hot spare)
3. The harddrives are SATA or SCSI, if you're using IDE drives keep in mind that all the sda1 references (for example) will be hda1.
4. Since this article is being written so close to the release of Etch as stable, there shouldn't be too many changes to these directions before release, but for reference we are using the Debian Etch RC1 installer on a netinst daily image downloaded March 13, 2007.
Before Installation
The first challenge was developing a partitioning scheme that would boot. lilo and grub cannot boot from RAID5 so an additional partition separate from the RAID5 had to be created for this purpose. There are many creative ways of doing this, but our solution was to create a 1 gig RAID1 root partition. Alternatively we could have created a smaller /boot partition.
Another consideration is where to put the swap partition. There is an argument for putting swap on it's own partition outside of the lvm (for speed, mostly). We made the decision to simply keep it on LVM for ease of administration.
Make sure any hardware Raid is turned off in the BIOS, we want all disks to appear separately in the partitioning table.
Creating RAID Volumes
Start the Debian Etch netinst as with a normal install.
At the Partition Disks menu choose Partitioning method: Manual
Delete any existing partitions so only "FREE SPACE" is listed.
Select the first drive and do the following:
- Create new partition
- New partition size: 1G (or the size you want root to be)
- Type for the new partition: Primary
- Location for the new partition: Beginning
- Use as: physical volume for RAID
- Done setting up the partition
This will create your RAID1 bootable section.
Then:
- Create new partition
- New partition size: <the remaining space on the drive>
- Type for the new partition: Primary
- Location for the new partition: Beginning
- Use as: physical volume for RAID
- Done setting up the partition
This will create your RAID5.
Partition the remaining three disks in the same way.
Now each partition on the drives will show up as partitioned as "K Raid"
Configure Software RAID
There is now an option to Configure Software Raid on your partitioning screen - select this.
At the next screen say "Yes" to write the changes to the storage devices and configure RAID.
Choose: Create MD device
- Multidisk device type: RAID1
- Number of active devices for the RAID1 array: 3
- Number of spare devices for the Raid1 array: 1
- Now you will choose the devices to use. Since you created the 1G partitions first, you will want sda1, sdb1, sdc1
- The next screen will ask you which device you should use for the spare, choose sdd1
Now you will want to choose Create MD device again.
- Multidisk device type: RAID5
- Number of active devices for the RAID5 array: 3
- Number of spare devices for the Raid1 array: 1
- Now you will choose the devices to use. The first three should be the ones you wish to use as active.
- The next screen will ask you which device you should use for the spare, select the only remaining option which should be sdd2
Now: Finish
You will be sent back to the partitioning screen.
Partition RAID1
Select the partition on your newly created Raid1 volume, it will say: "Use as: do not use" - select this line, hit enter and make it an ext3 / (root) partition
Done setting up this partition
Create Physical LVM Volume
Select the partition on your newly created RAID5 volume, it will say: "Use as: do not use" - select this line, hit enter and make it a "physical volume for LVM"
Done setting up the partition
Once this is completed the RAID5 volume will show up as partitioned as "K LVM"
Configure LVM
There is now an option to Configure the Logical Volume Manager on your partitioning screen - select this.
At the next screen say "Yes" to write the changes to the storage devices and configure LVM.
In the LVM Configuration screen you will first need to Create Volume Group:
- We name this Group the same name as the server itself.
- Choose device - should only be one choice: /dev/md1
Now Create Logical Volumes:
- Select the volume group you just created (there should only be one option)
- Create your logical volumes, one for each partition being created and name them: servername_var, servername_tmp, servername_swp and servername_home (note: you can name these whatever you want)
- The size of these Logical Volumes is the size you want to make the actual partitions of /var /tmp swap and /home
Once you are finished and arrive back at the LVM configuration screen choose Finish
Partition LVM Volumes
Back at the partitioning screen you will see all the logical volumes in the partition table.
Partition each of these as you normally would (when you go into each parition it will say: it will say: "Use as: do not use" - select this line, hit enter to change), LV servername_var will be the entire /var partition, etc.
When partitioning is complete: Finish partitioning and write changes to disk.
Continue Debian installation as with a normal install.
Bootloader
When you get to the step where you need to install grub/lilo you want to install it on your RAID1 partition, md0. The Debian installer should figure this out on its own and you can agree to the default, but keep this in mind if any problems arise when you complete the installation and reboot the machine.
Notes
Optional step:
To make sure LVM doesn't get "confused" by the separate disks versus the RAID volume, we tell lvm only to start on the md1 block device:
Edit /etc/lvm/lvm.conf: Change the filter line to: filter = [ "a|/dev/md1|", "r/.*/" ]
(and make sure you only have one filter line)
We leave this as an optional step because you may have other reasons for looking for other block devices.
Written by: Elizabeth Bevilacqua, System Administrator at LinuxForce
Acknowledgements:Stephen Gran, System Administrator at LinuxForce
CJ Fearnley, President of LinuxForce
References:
http://ads.wars-nicht.de/blog/archives/54-Install-Debian-Etch-on-a-Software-Raid-1-with-S-ATA-disks.html
[ Parent | Reply to this comment ]
I would also suggest that you stagger your spares for the RAID set on different drives.
eg: For the RAID 1 use sda1, sdb1, sdd1 for active, and sdc1 for the spare, while for the RAID5 using sda2, sdb2 and sdc2 for active, and sdd2 as spare.
The reasoning behind this is that if the system gets any decent use, then all disks will be in use regardless, and you won't get "spare" hardware failure on use. As the disk sits idle you really can't be sure that when it's needed to be called into use, it WILL actually be there. This way, as all disks are in use in some way, you'll KNOW when a spare fails (as one of the other active ones will die), and you can replace appropriately. It's no use having a spare if the damn thing fails during a rebuild, which is also around when other drives have a higher chance of failing (dying before, during or after the sustained load/activity of a rebuild).
It's probably also good to rotate these occasionally, to cycle the wear about. You might want to be careful with the MD partition containing /boot though, as the bios still tends to load off the first drive it sees, which is a problem if you've demoted it to a spare, and then updated your kernel.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
If the drive is totally dead, and you have specificed in the bios the other drives as part of the boot order, you should be fine.
If the drive is alive but corrupted, then you are pretty much seriously out of luck. This is the one real disavantage with software RAID. I could be wrong here, but I do not believe that GRUB actually knows too much about RAID, and may not know how to handle a non-fresh (eg: failed) disk in an array. Hence why I was suggesting to be cautious with rotating out sda1 in the axample above from an active drive to a spare, as the data will effectively still be on there, but it will be out of date.
Note that is an artifact of Software RAID, not specifically the Linux implementation of same.
BTW: I've had no problems with my software RAID 1's and 5's with the above setups, so I'm wondering what distro and versions of the kernel/raidtools you have, as that may explain some of the issues.
[ Parent | Reply to this comment ]
No hardware issues when drives became corrupt, but not knowing anything about sw raid and having the system basically become un-usable was pretty shocking. I am also not sure if I was using GRUB or lilo (as some of my installs for some reason would only allow me to use lilo) but most installs where GRUB, so who knows, I say GRUB.
The system is a Dell 2400 with 4 drives. I was using the perc 2 controller (which had also let me down when one drive failed (something Dell says has been a problem and they feel my pain) and did not allow me to rebuild the array, hence another reason for the sw raid switch)
I am still exploring debian and have since installed etch onto the system with hw raid 0 and 5. I came across this article and hope it is something that will work out for me. I'm going to give sw raid another go and use the above guide. As the above really does not give any real idea to what I was using and possible issues with the sw raid, I'm gonna assume nature of sw raid, or possibly GRUB.
[ Parent | Reply to this comment ]
If you were using Parallel ATA drives (standard IDE), then the following might apply: Using master/slave combinations in a RAID array is not a good idea. If the electronics of a PATA drive goes, it can take out the IDE bus, as unlike SCSI, they really weren't designed for hot-swapping, as the electronics (mostly) can't handle it. In the case of a master, this may stop the slave from being seen, meaning that the failure of a master drive causes the failure of two of the drives in your array, instead of just one. RAID 5 can only recover from one dead drive, so it's a bit of a problem.
All of the hardware raid controllers I have seen for Parallel ATA drives have 4 (or more) seperate controllers on board, every drive gets it's own cable and you run the drives in master mode. By going down the master/slave path, you lose such protection, so don't complain if it fails! Great for testing RAID code if you're a kernel hacker, but not useful for anything remotely resembling production.
Serial ATA doesn't suffer from these problems, as you don't daisy-chain the devices.
On the software side I do know that the raid tools have changed a bit, so your problems might have been caused by that end.
Also: Did you actually create a config file for mdadm that contained all the raid details? I've found the autodetect stuff (which is in the kernel) is not as reliable as it could be, so following that up with explicit definitions of what should be where seemed to help me in most of my situations. Most of the new installer stuff does that for you, so this only applies to older installs or manually created arrays.
PS: The hardware bit on PATA I gave for reference. I'm sure someone out there might find it useful. It was also predominantly typed in before I realised that the perc2 controller is SCSI. Rather than lose it, I simply edited it a bit.
[ Parent | Reply to this comment ]
If Grub is being installed on the RAID1 boot sector rather than MBR and you are on x86 or x86_64, the debian installer will probably prompt you about having an MBR installed (as this is required for the BIOS to initially access the disk).
At this step you can only pick from one of the physical devices and not the RAID partitions.
So the MBR should be manually installed on the other disks as a post installation task to ensure that no disk is being left MBRless and so unusable by the BIOS.
This should be true with PATA hardware and is something i went through when performing RAID sanity tests after an etch install (a year ago or so).
Most of the time i have no specific requirements for an MBR, so i usually tend to install the bootloader on the MBR and then duplicate it by hand on the other disks.
[ Parent | Reply to this comment ]
# grub --no-floppy
device (hd0) /dev/sda
root (hd0,0)
setup (hd0)
device (hd0) /dev/sdb
root (hd0,0)
setup (hd0)
device (hd0) /dev/sdc
root (hd0,0)
setup (hd0)
... and so on.
Notes:
* --no-floppy speeds up grub's loading
* the 'device' trick insures that the 2nd stage and the kernel are loaded from the same disk as the MBR, provides some independence from the BIOS settings (i've seen some voodoo cases where this was required)
* to be noted that after the first disk, the grub-shell history is of great use: 3xup,bksp,b, enter, 3xup, enter, 3xup, enter , and so on ;)
* take great care that the raid1 is in sync, to insure that all the required files are in their final position on disk
* thanks to grub's architecture, this only has to be done when upgrading grub or when changing a disk, not on every reconfiguration or kernel upgrade.
[ Parent | Reply to this comment ]
Thanks in advance!
[ Parent | Reply to this comment ]
And this is really important, last weak I have destroyed an lvm setup on a testing machine. It hanged while a raid1 was syncing and I was resizing a lvm logical volume on top of the raid :) Error message after reboot said someting about working with sda and sdb devices, not with the md device. I am not at the machine so it was easier for the friend to reinstall it, but maybe it could have been helped somehow though..
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I have a debian etch stable.
I made this setup:
3 hd.
3 x 1 gb for /boot raid 1
3 x 15 gb for / raid 5 (lvm)
3 x 20 gb for /home raid 5 (lvm)
3 x 256 mb for swap raid 5 (lvm)
I made all during the installation process. I have used lvm on raid 5 partitions.
I have never used lvm before, "only" raid.
The problem is that i have always recompiled kernel by vanilla sources, and i never used initrd cause the "important" things i am usual to put "built in " in the kernel configuration.
This time, with lvm, it doesn't work:
so: Do I have left something out of the kernel? (is dm-mod the part about lvm, right?) ?
Do I need initrd the same?
The error I get during boot is (after raid is corretly started):
VFS: cannot open root device "mapper/name-of-the-volume" or unknown-block (0,0)
Please append a correct "root=" boot option
md0 (driver?)*
kernel panic not syncing vfs: unable to mount root fs on unknown-block (0,0)
* md0 is the raid 5 metadevice
Thanks in advance.
[ Parent | Reply to this comment ]
This is much more flexible and allows Grub and LiLo to boot just fine. After all, the bootloader only needs the kernel and initrd to figure out how to access LVM on a RAID5.
[ Parent | Reply to this comment ]
i've done everything here, but after using of my new server /dev/md0 is now 100%. How can increase it?
Thanks all.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]