Enable software RAID on XenServer 6.2
Bevore we start:
I shall not use this on production servers. I shall not use this on production servers. I shall not use this on production servers. I shall not use this on production servers.
[Daaa daadidaada daa dadada daaa] (The Simpson theme rolling …)
Umm… where was I? Right, enabling a software RAID on XenServer 6.2. Possible? Yes. Recommended? No. Field of use: Poor techies like unable to afford a hardware RAID controller for a simple test box 😉
So, there’s plenty of docs out there, telling you the steps on how to enable software RAID using mdadm on a XenServer.
Some of the How-To’s I came along:
- http://sysadmin.compxtreme.ro/xen-6-0-2-software-raid-installation-procedure
- http://blog.codeaddict.org/2011/12/04/xenserver-6-0-software-raid1-installation
- http://www.bauer-power.net/2011/06/easy-software-raid-1-with-xenserver-56.html
So, I have no point in replicating the steps other’s have already written up, so go ahead and check out those HowTo’s carefully.
My thoughts, when I was reading up this stuff was like: “Oh my god, this ought to be scripted”
Luckily, some of the guys out there started already off with some scripts, however the ones I came along only covered parts of the procedure, namely steps 1 to 9 (refering to the http://sysadmin.compxtreme.ro how-to). So I then essentially took the script provided over at http://sysadmin.compxtreme.ro and took it one step further.
It now has no very basic interactive mode: By scanning for available hard drives, it does not rely on hard coded values (which struck me on my server). Thus it does not only detect the system root device (where XenServer bootet from), but also tries to find hard drives that meet the exact same specification (ie. same size).
Well, yes, mdadm allows to build software RAID from different, non-identical hard drives. But from my own expertise, building software RAID off different hard drives will sooner or later bite you!
I prefer to build software RAID always on identical hard drives, which makes things much more predictable. Thus, my incarnation of the setup script does pay attention to the disks being equal in size. Period.
Oh well, I also added the snippets that will finish off your RAID setup, namely steps 10 to 14 as well.
My motivation for doing this enhancement was simple: If you’re like me, re-installing things over and over again, because of breaking things just to see how they work, well, then you want something, that really helps you get back up again in no time. I love scripts 🙂
So, here’s the direct download link: http://phunsites.net/scripts/x6raidsetup.sh.gz
You may also run it directly off your XenServer like this:
wget -qO- http://phunsites.net/scripts/x6raidsetup.sh.gz | gunzip | bash
The script will scan your disk devices and propose to build a software RAID _if_ and disk identical to your boot drive is found. During the process, it will create a script file at /root/x6raidsetup2.sh, which you can call up after the first reboot in order to finish the setup procedure.
Here’s an example output from the first-stage setup script:
Trying to figure out root device ... system's root device: sda Please wait, locating disk drives ... got sda (976773168 blocks) got sdb (976773168 blocks) device sdc ignored because it's size is not equal to the system's root device device sdd ignored because it's size is not equal to the system's root device Disk is 'sdb' is the only suitable disk and has been auto-selected along with root device 'sda' !! Last Chance !! Do you want to continue? [Y, n] y clearing the partition table on 'sdb' ... installing gpt partition table onto 'sdb' ... creating partition /dev/sdb1 ... creating partition /dev/sdb2 ... creating partition /dev/sdb3 ... sleeping for 10 seconds ... creating RAID device: /dev/md0 ... creating bitmaps for /dev/md0 ... creating RAID device: /dev/md1 ... creating bitmaps for /dev/md1 ... creating RAID device: /dev/md2 ... creating bitmaps for /dev/md2 ... Formatting the root disk and mount it to /mnt ... Copying the root filesystem to the RAID array (this will take a while) ... Updating root filesystem in /mnt/etc/fstab to /dev/md0 ... Installing the boot loader to 'sdb' ... Updating initrd ... Updating boot loader configuration ... Preparing second stage setup script ... There we are, everything should be configured right now. Now, please check all output above carefully for any errors. Resolve any errors, then, if you feel everything is right, perform a reboot. Enter BIOS setup and set it to boot from the second harddrive 'sdb'. Once your system has rebooted, you may run this command to finish: /root/x6raidsetup2.sh
So, as seen from the script output, you should be switching the device boot order in your BIOS in order to boot off the new mdadm RAID. Then then second-stage script at /root/x6raidsetup2.sh will finish off, which will look like this:
Adding original system root device 'sda' to the software RAID ...
Monitoring RAID rebuild progres (press CTRL-C anytime to stop monitoring)...
md1 : active raid1 sda2[0] sdb2[1]
4193216 blocks [2/2] [UU]
bitmap: 1/128 pages [4KB], 16KB chunk
md2 : active raid1 sdb3[1]
479996864 blocks [2/1] [_U]
bitmap: 0/229 pages [0KB], 1024KB chunk
md0 : active raid1 sda1[0] sdb1[1]
4193216 blocks [2/2] [UU]
bitmap: 0/128 pages [0KB], 16KB chunk
unused devices:
Now you should have your mdadm RAID1 up and running in virtually now time (took me 5 minutes). Enjoy!
October 8th, 2014 at 4:40 am
Nice script!
Few errors.
Line 249 should be:
$CHROOT /mnt /sbin/extlinux –raid -i boot/ > /dev/null 2>&1
Otherwise it stops booting at splash screen.
Line 262 should be:
cat>/root/x6raidsetup2.sh<<EOF
Otherwise will not create the file.
October 8th, 2014 at 7:36 pm
Thanks. I added in your suggestion for line #249.
As for line #262, it is supposed to write out the file to /mnt/root, because /mnt is supposed to be residing on the newly initialized md-raid, thus also referring to the copied /root -> /mnt/root directory as of line #242.
It is not expected to end up on the /root directory (the one on the plain disk, ie. not md-raid).
You should however actually see the x6raidsetup2.sh in your /root directory once you reboot, after changing BIOS boot order to use the second drive (the md-raid enabled one) instead.
Unless I’m terribly mistaken now, this is how I envisioned it to work with the second stage script.
October 8th, 2014 at 11:52 am
Hi,
thx for the script, makes it very easy now to set up a raid on a xen machine. But 2 things i got:
First: Script only works fine if one prepared the third partition, which not always will be created whilst during install you can deselect the creation of a SR.
Second is a question i have. Does this raid will survive patches or updates like kernel updates? If not what is to do so?
thx
Stefan
October 8th, 2014 at 7:51 pm
Hi Stefan,
Good point, yes, it is really that way. I never questioned this so far, because I just took the existing script source and did some enhancements there 🙂
Surely, this can be extended by just parsing the number of /dev/ entries for the selected device on looping this number.
Accordingly, this is true as well for the 2nd stage script.
Maybe I find some time shortly to try on a fix for this.
As for the second question: Uhmm …. maybe. Regurlar updates should not break this raid as long as they don’t touch kernel, modules and the initrd image.
Actually, even kernel updates should not, because the initrd should be rebuilt in most of those cases anyway.
These update should run a similar command to the one in the script. Otherwise you may have success rebuilding it yourself before a reboot.
mkinitrd -v -f –theme=/usr/share/splash –without-multipath /boot/initrd-`uname -r`.img `uname -r`
You should also inspect the loader config file at /boot/extlinux.conf and check if the command refers to root=/dev/md0 and not the physical harddrive.
But mind the fact, that the guys over at Citrix could get the idea to remove mdraid support from kernel, which will definitely break the setup.
I must point out, I use this for testbed purposes only. The boxes run maybe a few weeks, are torn down and then rebuilt again. Basically the boxes simply don’t last long enough to ever receive any updates, which is why I have not encounter any issues so far.
And as I said in the blog, running software RAID is good for a cheap testing box, but for a production box is certainly not a good idea.
If you want to update, try it on a box that has nothing important on it first. I’d be happy on your experience anyway in order to share with other poeple.
Cheers,
-GP