Table 24 Mailbox server role activities in Exchange 2007
Activity How activity affects disk I/O
ESE database (.edb file) The Mailbox server stores all mail in an ESE database. The ESE database is randomly accessed and uses an 8-KB page size, although I/O coalescing can result in larger I/Os. For reliability, and in some cases for performance reasons, the database should be on disks that do not contain transaction logs.
Transaction log files (.log files) All changes made to the database are first committed to the transaction log, which is a sequential write to the disk. The writes vary in size from 512 bytes to the log buffer size. Content indexing Content indexing is a random workload that
should be placed on the same LUN as your database and will typically be about 5 percent of the database size. Because content indexing runs in the background, indexing messages as they arrive, the disk I/O impact is minimal.
Paging If a process requests a page in memory and
the system cannot find the page at the requested location, a page fault occurs. If the page is elsewhere in memory, the fault is a soft page fault. If the page must be retrieved from disk, the fault is a hard page fault. Most processors can handle large numbers of soft page faults without consequence. However, hard page faults can cause significant delays. Continuous high rates of disk paging indicate a memory shortage.
Activity How activity affects disk I/O
Content conversion Most content conversion is done on the Client Access servers and Hub Transport servers. Legacy Web Distributed Authoring and Versioning (WebDAV) content conversion, for legacy Outlook Web Access clients, occurs on the Exchange 2003 Mailbox server. When a client requests data that must be converted on a Client Access server, the data is
accessed from the Exchange 2003 Mailbox server, converted in the Mailbox server's TMP folder, and sent to the Client Access server. To improve performance, the TMP folder should not be on the same LUN as the page file and operating system.
Database maintenance The Exchange 2007 information store requires periodic online maintenance to be run against each database. The two tasks that affect disk I/O are the hard deletion of messages and mailboxes that are older than the configured retention policy, and online defragmentation of the database. Because backup of a database will halt any online defragmentation of that database that might be taking place, care must be taken to give both backup and database maintenance exclusive windows of time to complete their tasks.
Activity How activity affects disk I/O
Backup and restore The process of backing up data requires that data be read from database and transaction log file volumes. This additional I/O can affect user response times and should be avoided during business hours. The process of soft recovery requires that the ESE play back all of the transaction log files. This causes the I/O profile to be a sequential read stream. As a result, the recovery performance improves if the transaction log files are on a disk with fast sequential disk access. One way to avoid this is to use continuous replication, which enables you to offload VSS-based backups from the active copy of the database to the passive copy of the database.
Backup
Backing up mailboxes requires careful planning. The following sections provide some considerations for VSS and streaming online backups. There are trade-offs in every solution that affect variables such as cost, time, and reliability. Most administrators define a time for online database maintenance, defragmentation, and operating system maintenance. These activities compete with the backup time. Special care is needed to balance backup,
maintenance, and production load. Larger mailboxes may make a daily full backup strategy impossible to complete within your SLA. A common strategy to lessen the impact of a full nightly backup is to perform weekly full backups and daily differential backups. With this strategy, you need to recover the full backup, and then recover the last differential backup. Volume Shadow Copy Service
For details about VSS fundamentals and VSS best practices for Exchange 2003, we recommend that you r major VSS-related considerations in Exchange 2007 that must be considered:
• Larger mailboxes
• Ability to back up a CCR and LCR copy
Although VSS backups can be made on either the production or copy data, we recommend that you back up the copy and avoid an impact to the production physical disks.
With LCR, Exchange 2007 is replicating transaction logs to a separate disk on the same server. When using VSS clones on the copy, the copy storage should be configured on different physical disks so that the clone operation and checksum integrity do not affect the production physical disks. With VSS snapshots on the copy, the copy storage should be configured on different physical disks so that the checksum integrity and subsequent streaming to tape do not affect your production physical disks.
With CCR, Exchange 2007 is replicating transaction logs to a separate server. This server is a node in the cluster, but the target copy is not kept on shared storage. When using VSS clones, you can run the checksum integrity on the copy on the passive node using different physical disks, thereby isolating the backup process. With VSS snapshots, the checksum integrity and subsequent streaming to tape will not impact your production server or physical disks.
Streaming Online Backup
Unlike hardware-based VSS backups, where the data is typically moved within the storage appliance, when using streaming backups, the server is responsible for moving your data. The performance impact of the checksum integrity process is not an issue because every page is checked during the backup. In the case of concurrent backups, multiple streams can stress the limits of your backup media, whether it is gigabit Ethernet or fiber channel attached tape. For many customers, the backup SLA window, divided by the throughput-per-minute of their streaming backup medium, limits the permissible size of the storage group. For
example, if you had a one hour SLA on your storage group, and you can back up 100 MB per second, your maximum storage group size would be 360 GB.