In the server world we have three different kinds of storage available. Today, only two of these can be used with your SQL Server (as long as you want to keep the SQL Server in a supportable configuration). Your three options are Direct Attached Storage (DAS), Network Attached Storage (NAS) and Storage Area Network (SAN).
Network Attached Storage is the configuration that you shouldn’t be using with your SQL Server. NAS can be used with SQL Server if you drop in a trace flag and run your server in an unsupported configuration. However if there is a problem with the SQL Server Microsoft PSS (CSS, whatever they are called this month) may not be willing to help you as officially SQL Server does not support Network Attached Storage. NAS devices are specialized devices, typically running some flavor of Linux which present network shares which Windows can recognize to the network so that people or services can access the storage over the network. NAS devices can also be running Windows sort of like a traditional file server where you can access the files over the IP network.
Direct Attached Storage also called JBOD (Just a Bunch Of Disks) or local storage is storage which is directly attached to the back of the server. There will probably be a couple of disks which sit within the server, and when these are outgrown you’ll get an external shelf of storage which has more disks in it. These will be connected via SCSI, SAS or fibre channel cable to a card within the server. For SAS or fibre channel DAS units the controller which does the RAID will probably be within the shelf which holds the disks. For older SCSI units the card which handles the RAID will probably be within the server (there are SCSI shelves which have the controller within the shelf). Direct Attached Storage is usually faster than SAN storage as the disks within the DAS units are dedicated to the servers. What you gain in speed you loose in flexibility, and manageability.
Storage Area Network storage (SAN) is very flexible storage which has a big management overhead. But that management overhead gives you lots of options, and makes it very easy to reconfigure the storage on the fly without any changes to the servers. You can easily extend the storage, reduce the storage (if you have Windows 2008 and a storage array which supports making the volumes smaller), move the volume to faster storage, or slower storage all with no outage to the server. You don’t even need to tell the server. Because there is a lot of management involved with storage arrays (the device which actually holds the disks, also called arrays among other things) correctly configuring storage arrays for maximum performance is quite difficult and usually isn’t done to maximize the performance of the array. Storage arrays don’t ship in the best possible config, then need to be tweaked and tuned to fit the workload that your specific environment will be putting on them. All to often people that are managing the storage array don’t understand what all the nobs within the array management software do, so they don’t touch them (which is probably good) or the tweak them incorrectly (which is very, very bad).
I’ve talked to people that have deployed storage array’s from EMC that have gotten less than 1/2 the performance than I’ve been able to get from similar storage arrays. What makes me think that this is a storage array configuration problem is that they were using high end 15k RPM disks, while I was using 10k RPM disks. Obviously the workloads were different, but their workload was better suited to high speed storage than mine was. They were doing sequential reads (where the blocks which are being read and right next to each other on the spindles) on a RAID 10 array while I was doing VERY random reads and writes (where the block which are being read and written are all over the array) against a RAID 5 array.
Hopefully this helps shed the light on some of the terms which you may hear flying around your office.
Denny
