Exchange Storage Ins and Outs

If you want to start an argument with a Microsoft Exchange Server administrator, try giving unsolicited advice about storage design and configuration. Exchange 2000 Server and Exchange Server 2003 offer so many storage options that determining an optimal configuration is often difficult. In addition, some common and enduring Exchange misconceptions further complicate the decision-making process. In this article, I discuss some lesser-known Exchange storage design principles that will help you clarify what works so you can make the best design decisions for your environment.

Storage Partitioning
Exchange Server 5.5 uses a monolithic database design, with a maximum of three databases on each server: a mailbox database, a public folder database, and a directory database. This design allows some truly scary configurations; for example, I once had a customer with an average Exchange 5.5 mailbox database size of 140GB.

Exchange 2000 introduced the concept of multiple storage groups (SGs), each of which can contain multiple databases; Exchange 2003 uses the same mechanism. The SG (a logical object that doesn't exist on the hard disk) is an instance of the Exchange Information Store (IS) that runs within the store.exe process and owns the transaction logs for all the mailbox and public folder databases in the group. Each database is a separate logical object with a pair of physical disk files (the .edb and .stm files). Many customers who upgrade from Exchange 5.5 to Exchange 2000 or Exchange 2003 accept the default migration settings. This practice isn't advisable because you get Exchange 5.5's huge single database rather than having the benefit of multiple databases.

You can back up or restore only one database at a time per SG. If you have multiple SGs, you can back up or restore multiple databases simultaneously. Suppose you have a 140GB database that's divided into four SGs, each with a 35GB database. Backing up this divided database takes the same total amount of time as backing up one 140GB database; however, the individual backups take about a quarter of the time. If you back up to tape, you can add a second tape drive to back up two databases in parallel and cut the backup time in half. But the biggest performance gain occurs if you restore multiple databases in parallel. If you've backed up multiple SGs, you can restore one database from each SG at the same time and significantly reduce the overall restore time.

Another good reason to partition your storage is that doing so can help you abide by your service level agreements (SLAs). Suppose you have an SLA that requires you to restore executives' access to email within an hour of an outage but gives you a five-hour window for other employees. If you put the executives' and employees' mailboxes into separate SGs, you can restore the databases independently. Assuming that you have fewer executives than employees, you should be able to restore the executives' email access according to your SLA.

Microsoft's recommendation with the initial release of Exchange 2000 was to create the smallest number of SGs possible because each additional SG required a fixed allocation of between 100MB and 250MB of RAM—a significant amount at the time. Exchange 2000 Service Pack 3 (SP3) includes RAM allocation process modifications that dramatically reduce the amount of RAM required for additional SGs. Now, Microsoft's recommendation is to create as many SGs as possible. To draw on my earlier example, Microsoft recommends creating four SGs with one database each instead of one SG with four databases because each Exchange SG has its own set of logs. If you have only one database per SG, each database essentially has its own set of logs. This configuration simplifies and expedites disaster recovery because only one database's transaction logs must replay when you restore the database.

RAID
Once upon a time, administrators debated whether using RAID with Exchange was a good idea. That debate has long since been put to rest; administrators know that RAID can add a valuable degree of protection to Exchange data. Now the debate has turned to the type of RAID to use.

To determine which type of RAID to use, you need to remember that each RAID level balances performance against recoverability. What's good for one data type can be bad for another. Imagine a striped volume with two disks. Striping gives you great speed because applications can read from and write to all physical disks at the same time. But if you lose one disk in the stripe set you effectively lose the whole volume. This design might be acceptable in situations in which the performance boost would be beneficial but a transient disk failure wouldn't be the end of the world (e.g., for SMTP queues on a gateway machine). However, you'd have to be fairly risk-tolerant to put your databases on such a volume.

Microsoft's general recommendation is to use mirroring for data when protection is most important (e.g., transaction logs, the system volume). When data protection and access speed are both important, use either RAID 5 or RAID 0+1. If you have the budget, RAID 0+1 is preferable.

Logs and Databases
When you install or upgrade Exchange and accept the default log and database locations, all your Exchange data is stored on one volume. However, Microsoft has long recommended that you put transaction logs and databases on separate volumes because of the differences in their access patterns. Log files are always written to sequentially, and they're read (also sequentially) only during log playback. Databases are written to and read from in essentially random patterns, according to users' requests. Thus, putting your log files and databases on the same disk volume is a bad idea for two reasons: Doing so impairs performance and can compromise your ability to recover data in the event of a disk failure. These risks are present even if you're using RAID arrays instead of plain physical disks. Consider a case in which you have one large RAID 5 array with 10 disks that contains transaction logs and databases for two SGs. A better configuration from a performance and disaster recovery standpoint is to use two disks to make a mirrored volume for the transaction logs, dedicate seven disks for a RAID 5 array for the databases, and keep one unallocated disk as a hot spare. Depending on the database access patterns, you can also create separate RAID 5 volumes (each with its own set of physical disks) for the databases.

Keep in mind that online full backups remove the transaction logs. If you see a lot of log files after a backup finishes, you need to investigate because the backup wasn't successful. Never manually delete transaction log files without a good reason for doing so—such as if Microsoft Customer Service and Support (CSS) advises you to. Even then, you need to ensure that you have a current copy of the logs stored in a safe location before you delete them.

   Previous  [1]  2  Next