Log in
::
Register
::
Not logged in
Search:
Home
Articles
Editorials
Forums
Scripts
Blogs
QotD
Books
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Advertise
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2005
»
Administering
»
Why separate data, log and backups on SAN?
13 posts, Page 1 of 2
1
2
»»
Why separate data, log and backups on SAN?
Rate Topic
Display Mode
Topic Options
Author
Message
Rob Symonds
Rob Symonds
Posted Friday, November 21, 2008 8:01 AM
Old Hand
Group: General Forum Members
Last Login: Thursday, July 02, 2009 7:27 AM
Points: 353,
Visits: 420
Best practice is to split up data, log and backup files to different disks. This makes sense when you are using internal storage. This configuration gives you separate disk controllers and separate spindles for each which results in significantly reducing IO contention due to different workload characteristics.
It seems like things aren't so clear when you are using a SAN and your storage administrator is simply carving LUNs out of a large disk group. Chances are high that the SAN disks on your server are operating across the same physical sets of spindles. I imagine this is even more the case when your SAN is using something like virtual disk/vRaid technology.
I still break data, log and backup files onto separate disks. But I'm wondering at this point what that is actually getting me? It seems like the benefit on the physical IO side is somewhat reduced when using a SAN. What are the benefits on the SQL or OS side of keeping these on separate logical disks?
Post #606537
lrhyrne
lrhyrne
Posted Friday, November 21, 2008 8:24 AM
Grasshopper
Group: General Forum Members
Last Login: Monday, June 29, 2009 1:43 PM
Points: 14,
Visits: 26
It seems like things aren't so clear when you are using a SAN and your storage administrator is simply carving LUNs out of a large disk group. Chances are high that the SAN disks on your server are operating across the same physical sets of spindles. I imagine this is even more the case when your SAN is using something like virtual disk/vRaid technology.
I would think if you are putting your files on a SAN it should not matter how it is managed. The SAN should intelligently migrate your files based on their usage stats...depending on what type you are using.
This question could always be better resolved by testing a SAN forcing your files onto separate physical disks / disk arrays versus just letting it manage where your files land on a LUN. Anyone got a SAN sandbox?
Post #606564
loach
loach
Posted Friday, November 21, 2008 8:28 AM
SSC Journeyman
Group: General Forum Members
Last Login: Wednesday, July 01, 2009 9:55 AM
Points: 96,
Visits: 68
For critical production systems, I insist that the SAN administrator create dedicated RAID groups / LUNs for each of the purposes you describe (except maybe backups...). Not only does it make I/O performance issues easier to diagnose if the RAID groups aren't shared, but you then don't have the issue of potentially losing multiple volumes in the event that you lose more than one disk in a RAID group.
Maybe I'm just an old stick-in-the-mud, treating a SAN in much the same way I would local disk. I don't trust virtualization of production systems either for much the same reason.
Post #606569
Michael Earl
Michael Earl
Posted Friday, November 21, 2008 8:28 AM
SSCrazy
Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 2,731,
Visits: 22,032
You are correct in that you lose the benefit if the SAN admin is carving three partitions out of a LUN that is using the same physical drive array.
Of course, your initial assumption "should" be wrong. Your admin should be carving these out of individual physical disk arrays. They often really need different RAID configurations. Log files have lots of sequential writes, data files have lots of reads and non-sequential writes, and backups - well it is often best to put those on cheaper, slower drives so you can afford to retain a few days or weeks of them without breaking the bank.
The best place for information on how the SAN should be configured is your SAN vendor. MSSQL configurations are extremely common these days. They should have done enough of these to know what configurations will suit your needs - assuming you give them enough information. Every SAN solution seems to be a bit different, so talk to your vendor.
Post #606570
homebrew01
homebrew01
Posted Friday, November 21, 2008 9:58 AM
Ten Centuries
Group: General Forum Members
Last Login: Thursday, July 02, 2009 2:42 PM
Points: 1,260,
Visits: 1,872
Michael Earl (11/21/2008)
You are correct in that you lose the benefit if the SAN admin is carving three partitions out of a LUN that is using the same physical drive array.
Of course, your initial assumption "should" be wrong. Your admin should be carving these out of individual physical disk arrays. They often really need different RAID configurations. Log files have lots of sequential writes, data files have lots of reads and non-sequential writes, and backups - well it is often best to put those on cheaper, slower drives so you can afford to retain a few days or weeks of them without breaking the bank.
The best place for information on how the SAN should be configured is your SAN vendor. MSSQL configurations are extremely common these days. They should have done enough of these to know what configurations will suit your needs - assuming you give them enough information. Every SAN solution seems to be a bit different, so talk to your vendor.
I agree. That's how we did it at my last place, and will be doing here in a few months with our new data center. For instance, with 20 drives in the array, drives 1-4 can be drive E for logs, drives 5-8 can be drive F for data, drives 9-12 can be drive G for indexes, drive 13 & 14 can be drive H for backups etc .....
Post #606655
Perry Whittle
Perry Whittle
Posted Sunday, November 23, 2008 3:17 AM
Ten Centuries
Group: General Forum Members
Last Login: Today @ 10:35 AM
Points: 1,058,
Visits: 3,505
Michael Earl (11/21/2008)
Your admin should be carving these out of individual physical disk arrays. They often really need different RAID configurations.
couldnt agree more, does your SAN admin understand the RAID config required for SQL server
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs"
Post #607159
Rob Symonds
Rob Symonds
Posted Sunday, November 23, 2008 7:42 AM
Old Hand
Group: General Forum Members
Last Login: Thursday, July 02, 2009 7:27 AM
Points: 353,
Visits: 420
Yes and no
I've seen this happen in a few different places. Generally, the storage admins I've worked with have been top notch. They understand best practice for SQL when you are talking about normal RAID arrays. The issue starts to get more complicated when you factor in new storage technologies and the best way to share storage across the IT though.
As I mentioned, with things like virtual disk/vRaid technologies, this best practice is no longer so clear cut. While the vendor may recommend this or that strategy it has to be balanced against the fact that other servers in IT such as Exchange, ESX, clusters, DB's are going to share that storage. Throw in tight budgets and concerns about overall best use of capacity and you have an array of different competing factors that must be worked out.
Post #607192
GilaMonster
GilaMonster
Posted Sunday, November 23, 2008 9:46 AM
SSChampion
Group: General Forum Members
Last Login: Today @ 1:26 PM
Points: 12,626,
Visits: 8,658
Bear in mind that a san doesn't automatically make things fast. To quote a friend, 'There's no magic san dust'
Even with a san (or especially with a san) you need to follow IO best practices. Appropriate raid levels, dedicated disk arrays, aligned partitions, etc.
The MS best practice for sans is to never share disks between disparate workloads. ie, don't slice a LUN and give it to the data files and slice another from the same disks and give it to the log files
Gail Shaw
We walk in the dark places no others will enter
We stand on the bridge and none may pass
Post #607206
TheSQLGuru
TheSQLGuru
Posted Monday, November 24, 2008 8:36 AM
Ten Centuries
Group: General Forum Members
Last Login: Thursday, July 02, 2009 3:06 PM
Points: 1,173,
Visits: 1,625
Even if you don't, as others recommend, have 'control' or even input as to the configuration of the SAN for your SQL Server storage needs, you probably still should create separate drives on the various LUNs you are provisioned. There is the possiblity that those LUNS ARE on separate disks, controllers, switches, etc which will provide benefits and reduce possible performance choke points. If none of the above is true, at least it shouldn't cause things to be markedly worse. :)
Best,
TheSQLGuru
SQL Server MVP
Post #607600
GSquared
GSquared
Posted Monday, November 24, 2008 9:06 AM
SSCertifiable
Group: General Forum Members
Last Login: Wednesday, July 01, 2009 12:21 PM
Points: 6,281,
Visits: 3,254
Gotta agree with just about everyone here. Treat the physical disks in the SAN the same as you would internal disks, when it comes to SQL performance and disaster prevention. The only SQL thing I'd put on a SAN that wasn't handled that way, would be backup files.
- GSquared
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #607638
« Prev Topic
|
Next Topic »
13 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
may
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2009 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use