This article can also be found in the Premium Editorial Download "Storage magazine: Expanding SANs: How to scale today's storage networks."
Download it now to read this article plus other related content.
|SAN File System Architecture|
Clients participating in SAN File System retrieve data in a two-part process. Clients equipped with the virtual file system request data from the metadata server, which provides a file's physical location, and issues locks. With that information, clients retrieve data from SAN-attached disks directly over the Fibre Channel SAN.
Sure, compared to direct-attached storage (DAS), SANs are easy to scale, and they deliver consolidated management and backup, without sacrificing performance. But at the same time, says Brian Truskowski, IBM general manager for storage software, "whenever I talk to customers, they report that they're not really getting the maximum benefit" from their SAN.
Helping storage administrators get more from their SANs was the stated intent of IBM Corp. when it announced its Storage Tank product last month, after five years of research and development. When it's released in December, Storage Tank--now sporting the more corporate-sounding moniker SAN File System (SAN FS)--will provide users with features such as a global namespace, storage pooling and policy-based management, file-based snapshot and easier data migration. But while all these features sound great, the real question is: Is enterprise IT ready for SAN FS--and is IBM ready to adapt SAN FS to meet the needs of enterprise IT?
From an architectural standpoint, SAN FS is what is sometimes referred to as a clustered file system, distributed file system, or shared SAN file system. It's much like a dozen or so existing products on the market, including Advanced Digital Information Corp.'s StorNext (formerly CentraVision, or CVFS), EMC's HighRoad, Silicon Graphics Inc.'s CXFS, Sistina's GFS, PolyServe's Matrix Server, Sun Microsystems' QFS, Veritas' Cluster File System and even IBM's own SANergy and GPFS.
The common thread running through SAN FS and many of the other clustered file systems on the market today is the basic architecture: an out-of-band metadata server and distributed lock manager, working in concert with installable file system code that resides on participating client machines. In the case of SAN FS, file requests from an application server travel first to the metadata server, which looks up file locations in its mapping table, issues locks and then sends that information back to the client. Armed with the block location and lock, the application server then retrieves the file from the storage directly over a Fibre Channel (FC) SAN.
This was first published in November 2003