Information Store, LUN, and LCR recommendations for new SAN? 1

[cajuntank]

I have a single HP Proliant DL380 server as my Exchange box serving about 550 users. I only have internal hard drives designed out as RAID1 for OS, RAID1 for logs, and RAID 1+0 for information store. I have not implemented LCR as of yet since I was waiting on my new budget year to get my new HP MSA2000 iSCSI SAN. I'm looking for a few recommendations on how I should RAID my SAN (having several arrays, or one big RAID 1+0, etc...), if I should move my information store off to the SAN to take advantage of snapshots, or just point my LCR to the SAN and leave information store where it is, etc... Thoughts?

FYI. I also plan on having a storage server connecting via iSCSI for disk to disk backups and have a tape library hanging off of it for media I can take off-site.

 

[58sniper]

How to develop the storage solution depends on many things. The first is how big do you want the stores to be. Generally, you want them to be under 100GB if possible. This allows for better manageability, including restores, defrags, etc.

You also want your LCR on a separate LUN(s), since you're trying to guard against failure. If the primary store and the LCR store are on the same LUN, and the LUN fails, LCR hasn't done you any good.

I try to design the storage using best practices, and then double it for LCR. This means separate LUNs for logs and databases.

You also want to look at drive speed and RAID level. For TLs, the faster the drives, the better. RAID 1 works great. For DBs, you need to have capacity, and this is where RAID 1+0 comes in.

For a best practices approach to storage design, I would recommend using the product group's storage calculator. It will break everything down for you.

Exchange 2007 Mailbox Server Role Storage Requirements Calculator

http://msexchangeteam.com/archive/2007/01/15/432207.aspx

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[cajuntank]

I have my stores (3 total) currently set to max at about 50GB with the amount of users, the division of those users into specific stores, and mailbox limits applied to those stores. I understand about the separate LUN(s) in regards to TL and DB and I'm using SAS 10K drives across the board. Will have SAS 10K or 15K on the SAN as well.

Would you keep the stores locally on the server (DAS) or would you move them off to the SAN?

I don't know if I gain anything moving them to the SAN since I could direct LCR to the SAN and do my backups/snapshots of the LCR data instead of the live data.

 

[58sniper]

I'm a fan of DAS, myself. But it would be hard to keep both the stores and the LCR copies, along with the logs, all on DAS without using external shelves. Putting the LCR on to the SAN makes sense. You'd actually likely go to the LCR copy of the data before a snapshot, I would think.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[Zelandakh]

I'd go the other way round and move the DB and TLs to the SAN to take advantage of the snap (gives you DR assuming the mirror is off site as it should be). LCR to local for speed of restore which then doesn't need to snap and as Pat says it is the most likely need.

15k will give you a good head start on speed.

 

[xmsre]

I have an old MSA1000 that heats the space under the stairs. It has a single controller and an 8 port switch. I have old DLT hanging off it (off a SCSI bridge off the switch actually). It's not quite the level of hardware you're at, but the same functionality is there.

1. It doesn't matter if you put your stores locally or on the SAN for snapshots. If they're local, you leverage the MS software VSS provider; if they're on the MSA you leverage HP's VSS provider. Both VSS providers are copy on write and have the same performance issues. Every time data in a snapshot changes, a copy on write provider reads the old block, writes it to a diffeence area, then writes the new block. That's 3 IOs for every overwrite while a snapshot is in place.

2. Start with the MS Exchange 2007 Mailbox Role SIzing Calculator. It'll give you the recommended storage group layout, so you'll know how many LUNs to use and what level of performance you need (how many spindles).

3. Do choose the dedicated recovery LUN option. If you don't, each database LUN gets sized 2.1 times the size of the store. If you do, they get sized 1.1 times the size of the store with one additional recovery LUN sized to hold the database and logs for an RSG.

4. iSCSI works fine for Exchange 2003/2007. The IO size is small enough that you'll never come close to saturating 1Ge.

5. If you have enough spindles, you might as well keep the primary databases and logs on the MSA and put the LCR copies local. Why? The Exchange 2007 VSS Writer does not support LCR or SCR targets; you can't backup the targets with VSS. You can take a VSS backup of the source, and you want to eventually stream that to tape. The tape is attached to the MSA. Assuming there's more spindles on the MSA, your performance is greater and you avoid transferring the backup over the network again after you already did the LCR replication. In the event of failure of the MSA, you have the LCR copies local (presumably at degraded performance because you have feewer spindles).

John

 

[cajuntank]

Appreciate all the input. Got a lot to think about.

 

[cajuntank]

John, just as a point of interest on your #5, a VSS backup can be done on the LCR target. The documentation I've read doesn't state specifically whose VSS, but it does make the statement about running it against the LCR as long as the LCR are is on different spindles from the production database so as to not noticeably affect I/O.

 

[xmsre]

You can't backup an SCR target with VSS period. The Exchange 2007 VSS Writer CAN backup the passive copy of CCR or an LCR target, but it cannot RESTORE to a passive copy of the database. In CCR, in order to restore a backup taken from the passive copy, you have to fail over first (so the passive becomes active). In LCR, you have to activate the target, then restore.

I over summarized when I included LCR tagets. You can backup an LCR target with VSS, but the restore path makes that backup useless for all practical purposes. If you backup the active copy, you can restore to the active copy at any time or to the passive copy after you activate it.


John