Today, most of the public attention given to SANs is focused on the interconnects (such as Fibre Channel) that allow universal storage connectivity and the storage devices and computers that connect to them. But interconnects by themselves don't add any functionality to information processing, they only enable functionality to be added. To realize the benefits promised by SANs, not only must the hardware connectivity, performance, availability, and function be in place to enable them, system and application software must take advantage of the hardware to deliver them. Thus we have Rule 3 of storage networking:
Hardware makes SANs possible; software makes SANs happen.
SAN Software Capability
When evaluating SAN technology, the hardware components deserve close scrutiny, to be sure. More important, however, one must also scrutinize the software capabilities carefully to ensure that the implementation will deliver the functionality enabled by the hardware. The following sections give some examples of how software can make a SAN sing.
Sharing Tape Drives
It's very reasonable to expect to share a SAN-attached tape drive among several servers because tape drives are expensive and they're only actually in use while back-ups are occurring. If a tape drive is connected to computers through a SAN, different computers could use it at different times. All the computers get backed up. The tape drive investment is used efficiently, and capital expenditure stays low.
There's just one tiny problem. What is to keep a computer from (accidentally) writing to a tape while another computer is doing a backup? For two or three computers, an administrator can personally schedule tape drive usage so that this doesn't happen (unless something malfunctions, of course). As the number of computers and tape drives grows or as the applications running on them change, manual scheduling becomes increasingly difficult. What's really needed is a foolproof way for computers to negotiate for exclusive ownership of tape drives for the duration of a backup. When one computer wins a negotiation and is using a tape drive, others must be fenced off and kept from using the drive, even if an errant application or faulty backup schedule tries to do so.
Shoring Online Storage Devices
Sharing online storage, as shown in Figure 1.4, that's housed in an enterprise RAID subsystem is similar to sharing tape drives, except that more of it goes on mid requirements for configuration changes are more dynamic. A typical enterprise RAID subsystem makes the online storage capacity of one or more arrays of disks appear to be one or more very large, very fast, or very reliable disks. For now, accept that a RAID subsystem can look like several virtual disks from the viewpoint of host servers. It is quite reasonable that different servers be able to access those virtual disks at different times. For example, one server might collect a business day's transaction records on disk and hand them off to another server at the end of the day for summarization, analysis, or backup.
The problem here is similar to the problem of sharing SAN-attached tape drives among several servers: A server cannot be permitted to write data to a disk that another server owns at the moment. Some foolproof way of fencing off, or preventing other servers from accessing an allocated virtual disk, is needed. Moreover, a distributed system needs to remember which virtual disks have been allocated to (are owned by) which servers, even when one or more of the servers is shut down and rebooted.
Figure 1.4 Coordinating shared devices in a SAN
Again, it's software to the rescue. Some SAN infrastructure implementations help by subdividing a SAN into disjoint zones, and some RAID subsystems allow virtual disks to be reserved as the private property of a single computer (masked from other servers). It takes management software to exploit all these features, or to simulate them in SAN implementations whose components don't offer the features.
Application Failover
Figure 1.5 Application failover in a SAN-based cluster
Although the concept sounds simple, the clustering of two or more computers to enhance application availability is actually one of the most complex operating system problems there is. Even recognizing and isolating failures is nontrivial. Once an application failure is recognized, ownership of exactly the resources it requires to run (and no others) has to be transferred to a failover server immediately, completely, and unambiguously. The application must be restarted and its state at tile time of the failure recreated as nearly as possible. Again, it's software in tile form of a cluster server or cluster manager that does all this.
Sharing Data
More advanced forums of computer clustering, as illustrated in Figure 1.6, allow for tile concurrent sharing of data among different applications miming on different servers. This can be extraordinarily useful, for example, for incremental application growth or scaling. Simply stated, if an application outgrows the server on which it is running, don't replace the server with a bigger one. Instead, simply connect another server with the necessary incremental power to the SAN, leaving the original system in place. Both servers can run separate copies, or instances, of the application, processing the same copy of data. More servers can be added as application capacity requirements grow.
Figure 1.6 Shared data clusters enable applications to scale.
Applications configured this way are inherently highly available. If one of several servers running instances of the same application processing the same data falls, the remaining servers just take up the slack. Overall performance may decrease, but at least the application keeps running. That's much better than the alternative.
Data sharing can take any of several forms, from concurrent read-only access to different files in the sane file system, all the way to the sharing of a single database by multiple instances of a single application. In all cases, however, the mechanisms for orderly sharing—keeping different applications from overwriting each others' updates to data—are provided by... you guessed it... software.
Direct Data Movement between Devices
Earlier, we mentioned the emergence of more intelligent storage devices with new functionality that is accompanying SAN deployment One of the key functions being built into intelligent storage devices is the ability to exchange data directly with other intelligent devices in response to commands from a third party (e.g., a computer). Figure 1.7 illustrates such a set up. This capability promises to revolutionize backup, for example, by halving the amount of data movement required to create any kind of backup copy. Less obvious, but potentially at least equally useful, are the possibilities of mirroring or replicating data directly from one device to others.
Direct movement of data between devices needs two kinds of software. First, it needs software or firmware that implements the capability within the devices themselves. Second, host computer applications like backup and replication management that use the capability are required.
Figure 1.7 Direct copy of data between SAN devices
Summarizing SANs and Software
So, while high-performance, highly available, fully interconnected SANs are necessary to realize the benefits we have discussed, they are hardly sufficient. It takes system software on a massive scale to bring to life the benefits that are promised by the underlying properties of SANs. The software required to make the most of SANs takes two forms:
-
System applications. These applications build upon the basic SAN properties to provide a functionally enhanced execution environment for business applications.System applications include clustering, data replication, direct data copy between devices and the utility functions that use it, and so forth.
-
Management applications. These applications manage the inherently more complex distributed system environment created by the presence of SANs. Zoning, device discovery, allocation, and RAID subsystem configuration are examples of applications that fall into this category.
Both of these types of application are necessary for the success of SANs and, ultimately, for their utility as a tool for reducing cost and improving the quality of enterprise information services. While this book discusses the hardware components that constitute SANs, a good portion of it is also given over to a discussion of the software capabilities that make SANs into such extraordinarily useful business data processing tools.
