Particularly with the next generation, SAS will provide everything that users and integrators need to make the optimum blade-storage connection.

By David G. Hill

Blade servers are now very familiar to IT organizations, but they still have a lot of growth potential. And one of the gating factors for unlocking that potential is improving the relationship of blade servers and storage. Blade servers need a close relationship with storage -- just not too close. To get the most out of blade servers, no storage should be on the blade server itself. The storage should be either on a local "network" within a chassis (i.e., direct-attached storage) or externally on a SAN. Why?

Take the case where a blade has its own disk drives for application data. Two problems arise: one with provisioning and one with data protection. Provisioning is a capacity-planning issue. What happens if the disk fills up? Neither adding a disk nor migrating to another server with more storage is a palatable solution. Data protection is about the fact that the disk is a single point of failure. For data-protection purposes, the disk should be mirrored. But putting two hard disks on the same server blade causes cost, blade real-estate, and energy-consumption issues. Using storage on the blade itself for application data is not a good idea.

But the server has to boot from somewhere. The server blade may be able to get by with a flash disk instead of a hard drive, but that represents a single point of failure both for the storage and for the server. If the server is booted from a disk device that is not on the blade itself, then if a blade fails a new one can be swapped in and rebooted with the same exact version of the appropriate operating system. So moving the boot function off the blade itself makes sense.

However, the required functionality for booting off the blade itself is zoning. Fibre Channel has zoning capability, but the 3Gbps SAS generation does not have zoning capability. The next generation of SAS -- 6Gbps -- will have zoning capability defined in the SAS-2 specification. (As an aside, note that the new generation, which should be available in products later this year, is only nominally about speed; functionality, such as zoning, may be the real reason for buying 6Gbps SAS products.)

With the next generation of SAS, blade servers can boot from the network using SAS. No storage is required on the blade server. But why does it matter that SAS will be able to fully support blade servers when Fibre Channel already has that capability -- and Fibre Channel users are not likely to switch?

IT managers will want to plan the adoption of SAS for use in blade servers for three primary reasons compared to Fibre Channel:

• Flexibility and simplicity for both in-chassis (DAS) storage as well as external (SAN) storage;
• Greater cost efficiency; and
• Tighter integration with SATA for creating tiered storage.

Flexibility and simplicity are big pluses for the new generation of SAS in enabling either DAS or SAN storage with blade servers. If a SAS host controller chip is mounted on the server blade that communicates to the microprocessor on the blade through a PCI-e bus, that SAS controller then talks to a SAS expander as a stand-alone module. The SAS expander is essentially a cross-point switch that routes any source to any destination and can cascade to thousands of disk drives if necessary. In other words, the SAS expander acts as a blade switch. That blade switch can talk to either a storage blade internal to the blade center chassis (i.e., DAS) or externally to a SAN storage array. Boot disks (plural because there are multiple blade servers) can reside either on storage blades or on the SAN.

Note that using SAS expander devices as blade switches have both price and manageability advantages over using comparable Fibre Channel devices that were originally designed for SAN environments. Practically speaking, IT would want to go with two SAS expanders to prevent having a single point of failure. That can be in an active-active mode with load balancing. The cost and manageability advantages still prevail.

SAS+SATA
SAS controllers and expanders can also support SATA drives. But the key is that multiple hosts have to be able to share a single SATA drive, as one host may not be able to take advantage of all of the capacity of a SATA drive. That requires a SAS capability called "multiple affiliations," which are part and parcel of the new generation of SAS.

The ability to support both SAS and SATA drives simultaneously is very important, particularly in the context of blade servers. SAS drives have higher performance and reliability compared to SATA drives, but SATA drives have much higher capacity. Active production data that requires the high performance or reliability of SAS can reside on SAS drives, whereas data that does not demand such high performance or reliability -- such as read-only production data from a completed transaction -- can reside on SATA disks. And that read-only data, which can also be called "active-archiving" data, may take up the bulk of the storage requirements. Thus an IT organization can tier its storage so that the data is stored on the proper tier aligning to where it is in its information lifecycle. This means that the new generation of SAS can support an information lifecycle management (ILM) strategy. Since disks are roughly priced on a per-disk basis rather than a capacity basis, this is a cost-efficient solution that at the same time preserves performance or reliability for that data which demands it. And the close SAS-SATA relationship makes ILM much simpler and less costly than trying to cobble together a Fibre Channel solution.

Blade servers can accommodate multiple interfaces and drive types, but cost efficiencies and management simplicity bode well for SAS. All in all, the marriage of blade servers with SAS storage will be a happy one that provides management flexibility and cost efficiency, making SAS the future cutting edge for blade server storage.

David G. Hill is a principal with the Mesabi Group LLC consulting firm. Prior to founding Mesabi Group, he was the vice president of storage research and founder of the storage and storage management practice at the Aberdeen Group.

This article was originally written for the SCSI Trade Association and published in the Serial Storage Wire newsletter.

Related article:

For more on SAS, go to the SAS Resource Center.