advice on drive setup for SB SQL app

[ThePiston]

need advice how setting up drives for this new SB server:

We run a small business app and connect to server using remote desktop. We also use our server for basic file serving for about 10 active clients at a time. light loads.

What's the best setup for this? Currently I have one OS drive (non-raided) and one SQL/data drive (mirror raid).

That sound good? I'd like to raid 10 the SQL/data drive as well as the OS but that's way too many drives.

Would it make any sense to just use one set of drives and raid 10 all of it on one drive (and maybe 2-3 partitions?)

 

[Cerb]

To help, we would need far more information of what kind of application it is, and what kind of I/O load it presents. How big is the DB? Does it do a lot of writing? How much RAM do you have? How many concurrent users will it serve? What do you have in terms of a DBA (luckily, SQL Server has easy to use management tools, so a good sysadmin could easily learn to optimize anything really nasty)?

P.S. Why does this thread even exist? I just found the other one. Yet, this one is newer. WTF?

 

[ThePiston]

this thread is asking about drive setup including the OS. the other thread is just asking if I should use SSD vs spinning drives

 

[imackin]

What are the performance requirements? IOP/s, DB size, rear/write %, etc...

real quick suggestions though.
-mirror the boot drive
-have the pagefile on a different partition unless worried about BSOD's
-keep heavy writes off of SSD - "heavy transactional log drive"
-separate raid sets for DB and log drives
-64k block size for NTFS, MS SQL seems to like this.

 

[ThePiston]

not sure about IOP/s or read/writes, DB is 2.6GB

 

[Emulex]

1. RAID-10 only
2. Use a decent raid card - or not! read more.
3. Each LUN/Adapter in virtualization will get divided up better.
4. Microsoft apps use a ton of TEMPDB - cpu's to tempdb is not a bad idea.
5. The more ram SQL server has (8gb rdimm ECC $50) the less it writes to the main database but tempdb and LOG are mission critical.

so what I do:

1. M5014/M5015 IBM (9260-8i) with fastpath or LSI 9271-4i/8i without fastpath.
2. RAID-10 for OS
3. RAID-10 for TEMPDB
4. RAID-10 for log ** can be separate 2 drives **

When i say that I'm saying divvy up the raidset of disks into multiple raids.

drives 1-8 are samsung 840 pro:
lun 0 - raid-10 for o/s C: 100gb
lun 1 - raid-10 for database 400gb
lun 2 - raid-10 tempdb - 50gb
lun 3 - raid-10 tempdb2 - 50gb
lun 4 - raid-10 for log 100gb
[adjust for your needs]


or

drives 1-6 are samsung 840 pro, drives 7-8 are samsung 840 pro

lun0 raid-10 drives 1-6 - os
lun1 - raid-10 drives 1-6 - database
lun2 -raid-10 drives 1-6 tempdb
lun3 - raid-10 drives 7-8 tempdb
lun 4 - raid-10 drives 7-8 log

or two M5014 and split the pci-expres bus since 6 drives will outpower the pci-e 2.0 bus and low end cheap m5014's.

The samsung 830's are solid. the 840 pro's i've had one hiccup. You must arctic silver these cards and keep the extremely cool. or they will reset and throttle themselves.

64KB STRIPE
NORA (no read ahead)
WT (write through)
DRIVE CACHE ENABLED
basically bypass the battery/cache/etc.

SOLID.

Building a server now DL380 G7 with 16 SFF and two raid controllers with 512GB 840 pro's.

The 9260 with fastpath is equal to the 9265 without fastpath, but the 9265/9266/9271 run much hotter which is a serious concern for many people.

M5014 - $60-130 used in great shape (no battery needed for ssd)
M5015 - just wider 64bit cache but we're turning this off and used batteries=bad mojo.
Fastpath - trades latency for high queue depth.
This is LSI's magic.

Adaptec/HP's PMC based chips do not perform as well as LSI w/fastpath.

 

[ThePiston]

holy sh*tballs man, I think that might be overkill for my project, but I appreciate the passion

 

[Cerb]

holy sh*tballs man, I think that might be overkill for my project, but I appreciate the passion

Well, this thread was made lacking the meaty info for that, but yeah, just a wee bit overkill.

However, lots of RAM and a LSI-based controller card are hard to go wrong with.