1

What kind of storage configuration would you recommend for a small Exchange server deployment supporting about 50 users? Probably won't grow past 75 users in 3 years. Majority will be "medium" users, with a few "heavy" users and BlackBerry clients.

So far, everything that I've read suggests keeping the Exchange database and the transaction logs on separate physical drives, and keeping both of those off of the system drive. It also says to put the transaction logs on something fast, like a Raid 1+0 array. Considering that all the data needs to be protected, it looks like this would be an optimal setup:

System drive - 2 small drives in RAID 1 Exchange database - 2 big drives in RAID 1 Transaction logs - 4 fast drives in RAID 1+0

However, using 8 drives for a tiny Exchange server seems like incredible overkill. Where would it be safe to cut back?

4 Answers 4

4

Even with heavy users and a lot of headroom you are not going to see much more than 2 IOPS per user and you will probably never even break 1 IOPS per user if it's a small environment like this [See this Technet article. Even taking a fairly conservative number of 80 IOPS per drive (assuming you opt for large 7200rpm SATA drives for the data) and factoring in the double IOPS overhead for write IO, you should still be fine with lumping all the Exchange data and logs onto a two drive RAID1 pack. If you have the option and want to isolate the logs, then by all means go ahead but you are never going to stress a half decent 2-drive RAID-1 set up with the sort of IO that your Exchange environment is going to generate even at 75 users.

3
  • 1
    +1 - I agree. I'd probably put the transaction logs on the RAID-1 set with the operating system, and the database onto another RAID-1 (since the OP mentioned he might want to get down to 4 disks). That'll offer some redundancy in case of losing either spindle (since you'll still have either the database or transaction logs intact). Realistically, you could do it on 2 drives and be just fine, but I'd sleep better w/ the separate spindles for the database and transaction logs, personally. Oct 18, 2009 at 23:59
  • Good point Evan - it's always a good idea to get as much use out of the available redundancy as possible.
    – Helvick
    Oct 19, 2009 at 0:04
  • This is exactly the kind of answer I was looking for. We tend to be more limited by capacity than performance, so I think two RAID 1 sets of SATA drives will be perfect.
    – Nic
    Oct 19, 2009 at 0:39
0

I'd say the first place to cut back would be not using striping for the t-logs. On such a small server you really don't need striping-backed performance there.

You could also consider not putting the logs on a separate storage, but the first thing I'd cut would be the two extra drives for striping and just run two drives in RAID 1 for the t-logs.

1
  • That sounds like a great start. If I wanted to get down to 4 drives, should I put the database or transaction logs on the system drive?
    – Nic
    Oct 18, 2009 at 21:41
0

How much traffic will each user generate? This is quite an important factor to take into account. How much storage per user? How much growth a day?

Whatever you do, don't cut down on RAID. Use at least RAID 1 for each volume. A crashed server because of a single disk failure is definitely something you don't want.

Also, there's a really good reason to physically separate databases from transaction logs: disaster recovery. It's really, really bad to have them on the same volume, because you risk losing both at the same time. If you by chance lose your database, you want to have you transaction logs ready, otherwise the most you can do is restore your last full backup (which may be from some days before the crash).

Summary: RAID 1 for the O.S., RAID 1 for transaction logs, RAID 1, 5 or 10 (depending on your storage needs) for database(s).

2
  • That's a great point about the reasoning for separation of transaction logs and database. Do people normally also back up transaction logs at all?
    – Nic
    Oct 19, 2009 at 0:36
  • That would be pointless, because they're automatically truncated when you do a full database backup. The only time you need them is when you're restoring (but you WILL need them, then).
    – Massimo
    Oct 19, 2009 at 5:55
0

With the small number of users you have, I don't think you should be going too far down the route of optimizing storage. Bottom line is, unless you do something completely daft, the storage subsystem is not going to be a bottleneck. So take some basic common sense recommendations and don't worry overly much about it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .