Exchange Server and network-attached storage

For additional information, click the following article number to view the article in the Microsoft Knowledge Base: For additional information about this subject in Microsoft Exchange Server 5.5, click the following article number to view the article in the Microsoft Knowledge Base:

Executive Summary

Microsoft recommends Direct Attached Storage (DAS) or Storage Area Network (SAN)

Microsoft generally recommends that you use a DAS or SAN attached disk storage system (for example, small computer system interface [SCSI], Fiber Channel, or integrated device electronics [IDE]) to store your Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003 database files, because this configuration optimizes performance and reliability for Exchange Server.

Microsoft does not support network-attached storage

If access to a disk resource requires that a share be mapped, or if the disk resource appears as a remote server by means of a Universal Naming Convention (UNC) path (for example, \\servername\sharename) on the network, the disk storage system is not supported as a location for Exchange Server databases.

Microsoft only supports using Microsoft Windows Hardware Quality Labs (WHQL) qualified storage devices with Exchange 2003. Exchange 2003 addresses a number of issues that prevent earlier versions of Exchange from being used in conjunction with network-attached storage devices. With these changes, you can host Exchange 2003 database files on network-attached storage devices, but any solutions that provide this capability must also provide additional functionality to fully enable the solution. This includes manually moving the Exchange database files to the device because the Exchange 2003 System Manager tool does not support moving database files to a remote file system.

Special consideration about backup and restore

Several network-attached storage and SAN solution providers have bypassed the Exchange Server online backup API to provide specialized out-of-band or very fast backup and restoration functionality. These backups are known generically as "snapshot" backups. At the time of this article's publication, vendors that implement custom snapshot solutions must make sure independently that they back up and synchronize all the appropriate Exchange Server data files, and that they capture those data files in the correct state. These processes might cause issues with the reliability and consistency of the databases.

Using block storage devices that are qualified to use the "Designed for Windows" logo with Exchange Server

Block mode storage devices that have received a Designed for Windows logo through submission to Windows Hardware Quality Labs (WHQL) as "Storage/Raid controller" or "Storage/RAID system" have been shown to meet the requirements for block storage for the Windows platform and are therefore the most suitable storage devices for use with Exchange Server.

Some storage devices can expose both files and blocks (also called logical units). For these storage devices, if a logical unit is exposed through a Fiber Channel or parallel SCSI interface, and the device has the Designed for Windows logo, Microsoft provides support. Microsoft does not add logos to or provide support for storage that is exposed as a file system (network-attached storage).

Currently, only DAS systems and SAN storage systems meet this requirement. For non-clustered Exchange Server solutions that use DAS or SAN, Microsoft will support the Exchange program and the Exchange data (but not the storage device or data issues\corruption caused by the storage device, which is the responsibility of the storage device vendor).

Support of clustered Exchange Server solutions is addressed below under the "Clustering" heading.

Using block storage devices that are not qualified to use the "Designed for Windows" logo with Exchange Server

Microsoft does not support the use of non-WHQL qualified storage devices with Exchange Server.

Note The Internet engineering task force (IETF) is working to specify an iSCSI standard. Microsoft anticipates that it will support the iSCSI Standard within 90 days of its ratification by the IETF and that a WHQL program will be implemented for devices that implement the final iSCSI standard (although Microsoft cannot guarantee that such support will be offered or that such WHQL program will be created).

Using network-attached storage with Exchange Server

A network-attached storage system is a file-based storage system that can be attached to an Exchange Server computer through the network redirector by using a file sharing protocol (such as server message block [SMB], Common Internet File System [CIFS], or network file system [NFS]). If access to a disk resource requires that a share be mapped, or if the disk resource appears as a remote server by means of a Universal Naming Convention (UNC) path (for example, \\server_name\share_name) on the network, the disk storage system is not supported as a location for Exchange Server databases. Since network-attached storage devices use this form of file redirection, use of network-attached storage with Exchange Server is not supported by Microsoft.

For additional information about specific errors and settings associated with placing Exchange data files on network-accessed disks, click the following article number to view the article in the Microsoft Knowledge Base:

The Exchange Server computer requires access to physical disk characteristics that are only available on channel attached disks. These physical disk characteristics are not available when storing exchange databases on network file shares.

For a specified storage system, accessing Exchange Server database files through the network stack (as opposed to accessing the storage system as a local device) might result in some increased risk of data corruption and performance degradation.

The chance that such problems may occur increases as disk operations increase in input/output (I/O) bandwidth requirements and complexity. The level of risk and loss of performance varies by device, protocol, network congestion, and configuration. As network bandwidth, latency, data access protocols, and storage technologies continue to evolve, the gap continues to reduce between the performance and reliability that is attainable with locally attached devices versus network-attached devices.

However, this important principle remains: the disk system that is used to store Exchange Server data must be accessible with all the features, protocols, application programming interfaces (APIs), and access methods that are available on a locally attached block mode Microsoft Windows volume, regardless of physical disk locations or underlying disk access technologies and protocols.

You must consider the following issues when you select a disk system and disk access technology for Exchange Server, or any enterprise-level database management system (DBMS).

Performance

Exchange Server, like other enterprise messaging systems, can add an extremely large load on the disk I/O subsystem. In most large database programs, physical I/O configuration and tuning play a significant role in overall system performance. There are three major I/O performance factors to consider:

• I/O bandwidth - The aggregate bandwidth, typically measured in megabytes per second, that can be sustained to a database device.
• I/O latency - The latency, typically measured in milliseconds, between a request for I/O by the database system and the point at which the I/O request completes.
• CPU cost - The host CPU cost, typically measured in CPU microseconds, for the database system to complete a single I/O.

Any of these I/O factors can become a bottleneck, and all these factors must be considered when designing an I/O system for a database program.

If disk I/O is processed through the client network stack, the I/O is subject to the bandwidth limitations of the network itself. Even when you have enough overall bandwidth, you may have issues of greater latency and increased processing demands on the CPU, as compared to locally attached storage. Additionally, consider the availability of the network-attached storage when you plan an Exchange deployment in which the storage is attached by using a network. Microsoft recommends you protect the Exchange Server, the storage system, and the connecting network with a UPS.

Microsoft recommends that you contact your vendor before you deploy any storage solution for Exchange Server databases, to obtain assurance that the end-to-end solution is designed for Exchange Server use. Many vendors have best practices guides for Exchange Server.

Microsoft also recommends that you benchmark your I/O performance to make sure that none of the I/O factors that are described earlier are causing system bottlenecks.

Reliability

Exchange Server uses a transaction log and associated recovery logic to make sure that there is database consistency if a system failure or an unmanaged shutdown occurs. When the database manager writes to its transaction logs, the database manager must depend on the return of a successful completion code from the operating system as a guarantee that the data has been secured to disk, not just to a volatile cache that will be lost if there is a system failure.

Additionally, the limits of recoverability are determined by the ability of the disk system to make sure that data written to the disk is stored and retrieved reliably. Microsoft recommends that you use disk systems that can detect imminent failures and salvage or relocate affected data when you use Exchange Server.

Microsoft continues to work with other vendors to identify and resolve problems that affect the integrity and recoverability of Exchange Server data. Exchange Server includes several internal mechanisms for detecting and isolating file-level damage to an Exchange Server database. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

Special program requirements

The list of requirements for Exchange Server that this section describes is not a complete list. Please see the vendor documentation and Microsoft deployment guides for more comprehensive and up-to-date information.

Exchange Server program-specific considerations

Exchange Server makes use of an Installable File System (IFS) driver that requires access to physical disk characteristics that are reported by block mode storage devices. The IFS driver is an integral part of Exchange Server architecture and is used by internal Exchange processes for message delivery. Because of this dependency, if Exchange Server databases are stored on a device that does not appear to the Windows operating system as a block mode storage device, Exchange Server databases do not mount.

Earlier versions of Exchange Server (earlier than Exchange 2000) do not include an IFS driver; because of this, the requirement for block mode storage devices does not apply to those versions.

Backup and restoration

The Exchange Server online backup API automatically synchronizes and gathers the Exchange Server database and transaction log file data that is required for successful restoration. For fault tolerance and performance reasons, Exchange Server transaction logs are typically stored on drives that are separate from the database files.

Online backup of Exchange Server databases occurs through the same channel as typical database access. If this access is across the network, backup and restoration operations might greatly increase peak bandwidth requirements.

Several network-attached storage and SAN solution providers have bypassed the Exchange Server online backup API to provide specialized out-of-band or very fast backup and restoration functionality. These backups are known generically as "snapshot" backups. At the time of this article's publication, vendors that implement custom snapshot solutions must make sure independently that they back up and synchronize all the appropriate Exchange Server data files, and that they capture those data files in the correct state. These processes might cause issues with the reliability and consistency of the databases. Vendors that implement this approach must confirm that they can make sure that all data integrity is maintained.

For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

Clustering

Microsoft recommends that storage systems for Exchange Server data on clustered servers be qualified for cluster implementations and designed to support Exchange Server data. A storage system that might perform well with Exchange Server in a non-cluster environment might not be suitable for use in a cluster. To obtain support for clustered configurations, the whole cluster must be listed on the Cluster HCL.

Exchange Server requires that messaging databases be stored on storage volumes that are recognized and registered with the Microsoft Cluster service cluster administrator.

Supportability

Incorrect use of Exchange Server software with a network-attached storage product might result in data loss, including total database loss.

Microsoft recommends that you contact your vendor before you deploy any storage solution for Exchange Server databases, to obtain assurance that the end-to-end solution is designed for Exchange Server use. Many vendors have best practices guides for Exchange.