SQL 2K5 - Need Advice on LUNs

[fuzzyocelot]

Hey everyone!

We've been working with our hardware people in trying to come up with a design for our new SQL 2005 servers. We're currently working on one for production (clustered) and one for disaster recovery (non-clustered). We're hoping to set up mirroring as well. They just asked us if the following design is okay. I need some help here because I haven't a clue about LUNs and SQL Server. The servers will be Windows 2003 Enterprise SP2 64-bit.

Both SQL servers will have 2 instances of 2005 64-bit. They propose the production server to have 4 separate LUNS and corresponding drive letters. One LUN for the databases on Instance#1, one LUN for the logs for Instance#1, one LUN for the databases on Instance#2, and one LUN for the logs for Instance#2.

For the disaster recovery server, they propose having 2 LUNS. One for the databases on Instance#1 and Instance#2, and the other one for the logs for Instance#1 and Instance#2. All the drive letters on the disaster recovery server will match the production server.

Does anyone know if this will work okay? Anything advice is greatly appreciated!

TIA!
Rebecca

 

[fuzzyocelot]

By the way, the total size of the data files for Instance#1 is 70 GB and for Instance#2 it’s 170 GB.

The total size of the log files for Instance#1 is 4 GB and for Instance#2 it’s 17 GB.

Thanks!

 

[fuzzyocelot]

Also, does this tie in with RAID? If so, how? I just read the FAQ on RAID.

 

[ptheriault]

a LUN is how you connect to your SAN. The RAID level is the configuration of you disks on the SAN. Definetly read Denny's FAQ on RAID and which is best for your server.
faq962-5747

I would be less worried about the LUN and more concerned with the RAID level.

- Paul

- If at first you don't succeed, find out if the loser gets anything.

 

[fuzzyocelot]

Thanks! I actually just read up on mydenny's FAQ on RAID.
I found out the server will boot to a local 36 Gig RAID stack. I'll talk to our hardware people and find out what RAID level(s) they're planning on.

 

[fuzzyocelot]

One correction... the DR server will have one LUN.

 

[mrdenny]

When setting up a cluster the instances can not share drives. I would also recommend setting up two additional drives. One for each instances tempdb database.

For the DR system I would recommend setting up the exact same number of drives with the same sizes. This will give you many more options for how to replicate the data.

My moving the tempdb database to a seperate drive you can avoid replicating that database from Prod to DR. As long as you have the folders setup on the DR drive you will be fine.

You've got several options for the actual replication of the data from Prod to DR. Some of them are SQL Server Mirroring, Replication from the Production SAN to the DR SAN, Log Shipping to name a few. I prefer native methods over the third party methods which are available (NeverFail, etc).

With reguard to the LUN configuration what SAN vendor to you use (EMC, HP, 3PAR, etc)? What RAID levels will each LUN be made up of? How many physical spindals will each RAID group be using? What else will be sharing those RAID groups? What sort of IO load will you be putting on the Disks (if you have already existing systems you can use PerfMon to find this out)? If there are already other LUNs in the RAID Group(s) what IO load are they using? What is the IO capacity of the physical spindals and RAID groups?

Your storage guy can answer most of those questions (at least he better be able to).

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[fuzzyocelot]

Thank you for the post, mydenny! I'm pretty sure we use HP as our SAN vendor. I'll try to figure out what sort of IO load we'll be putting on the disks as we have existing systems (SQL 2000).

I'll track down our storage guy and see if I can get him to answer those other questions.

Thanks again!

 

[mrdenny]

No problem.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[fuzzyocelot]

Sorry it took so long to get back. We've been having some SQL Server performance issues that's taken over as a main priority right now. That and one of our most important SQL servers (for the fire department) crashed this morning and they were in the middle of payroll! Not to mention I'm the only DBA here today! Yikes! But that's another thread.

Anyway, I was talking to one of our hardware/network guys the other day about the storage situation and he brought up something interesting in regards to SQL replication. There's something called Continuous Access which replicates on a LUN level. He asked me if we want to go this route since they figured out how to get it working. I haven't a clue! lol Do you have any advice or know anything about this CA stuff? We were going to go with SQL 2005 mirroring but now we're looking into this CA thing. Any advice?

Thanks!

 

[mrdenny]

It depends on the change rate of the database. If you have a slowly changing database then that will probably be fine. If you have a fast changing database I'd stick to database mirroring.

When the SAN replicates the data using the CA what block size is it using?

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com