Small Mosaic


Categories:

books
career
codinghorrors
comics
events
geekstuff
justdont
languages
languages/bash
linkshot
magazines
meta
misctech
movies
nottech
operatingsystems
operatingsystems/linux
operatingsystems/linux/debian
operatingsystems/solaris
paranoidadmin
perl
ruby
security
security/apache
security/tools
serversmells
sites
specifications
sysadmin
tools
tools/commandline
tools/firefox
tools/gui
tools/network
tools/online
tools/online/greasemonkey
unixdaemon

Archives:

April 20084
March 20081
February 20081
January 200815
August 20072
June 20079
May 20076
April 20078
March 200731
February 20073
January 200721
December 20061
November 20064
October 20066
September 200632
August 200617
July 200614
June 20069
May 200613
March 200611
February 200616
January 200611
December 20051
November 20056
October 200519
September 200525
August 200516
July 200516
June 200513
May 20052
April 200519
March 200531
February 200520
January 200531
December 200421
November 200430
October 200432
September 200418
August 20047
July 200414
June 20045

Sun, 24 Apr 2005

Linux FireWire Clustering: Brain Dump
I had an interest in shared storage FireWire clustering on Linux for a while. After spending a couple of evenings learning about it and having a little play I ended up with a big text file of links and notes. Below is the slightly more rationalised version of my notes. If I ever need it again I'll try and write them up properly, in the mean time they might serve as a useful pointer to some other traveller.

Thanks to a push by Apple FireWire is now reaching commodity status. The hardware itself is getting cheaper and widely available. Software and operating system support is getting better and as these continue to increase more people will hack around with the technology. I've only become interested in FireWire for one main reason; as cheap, shared storage.

It's been possible to share SCSI disks between two or more machines for quite a while. Unfortunately the hardware required has always been expensive, uncommon and (at the lower end) had a lot of problems with one machine rebooting and causing problems for all the others. So why do people use it? Because it's one of the best ways to do multi-node shared storage.

If we look at pure performance then FireWire isn't going to upset the SCSI or fibre channel users too much, while it's quick enough for basic networking (Apples IP over FireWire) it's not really suited for a heavily used production environment; but if you have one of those then you should invest in a SCSI or fibre channel based option instead. So why would you use FireWire for shared storage?

There are two main reasons, firstly (and these articles whetted my interest in shared FireWire) Oracle have documented how to use FireWire Real Application Clusters and even their Director of Linux Engineering, Wim Coekaerts, has written about Setting Up Linux with FireWire-Based Shared Storage for Oracle9i RAC as an economical way to develop and test RAC environments without requiring two hideously expensive storage deployments; one for live and one for dev/QA. It's worth noting that while Oracle do mention this as an option they don't in any way (at the time of writing) support it. It's going to be a long while before you see FireWire shared storage holding Oracle databases in live!

So how do you do it? A number of external FireWire drives (the Oxford 911 chipset seems to work well) allow multiple simultaneous logins to the device. If you have two machines with decent FireWire cards (I don't have a list of which ones do and don't work) and (this is VERY IMPORTANT!) a decent clustered file system (OCFS is known to work and GFS may be usable) then you can configure hosts running Linux to share the storage. For full details have a look at the Oracle articles above.

As an aside under Linux you can use software called DRDB for sharing storage across two machines. Here's a summary taken from the DRDB site itself "DRBD is a block device which is designed to build high availability clusters. This is done by mirroring a whole block device via (a dedicated) network. You could see it as a network raid-1. DRBD takes over the data, writes it to the local disk and sends it to the other host. On the other host, it takes it to the disk there." While DRDB isn't the ideal solution for everyone (for some discussion on this have a look at the Linux Clustering thread.

Notes:

PS While researching FireWire Clustering I discovered how much I HATE the Google Groups interface.

Like this post? - Digg Me! | Add to del.icio.us! | reddit this!

Posted: 2005/04/24 21:20 | /geekstuff | Permanent link to this entry | This entry + same date


books career codinghorrors events geekstuff justdont languages/bash linkshot magazines meta misctech movies nottech operatingsystems/linux operatingsystems/linux/debian operatingsystems/solaris perl ruby security security/apache security/tools serversmells sites specifications sysadmin tools/commandline tools/firefox tools/gui tools/network tools/online tools/online/greasemonkey unixdaemon

Copyright © 2000-2005 Dean Wilson XML feed logo