Exchange Storage Ins and Outs

Circular Logging
Circular logging is a poorly understood Exchange feature that many administrators dismiss as inherently risky—with good reason. When you enable circular logging, Exchange limits the total amount of disk space it uses for transaction logging by overwriting previously created transaction logs after a backup finishes. Although this method makes sense in theory, in practice it means that you might not have a complete set of logs for a particular database—which means that you can't fully recover the database in the event of a failure.

A couple of situations exist in which you might want to enable circular logging for an SG. One case is on front-end SMTP servers. The Exchange 2003 SMTP service requires that you have a mailbox database mounted so that it can generate nondelivery reports (NDRs). Over time, that database accumulates transaction logs unless you enable circular logging. Another situation that calls for circular logging is if you're performing a task that generates a high number of transactions. For example, suppose you need to move 500 mailboxes from one server to another overnight. Doing so will generate a volume of transaction logs on the two servers approximately equal to the volume of mail being moved—a substantial amount. To solve this problem, perform full backups of both servers, then enable circular logging on the SG from which you're moving the mailboxes. You might also want to enable circular logging on the target server, although leaving it off is the safer option. In most other situations, leave circular logging off to avoid overwriting transaction data that you might need later.

SANs
SANs offer some powerful Exchange storage benefits. Having a flexible storage system that lets you allocate and reallocate space on the fly is useful in itself. In addition, being able to logically reassign and move volumes between hosts lets you take full advantage of clustering, point-in-time copies, and other technologies that depend on or benefit from SANs.

However, SANs also introduce some additional storage variables, most of which are specific to the SAN vendor. For example, the way in which a SAN controller allocates physical disks to logical volumes varies among vendors. Some vendors suggest that when you create an aggregate volume, you put as many disks in it as possible; others don't. Some vendors have transparent support for reallocating storage on hot spots; others don't. You need to know and understand your SAN vendor's recommendations for how to allocate and provision Exchange storage. A strategy that works well for one SAN vendor's system might not work for another's.

In general, vendor recommendations follow the Microsoft recommendations I've discussed. The most common discrepancies are regarding the size and type of disks to use for a particular configuration, and RAID design and allocation (e.g., Network Applicance's—NetApp's—filers typically use RAID 4 rather than RAID 5). Before you commit Exchange mailboxes to a SAN setup, use the Microsoft Jetstress tool (jetstress.msi) to evaluate the setup's performance. To download this tool, go to http://www.microsoft.com/downloads/details.aspx?familyid=94b9810b-670e-433ab5ef-b47054595e9c&displaylang=en. In addition, involve your SAN vendor's engineers to ensure that your SAN design and layout are appropriate for your Exchange requirements. Doing so will help protect you against unpleasant and potentially expensive surprises as your storage requirements grow.

Make the Best of Change
Exchange storage technologies have changed significantly in the 10 years since Exchange first shipped. Knowing how to make the best of those changes will help you effectively design and operate an Exchange system that offers superior reliability and performance. For more information about Exchange storage and design, see the resources listed in the Learning Path box.