SAS: now and in the future.

Serial Attached SCSI is the logical evolution of SCSI, including long-established software advantages and the Serial ATA electrical and physical connection interface. With enterprise storage requirements escalating and becoming more complex, factors such as larger capacity, greater density, security, scalability and accessibility are more critical than ever. To look into the issues revolving around SAS, the SCSI Trade Association convened a roundtable to answer questions posed by CTR editor-in-chief Mark Ferelli.

When are SAS systems going to be on the market?

Wong: My expectation is that the components will be coming together and be very robust by Q3 and Q4. And then you'll start to see products from system vendors be available in the beginning of 2005.

What is the pacing item that will govern the introduction of SAS-specific products in the marketplace?

Wong: I think the pacing item is just the interoperability and qualification that needs to go through the OEMs. So again, the plugfests of the components suppliers have gone very well. The components are coming together very well. And I think the pacing item is just the testing and qualification to get these into products and released to the market.

Croteau: Two things are happening fast. One, I think the way that the specification is being put together intelligently to utilize some of the work that's already been done in SATA, to leverage that into the interoperability, is helping get SAS product to the market faster than we benchmark it against similar products--such as Fibre Channel or iSCSI--pick your favorite technology from the last decade or so. The second is that really new technology deployment in the market is two-phased. The first will be discreet product, just as we normally do, so Linus referenced himself as a component supplier. Certainly we have others in the SCSI Trade Association. And those products will start to show up towards the second half of this year. And then the large scale of the ramp will really target the next server refresh cycle. And that's why the 2005 time-frame really looks like the bread and butter of SAS deployment. But right now, just based on interoperability and just based on the early plugfest data, I would say it's well ahead of several other new technologies. If you look at it just because of all the investment that we're utilizing, it's driver models SCSI command structure and then all the serial work that's been done on the status side with regard to buys and cabling, etc.

I'd like to draw an analogy with iSCSI for just a moment. One of the things that is pacing the introduction of iSCSI into the marketplace is the lack of iSCSI targets. There are initiators all over the place, but targets are just coming to market. How target-rich an environment is SAS now, and what is the road map to get to a more target-rich environment?

Schilling: Well, assuming that you could classify disk drive as a target, we're pretty rich with targets with really all drive suppliers having announced support for SAS and, to varying degrees, delivering product or plans to deliver product.

What level are the targets going to be? Are we going to stick to things like disk and tape drives or automation?

Croteau: I think if you look at SCSI deployment historically, any device that's utilized SCSI is--and will be--a candidate for SAS just based on the evolution of spec. And I think comparing it with iSCSI, while they do share some of the fundamental common command structures, iSCSI's really just a transport, a method to get to a box. Whereas, when we talk about SAS, we're really talking about the fundamental connection of the hard drive and the host connectors. In fact, I wouldn't be surprised if you didn't see combinations of iSCSI in fabric to SAS. But SAS is not dependent on fork-lift upgrades, etc., for value propositions like the iSCSI camps have made. It's a natural evolution of the technology and continues SCSI well into the future.

Wong: What Chris said is important. There is a fundamental difference between iSCSI and SAS--which is that SAS is just the next generation of SCSI. We're going from Ultra 320 SCSI, parallel SCSI, to 3-gigabit-per-second serial SCSI. iSCSI isn't just the next evolution of Fiber Channel, it's an alternative technology to create a storage area network (SAN). And the value proposition needs to be defined. The usage models need to be identified. Is it a DAS replacement? Is it an entry-level SAN? There are a lot more unknowns in the iSCSI environment and iSCSI world. Those unknowns don't exist for SAS; SAS is just there instead of Ultra 640.

Then we see SAS as the next evolution of SCSI. What benefits are our readers--who are dominantly systems integrators--going to experience from instituting a SAS capability within their organizations?

Schilling: One might be the idea that a SAS backplane or system is not only compatible with SAS disk drives, but SATA disk drives. So it will provide significant flexibility for your readers, integrators and users to design and develop a common backplane that can be proliferated across different applications with the ability to chose drive type based upon application and use it on that common backplane.

Are the end-user customers of those system integrators sophisticated enough to identify the differences and the benefits? Because it could even impact their hardware inventory.

Croteau: Actually, I think it'll ultimately simplify their inventory issues because if you standardized on a common backplane, even if the end users get as mundane as mission-critical data, it's nice to have data and equate mission critical to SAS and the robust reliability that's built into the SCSI disk drives and infrastructure. We have

one SAS, one backplane or one server system, and we get to pick and pay for the level of reliability that we want in the storage media itself. I won't speak for the whole group, but in my mind, this is fundamentally the most important thing that's happening right now, bringing this capability into SAS. Because it's the first time that I can think of--and I've been challenging people to find another technology that's combined two dissimilar technologies into one.

Schilling: We're seeing and our [OEM] customers are seeing that, within the enterprise, the idea of using one type of disk drive for all applications is a thing of the past. And data centers and enterprises are indeed buying stored solutions with drives in them that are optimized for that particular application. Chris was talking about the fixed-content large images, documents and other related files that may be accessed infrequently; but when they are, they need to be there quickly. You're going to see very high capacity oriented for 500-gigabit, 7200-RPM SATA drives being used to store that data. And with our technology, we enable an integrator or an IT end user to within a single enclosure (if they choose to take this approach) and provide different tiers of storage for the enterprise. The other thing that I'd add is that the point-to-point 3-gigabit (point-to-point full duplex 3-gigabit per second) architecture of SAS will enable smaller, faster storage solutions that are used for mission-critical data storage. It's a far more scalable, flexible architecture than what users and integrators have experienced with parallel SCSI.

With the rise of new disk-intensive architectures--such as disk to disk for primary and, in some cases, secondary backup or disk to disk to tape where disk takes on a cache role in-between primary and archival storage--do you see SAS as an enabling technology for these capabilities? And if so, how are they going to impact how IT handles data?

Wong: I think SAS absolutely is a new end technology for precisely what we've been talking about--the flexibility you get by being able to standardize on one backplane. You can imagine a rack with one standard backplane and you can simply populate the right type of drive for the right workload. I think, at a technical level, it's a great enabler. And then architecturally, because it's a point-to-point architecture, it offers greater scalability. It also supports the higher level of connectivity and scalability that you need to support these larger configurations.

Bill, how is serial attached SCSI going to impact a small form factor disk drive?

Schilling: It's highly complementary to an enterprise-class 2.5-inch disk drive. Jay can certainly comment on the smaller connector sizes that are available with SAS versus parallel SCSI. So the idea of having a smaller drive is highly beneficial. The fact that with an enterprise-class 2.5-inch drive, you'll be able to pack in 24 to 30 drives within a 2U array--SAS further enables that solution with its highly scaleable point-to-point architecture. So, in many ways, serial attached SCSI and enterprise 2.5-inch class drives are the perfect marriage, they complement one another.

Jay, one of the things that I'm concerned about in SAS, and what seems to me a key benefit, is a simplification in cabling and connectors.

Neer: One of the problems that systems houses had with internal cabling prior to the serial interfaces was the real wide rib-style cables. And if you do other than a backplane connection, for example, the multilane 4X in a SAS environment, the cable is much smaller. It's a round implementation and is a lot easier to deal with from a routing standpoint and also enhances any airflow issues that there were with ribbon cables blocking the airflow before.

Micheletti: It's worth mentioning that costs are also expected to be favorable because SAS and SATA (Serial ATA) will share a very similar design with regard to cables.

Now, the other important SAS issue is the common connector pattern, the ability to choose either lower performance SATA or higher performance SCSI-based drives. How is disk array technology going to have to adapt (if at all) for the entry of SAS into the IT connectivity mix?

Wong: I don't think the RAID technology itself changes that much. RAID today certainly supports five, ten, twenty, however many drives. But I think there are some interesting trends and they are--as disk capacities get larger in these RAID arrays and in particular as disk drives get smaller and you start to have a larger number of disk drives in arrays--people are concerned about multiple disk-drive failures.

So, right now, RAID-5 protects against a single drive failure but not a second drive failure. And the problem is, with the long rebuild times, people are looking for technologies like RAID-6 or ways of protecting against more than one drive failure. So I think it's not directly related, but it's certainly a relevant trend.

How about things like service life for the disk drives? We now have drives working harder than ever before and, as you point out, RAID isn't necessarily ready for a second drive failure. And disk drives are still spindle-based creatures and they will go down. So SAS is going to enable sort of a more uptime situation and I'm wondering what will have to happen within the drive to adjust, if anything?

Schilling: That's good point. I appreciate the fact that you've been able to conclude that the technology might actually kind of increase the workload on the drives, and that is true. And the drives here at Seagate are focused on reliability and things that we can do to the drive, in our testing and in our manufacturing, to increase our drives' reliability. The enterprise 2.5-inch drive from Seagate is initially spaced at a 1.4 million hour MTBF (Mean Time Between Failures) reliability spec which is higher than most drives have been in the past. So we're making a conscientious effort to increase and raise the bar of the reliability performance of our product. Of course, on the flip side--in a sort of tiered storage or in some storage environments--an enterprise-class drive may not be fully utilized due to the nature of that particular workload. And again, with the ability to populate whether it be within a system (a single system or a single enclosure) the idea of using 7200-rpm SATA drives enables you to match up the drive to the workload and deliver more cost-effective service.

Let me give everybody a scenario to consider. I have implemented a SAS subsystem within my IT installation. It has been there for some time and sooner or later I will have to think of upgrading and updating. How much grief or how little grief am I going to have to go through to update my SAS system in-house?

Croteau: Could you be a little more specific on what kind of subsystem? Is this part of a SAN or is this direct attached or--?

No, let's make this either a secondary storage or a storage area network. Work both sides of the street, if you can.

Croteau: I think, predominantly, you're going to see a couple of scenarios. One is in the life cycle management that the array may be taken offline and that data may be migrated to a newer, more reliable (or maybe even just more cost effective) storage medium in the future. But the array itself may get pushed out into another tier in the infrastructure. And I know we keep harping on this duality nature of SAS as a SCSI or ATA host, but it really does give you some interesting connotations on the hardware if I'm able to multitask that based on the workload that I want it to do. So I may take the backplane--that's the cabinet, the array itself--and move it out into a lower workload environment in the future. I may even pull the drives out and populate it with newer SATA drives, higher capacity and turn it into a reference platform. Or I may just leave it in the pool if it's in a SAN, as part of my virtualized data, given that the age of the data will start to limit the access to it. It'll be available when people want it and this will kind of naturally migrate to a lower workload. But over time, the beauty of SAS is maintaining that SCSI investment and so not having to reinvest validation time in drivers and operating systems and application compatibility is really one of the key factors driving the SAS adoption cycle and why we're so bullish on the deployment of SAS.

How about things like host bus adaptors? Will they have to be replaced in each generation or is it a forklift situation?

Wong: It'll look just like host bus adaptors today. You know, the next generation will be a new card and you'll have new disk drives and probably a new component, new infrastructure as well. I'm not sure SAS changes the world in terms of upgrading to new technologies. If it's a server, it's probably attached in the box. You roll in a new server and you're done.

How about from the cabling and connectors side? Is there an evolutionary cycle envisioned there?

Micheletti: From one level of SAS to another, not to my knowledge. I believe the cabling should be the same and, if you have a backplane there, that interface would remain the same.

Well, that's significant for an investment protection and an architectural topology development point of view. How are the drives themselves, things like SATA, going to integrate as the areal densities increase (as they do every year) and the spin speeds increase?

Schilling: Probably not unlike what was described before. You know, we expect that to leverage serial attached interface in all future enterprise-class drives--particularly our 15K 3.5-inch drive family and our 2.5-inch enterprise-class family. So host bus adaptor suppliers like Adaptec will follow on higher performing--we've got 6-gigabit-per-second performance on the serial attached SCSI roadmap--I think going as high as 12 gig.

The roadmap was just 12, yes?

Schilling: Right. And, likewise, we continue to drive areal density on our products both enterprise and non-mission-critical SATA drives. So today, or very soon, Seagate will be announcing a 400-gigabyte SATA drive that we expect will increase in capacity and follow on generations within this product family.

How about on the subsystem level, Jay? I'm thinking about things like enclosures and such like because they will have to grow as the sophistication of SAS changes. No, actually, let's focus on how things like enclosures will have to evolve as SAS evolves.

Neer: The structure of the enclosures will be affected because there are more hard disk drives in a 2-inch form factor now, for example. So they're going to have to accommodate the rotational vibration and the other facets of that.

Schilling: And note that with a 2.5-inch disk drive, the power requirement is about 40% to 50% less than a 3.5-inch 10K drive. So we're not creating an unusual power burden within a single 2U array as a result of more drives. But obviously, with more drives there are things that enclosure designers need to take into consideration in developing SAS-based 2.5-inch enclosures. I can say that 2.5-inch enclosures are indeed in development and you'll start seeing companies offering 2.5-inch enclosures in the July/August timeframe to distributor customers.

Is there anything that you would like to add, Mike, from the standpoint of test and making sure all this stuff is going to work together as it evolves?

Micheletti: Well, maybe back to this notion of upgradeability. I think it's conceivable that when 6-gig SAS shows up you could upgrade host side environments, and with a 6-gig link attaching to primarily 3-gig disk drives, you benefit by essentially implementing an aggregation strategy for the storage where you're getting throughput on the back end just because of the 6-gig link. That's something that I think IT and the integrators would care about.

What are your expectations for the development of the SAS spec in the future? Are we going to do a Moore's Law change every 18 months, or is something little less or a little more sedate involved?

Schilling: I think the roadmap has been pretty clear that the next evolution of SAS will be a 6-gig or a doubling of Moore's Law effect, if you will. Following that is the 12-gig connection rate.

PARTICIPANTS

Mark Ferelli: Moderator and editor-in-chief of Computer Technology Review.

Bill Schilling: Director of Global Product Marketing for Seagate Technology.

Linus Wong: Director of Strategic Marketing at Adaptec.

Chris Croteau: Director of Business Development for Storage Technologies at Intel.

Mike Micheletti: Product Manager at CATC.

Jay Neer: Strategic Product Manager at Molex.