[NTLUG:Discuss] Practice with clustering at home?

[Burton Strauss]

Danger Leaping Lemurs: Bryan, you saw the letters U S and B and jumped to
the wrong conclusion.  And started off flogging deceased equines per usual.

What Thomas was really asking is for information on using FireWire for a
low-end cluster. 

(1) IIRC you would need to run GFS or another cluster aware file system - in
the pointer below, Oracle's RAC does that for you.

(2) Pointers:

Oracle has a couple of examples posted, the older (9) one at
http://www.oraclenotes.com/articles/RacLinuxFirewire.htm and 10g at
http://www.oracle.com/technology/pub/articles/hunter_rac10g.html which has
more details re hardware config.

These people http://www.micronet.com/General/ have product for sale, no clue
beyond that.



-----Burton



-----Original Message-----
From: discuss-bounces at ntlug.org [mailto:discuss-bounces at ntlug.org] On Behalf
Of Bryan J. Smith
Sent: Tuesday, August 30, 2005 11:24 AM
To: thomas.cameron at camerontech.com; NTLUG Discussion List
Subject: Re: [NTLUG:Discuss] Practice with clustering at home?

Thomas Cameron <thomas.cameron at camerontech.com> wrote:
> I heard during a Red Hat class I took that you could use firewire 
> drives

Danger!  Danger!  Warning Will Robinson!  ;->

> to run Red Hat Cluster Suite in lieu of buying a SAN.  I have never 
> used firewire, being more of a USB kind of guy.

USB was never designed to compete with FireWire, it was designed to
complement it at the low-end.  E.g., DeviceBay and other standards.

USB was never designed for high-speed block devices, and cannot do
device-to-device transfers -- let alone its virtually impossible to get more
than a few devices on the same bus because of inter-device fighting.  This
was due to the fact that Intel-Microsoft designed USB controllers and host
drivers rather simplistically, putting all the "brains"
(and vendor-defined standards) at the end-device.  That's why it took about
3-4 years after OHCI controllers were on mainboard before the devices came
out.

These things are unheard of in FireWire, where it was designed for multiple
targets off-the-bat.  The only reason USB is more popular is because Intel
changed its mind on licensing FireWire.  When the FireWire logic was thrown
out of the PIIX southbridges, that was it, 90% of consumers were cut off.
Especially considering that FireWire is not expensive at all (which renders
the whole BetaMax v. VHS comparison moot).

Another common assumption is that USB 2.0 is 480Mbps.  Not only can Intel
get no where near that (and have admitted the limitations), you have to have
an EHCI controller to get it. 
All but 1 controller on a supposed USB 2.0 IC is typical OHCI and only
capable of 12Mbps.  On FireWire, nothing is capable of less than 100Mbps,
and 400Mbps is the norm.

> Anyone have any idea how to make a single firewire disk available to 
> multiple servers, kind of like a SAN?

Yes, and I highly recommend _against_ it.

I would investigate going with Serial Attached SCSI (SAS) instead.  Much
more stable and designed explicitly for it. 
FireWire is fine as a narrow SCSI external device replacement, but there's a
lot missing as a full SCSI replacement.

Sadly enough, USB is really more akin to age-old EIDE with programmed I/O
(PIO), only worse.  There were at least a half-dozen _better_ serial
protocols that had been around 10 years, but USB got the call because it was
ultra-simplistic for Intel and Microsoft to claim they were shipping it
(again, even though devices .  Anyone who has written a block driver for a
USB device knows what I'm talking about.  ;->

For more on SAS, see my blog: 
http://thebs413.blogspot.com/2005/08/serial-storage-is-future.html
 

The SAS concentrators shouldn't be too terribly expensive.


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)

_______________________________________________
https://ntlug.org/mailman/listinfo/discuss