Wandering Thoughts archives

2013-09-14

A basic overview of SAS and using SATA with SAS

I have been busy having a somewhat painful learning experience about SAS, especially bearing on putting SATA disks behind SAS. In my usual way I'm going to write down what I've learned so that it will stick.

SAS is yet another disk interconnect technology. It came out of SCSI (as opposed to SATA coming out of ATA) and so it is generally more large-scale, enterprisey, and costly. You can, at least in theory, use SATA disks in (some) SAS systems.

(For my purposes here I'm going to skip over the actual and claimed differences between SAS disks and SATA disks of the same basic specification. You can find partisans on both sides and I lack the knowledge to have an informed opinion.)

Like SATA, SAS is fundamentally a directly connected point to point system; one SAS port, one disk. However normal SAS connectors are 'multi-lane', which is to say that they have the actual wiring for several SAS ports bundled into one physical cable and connector. The essentially standard sorts of connectors (such as 'IPASS' aka SFF-8087) has four lanes and so one connector on your SAS card or SAS-equipped motherboard can connect to four drives (through various things in the middle to break out the lanes). SAS also has standard support for SAS expanders, which are very roughly the equivalent of SATA port multipliers except that they support many more drives and generally work better.

Many cases that support SAS drives (such as the SuperMicro SC836 series) have a SAS backplane that sits between the drives and the rest of the world (such as your server motherboard). There are at least three general ways that such a backplane can work: it can have one or more SAS expanders, it can wire all drives through with completely separate connectors (aka '1:1'), or it can have IPASS connectors on the outside and break out each lane to a drive on the inside (aka '4:1'). If the backplane has SAS expanders you need only a few SAS ports to talk to all of the disks (often only one or maybe two). Otherwise you need as many SAS ports as you have drives.

(I think that a JBOD SAS disk enclosure is almost always going to have a SAS expander or two so that you only have to connect up one or two external cables. A server chassis may use any of the three options and your vendor may even let you choose. A full discussion of which one you might want when is beyond both my experience and the scope of this entry.)

You can plug SATA drives into SAS drive connectors (although not vice versa). While the two sorts of drives use completely different protocols, a properly functioning SAS environment will arrange to speak SATA to SATA drives. If you are not using a SAS expander I believe that the host SAS controller does this directly. If you are using a SAS expander there is STP (the SATA Tunneled Protocol) and I believe that your host SAS controller talks STP to the SAS expander, which turns it into SATA when it talks to the drive(s). On the Internet you can read all sorts of bad things about using SATA drives in SAS systems but my impression is that what creates most of this badness is putting SATA drives behind SAS expanders (see eg this). SATA drives that are directly connected to host SAS controllers seem to be reported as working okay.

As far as I can tell this means that JBOD SAS disk enclosures with SATA disks are probably not recommended but SAS server cases may be okay depending on what their SAS backplane is. You want a non-expander option, which will probably have the inconvenient side effect that you'll need an additional SAS controller card or two (8-port cards seem to be the standard). This may have implications for your long term storage expansion plans.

(SAS disks remain sufficiently more expensive than SATA disks that we can't deal with the whole mess by just using SAS disks.)

tech/SASWithSATAIntro written at 01:15:39; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.