Making the Best Use of SAN/NAS Disks with Exchange Server 2010

SAN or NAS disks are generally more expensive than the disks used in DAS. As such, you can generally utilize the SAN/NAS storage only where it makes a significant difference in performance. Many aspects of Exchange Server 2010 utilize the disks but use them in different ways.

The largest consumer of disk performance is the Mailbox role. In Exchange Server 2010, it is common to run servers that are dedicated to doing nothing but hosting mailboxes. On these systems, several different consumers of disk resources would benefit from being placed on SAN or NAS, as discussed in the following sections.

Storage of Transaction Log Files (.log Files) and Database Files (.edb Files)

Changes made to the database are first committed to the transaction log. This results in a sequential write to the disk. Because sequential I/O is significantly higher per disk than random I/O, the logs do not benefit as much from being placed on SAN or NAS disks. For performance reasons and recoverability reasons, the logs should not be located on the same disks as the database. Similarly, the logs should not be on the same disk as the page file for the operating system.

To create a storage group with log files on a NAS or SAN disk, complete the following steps:

1.	From the Start menu, select All Programs, Microsoft Exchange, Exchange Management Console.
2.	Expand Organization Configuration, and then highlight Mailbox.
3.	From the Database Management tab, click New Mailbox Database.
4.	Enter the database name and browse to the server that will host it (see Figure 1). Click Next. Figure 1. New Mailbox Database Wizard.
5.	Click browse to choose the database path.
6.	Navigate to the drive letter representing the SAN/NAS disk, and click OK.
7.	Click browse to choose the log folder path.
8.	Navigate to the drive letter representing the SAN/NAS disk, and click OK.
9.	Click Next.
10.	Click New to trigger the creation of the mailbox database.

Performing Content Indexing

The Search features have been significantly improved in Exchange Server 2010. Content indexing is a random access workload that should be placed on the same LUN as the database that it is indexing. Content indexing is usually approximately 10% of the database size. Exchange Search (formerly known as Content Indexing) runs in the background, indexing messages as they arrive and, as such, the disk I/O impact is minimal.

Exchange Search is enabled by default on all databases; to manage content indexing, perform the following:

1. From the Start menu, click Programs, Microsoft Exchange, Exchange Management Shell.

2. From the Exchange Management Shell, type the following:

   Set-MailboxDatabase -Identity <Database Name> -IndexEnabled:$false|$true

3. Press Enter.

When a process requests a page from 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. If memory cannot be increased sufficiently to reduce the number of hard page faults, you must improve the speed of the disks that host the page file. In this scenario, the page file location could benefit from the improved performance of a SAN or NAS disk.

If you want to move your page file to a SAN or NAS attached disk, perform the following steps:

1.	Right-click My Computer and select Properties on the shortcut menu.
2.	Click the Advanced System Settings task.
3.	In the Performance section, click Settings.
4.	From the Performance Options pane, click the Advanced tab.
5.	Near the bottom of the pane in the Virtual Memory section, click Change.
6.	Uncheck Automatically Manage Paging File Size for All Drives.
7.	Highlight the drive letter that represents the disk that should host the page file.
8.	Click the Custom Size option button.
9.	Enter an initial size of 1.5*system memory.
10.	Enter a maximum size of 1.5*system memory, and then click Set.
11.	Highlight the drive letter that previously held the page file.
12.	Click the No Paging File option button, and then click Set.
13.	Click Yes to accept the warning about the page file on the volume you are modifying, and then click OK.
14.	Click OK again to accept the notification that you need to reboot for the settings to take effect.
15.	Click OK twice to close the dialog box.
16.	Click Yes to reboot if it is acceptable to reboot the system.

You might wonder why the page file was configured with the same value for initial and maximum sizes. By setting the range to a single value, the page file is initially created at a size that will never change. This allows the page file to be contiguous on the drive. A page file that is allowed to grow might grow to a new location on the hard drive. This results in fragmentation of the page file and causes a reduction in page file performance.

In Exchange Server 2010, significant improvements have been achieved in memory management because of the use of 64-bit code. This enables you to install enough memory to greatly reduce the need for the system to page to disk.

Content Conversion

Most content conversion performed in an Exchange Server 2010 environment is performed by the client access servers (CASs) and the Hub Transport servers. Legacy WebDAV content conversion, for legacy Outlook Web Access (OWA) clients, occurs on the Exchange 2010 mailbox server. When a client needs data that must be converted on a CAS, the data is pulled from the Exchange 2010 mailbox server, converted in the Exchange Server 2010 mailbox server’s TMP folder, and sent to the CAS. To improve performance, the TMP folder should not be on the same LUN as the page file and operating system. If there is a large amount of legacy OWA clients supported, placement of the TMP folder on a NAS or SAN disk might result in improved performance.

Performing Database Maintenance

The Exchange Server 2010 Information Store performs periodic online maintenance against each database. The two tasks that impact disk I/O are the hard deletion of messages and mailboxes that are past their retention policy and online database defragmentation. Because a backup job will halt online defragmentation, you must be sure to give both database maintenance and backup jobs exclusive windows of time to finish their tasks or disk contention will result in greatly reduced performance for both tasks. If you cannot sufficiently separate these two events, the increased I/O load would benefit from the databases being located on SAN or NAS disks.

Backing Up and Restoring Data

Backing up data requires that data be read from both the database and transaction log volumes. This additional I/O can impact user response times and should be avoided during business hours. Placing the databases and log files on faster SAN or NAS disks can often result in faster backup and restore processes, assuming the destination location for the data is not the bottleneck. Backups that attach to the SAN or NAS directly are usually much faster than backing up Exchange Server 2010 via the network with an Exchange Server agent. Backups that are performed at the storage itself, usually called snapshots, can occur in literally seconds.

The process of performing a soft recovery in the case of a database restore requires that the JET engine plays back all the transaction log files. This results in a sequential read stream from the disks containing the associated log files. As a result, the recovery process can be faster if the transaction log files are on a disk with fast sequential disk access, such as SAN or NAS.

In addition to having similar needs for content conversion and paging, CASs also consume disk I/O in the process of protocol logging.

Enabling Protocol Logging

Protocol logging, if enabled, results in a sequential write that is a performance hit and consumes disk space to store the logs. Protocol logging is typically used to verify the performance of a given protocol or when you suspect attacks from the Internet.

Impact from Message Tracking Logs

Edge and Hub Transport servers maintain message tracking logs that result in sequential write traffic for the log files. Because sequential write performance is much higher than random access, these types of logs typically don’t require high-performance disks.

Conversion of Incoming Mail

The Hub Transport server converts incoming mail into a Messaging Application Programming Interface (MAPI) format. This occurs in the TMP directory of the Hub Transport server. As such, it is important to ensure that the TMP directory is not located on the same LUN as the page file or the operating system. In environments that receive large amounts of Internet mail, it is beneficial to place this TMP directory on a SAN or NAS attached disk.

Events Trigged by Agents

Customization of the Transport server is done via bits of code more commonly referred to as agents. These agents run in the common language runtime environment and are triggered by specific events. Some agents write data to a log, which can result in a disk performance hit in addition to consuming disk space. If you find your environment taking performance hits because of agents, consider configuring them to place their logs on higher-performance NAS or SAN disks.