Gallery

Jumping the gun

Posted on 28 Jan 2009 at 16:12

Steve Cassidy finds that in times of recession there's no middle (sized) ground, and looks at a monster server out of a datacenter manager's dreams.

Remember that the reason I was probing the innards of this heavy-metal server in the first place is that it was running like a three-legged hedgehog in a snowdrift. Directory listings took ages, doing anything in the Gnome interface was agonisingly slow-motion. This was because that quick-fire, carefree concept of mounting a multiple-terabyte RAID as a single folder off the side of a 9GB partition on a laptop disk fails to take account of the way usage patterns affect the operating system. This server had spent its unbelievably tedious life storing still pictures from a posse of CCTV cameras and running for months, or even years, without a reboot. The tiny disk partition it was booting from had become entirely clogged with temporary files, small downloads and maintenance patches. This machine could have been using some variant of unRAID, and booting from the very fastest of flash drives known to mankind, but it would still have become clogged up when configured this way.

Then there's the belief that leaving the OS off the RAID array confers benefits, because one can never be sure what might actually be maintaining the redundancy. This is a very ancient idea and one that has persisted for far longer than it deserves: originally, way back in the 1970s when both Unix and RAID arrays were cutting their teeth, it was uncommon for hardware vendors to offer much assistance in implementing your array. RAID was a way of offering redundancy on the cheap, so said the original doctrine, and hence RAID was to be implemented in software, looked after by the operating system and mediated by the humble CPU of your PC (while doing all your other work, too). This outlook has been carried forward into the current day Linux design, and has caused a lot of fuss and distraction within Windows server design, too, and so both platforms will let you create a purely OS-mediated RAID.

The need to do this has vanished - evaporated - it's deader than Monty Python's parrot. The RAID card running the 16 drives in this monster server is made by 3ware, and its BIOS could handle the entire business of clumping physical drives together without involving the OS at all. Indeed, not only are the drives clumped, but they're addressed right down individual SATA cables. The potential throughput of this card and these drives in this configuration is nothing short of phenomenal. It represents a truly massive step forward that we should all be thanking the hardware companies for, and indeed this month I've been thanking them because I had a drive failure in a crucial server at another client's - even though it was a Dell (so the services provided for failing-over inside a Windows server were somewhat deficient), its RAID BIOS nevertheless took no more than a minute or two to include a replacement drive into the array, and start filling it with redundant data from the other two. It was a far simpler procedure than having to replace and reload the OS onto a single, vulnerable laptop drive - the server was barely offline for five minutes.

What was even more galling, when I compared that Dell-and-Windows server with the Linux and Intel-own-brand monster, was that if 9GB were big enough to hold CentOS then installing it onto the main RAID instead would have deprived those myriad CCTV pictures of precisely 0.12% of their available storage space, which is hardly what you'd call an unacceptable overhead...

A word of caution, though: there's still an element of juggling required to get Windows servers to boot from logical drives held on RAID cards, and there's an even crazier sequence of hoops to jump through to make OS X do it. Apple tends to tell people to just mirror the boot volume, since that's easier. I'd assume getting Linux to run from an "exotic" boot environment might be even harder, which is why we get to hear a lot of flimflam about "RAID being for data" when in fact the issue is that Linux is still, annoyingly, held back by excessive simplicity.