By David G. Hill, Principal,
Mesabi Group LLC
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 with storage. Blade servers need a close relationship with storage — just not too close. In order 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 (DAS)) or externally on a storage area network (SAN). Why?
Take the case where a blade has its own hard disk drive (HDD) 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 another 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 who wants to put two hard disks on the same server blade for cost, blade real estate, and energy budget reasons? Using storage on the blade itself for application data is not a good idea.
But the server has to boot from somewhere. Now the server blade may be able to get by with a flash disk instead of a HDD, but that is still storage. And 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 booting function off the blade itself makes sense.
However, the required functionality for booting off the blade itself is zoning. Fibre Channel (FC) has zoning capability, but the 3Gb/s SAS generation does not have zoning capability. The next generation of SAS, known as 6Gb/s SAS, will have zoning capability defined in the SAS-2 specification. (As an aside, note that the new generation, which should be available in products sometime in 2008, is only nominally about speed, with backward compatibility provided. Functionality, such as zoning, may be the real reason for buying 6Gb/s SAS products.)
In any event with the new generation of SAS, blade servers can boot from the network using SAS. No storage at all is required on the blade server. But why does it matter that SAS will be able to fully support blade servers when FC already has that capability – and FC users are not likely to switch?
IT planners will want to plan the adoption of SAS for use for blade servers for three primary reasons as compared to FC:
- Flexibility and simplicity for both in-chassis (DAS) storage as well as external (SAN) storage
- Greater cost efficiency
- Tighter integration with SATA for creating a tiered Information Lifecycle Management (ILM) strategy
Flexibility and simplicity is a big plus 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 talks to the microprocessor on the blade through a PCI-e bus, that SAS controller then talks to a SAS expander as a standalone module. The SAS expander is really a cross-point switch that routes any source to any destination and can cascade to thousands of HDDs 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.
Please note that using SAS expander devices as blade switches have both price and manageability (i.e., flexibility and simplicity including configuration) advantages over using comparable FC devices that were originally designed to serve 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 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. Multiple affiliations are part and parcel of the new generation of SAS.
The ability to support both SAS and SATA drives simultaneously is very important. SAS drives have relatively higher performance and reliability as compared to SATA drives whereas each SATA drive can have significantly larger capacity. Active production data that requires the relatively higher 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 FC solution.
Now blade servers can accommodate multiple interface electronics and connectors, 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 relative management flexibility and cost efficiency benefits that IT will welcome. SAS will indeed be the future cutting edge for blade server storage.
Prior to founding Mesabi Group, David Hill was the Vice President of Storage Research and founder of the Storage & Storage Management practice at the Aberdeen Group. Before Aberdeen, Hill spent many years at Data General where he directed Data General’s internal IT data centers and managed the introduction of new analytical tools and business systems. At EMC, he carried out strategic marketing, competitive analysis, sales force planning, and market forecasting. He has an advanced degree from the Sloan School at the Massachusetts Institute of Technology.