-
SAN configuration question
I am in the process of configuring a new SAN for a SQL Server. I am going to use RAID 10 for all raid groups. I have enough drives to do the following:
Tempdb – 4 drive Raid 10
Logs – 4 drive Raid 10
Data – 12 drive Raid 10 (will contain the following files:
primary data file – 46% of all of the IO on server
secondary file that contains all of the indexes – 33% of all of the IO on server)I can create a Raid Group (raid 10) with 12 disks that has just one LUN on it. This would contain the data file and the index file. Advantage – many spindles handling the IO of two heavily used SQL files. Disadvantage – Data file (46% of total IO) on server and Index file (33% of total IO) on server will be competing for the same resources.
My other choice is to use 8 disks for one Raid Group (raid 10) that has one LUN on it. The data file would go here. The other 4 disks would be another Raid Group (raid 10) that has one LUN on it that contains the Index file. Advantage – The IO for two heavy utilized SQL files would separate. Disadvantage – Less spindles dedicated to each Raid Group.
Should I choose option 1 or option 2?
I appreciate your input.
-
2 Replies
-
When you say “SQL Server”, I’m assuming you mean Microsoft SQL Server. Have you reviewed Microsoft’s best practices and other guidance documents? Those type of things will often cover what is supported or generally recommended.
Some questions:
– What kind of array do you have?
– How is the server connected to the array?
– You listed 20 disks above. Is that what you have to work with or just an example?
– Do you know the transaction load you need to handle?
– Are you doing any array based replication?For a situation with a small number of disks and no array replication, I’d opt to put a RAID10 across all of the disks to allow sharing of all of the IO across all functions and then cut that up with an LVM and put different file systems on each logical volume to minimize impact of file system corruption and otherwise help keep the file systems sane/healthy.
The ultimate best it to break everything into their own RAID groups such that under max load none of them ever have IO problems and contention isn’t an issue. Of course this means lots of disks which may not be cost effective.
-
You should do a lot of small IO lantecy testing to configure the index file array. That’s a huge point of contention for heavily used databases. We helped GTE with their clone detection stuff many years ago and it was always the index files causing trouble. (especially when you inadvertently put them on your boot drive in your home directory)
Reply to this Discussion! Login or Sign Up