We have Exchange 2007 environment with 230 users. The multi-role server is a ProLiant DL 380 G5(Xeon, 10 GB of RAM). 6 disks are RAID 5 configured and split into C and D drives. C holds the OS and D holds the DB and logs for First Storage Group, logs and DB for Second Storage Group, and logs and DB for Journal Storage Group(for journaling). Average Disk que length for D is 15. LCR is configured with iSCSI SAN. The average disk que length for the LCR is 0. I would like to introduce two disks and configure RAID 1 and move logs of FSG and JSG onto it. Do you guys think it would also be better if I move the JSG DB onto a SAN? This would separate the DBs for both JSG and FSG but they share a LUN for the logs. Any input would be greatly appreciated!

You are saying that C: and D: are on the same RAID-5 volume, so the 'performance' of each doesn't really apply. They are just partitions. I would have put the OS on its own set of disks, but since you're probably not interested in tearing it all down, perhaps add the 2 new RAID1 drives for the queue database (you didn't mention this, but if its a HT server, this could be a lot of disk activity) and journaling? For 230 users, unless you're actually having problems I'd probably spend your engineering time elsewhere. :) Mike Crowley | MVP My Blog -- Planet Technologies

So you would not recommend moving the logs(FSG and JSG)onto a RAID 1 partition as well as JSG DB onto a SAN? I've been reading tons of article/forums and none has mentioned move the queue DB onto a RAID 1. I would rather start all over with Exchange 2010 than "tearing it all down". Please see:http://forums.msexchange.org/m_1800464824/mpage_1/key_/tm.htm#1800491798. Thanks!

My point is that C and D are the same anyway. There isn't really a performance difference since they are on the same spindles. Mike Crowley | MVP My Blog -- Planet Technologies

Even if I move the logs(another partition) and DB on SAN? So would just move the que DB? Besides that anything else you would do? From what I understand, Exchange disk sizing should be as follows(say you have 13 hard drives and 2 DBs): 1) Partition 1: 3 disks RAID 5 for OS; 2) Partition 2: 3 disks RAID 5 for DB1; 3) Partition 3: 3 disks RAID 5 for DB2; 4) Partition 4: 2 disks RAID 1 logs of DB1; 5) Partition 5: 2 disks RAID 1 logs for DB2: Therefore, I could place the DB of SG on 1 partition, share the logs on another partition, and place the JSG DB on another(SAN). Thanks again.

All of these partitions are essentially pointless. You do not gain anything (related to performance) by creating artificial drive letters on the same physical RAID set. There is no 'disk sizing guidance' that suggests there is a benefit to isolating data on different partitions. The guidance is all around disk configurations at the physical level. Mike Crowley | MVP My Blog -- Planet Technologies

So you're suggesting different physical RAID controllers for each set of of logical drives? So for a RAID 5(DBs) should be completely different PHYSICAL RAID controller for another RAID 1(logs)? Thanks.

You ideally want to RAID group on the SAN to cross multiple disks across diffrent banks. Then present them to windows. If you can, carve them to each purpose, i.e x GB for DB and xGB for LUN.Sukh

I'm actually testing it on the SAN. Average disk queue length is not even hitting 1, which is really good. The only thing is the whole SAN is at RAID 5. So instead of carving a whole 300 GB for both First Storage Group logs and DB as well as Journal Storage Group logs and DB, I should present a SAN space for JSG(logs AND DB), FSG(logs and DB). So in total I should have 4 SAN attachments; 1 for each? Thanks.

Also, I'm using the NT backup to backup First Storage Group. Do you see any problem if I move the DB and logs of FSG to the SAN? Thanks.

I'm actually testing it on the SAN. Average disk queue length is not even hitting 1, which is really good. The only thing is the whole SAN is at RAID 5. So instead of carving a whole 300 GB for both First Storage Group logs and DB as well as Journal Storage Group logs and DB, I should present a SAN space for JSG(logs AND DB), FSG(logs and DB). So in total I should have 4 SAN attachments; 1 for each? Thanks. Your SAN isn't being used as much or is capable to handle the load. I've seen some just create a RAID5 on the SAN then carve up the LUN as needed. If you're looking for real performance and to get it as close to perfect it's going to take some time and testing and you need to create the right RAID groups at the SAN level and then present to Windows. If you dont want to do that, then I would just create LUN's for each, i.e 1 for DB and 1 for Logs as you mentionedSukh

Sukh828, What about backing(using NT) up FSG once it's on the SAN? Have you seen any issues with this?

I haven't personally seen issues, Windows just sees the drives and will backup.Sukh

So you're suggesting different physical RAID controllers for each set of of logical drives? So for a RAID 5(DBs) should be completely different PHYSICAL RAID controller for another RAID 1(logs)? Thanks. I never said different controllers. Logical drives are a layer above controllers. Mike Crowley | MVP My Blog -- Planet Technologies

Sukh828, Our client so far are responding well and the disks are less than 1 in average disk queue length. How have you designed disks for Exchange with say 10K mailboxes? Thanks.

It's not just the mailboxes numbers, there's a number of things, take a look at thisSukh

Can you give examples of bigger deployments and what factors you use to go with that design?

Once you have an understanding of the mail usuag at each location(s), then you can use that to determince the physical requirements of the disk combmined with the mbx calculator. Validate using the link about and LoadGen.Sukh

Sukh828, After I moved the logs(FSG and JSG) and DBs(JSG and FSG), most users stated that it is faster with the exception of two people. After restarting, it seems to do the trick. One thing I notice is that the average disk queue length for all the SAN attachments were not even hitting 1 which is good. But, the D drive where Exchange is installed, is still hitting the double digits as soon as users started using Outlook. Could the queue DB be contributing to it? The other thing I can think of is the Public Storage Group(logs and DB). We don't have public folders, but Outlook 2003 uses it to mount e-mails. Any thoughts? What else should I look at? Thanks!

If anything as Mike mentioned before move the queue db, the PF shouldn't make much diff if only used for free/busy & OAB. It would be good to get OLK 2010 deployed. Also consider cache mode if not doing so.Sukh

We have few Mac Outlook clients in the network. One client was showing Event ID 1309 every 3 minutes on the server and avg disk queue length for D drive was above 2. Told user to use OWA. Don't see the log anymore and queue is not even 1. Have you every seen this before?

We have few Mac Outlook clients in the network. One client was showing Event ID 1309 every 3 minutes on the server and avg disk queue length for D drive was above 2. Told user to use OWA. Don't see the log anymore and queue is not even 1. Have you every seen this before? No, dont really use Macs, sorry.Sukh