SUMMARY
For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
839687
Microsoft support policy on the use of network-attached storage devices with Exchange Server 2003
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:
317172
Exchange Server 5.5 and network-attached storage
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:
314916
Issues that might occur if you place Exchange data files on network shares
MORE INFORMATION
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:
314917
Understanding and analyzing -1018, -1019 and -1022 Exchange database errors
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:
311898
Hot
split snapshot backups of Exchange
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.