Exchange 2000 Server Sizing: Memory and Disk Subsystems

Let's continue our discussion about server sizing for Exchange 2000 Server from the December 22 edition of Exchange & Outlook UPDATE (See the URL at the end of this column). This week, we look at two key server subsystems: memory and disk.

Exchange 2000 doesn't leverage any of the advanced features for memory usage that are available in Windows 2000 Datacenter. However, Exchange 2000 does make good use of at least a couple of gigabytes on any server. I'm disappointed that Exchange 2000 is (by default) set up to take advantage of less RAM than Exchange 5.5. For some reason (related to the fact that Exchange 2000 supports multiple Extensible Storage Engine—ESE—instances, and memory is at a premium), Exchange developers chose to limit the ESE buffer cache to 900MB. Therefore, for large systems, you must do some tuning for Exchange 2000 to actually use memory available on a server with greater than 2GB (with the /3GB boot.ini switch). Memory-hungry server roles for Exchange 2000 include mailbox servers, public folder servers, and bridgehead servers. As a guideline for mailbox servers, I recommend using 500KB of RAM per mailbox (e.g., a mailbox server with 1000 users would need about 512MB of RAM). Overall, you need to know your server role and a little about your storage design to determine the right amount of memory.

Data storage has changed significantly in Exchange 2000. Storage Groups (SGs) and multiple databases have the greatest effect on the disk subsystem design. However, the disk and memory subsystems have a close relationship, and it's difficult to separate the two when it comes to server sizing. For example, the more RAM available, the more Exchange data the information store (IS) can cache. By adding more RAM, you can reduce the disk I/O requirements (to a point). Two important questions come to mind regarding Exchange 2000 disk sizing for mailbox and public folder servers (for other server roles, storage design is not as crucial or complex).

First, should you add more SGs or more databases? Because Exchange 2000 can support up to 20 databases (four SGs, each with five databases), is it wiser to populate existing SGs with databases before adding more SGs? Most likely, you'll want to populate SGs to the maximum of five databases before adding additional SGs because additional databases have less memory (working set and virtual) overhead than additional SGs. The answer might depend on your administrative designs as well. Either way, you must weigh the administrative advantages of more granular data partitioning against the resource overhead of those additional memory requirements.

The second question relates to the golden rule of storage design: Separate sequential I/O from random I/O. Because each SG has its own set of transaction logs (sequential I/O), and each database file is accessed via random I/O, how strict should you be when applying the rule to Exchange 2000 storage design? Should you define a separate disk array for each SG (for transaction logs) and one for each individual database file? On a server with 20 databases, you'd need to define at least 24 separate arrays (or LUNs). This number might not be practical for some deployments. Again, the choice is a bit of a trade off, and you'll have to make the call yourself (other considerations, such as clustering, might make this a requirement). I recommend you combine all the transaction log volumes on to one array and place the databases on another. If you need to further separate I/O, you can do so as requirements dictate.

Server sizing for Exchange, in my opinion, is more of an art than a science (although, I believe it's art based on science). As you struggle with server sizing for your Exchange 2000 deployments, consider issues such as server role and how you should design each subsystem. Also, don't forget that you should base these design decisions on information obtained through workload characterization that reflects your environment. You should also ask your hardware vendor for help. Hopefully, you chose a vendor who knows something about Exchange.