6 Responses to “Tom’s got nice SAS”

1. Allen Says:
   April 23rd, 2006 at 3:09 am

   For me, the interesting part of the Tom’s Hardware article is the SANBlock S50 JBOD. This is a cool machine.

   Another cool machine is found at HP: the MSA50. This is a 1U 10x SFF SAS JBOD.

   I read the fine print. There is something interesting about both of these arrays: both either hint at or promise dual IO modules, but they are not yet available. Specifically, the HP array has space reserved for, and a tantalizing hint in the specifications document about a ‘potential’ second IO module. The S50, on the other hand, claims a dual IO module ‘version’ will appear ‘Spring 2006′.

   You have a policy about not commenting on specific product features, particularly those that haven’t been announced. Here is my none product feature specific question; is there something fundamental about SAS that has caused two entirely independent implementations of SAS array devices to omit redundant IO modules? I look at this and suspect that the companies involved (HP and Adaptec, primary SCSI/SAS players) are as yet still hashing out the fine print on SAS and aren’t really prepared to try selling anything more involved than a single IO module device.

   BTW, Promise Technologies actually has a 2U 12x SAS JBOD (VTrak J300s) they claim supports a redundant IO module. There are a few others lurking out there among the quasi-OEM manufactures as well. It will, however, be some time before I’d consider recommending Promise (or the others) to my clients.

   My storage nirvana is a SAS head with full component redundancy (on the order of the Clariion AX series with dual storage processors) supporting at least two 14 drive JBODs (redundantly connected) and 8-12 hosts. LSI has the chip (LSISASx36), but I know we’re a long way from a finished product. However, if I could by the JBODs now and eventually but them behind this imaginary head… this would at least preclude taking a FC or iSCSI bath.

2. Tom Says:
   April 24th, 2006 at 6:24 am

   Allen,

   IMHO, I see three ways to use a JBOD box with redundant IO modules:

   (1) Single controller in the host, connected via two redundant cables to the enclosure. This allows cable failover.

   (2) Dual controllers in the host, each connected via a single cable to the enclosure. This allows controller failover.

   (3) Dual servers, each with a controller connected via a single cable (or perhaps dual) to the enclosure. This allows server failover.

   Starting in reverse order, the dual server approach smells like clustering. And Microsoft is not interested in propogating support of PCI RAID clustering with SAS. Pity, since the cabling is so much nicer than SCSI. I made a post on this topic earlier.

   Dual controllers in a server is interesting, but probably overkill. Controllers don’t/shouldn’t go bad. Servers (due to power supplies, fans, etc.) and cables go bad. So I’m not crazy about this solution. Plus, it requires an MPIO framework under Windows, and I’m not sure what framework under Linux.

   So that leaves us with the first usage, which I think is the most interesting. Cables do fail and they do fall out. Or someome yanks the wrong cable. And it’s not hard to support this feature - the RAID controller “just” needs to support detecting the same storage via multiple paths, and then avoid presenting twice the amount of real storage to the host. If a cable fails, then the controller either “remembers” the other path to the storage, or re-detects the topology and finds the remaining path.

   Another cool use of the dual paths is for added performance, i.e., using both paths to actively transfer data. But this is probably a little over the top since a 4X SAS cable can already support 1.2GB/s and a TON of random IOPs.

   Lastly, and I think you referred to this in your comment, a dual-ported JBOD enclosure is probably most interesting behind a dual-controller RAID enclosure, such as a FC-to-SAS or iSCSI-to-SAS enclosure. (And someday a SAS-to-SAS enclosure for great performance and the lowest cost point.) In this configuration, each RAID controller would connect to the dual-ported JBOD enclosure for cable and controller redundancy.

   This is all great stuff, because I believe that most people with multiple servers go down the expensive FC SAN road because that was their only choice. SAS makes a lot more sense - especially if you can use cheap SATA drives protected by RAID-6.

   Thanks for reading.

   TT

3. Allen Says:
   April 24th, 2006 at 4:14 pm

   >> a dual-ported JBOD enclosure is probably most interesting
   >> behind a dual-controller RAID enclosure

   That’s the killer app for SAS. The high throughput/low latency and low cost of U320 with the natural and easy fault tolerance of FC and the flexibility of iSCSI [1]. Whichever tier 1 storage vendor builds it first will make their year early.

   It was said this way in another article: “SAS is the SAN people really want.” I know I do.

   [1] iSCSI is here to stay regardless of SAS for two reasons, WAN being only the most obvious. Less obvious: true block level access for Virtual Machines. There’s no other (good) way to do this with without bending things a lot. Google this to see what I mean:

   iscsi site:vmware.com

   Quarter TiB .vhd files are cool in a perverse sort of way, but they are effectively opaque to the rest of the system. Is there a reason a SAS RAID head/enclosure couldn’t also have a few (optional, user installable, thank you) Ethernet ports to leverage the perfectly good RAID engine…?

4. Tom Says:
   April 25th, 2006 at 7:32 am

   Are you talking about a SAS-to-SAS RAID controller that also has an Ethernet option? If so, I agree completely. That’s exactly how remote replication should be done. SAS doesn’t have the required cable lengths to even get out of the rack, and FC is just rediculously expensive. iSCSI, or some other proprietary protocol, is the way to go. Unfortunately it requires either a TOE or a big improvement in the SAS RAID CPU to get decent performance. But as x86 prices come down, and the x86 CPUs and chipsets become more integrated, even the cheapest controller will have a a ton of GHz to throw at the problem.

   TT

5. Trevor Says:
   January 26th, 2007 at 11:34 am

   This thread is a little stale, but I’ll tack on anyway.
   Well, it looks like your wish has come true XiraNet now has a device that supports both 10 GB and Infiniband.

   http://www.xiranet.com/43.0.html

6. Tom Says:
   January 26th, 2007 at 12:33 pm

   Wow! At first I assumed that it was just using InfiniBand for inter-controller communication, but this is a real InfiniBand connection to the host. Cool. Thanks for sharing.

   BTW, did you mean to post this in the InfiniBand thread?. No big deal either way. Like you said, both threads are pretty stale. But extra points to you for finding it and commenting!

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

By submitting a comment, you understand that if your post violates any federal, state or local law, or contains libel, slander, defamation, product disparagement, harassment, obscenity, or indecency, it will be edited or deleted.