Capacity Planning for Exchange
Microsoft Exchange e-mail systems have emerged as the de facto communication and collaboration tool for today's organizations. However, keeping Exchange running smoothly can be a headache, especially when capacity needs and performance requirements conflict. Here are five capacity planning best practices for optimizing the performance of your Exchange infrastructure.
Mon, July 13, 2009
Network World — Microsoft Exchange e-mail systems have emerged as the de facto communication and collaboration tool for today's organizations. However, keeping Exchange running smoothly can be a headache, especially when capacity needs and performance requirements conflict. Here are five capacity planning best practices for optimizing the performance of your Exchange infrastructure.
* Database and storage sizing: It is critical to start with an assessment of whether you have enough space to store all the data. If a database logical number unit (LUN) runs out of space, the connected databases will “dismount”. Generally speaking, running out of disk space will result in an e-mail service interruption that exceeds most organizations' recovery time objectives.
Next, limit the amount of data users are allowed to store in their mailboxes. This helps to determine how many users each server can support. Without mailbox space limits, it is difficult to estimate capacity requirements. As users approach their mailbox quota, an equivalent amount of mail must be deleted. This forces growth to be split between the database dumpster and the mailbox.
Another important consideration is controlling database whitespace. Having 50% or more of whitespace will significantly slow down performance, but it's not a problem when users are not near their mailbox quotas. To keep whitespace from growing beyond appropriate limits, online maintenance must be able to complete a full pass at least once per week. To accomplish this, enough time must be allocated to enable online maintenance to run nightly.
While smaller databases are quicker to back up and restore than large databases, you can minimize the complexity of the latter by limiting the number of databases and LUNs to manage. Exchange 2007 can support a maximum of 50 databases per server, and Microsoft recommends 200GB for each database. However, since 200GB databases can be unwieldy and difficult to manage, using 100GB databases with continuous replication is a better option.
* Planning for backup and restore: To limit data loss, it is best to perform a full online backup every day. With Exchange 2007, administrators can perform a streaming online backup to a disk or use the Volume ShadowCopy Service. Because streaming online backup requires high throughput to copy data to/from LUNs, it often requires very fast hardware to complete a backup within a few hours. So while streaming backup is feasible, using the Volume ShadowCopy Service (VSS) for backing up Exchange is more practical.
The VSS is used by Exchange 2007 to make volume shadow copies of databases and transaction log files. It can take snapshots of either the production copy or the passive copy. Taking VSS snapshots of the passive copy minimizes the load on the production LUN during checksum integrity as well as the subsequent copying to tape or to disk. This frees up time on the production LUNs to run online maintenance or do other tasks.
