This week, I have more information about Exchange Server storage. First, I have an update to my recent commentary about Exchange Server 2003 support for the Internet SCSI (iSCSI) protocol. (You can read this commentary, "iSCSI Support for Exchange," at http://www.winnetmag.com/windows/article/articleid/42135/42135.html .) I wrote that the Windows Catalog didn't currently list any iSCSI devices supported for use with Exchange 2003. However, Claude Lorenson, program manager for iSCSI support at Microsoft, confirmed that the devices labeled “Designed for Windows XP” in the catalog are also certified for use with Exchange, even though they don't yet display the new “Designed for Windows” logo that the original Microsoft press release specified as a requirement. He also confirmed that no separate certification process is required for Exchange compatibility, although many vendors are choosing to perform their own compatibility tests. This clarification is good news if you’re thinking about deploying iSCSI--take a look at the Windows Catalog to find a wealth of supported devices. According to Lorenson, many customers are already using iSCSI Storage Area Networks (SANs) with Exchange 2003 in their production environments.
In more storage news, this week Microsoft released a new article--"Microsoft support policy on the use of network-attached storage devices with Exchange Server 2003" ( http://support.microsoft.com/?kbid=839687 )--describing its support policy for Network Attached Storage (NAS) devices and Exchange 2003. This policy is fairly straightforward: Only NAS devices certified by the Windows Hardware Quality Labs (WHQL) are supported for use with Exchange. The same is true for block-mode storage devices, regardless of how those devices attach to the server. The article makes some other points that are worthy of discussion:
- Some solutions rely on host CPU processing. In particular, NAS solutions that rely on adding redirectors to the Exchange server’s network stack to send and receive data might experience higher I/O latency. Although the article doesn’t explicitly say so, using IP Security (IPSec), as you probably should do for IP SAN deployments, can exacerbate the problem. You might get some relief by using NICs or iSCSI host bus adapters (HBAs) that offload IPSec processing from the host CPU; generally, the additional CPU overhead isn't a problem on servers that have adequate headroom.
- For NAS or iSCSI deployments that use network switches, put those switches (and any other network equipment between host and target) on a UPS--otherwise, the path between the storage and Exchange servers will be vulnerable to failure during power outages.
- If you want to use clustering, ensure that your entire cluster system--including all cluster nodes and the storage system--appears on the Microsoft cluster Hardware Compatibility List (HCL). Building an ad hoc cluster out of parts that are WHQL-certified isn't the same as building a cluster from components listed on the cluster HCL.
- Verify that your Exchange storage system is designed for use with Exchange 2003 and is set up according to the storage vendor’s best practices. Don't be shy about asking the vendor for assistance gathering this information.
Two other Microsoft articles describe the NAS and SAN support policies for earlier Exchange versions. Regarding Exchange 2000 Server, "XADM: Exchange Server and Network-Attached Storage" ( http://support.microsoft.com/?kbid=317173 ) says NAS devices are supported only if they operate in block mode. Devices that provide access through file shares (either as mapped drives or through UNC paths) are explicitly not supported, even though some vendors provide support for their devices when used with Exchange. For Exchange Server 5.5, "XADM: Exchange Server 5.5 and Network-Attached Storage" ( http://support.microsoft.com/?kbid=317172 ) says Microsoft supports the use of networked servers or NAS devices as long as the storage device or server is WHQL-certified. If you use an uncertified device that meets the I/O requirements that the article describes, Microsoft will support Exchange but won't assist you with any problems that the NAS device causes--you'll have to go to the vendor for help.
Why the difference in support between the two earlier versions of Exchange? Exchange 2000 uses an Installable File System (IFS) driver to provide logical access to items in the database, and the driver--known as the Exchange IFS (ExIFS)--requires a block-mode storage device. Exchange 5.5 doesn’t use an IFS driver, so it doesn’t matter whether the underlying volumes are shared over the network as long as there is sufficient network bandwidth and low enough latency.
When properly designed and deployed, NAS and SAN devices can provide welcome improvements for your Exchange servers. As with every storage technology, you need to balance acquisition and operation costs, security, scalability, recoverability, and supportability to find the best vendors and technologies for your environment.
