When SAN is not SAN: new language for the SAN marketplace - Storage Networking

Computer Technology Review,  Oct, 2002  by Marty Frary

• E-mail
• Print
• Link

We can decompose the acronym, SAN, to identify three essential features of a SAN: "storage" nodes or resources, a physically and logically localized "area" in which those storage resources reside, and "network" connectivity. Storage nodes comprise -- storage devices (tape, disk drives) or subsystems (disk arrays, tape libraries) -- instead of compute -- application or file servers. The localized area is physically and logically separate from a typical LAN on which clients run applications and hosts serve files. Finally, the connectivity among the components of the SAN is network-based. Storage device and subsystem interconnect is via network media and protocol to many, possibly heterogeneous, sources and sinks of data instead of channel or bus attached to a single server.

While these features are essential to the existence of a SAN, a SAN is much more than a collection of components. It must include control or management software that orchestrates connections and data transfer to achieve the desired functionality. A SAN, typically, provides block-based I/O services, but may also support filebased I/O. The emphasis on block-level transactions is a convenience for and construct of data replication or backup software, because some see the primary value of the SAN as the domain in which backup of disk to tape might take place, independent of client-side activity. When backups are done in that automated fashion, there is no particular need for file-system involvement in moving data. However, there is also no particular reason to preclude the capability of file-level transactions occurring within the domain of a SAN. In fact, it is desirable to be able to mix both block- and file-level traffic to simultaneously accommodate both database and file system-attached clients. Furthermore, it is desirable to be able to mix heterogeneous storage resources within a SAN.

So, what does the SAN acronym really describe? It is probably not very useful to say SAN is a product or a technology. Rather, it is more useful to describe SAN as a topology or configuration or architecture aimed at achieving specific functions in an IT environment. While the description above is consistent with most others found in the literature, it really doesn't help one to understand either the full capability or the added value of any particular SAN installation. What is really needed is not just an unambiguous definition but a useful way of communicating the functional capabilities of a SAN. A SAN is really about functionality. A SAN is a way to provide channel-like access between multiple servers and multiple storage resources with network-like connectivity. A SAN is a way to share or virtualize devices, volumes, and data. A SAN is a way to provide dedicated bandwidth to data management, apart from a normal enterprise LAN on which applications are run.

For the sake of further discussion, we'll define a SAN as a configuration of components comprising three types of functional elements; devices, connectivity and control. The devices include storage devices or systems. The connectivity includes interconnection, routing, switching, media, and protocol. The control includes management of storage resources, data paths, data, and data transfer.

Why and How to Differentiate?

Common terminology and understanding is important to market and technology advancement and for customer benefit. The most important reason to differentiate SANs by function or some other attribute is three-fold. First, it is better for customers, because vendors can provide more clearly defined functional specifications using new language. Second, it is better for vendors, because customers can supply more clearly defined functional requirements in terms of this new language. Finally, industry analysts can more accurately characterize the market when nomenclature is more granular and less ambiguous.

Many attributes of a SAN configuration could be used for classification. They could be based on hardware or software, connectivity, or functionality. For example, one could classify a SAN in terms of hardware attributes; as in a 10-node SAN, a 100TB SAN, or a disk-only SAN. One might also classify in terms of connectivity, such as a fiber-channel SAN, or a Gigabit Ethernet SAN. Finally, one might classify in terms of functional capability, as in a peer-managed SAN. Of course, there are many other possible classification schemes that could employ increasing levels of specificity by combining attributes or by deriving new figures of merit. For example, there might be a 100TB, Fibre-Channel SAN. Or, there might be a 100Mnode SAN, where Mnode is defined as data transfer capability in MB/sec. divided by the number of storage nodes in the SAN.

The key is to provide some useful level of classification while avoiding too much specificity. This might be achieved by focusing more on what is provided, than by how it is provided.

There is precedence for this kind of language in the IT industry. For example, disk arrays are classified according to RAID levels.