[NTLUG:Discuss] RE: Practice with clustering at home?
Bryan J. Smith
b.j.smith at ieee.org
Tue Aug 30 15:49:29 CDT 2005
Burton Strauss <Burton_Strauss at comcast.net> wrote:
> 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.
I'm going to respond to this a second time.
First off, I did _not_ miss it at all. From that same post:
"TC>>> you could use firewire drives
Danger! Danger! Warning Will Robinson! ;->"
TC>>> 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.
...
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."
And secondly, yes, I talked a bit on USB.
To come back to it, I guess I should have done a _full_post_
on "multi-device targetting" -- which USB doesn't do -- and
"multi-host targetting" -- which FireWire really doesn't do
-- but _is_ required for "storage failover." But then you'd
just complain about me giving a theory on storage when it's
not necessary either.
In a nutshell, when someone starts saying things like "I've
only used USB" in the context of FireWire as a storage
failover, then there's a lot of concepts that haven't been
covered.
Again, USB is one device, one channel, devices on the same
channel cannot talk to each other (if they don't already
conflict -- especially for block devices). No multi-device
targetting, no multi-host targetting.
FireWire is multiple devices per channel. Multi-device
targetting, but no multi-host targetting. The problem is
that some people deploy FireWire and have multi-host
targetting, typically with data loss.
iSCSI attempted to introduce low-cost SAN, but it's got a lot
of overhead -- at both the target and host.
SAS is going to do a much better job, at much higher speed,
with less overhead, and the only negative being cable length.
So again, next time, I'll just write a blog entry and point
to it instead of trying to address so many missing concepts
in a couple of e-mails.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
More information about the Discuss
mailing list