SAN 101 for the DBA
Two is always better than one, and that's even more true when you're talking about setting up storage for SQL Servers on a SAN.
- By Eric Johnson
- 04/05/2010
You're a DBA and you need storage for your SQL Servers; in many organizations, this means storage area network (SAN) storage. While most organizations will have anywhere from one to possibly teams of SAN administrators, it pays for DBAs to know a little bit about how SANs work. This week, I'll give you a very high level look at SAN configuration. By no means will this be complete, as we are only going to look at concepts so that you, as a DBA, can better understand what you are being given in terms of storage.
At a high level, SANs are really just a bunch of hard drives in an external enclosure that can be accessed by many different servers via the network. In most cases, we're talking here about a fiber network. This is an oversimplification, of course, but as a DBA, this is how you need to think of SANs. I won't get into how servers access the SAN, but believe me when I say it's complicated and I don't want any SAN administrators to feel like I am making light of their jobs.
Disks on the SAN are used to create arrays, just like you would do with internal or external drives attached directly to a server. These can be any type of RAID under the sun; RAID 1, RAID 5, RAID 10, you name it. Once the RAID arrays have been setup, allocations of disk space are created that can be assigned to servers. These allocations of space are known as LUNs (for Logical Unit Numbers). These LUNs are then presented to Windows as a single physical disk. From there, the Windows administrator or DBA can do all the things that the server can do with a real internal physical disk.
When setting up a SQL Server, you will most commonly want to separate your files in some form or fashion. This can be as simple as putting all data files on one drive and all log files on another drive or as complicated as splitting system databases, data files, log files, tempdb, and even index file groups to different drives. Which solution you use will depend on your particular needs.
Why is all this important? I have seen environments where the SAN is one big RAID 5 array and all the LUNs are created from the single array. This means that all the SQL Servers in the company are sharing one big RAID 5. This means there's no separation of files, even across servers. One day, the servers started seeing very slow I/O response from the SAN and one by one, the servers became useless. The solution was to rearchitect the entire SAN and split things out in a more logical way. This meant multiple RAIDs and ensuring that two busy LUNs were not created on the same array.
I am not saying that you need to be a SAN expert, but having even this basic level understanding will help you to ask questions when you request SAN storage. If I/O is of extreme concern and you want to split a database's index files from its data files, it might be a good idea to request two LUNs from two different arrays.
About the Author
Eric Johnson, SQL Server MVP, is the owner of Consortio Services in Colorado Springs providing IT systems management and technology
consulting. He is also the President of the Colorado Springs SQL Server
User Group. He can be contacted at www.consortioservices.com.