December 12, 2000, 4:59 PM — 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
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
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.