Here are five capacity planning best practices for optimising the performance of your Exchange infrastructure.
1) 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.
2) 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.
Microsoft System Center Data Protection Manager (DPM) is an alternative backup solution that works well with Exchange 2007. DPM can either save a VSS copy of data immediately, or manually copy data to DPM volumes. Once DPM has synchronized the entire Exchange database and transaction logs, it can make an “Express Full” backup that updates only the changes. This results in a much faster backup that is as reliable as a classic full backup.
3) Capacity planning for mobile devices: While mobile devices improve user productivity they present a unique challenge to capacity planners because of their resource requirements. For example, an average Research in Motion BlackBerry Exchange user requires nearly four times the server performance as an ordinary Exchange mailbox user.
In addition to increased performance, mobile devices introduce a data control issue: you must know where all Exchange Personal Store (PST) files are located for your entire organization, know who regularly stores PSTs, and have a plan to control PST usage. The best approach is to implement a PST control policy to document where these files are stored. This should be addressed in the planning phase, because uncontrolled content could create a problem in the event of legal discovery or other proceedings.
4) Business continuity and disaster-recovery planning: To implement a business continuity solution for Exchange it's best to work backwards. First, establish your service-level agreement (SLA) and determine how long your organization can function without access to e-mail data. Next, calculate how quickly you can restore from your chosen backup solution (disk or tape), and design your solution around these variables. Don't make the mistake of basing your business continuity assumptions on disk size instead of the organization's disaster-recovery needs.
When making disaster-recovery planning decisions, figure out the Recovery Time Objective (RTO) — that is, how long the business can function without access to data in case of disaster. Also, determine how much of the overall messaging solution might be negatively impacted by data loss, and conversely, how much of the messaging project budget can be dedicated to business continuity. This will help determine RTO, which normally spans one to 12 hours. As expected, solutions with shorter RTOs cost significantly more than those with longer RTOs.
Test the solution by running a fire drill a few times each year by replicating the restore process to make sure it works properly and quickly enough. Assess whether the solution can meet the SLA time requirements of X hours, document the results, and outline the steps required for a real-life disaster-recovery operation.
5) Compliance: archiving and journaling: There are three core purposes for archiving: storage cost reduction, compliance and the creation of a bottomless inbox experience for the user. A well-architected archiving policy can save thousands of dollars in storage and licensing costs. For compliance, this can be a high-impact feature for Exchange in order to adhere to corporate and regulatory policies. It is critical to understand exactly which regulations apply to e-mail within the organization, because proper storage management (archiving, backup and journaling) can save time and legal costs. While the bottomless inbox feature is nice to have from a user perspective, it has little impact on business functionality.
Archive solutions — those that replace archived content with a stub reference that has a reduced impact on performance — can help when used with proper planning and design. While there have historically been problems associated with archiving large-count mailboxes in Outlook, Outlook 2007 SP2 has adequately addressed these problems. Archiving in Exchange is often as simple as enabling message or envelope journaling, and then periodically moving the journaling mailbox to an offline archive. Once the required retention period has elapsed, purge the content to limit the strain on your resources.
Careful planning of the Exchange server environment will always pay valuable dividends, particularly with regard to archiving and journaling. Using these five best practices for Exchange will help maintain a balance between the user experience, budget and legal/compliance requirements within an organization, while significantly reducing e-mail service interruptions.
