According to the Storage Networking Industry Association dictionary (and who should know better?):

A storage area network (SAN) is any high-performance network whose primary purpose is to enable storage devices to communicate with computer systems and with each other.

We think that the most interesting things about this definition are what it doesn't say:

It doesn't say that a SAN's only purpose is communication between computers and storage. Many organizations operate perfectly viable SANs that carry occasional administrative and other application traffic.

It doesn't say that a SAN uses Fibre Channel or Ethernet or any other specific interconnect technology. A growing number of network technologies have architectural and physical properties that make them suitable for use in SANs.

It doesn't say what kind of storage devices are interconnected. Disk and tape drives, RAID subsystems, robotic libraries, and file servers are all being used productively in SAN environments today. One of the exciting aspects of SAN technology is that it is encouraging the development of new kinds of storage devices that provide new benefits to users. Some of these will undoubtedly fail in the market, but those that succeed will make lasting improvements in the way digital information is stored and processed.

Let's dig a little deeper into this definition.

What Makes a SAN Different?

Anyone in the information technology field knows very well that computers are already connected to storage devices. If that's all a SAN does, what's new or different about it? The answer is a simple phrase that we'll keep coming back to over and over throughout this book:

Universal Storage Connectivity

Computers are indeed connected to storage today, but are all of an installation's computers connected to all of its storage? That's the key point about SANs—they connect lots of computers to lots of storage devices, enabling the computers to negotiate device ownership among themselves and, ideally, to share data. If there is one defining characteristic of a SAN, it's universal connectivity of storage devices and computers.

To appreciate the value of universal storage connectivity, consider the conventional client/server computer system depicted in Figure 1.1.

Figure 1.1 Client/Server information islands

From this business-as-usual picture of client/server computing, it's immediately apparent that by deploying multiple servers, an organization automatically creates unconnected islands of information. Each island is accessible by one computer but not the others. If Computer B needs to use data that was produced by Computer A, that data has to be copied to Computer B.

There are several techniques for moving data between computers: backup, file transfer; and interprocess communication, to name a few. But the real issue is that the information services organization has to acquire and manage the extra resources required both to copy data from Computer A to Computer B and to store it at both sites. There's no business reason for this duplication of effort, other than that a computer needs data that was produced by another computer.

There's a more serious implication of an information processing strategy that relies on regular copying of data from computer to computer. Computers that receive data copies are often forced to work with data that is out of date simply because it's physically impossible to make copies in a timely fashion. Moreover, the extra operational complexity introduced by having to copy data between servers creates additional opportunity for costly errors.

Contrast this with the SAN based distributed system architecture illustrated in Figure 1.2.

Figure 1.2 A SAN eliminates islands of information

With a SAN, the concept of a single host computer that owns data or storage isn't meaningful. All of the servers in Figure 1.2 are physically connected to all of the storage devices. If Server F needs data that was produced by Server E, there's no need to copy it, because Server F can access the devices on which Server E stored the data. All that's required is a logical change of storage device ownership from Server E to Server F or better yet, an agreement by Server E to stay out of the way while Server F is actively using the data.

There's no need to devise mid schedule data transfers between pairs of servers.

There's no need to purchase and maintain extra storage for temporarily staging one server's data at another server.

There's no need to worry about whether copies of data being used by two computers running different applications are synchronized (i.e., have exactly the same contents), because the two computers are working from the same copy of data.

Indeed, at this simplistic level, it's hard to see how any organization responsible for electronic information processing could not want a SAN. Let's drill still deeper and see how true that is.

What Makes a Good SAN?

The completely interconnected SAN architecture shown on the right side of Figure 1.2 is intuitively attractive, but if it's going to be the I/O backbone of an information services operation, it needs to have couple of qualities:

A SAN must be highly available. A single SAN connecting all computers to all storage puts a lot of enterprise information accessibility eggs into one basket. The SAN had better be pretty indestructible or the enterprise could literally be out of business. A good SAN implementation will have built-in protection against just about any kind of failure imaginable. As we will see in later chapters, this means that not only must the links and switches composing the SAN infrastructure be able to survive component failures, but the storage devices, their interfaces to the SAN, and the computers themselves must all have built-in strategies for surviving and recovering from failures as well.

The I/O performance of a SAN must grow or scale as the number of interconnected devices grows. If a SAN interconnects a lot of computers and a lot of storage, it had better be able to deliver the performance they all need to do their respective jobs simultaneously. A good SAN delivers both high data transfer rates and low I/O request latency. Moreover, the SAN's performance must be able to grow as the organization's information storage and processing needs grow. As with other enterprise networks, it just isn't practical to replace a SAN very often.

On the positive side, a SAN that does scale provides an extra application performance boost by separating high-volume I/O traffic from client/server message traffic, giving each a path that is optimal for its characteristics and eliminating cross talk between them.

The investment required to implement a SAN is high, both in terms of direct capital cost and in terms of the time and energy required to learn the technology and to design, deploy, tune, and manage the SAN. Any well-managed enterprise will do a cost-benefit analysis before deciding to implement storage networking. The results of such an analysis will almost certainly indicate that the biggest payback comes from using a SAN to connect the enterprise's most important data to the computers that run its most critical applications.

But its most critical data is the data an enterprise can least afford to be without. Together, the natural desire for maximum return on investment and the criticality of operational data lead to Rule 1 of storage networking:

When designing a SAN to access critical enterprise data, make sure the SAN is highly available (i.e., can survive failures of both components in it and components attached to it) and make sure it can grow well beyond anticipated peak performance needs without disruption.

What Makes a Great SAN?

So the fundamental feature of SANs is universal data storage connectivity. Universal connectivity enables a host of important benefits. Depending on the particular SAN hardware and software components chosen, additional benefits may accrue from advanced functions being built into today's SAN devices. Again, we describe some specific features and benefits later on, but for now we assert Rule 2 of storage networking:

When evaluating SAN implementation options, once the basic capacity, availability, and performance requirements can be met, look for advanced functionality available in the chosen architecture and consider how it might be used to further reduce cost or enhance the information services delivered to users.