The strength of a SAN is that it can modularly expand storage without sacrificing data-access speed. By removing storage from a PC or mainframe server to a pool, a SAN enables you to add drives and/or drive subsystems continually, as needed. Gone are the days of hard drives discarded along with obsolescent servers. Since one of the basic rules of computing is that data expands to fill the available space, the appeal of expandable storage is timeless.
The risk posed by a SAN is an effect I call the Alice's Restaurant Syndrome: Given a huge storage space, garbage won't be taken out. When it does eventually get taken to the dump because it smells, you'll get into trouble somehow.
Gotchas and head-scratchers
SANs present a few other gotchas. After surmounting (excuse the pun) the hurdle of deploying the fiber cables that are a SAN's nervous system, many network integrators and designers will face a problem they probably haven't encountered in a while: filing system interoperability -- as in not.
A SAN is most useful when it supports a variety of clients or server operating systems. Those that support the widest range of platforms, however, may do so at the exclusion of Windows. Because they prefer NTFS (the NT file system), NT and 2000 servers are not natively able to cooperatively use SAN storage areas based on Unix filing systems. Providing data access to other filing systems requires something else -- and that something costs money.
Those unwilling to address this problem find that their SAN will be segregated into NTFS and non-NTFS areas. In such a segregated environment, Windows NT/2000 servers still benefit from the modularity a SAN provides. However, these servers' volumes or other storage areas will not able to be mounted concurrently by, say, both a Unix server and an NT server -- unless help is applied. (After all, not even the much touted Microsoft Interix, the Unix application portability suite, talks to Unix filing systems.)
Help comes in the form of SAN operating systems. A SAN OS is actually a set of programs that live inside the servers participating in a SAN; Navistor's suite of programs provides a good example. The idea behind the Navistor architecture is to have at least one server that coordinates storage access. Every other server participating in the SAN is equipped with a driver and a management interface that provide connectivity to the primary, coordinating server; the coordinating server both translates requests and provides security.
The software layer thus interjected into each device in the Navistor system translates application filing-system requests into common, Esperanto-like calls to the storage devices under the SAN OS's control. So far, Navistor has provided compatibility with the most commonly used file systems. (See Resources, below, for Navistor's site, which provides more details and caveats.)
SAN drives are tricky to use as boot media. This news won't break the hearts of industry old-timers who are already suspicious of detaching all of a server's media in favor of a SAN.
Another gotcha: No simultaneous access is allowed to the same physical data file unless, of course, that file is read-only. (A SAN operating system won't allow you to corrupt data through simultaneous writes, thank heaven.) And a SAN operating system must still provide a way to find files adequately through the use of operating system search criteria (search paths or registry entries or tree calls) or other filing-system search methods such as Explorer.
Windows 2000 dynamic disk management won't work on a SAN -- as well it shouldn't, since it could allow a user to dynamically repartition a shared area, to the detriment of stability.
The app factor
During the prejudgment and appeal stages of the Napster case, a reporter on NPR's afternoon radio show All Things Considered interviewed a fellow with an MP3 addiction. He downloads MP3 files -- more than 2,000 to date -- incessantly, occasionally checking out the results to find "interesting music and new artists." I think it's an obsessive-compulsive disorder, but then, many computer apps -- and users -- suffer the same problem: Observe my 351MB personal message store ... and its backup.
One of the best candidates for a SAN is the traditional client/server relational database store. While there's a trend toward buying huge server memory arrays -- think DRAM or "user memory" -- to keep relational databases in memory (as opposed to magnetic storage), such a solution is only part of the picture.
Relational database applications require the creation of views and tables. Some tables are dynamic and have a short life; others exist for a longer but still finite amount of time; some live forever. An increasing reliance on the mining of data from the data warehouse -- and on the resulting large sorts and analytical analyses -- is driving the need for elastic storage space. The need to maintain elasticity may also keep database views, tables, sorts, and the like, away from primary table storage and necessitate additional space -- SAN space. Data-mining programs may build tables via Ethernet-based queries to applications such as Oracle or SQL Server, then place those tables elsewhere on the SAN.
The SAN-app quick list
Adopting a SAN reminds me of practicing est or transcendental meditation. Once you've shaken your old mindset, you start to find new ways of applying the method. Likewise, once you've made the necessary leap to a new infrastructure, you'll find that removing storage from the data-processing method associated with servers is liberating. A SAN will have helped you achieve application-services modularity.