Number of hard drives for Exchange 2

[nogarap]

We've had an exchange problem here, in that my D:\ drive, where I keep the Exchange databases is running out of disk space. It filled completely yesterday, and I've got it going agin by keeping transaction logs on a USB hard drive hanging out of the back of the Exchange box, which is a terrifying arrangement, and it frightens the life out of me.
I've got another server which I think will probably become a new Exchange server. It can only hold 4 hard drives, so I'd be looking at RAID5, with all the partitions on these 4 drives. I know it's not ideal, and I'd really prefer to have 6 drives (mirrored C: drive, RAID5 D: drive), but I don't think they'll buy me a new server, so this is what I've got.
Has anyone got any experience of running this type of setup? Was performance acceptable, or should I avoid this? I've got a private information store of 200GB, and public information store of 2GB.
Many thanks in advance,
Gaz

 

[58sniper]

That's a pretty big mail store for a single RAID 5 volume. Ideally, you'd split that into smaller stores, with those being on separate arrays than the transaction logs.

If they won't buy you another server, will they buy you an external shelf with drives in it?

Pat Richard MVP

 

[zbnet]

So you've got a priv of 200GB, on a server that's full; and another server that isn't beefy enough to be an enterprise exchange sever. I think you've got a perfectly legitimate case to go back to management and ask them just how inmportant their email service is to them. If it's important, they need to spend money on it; if not, they can let it fail.

[There's a potential side issue - how did the current server fill up? You don't say - were you capacity planning it and informing management as it progressily filled up? If so - and they didn't listen - the failure is theirs, not yours. If you missed it, then update your resume, and learn from this experience.]

PS large stores work better on Raid 0+1, rather than Raid 5. If you're getting a shiny new external drive cage as per Pat's suggestion above, get enough spindles to do Raid 0+1

 

[nogarap]

Thank you Pat and zbnet for the speedy replies.
Agreed, it wasn't one of my exchange career highlights! Probably the 2nd most embarrassing moment. Management isn't great in developing policies on leavers etc, so we have lots of mailboxes of ex-staff that managers won't let me delete, but ultimately, it's my server, so if it fouls up, it's probably my fault.
Management have signed off on 4 x 146GB hard drives, so I'll have approx 400GB for storage on the new server. That's all the money there is for now. My plan is create at least 2 sttorage groups (directors want a very long deleted items retention period for themselves), and have the databases and logs on different partitions.
I'm going to build the new server as a new Exchange server, move the mailboxes to it, then remove the original server. They've agreed to let me redeploy the old server as an archive/PST server, and I can archive old mailboxes of leavers on to there, achieving management's goal of the old data being available online.
If I do this OK, and keep mail stable, there's a chance they'll buy me an external array next time round.
I'm hoping the drives arrive on monday, I'm actually really looking forward to doing it.
Thanks again for the advice, have a great weekend.
BTW, worst moment was, as a newly passed paper MCSE, my ISP called me up to tell me my 5.5 server was being used as a relay server by spammers! Very embarrassing!

 

[58sniper]

I'd archive those "leavers" to .pst so that you have them, but it would allow you to yank them out of the store. I'd do that BEFORE moving to another server.

400GB isn't enough space for a 200GB store, IMNSHO (and I still think 200GB in a single store is a bad idea). You won't have enough space for maintenance, should you need it. By the sounds of it, you won't have separate volumes for the logs, which is highly recommended, both from a disaster recovery standpoint, and from a performance standpoint.

Pat Richard MVP

 

[nogarap]

Yes, very good point to archive the leavers from the old server and not the new one. Event viewer tells me I've got 20GB white space in the existing database already, and I reckon I've got about 50GB of leavers mailboxes in the store. If I archive them, and then move the live mailboxes, I think the store will come down to 120-130GB, which I'll split into 2 storage groups (purely for admin purposes). The storage groups will split into maybe 90GB + 40GB. I might still be ok for space to run maintenance utilities as/when I need to.
Performance won't be wonderful, but at least it should be fwirly stable (I hope). Thanks again.
Gaz

 

[58sniper]

The file sizes won't decrease by themselves. You'll just have more whitespace in the database. That will go away when you move them to the new server.

Using more than one storage group is certainly the way to go.

Pat Richard MVP

 

[xmsre]

RAID 5, with a write penalty of 4, is an extremely poor choice for Exchange 2003. Exchange 2003 without cached clients has a read/write ratio of about 3:1. With cached clients, the read/write ratio is about 2:1. The rule of thumb is: if the write penaty is higher than the read/write ratio, the RAID type is a poor fit for your application. RAID 1/10 with a write penalty of 2 is a much better fit than RAID 5 for an allication with a 3:1 or 2:1 read/write ratio.

I'd look at a mirror for the os, a mirror for the logs, and RAID 10 for the databases. This will mean more spindles than you have and an external enclosure. Don't think you'll do better with RAID 5 though. Due to the write penalty, in order to reach the same performance level you'll need twice as many spindles.

 

[58sniper]

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

That's my new motto.

Pat Richard MVP

 

[xmsre]

The rule of thimb is: If the write penalty of your chosen RAID type is higher than the read/write ratio of your application, then the RAID type is not appropriate.

RAID 5 has a write penalty of 4. Back in Exchange 5.5, when you had 5:1 or 6:1 read/write ratios with Outlook 98, RAID 5 was acceptable. In Exchange 2000, the read/write ratio decreased to 3:1 or thereabouts and RAID 5 was questionable. Some of the high end storage systems that cached the writes and reordered them, along with big cache on the storage controller could conceivably get to to 3:1 as long as you wre sticking to a small dataset, say a single 16GB database. In Exchange 2003, IO efficiency improved again, databases got larger, and you started seeing wide use of cached clients further lowering the read/write ratio. In Exchange 2007, it's not uncommon to see 1:1. RAID 5 just doesn't cut it any more. We're pushing the limits of RAID 10 (with it's write penalty of 2) in many Exchange 2007 deployments much like we pushed the limits of RAID 5 in the early days of Exchange 2000.

In the last 20 years, disk capacity has increased by several orders of magnitude. Rotational speed and random access times haven't improved anywhere near as much. My first hard drive, a whopping 10MB with 80ms access times was state of the art in 1985. Today, enterprise class SCSI drives hold 300GB or so and have 5ms random access times. Disks are getting bigger at a far higher rate than they are getting faster.

<sidebar>

What about that announcement by vendor X that they support SSDs in their systems? The current generation of flash SSDs has excellent random read performance. Sequential write performance is very good too. The problem with SSDs is the time it takes to set up to do a write, and the weakness is random writes. Random write performance of SSDs is actually worse than the current generation of enterprise class SCSI drives. They'd be great if your application was querying a data warehouse all day long, but for Exchange it's still the write performance that'll get you in the end.

http://mtron.easyco.com/news/papers/easyco-flashperformance-art.pdf

http://www.tomshardware.com/reviews/enterprise-flash-ssd,1971-10.html

</sidebar>

Spindle count for Exchange is primarily driven by the performance requirement. Determine the number of spindles using the performance requirement, then choose the size based on space requirement.

 

[wahnula]

Thanks xmsre for the explanation of different arrays and their "RAID penalty". Much appreciated here, a star for your efforts.

Tony

Users helping Users...