From a TechRepublic reader:  “I enjoyed reading your article on SAS, SATA, and NL-SAS. I’m looking forward to other articles about storage technologies. I am particularly interested in how this applies to SSDs and iSCSI. What are the relationships with these various technologies? I’m moving to an iSCSI interface to allow more virtual access from various servers and less dedicated storage. Should the drives be SAS or SATA in the iSCSI array or should I care? What about SSDs for the main server OS drives, and perhaps applications. I’m going to start with the supposition that everything else, file storage, backups, etc., belong on the iSCSI device (with additional backups to the cloud and/or replication off-site). I’d love to hear your ideas on these issues.”

This is a great set of questions. First, I’ll take the one about how Serial ATA (SATA) and Serial Attached SCSI (SAS) apply to SSDs and iSCSI.

SATA and SAS are storage interface and bus types designed to aid in the movement of data from one place to another. Think of SAS and SATA as different kinds of computer interfaces, such as PCI Express, but there are actually multiple components that make up the overall SAS architecture.

  • Initiators. The initiator is the SAS controller to which SAS expanders or targets can be connected.
  • Expanders. Expanders sit between initiators and targets, but can also connect to other expanders, as you can see in Figure A. Expanders are sort of like network switches in that they can direct traffic and they provide the ability to scale the SAS architecture beyond single port limits.
  • Targets. A target is either a SAS drive or a SATA disk. SATA disks can be connected to SAS expanders and initiators, but do not perform quite as well as SAS disks.

Figure A

A simplistic SAS diagram

The individual drives each have their own host interface – SAS or SATA – connected to either an expander or the initiator. Even the SSD drive in this example has a SAS interface, although it could also have a SATA interface. So, this means that the initiator – the controller in the system – communicates with the SSD using SAS or SATA commands. In this way, an SSD is just like any other SAS or SATA disk. It just uses a different method for storing data.

With it now understood that SAS and SATA are host interfaces and SSD is one of the drive types that can be used with a SAS interface, how does iSCSI fit into the equation? Figure B below gives you a look.

Figure B

A simplistic iSCSI diagram

In Figure B, note that the host server has an iSCSI initiator. It’s either hardware- or software-based and controls communications with the Ethernet-based storage array. By virtue of the fact that the system is using Ethernet for storage traffic, speeds of both 1 Gbps and 10 Gbps are supported. In an iSCSI storage network, SCSI commands originate on the host, at which point, they are encapsulated inside TCP/IP packets. These TCP/IP packets then traverse the Ethernet network just like any other network traffic. At the storage array side of the equation, these packets are received and the SCSI commands are extracted from the TCP/IP packet and passed on to the storage device for execution. Data that is transmitted back to the host undergoes this same encapsulation process.

This means that there is some overhead with iSCSI. The encapsulation process does require some processor time to accomplish.

iSCSI is the storage transport but, at present, there is no such thing as an “iSCSI disk.” iSCSI arrays use SAS and SATA disks (which can also be SSDs) for storage, but the data is transported to hosts using iSCSI.

Even though iSCSI adds a bit of overhead and does not provide the level of throughput of raw SAS, there are some really good reasons to use this technology. As you saw in Figure B, iSCSI provides a good method by which to decouple storage from the host. This allows you to share the storage among multiple hosts in an industry standard way. The diagram in Figure C shows how such a system might be architected.

Figure C

A single array shared with three hosts

Next week, I’ll take up the second part of the question, which concerns which types of drives should be used in various scenarios.


In this post, you learned about how SAS is architected from a high level and how iSCSI fits into the storage equation. iSCSI is a transport protocol while SAS, although it can be a transport protocol in direct-connect scenarios, is also a disk type.