Editorial

Posted on March 01, 2003

RssImageAltText

NAS + SAN = chocolate + peanut butter?

Click here to enlarge image

A lot of vendors talk about NAS-SAN convergence (the topic of this month's Special Report) as though it were the second coming of Reese's peanut butter cups—you know, the best of both worlds.

Two years ago, I would have called it Network Appliance-envy. Vendors who were concentrating on SANs suddenly realized that NetApp was making more money on NAS than any one vendor was on SANs. By then, it was too late for any vendor other than EMC to cut into NetApp's NAS market share, so the race to NAS-SAN convergence was on.

At that time, I didn't think that end users really had any need to merge the two architectures. At most sites, NAS was deployed for specific applications (CAD/CAM, e-mail, etc.) where file serving was king and low cost was queen.

Direct-attached storage and SANs were used for block-level I/O applications that required higher performance (databases, transaction processing, etc.). And n'er the twain shall meet. In fact, they were typically on different floors, or in different buildings, managed by different IT groups.

Last year, however, we polled our readers on the subject of NAS-SAN convergence. Of those readers who had both NAS and SAN, 64% said they had the need for products that merge, or combine, the two architectures. Obviously, there is a need for NAS-SAN convergence.

EMC and Hewlett-Packard (Compaq at the time) were among the first major vendors to merge NAS and SAN, although those companies' approaches required the use of those vendors' disk arrays on the back-end. Last year, NetApp retreated from its "Who needs SANs?" stance and introduced the FAS900, which combines a NAS filer and a Fibre Channel SAN back-end. And smaller vendors, such as Auspex, introduced vendor-independent controllers that enabled NAS-SAN convergence. A number of other vendors are in this space, because it's not really rocket science to stick a NAS head (gateway) in front of a Fibre Channel back-end, which today is the dominant method of achieving NAS-SAN convergence.

That's pretty straightforward, but this market is going to get very murky—at least from a terminology standpoint—when IP storage gains traction with adoption of iSCSI and adapter cards that offload TCP/IP and iSCSI processing from host CPUs. If you can do (block-level) iSCSI and (file-level) TCP/IP storage I/O over standard Ethernet—with or without Fibre Channel target devices—do you call that NAS-SAN convergence?

For that matter, is this a "SAN?" And if everything's network-attached storage, what's the difference between NAS and SAN anyway?

I suppose it will depend on whether you're touching the tail, the tusk, or the trunk of the elephant.

Dave Simpson
Editor-in-Chief


Comment and Contribute
(Maximum characters: 1200). You have
characters left.

InfoStor Article Categories:

SAN - Storage Area Network   Disk Arrays
NAS - Network Attached Storage   Storage Blogs
Storage Management   Archived Issues
Backup and Recovery   Data Storage Archives