More questions and answers from SAN School lesson #1

By SearchStorage.com editors 13 Jan 2004 | SearchStorage.com

Digg This!     StumbleUpon     Del.icio.us

SAN School: Lesson 1

In the first chapter of SAN School, Chris Poelker explained who would benefit from implementing a SAN and why. You learned the details about how a SAN works to pool data together, store it in one centralized location and push block-based data across the network. Chapter one also gave you a foundation to start planning for your new network and realize the SAN vision: To use multiple applications and systems in one network with many different data centers managed in one place, so your operation can be global in scope, which isn't possible with DAS.

Since so many of you asked Chris Poelker questions during the SAN school Webcast, he didn't have time to answer them all. Therefore, we sent those questions to Professor Poelker and are posting them along with the answers for you here.

Here you'll find answers to questions pertaining to:

Chapter 1

Question: What is the difference between block-based data and file-based data?

Professor Poelker: When people in the industry make reference to "block based data", what we are really talking about is the access mechanisms used by those applications that get access to their "data" using the SCSI (small computer system interface)protocol, which is a protocol used by operating systems (your computer)to "talk" to disk drives (where the data is stored). The SCSI protocol transmits data in "blocks", rather than something like the IP protocol, which transmits data in "packets." So block based data is the data stored on disk drives, in its native format.

File based data is also stored on disk drives, but access to "file based data" is normally done over an Ethernet network, rather than a storage network. The term NAS, or network attached storage, uses NFS of CIFS (file access protocols) over the TCP/IP protocol (underlying network transmission protocol)to "talk" to individual "files" stored on disk drives. So file based data are the actual individual files (like a word document, or a home directory) stored on the drives.

There is much more overhead associated with access to individual files, rather than raw block transfer of data to disks. This is why high performance databases almost always access data using "block" access, rather than "file" access. You can simplify this by always associating "file" access with NAS devices, and "block" access with SAN devices.

Question: When deciding whether or not a SAN makes sense, is there a threshold size of storage needed before a SAN makes economic sense (over 100 GB, 1TB, etc.)? Or, do the other factors totally outweigh that question?

Professor Poelker: There is no set rule... all the factors need to be combined to see if it makes sense from a financial perspective. If all the benefits of what SAN has to offer outweigh the initial capital outlay, and it will pay for itself in a reasonable period of time, then go for it. The larger the organization, the larger the benefits will usually be. If you're a small shop and have just a few servers to manage, and backup is not a problem, then you probably do not need a SAN.

If you find backup is becoming a burden, or you need to share disks because you are implementing server clustering, or it's a nightmare to manage the data on all your internal storage, then a SAN would make sense.

Question: Why not use a shared file system in a SAN versus NAS for servers that need file sharing?

Professor Poelker: Actually, that's where the industry is heading. A GFS (Global File System) is currently under development by Microsoft for the Windows platform (via Longhorn). There are already multiple solutions on the market from other OS vendors (Sun's SAMfs, IBM's, storage tank), and a few for Linux. You can buy these solutions today, but they are proprietary. When all the OS vendors finally get together and agree on a standard for storage based Global file systems, it will become more prevalent and much cheaper.

View this lesson at anytime here

About Christopher Poelker:

Aside from being an author and a SearchStorage.com SAN expert Christopher Poelker is a storage architect at Hitachi Data Systems. Prior to Hitachi, Chris was a lead storage architect/senior systems architect for Compaq Computer, Inc., in New York. While at Compaq, Chris built the sales/service engagement model for Compaq StorageWorks, and trained most of the company's VAR's, Channel's and Compaq ES/PS contacts on StorageWorks. Chris' certifications include: MCSE, MCT (Microsoft Trainer), MASE (Compaq Master ASE Storage Architect), and A+ certified (PC Technician).

Digg This!     StumbleUpon     Del.icio.us